Re: [petsc-users] On the edge of 2^31 unknowns

Sometimes when we do not have exact counts, we need to overestimate sizes. This is especially true in sparse MatMat. Matt On Mon, Nov 16, 2015 at 9:38 AM, Eric Chamberland < eric.chamberl...@giref.ulaval.ca> wrote: > Hi, > > we just tried this morning to solve a 1.7 billion dofs problem (on

[petsc-users] On the edge of 2^31 unknowns

Hi, we just tried this morning to solve a 1.7 billion dofs problem (on 1060 processors task) . Unfortunately, petsc-3.5.3 didn't succeed within a MatMatMult product with the following backtrace: [0]PETSC ERROR: Out of memory. This could be due to allocating [0]PETSC ERROR: too large an

Re: [petsc-users] SuperLU_dist computes rubbish

Barry: > $ ./ex10 -pc_type lu -ksp_monitor_true_residual -f0 ~/Downloads/mat.dat > -rhs ~/Downloads/rhs.dat -ksp_converged_reason > Linear solve did not converge due to DIVERGED_NANORINF iterations 0 > Number of iterations = 0 > Residual norm 0.0220971 > Hmm, I'm working on it, and forgot to

Re: [petsc-users] SuperLU_dist computes rubbish

On Sun, 15 Nov 2015 21:41:49 -0600 Barry Smith wrote: > $ ./ex10 -pc_type lu -ksp_monitor_true_residual -f0 > ~/Downloads/mat.dat -rhs ~/Downloads/rhs.dat -ksp_converged_reason > Linear solve did not converge due to DIVERGED_NANORINF iterations 0 > Number of iterations = 0

Re: [petsc-users] shared components for real- and complex-scalar builds

On Mon, Nov 16, 2015 at 5:37 AM, Marco Zocca wrote: > Currently, I'm re-building fblaslapack and mpich along with PETSc for both > cases, but would it be possible to share either between the two builds? > If you build them yourself with the same compilers, independent of

Re: [petsc-users] shared components for real- and complex-scalar builds

> On Nov 16, 2015, at 6:24 AM, Matthew Knepley wrote: > > On Mon, Nov 16, 2015 at 5:37 AM, Marco Zocca wrote: > Currently, I'm re-building fblaslapack and mpich along with PETSc for both > cases, but would it be possible to share either between the

Re: [petsc-users] GAMG and zero pivots follow up

Mark Adams writes: >> Yikes! I did not check that. Why do we have PRECONDITIONED as the default >> for CG? That is the preconditioned norm of the residual. I.e., || M^{-1} (A x - b) ||_2 > The two norm of the residual (ie, natural, right?) is not monotone either > in CG.

Re: [petsc-users] Using STRUMPACK within PETSc

Dear Satish, That totally did the trick ! Thanks a lot:-) Niels Fra: Satish Balay [ba...@mcs.anl.gov] Sendt: 16. november 2015 18:21 Til: Niels Aage Cc: petsc-users@mcs.anl.gov Emne: Re: [petsc-users] Using STRUMPACK within PETSc >From

Re: [petsc-users] On the edge of 2^31 unknowns

On 16/11/15 10:42 AM, Matthew Knepley wrote: Sometimes when we do not have exact counts, we need to overestimate sizes. This is especially true in sparse MatMat. Ok... so, to be sure, I am correct if I say that recompiling petsc with "--with-64-bit-indices" is the only solution to my problem?

Re: [petsc-users] Using STRUMPACK within PETSc

>From STRUMPACK-Dense-1.1.1/src/StrumpackDensePackage_C.cpp > /* This C++ file implements the functions of the C interface. */ #include "StrumpackDensePackage.hpp" extern "C" { #include "StrumpackDensePackage.h" << So looks like you have to use StrumpackDensePackage.h with

Re: [petsc-users] On the edge of 2^31 unknowns

Barry, I can't launch the code again and retrieve other informations, since I am not allowed to do so: the cluster have around ~780 nodes and I got a very special permission to reserve 530 of them... So the best I can do is to give you the backtrace PETSc gave me... :/ (see the first post

Re: [petsc-users] On the edge of 2^31 unknowns

Eric, The behavior you get with bizarre integers and a crash is not the behavior we want. We would like to detect these overflows appropriately. If you can track through the error and determine the location where the overflow occurs then we would gladly put in additional checks and

Re: [petsc-users] On the edge of 2^31 unknowns

I looked into the code of PetscLLCondensedCreate_Scalable: ... ierr = PetscMalloc1(2*(nlnk_max+2),lnk);CHKERRQ(ierr); ... and just for fun, I tried this: #include int main() { int a=1741445953; // my number of unknowns... int b=2*(a+2); unsigned long int c = b; std::cout << " a: "

Re: [petsc-users] GAMG and zero pivots follow up

On Fri, Nov 13, 2015 at 2:48 PM, Matthew Knepley wrote: > On Fri, Nov 13, 2015 at 12:28 PM, Jed Brown wrote: > >> Matthew Knepley writes: >> > Something very strange is happening here. CG should converge >> monotonically, >> > but above

Re: [petsc-users] On the edge of 2^31 unknowns

Barry Smith writes: >> On Nov 16, 2015, at 2:41 PM, Jed Brown wrote: >> >> Barry Smith writes: >>> Out goal is that if something won't fit in a 32 bit int we use a 64 >>> bit integer when possible or at least produce a very useful

Re: [petsc-users] On the edge of 2^31 unknowns

ah yes, and we have a bunch of those 2's running around > On Nov 16, 2015, at 2:53 PM, Jed Brown wrote: > > Barry Smith writes: > >>> On Nov 16, 2015, at 2:41 PM, Jed Brown wrote: >>> >>> Barry Smith writes:

Re: [petsc-users] On the edge of 2^31 unknowns

> On Nov 16, 2015, at 2:41 PM, Jed Brown wrote: > > Barry Smith writes: >> Out goal is that if something won't fit in a 32 bit int we use a 64 >> bit integer when possible or at least produce a very useful error >> message instead of the horrible

Re: [petsc-users] On the edge of 2^31 unknowns

Le 2015-11-16 15:46, Barry Smith a écrit : On Nov 16, 2015, at 2:41 PM, Jed Brown wrote: Barry Smith writes: Out goal is that if something won't fit in a 32 bit int we use a 64 bit integer when possible or at least produce a very useful error

Re: [petsc-users] On the edge of 2^31 unknowns

Barry Smith writes: > Out goal is that if something won't fit in a 32 bit int we use a 64 > bit integer when possible or at least produce a very useful error > message instead of the horrible malloc error you get. The more > crashes you can give us the quicker we can

Re: [petsc-users] On the edge of 2^31 unknowns

Eric Chamberland writes: > int main() { >int a=1741445953; // my number of unknowns... >int b=2*(a+2); >unsigned long int c = b; >std::cout << " a: " << a << " b: " << b << " c: " << c <return 0; > } > > and it gives: > > a:

Re: [petsc-users] On the edge of 2^31 unknowns

> On Nov 16, 2015, at 12:26 PM, Eric Chamberland > wrote: > > Barry, > > I can't launch the code again and retrieve other informations, since I am not > allowed to do so: the cluster have around ~780 nodes and I got a very special > permission to reserve

Re: [petsc-users] On the edge of 2^31 unknowns

On 16/11/15 03:22 PM, Barry Smith wrote: Out goal is that if something won't fit in a 32 bit int we use a 64 bit integer when possible or at least produce a very useful error message instead of the horrible malloc error you get. The more crashes you can give us the quicker we can fix

Re: [petsc-users] On the edge of 2^31 unknowns

I have started a branch with utilities to help catch/handle these integer overflow issues https://bitbucket.org/petsc/petsc/pull-requests/389/add-utilities-for-handling-petscint/diff all suggestions are appreciated Barry > On Nov 16, 2015, at 12:26 PM, Eric Chamberland >

[petsc-users] shared components for real- and complex-scalar builds

Currently, I'm re-building fblaslapack and mpich along with PETSc for both cases, but would it be possible to share either between the two builds? Thank you, Marco

[petsc-users] Fwd: funny kids on Jimmy Kimmel

My daughter sent me this fun youtube, enjoy :-D with Hillary Clinton! https://www.youtube.com/watch?v=db94fvXK2ww

[petsc-users] Fwd: IDEAS Project xSDK documents open for comment

PETSc users and developers, For your information. Please comment if you have suggestions for improvement. Barry > > > From: Michael A Heroux > > Date: Thursday, November 12, 2015 at 2:53 PM > To: Trilinos Users

Re: [petsc-users] CG+GAMG convergence issues in GHEP Krylov-Schur for some MPI runs

Hi Mark, > On 12 Nov 2015, at 21:16, Mark Adams wrote: > > There is a valgrind for El Capitan now and I have it. It runs perfectly > clean. Do you compile it yourself or use Homebrew / MacPorts? I always seem to have some noise it valgrind at least from OpenMPI (even with