March 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] making BuildSystem hard to debug
by Matthew Knepley 21 Mar '12

21 Mar '12

On Wed, Mar 21, 2012 at 11:57 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Wed, Mar 21, 2012 at 11:46, Matthew Knepley <knepley(a)gmail.com> wrote: > >> The compile routine does not decide whether to crash, so I had >> configure.py dump these headers if there was an exception. I >> can test it later today. >> > > When a test fails, why doesn't it wrap the whole test case up in the > exception object. If that exception is not caught, it prints a summary and > places the complete test case in configure.log? > I am not sure what you mean "wrap the whole test case up". Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Re: [petsc-dev] making BuildSystem hard to debug
by Jed Brown 21 Mar '12

21 Mar '12

On Wed, Mar 21, 2012 at 11:46, Matthew Knepley <knepley(a)gmail.com> wrote: > The compile routine does not decide whether to crash, so I had > configure.py dump these headers if there was an exception. I > can test it later today. > When a test fails, why doesn't it wrap the whole test case up in the exception object. If that exception is not caught, it prints a summary and places the complete test case in configure.log?

1 0

Re: [petsc-dev] making BuildSystem hard to debug
by Matthew Knepley 21 Mar '12

21 Mar '12

On Wed, Mar 21, 2012 at 10:24 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > On Mar 21, 2012, at 8:38 AM, Matthew Knepley wrote: > > > On Wed, Mar 21, 2012 at 8:22 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > Matt, > > > > One thing that has always pissed me off about BuildSystem but for some > reason I never had the energy to bitch about is when a compile goes wrong, > BuildSystem logs the source code that wouldn't compiler BUT IT DOES NOT LOG > THE CONTENTS OF THE TWO FILES > > > > #include "confdefs.h" > > #include "conffix.h" > > > > MAKING DEBUGGING HARDER. Can you please have BuildSystem log these files > when it logs the source code that didn't compiler. > > > > We originally did this. It was way too long. I just debugged the same > thing. > > If you just dump it on a crash then length doesn't matter. Without it > one is left to completely guess exactly what is in them and could have > triggered the problem. > The compile routine does not decide whether to crash, so I had configure.py dump these headers if there was an exception. I can test it later today. Matt > Barry > > > > > Matt > > > > Thanks > > > > > > Barry > > > > > > > > > > > > -- > > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which their > experiments lead. > > -- Norbert Wiener > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Re: [petsc-dev] XXXDestroy(object) -> XXXDestroy(*object) not in changelog
by Matthew Knepley 21 Mar '12

21 Mar '12

+1 Matt On Wed, Mar 21, 2012 at 11:09 AM, Sean Farley <sean(a)mcs.anl.gov> wrote: > Fixed. > > > I like how it's easy to tell what changed in the webpages now :-) > > http://petsc.cs.iit.edu/petsc/petsc-dev/rev/d058bd1e3700 > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Re: [petsc-dev] XXXDestroy(object) -> XXXDestroy(*object) not in changelog
by Sean Farley 21 Mar '12

21 Mar '12

> > Fixed. I like how it's easy to tell what changed in the webpages now :-) http://petsc.cs.iit.edu/petsc/petsc-dev/rev/d058bd1e3700

1 0

Re: [petsc-dev] XXXDestroy(object) -> XXXDestroy(*object) not in changelog
by Matthew Knepley 21 Mar '12

21 Mar '12

Fixed. Matt On Wed, Mar 21, 2012 at 9:32 AM, Aron Ahmadia <aron.ahmadia(a)kaust.edu.sa>wrote: > It is perhaps not enough, but 3.2 Changes say that VecDestroy() now zeros >> the pointer so that it cannot be reused. >> > > It is not enough, as you know this change hit every Destroy() function in > PETSc. > > A > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Re: [petsc-dev] --download-dependencies flag?
by Cortese, Tom A 21 Mar '12

21 Mar '12

I agree, that's annoying. However, is it conceivable that someone may want to install PETSc, download MUMPS, but use their own ParMetis and/or ScaLAPACK (especially the latter, since a vendor-optimized version may already be installed in a system scientific software library, and that will likely perform better than something that is downloaded and compiled from high-level source)? I suppose it could be left to the "power users" to specify something like ./configure --download-mumps --with-scalapack=blahblah and then let the PETSc installer decide on its own that it needs to download ParMetis, but that ScaLAPACK is covered. At the very least, I would hope that some sort of prominent message is displayed if indeed the PETSc configure automatically decides to download extra things that I didn't specify... Just my two cents (I'm not a PETSc developer, but I have had lots of experience building PETSc on a wide variety of systems)... -Tom C. ________________________________ From: petsc-dev-bounces(a)mcs.anl.gov [petsc-dev-bounces(a)mcs.anl.gov] on behalf of Aron Ahmadia [aron.ahmadia(a)kaust.edu.sa] Sent: Wednesday, March 21, 2012 5:46 AM To: For users of the development version of PETSc Subject: [petsc-dev] --download-dependencies flag? In order to get a user up-and-running with a MUMPs-enabled PETSc, I followed this frustrating chain: configure --download-mumps=1 ... Error, no parmetis! configure --download-mumps=1 --download-parmetis=1 Error, no scalapack! configure --download-mumps=1 --download-parmetis=1 --download-scalapack=1 It would be convenient if the PETSc BuildSystem did what other package installers like pip, yum, etc..., do, and grab dependencies that I need based on what I have requested. Additionally, it would make it a lot easier to build PETSc on complicated systems if BuildSystem did a quick dependency/flag check instead off the way it works now (sequential intermixing of really slow and fast configure options). A

1 0

Re: [petsc-dev] making BuildSystem hard to debug
by Barry Smith 21 Mar '12

21 Mar '12

On Mar 21, 2012, at 8:38 AM, Matthew Knepley wrote: > On Wed, Mar 21, 2012 at 8:22 AM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Matt, > > One thing that has always pissed me off about BuildSystem but for some reason I never had the energy to bitch about is when a compile goes wrong, BuildSystem logs the source code that wouldn't compiler BUT IT DOES NOT LOG THE CONTENTS OF THE TWO FILES > > #include "confdefs.h" > #include "conffix.h" > > MAKING DEBUGGING HARDER. Can you please have BuildSystem log these files when it logs the source code that didn't compiler. > > We originally did this. It was way too long. I just debugged the same thing. If you just dump it on a crash then length doesn't matter. Without it one is left to completely guess exactly what is in them and could have triggered the problem. Barry > > Matt > > Thanks > > > Barry > > > > > > -- > What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. > -- Norbert Wiener

1 0

Re: [petsc-dev] XXXDestroy(object) -> XXXDestroy(*object) not in changelog
by Aron Ahmadia 21 Mar '12

21 Mar '12

> > It is perhaps not enough, but 3.2 Changes say that VecDestroy() now zeros > the pointer so that it cannot be reused. > It is not enough, as you know this change hit every Destroy() function in PETSc. A

1 0

Re: [petsc-dev] Floating point exception in ex47cu.cu
by David Fuentes 21 Mar '12

21 Mar '12

I'm having a similiar problem with ex47cu with petsc 3.2-p7 cuda 4.0 thrust 1.4 cusp 0.2 Unfortunately, it's pretty random. sometimes the executable runs fine. Other times it will crash with floating point exceptions as below. (The function evaluation will returns inf's and nan's when using -da_vec_type mpicusp) the -arch=sm_13 flag is being used. My card has compute capability 2.0 would using -arch=sm_20 possibly help ? also, is there a particular version of cuda/thrust/cusp that should be used ? Thanks, David On Mon, Apr 25, 2011 at 8:46 AM, Satish Balay <balay(a)mcs.anl.gov> wrote: > That would be wierd. Currently configure defaults to sm_10 for single > precision, and sm_13 for double precision. [I've verified this again] > > can you send configure.log [without the cuda-arch option] - to > petsc-maint? > > > Satish > > > On Mon, 25 Apr 2011, Евгений Козлов wrote: > > > Yes, this was the problem. Now it works. > > > > Thank you. > > > > 2011/4/25 Victor Minden <victorminden(a)gmail.com>: > > > Eugene, > > > Based off of > > > Configure options --prefix=/home/kukushkinav > > > --with-blas-lapack-dir=/opt/intel/composerxe-2011.0.084/mkl > > > --with-mpi-dir=/opt/intel/impi/4.0.1.007/intel64/bin --with-cuda=1 > > > --with-cusp=1 --with-thrust=1 > > > --with-thrust-dir=/home/kukushkinav/include > > > --with-cusp-dir=/home/kukushkinav/include > > > It looks like maybe you're not setting the configure flag > > > --with-cuda-arch=XXX. Without this, PETSc uses the nvcc default, > which when > > > I last looked was sm_10. The problem with this is that sm_10 doesn't > > > support double-precision. Maybe this is your problem? For example, I > use > > > -with-cuda-arch=sm_13, which corresponds to NVIDIA compute capability > 1.3 > > > Cheers, > > > Victor > > > --- > > > Victor L. Minden > > > > > > Tufts University > > > School of Engineering > > > Class of 2012 > > > > > > > > > On Fri, Apr 22, 2011 at 12:22 PM, Евгений Козлов < > neoveneficus(a)gmail.com> > > > wrote: > > >> > > >> Hello, > > >> > > >> I am interesting in using PETSc for iterative solving sparse linear > > >> system on multi-GPU systems. > > >> > > >> First of all, I compiled PETSc-dev and tried to run some examples, > > >> which will run on GPU. > > >> > > >> I found src/snes/examples/tutorials/ex47cu.cu. It was compiled and > > >> executed. > > >> > > >> Out of original program src/snes/examples/tutorials/ex47cu.cu: > > >> > > >> [0]PETSC ERROR: --------------------- Error Message > > >> ------------------------------------ > > >> [0]PETSC ERROR: Floating point exception! > > >> [0]PETSC ERROR: User provided compute function generated a > Not-a-Number! > > >> [0]PETSC ERROR: > > >> > ------------------------------------------------------------------------ > > >> [0]PETSC ERROR: Petsc Development HG revision: > > >> d3e10315d68b1dd5481adb2889c7d354880da362 HG Date: Wed Apr 20 21:03:56 > > >> 2011 -0500 > > >> [0]PETSC ERROR: See docs/changes/index.html for recent updates. > > >> [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. > > >> [0]PETSC ERROR: See docs/index.html for manual pages. > > >> [0]PETSC ERROR: > > >> > ------------------------------------------------------------------------ > > >> [0]PETSC ERROR: ex47cu on a arch-linu named cn03 by kukushkinav Fri > > >> Apr 22 18:33:32 2011 > > >> [0]PETSC ERROR: Libraries linked from /home/kukushkinav/lib > > >> [0]PETSC ERROR: Configure run at Thu Apr 21 19:18:22 2011 > > >> [0]PETSC ERROR: Configure options --prefix=/home/kukushkinav > > >> --with-blas-lapack-dir=/opt/intel/composerxe-2011.0.084/mkl > > >> --with-mpi-dir=/opt/intel/impi/4.0.1.007/intel64/bin --with-cuda=1 > > >> --with-cusp=1 --with-thrust=1 > > >> --with-thrust-dir=/home/kukushkinav/include > > >> --with-cusp-dir=/home/kukushkinav/include > > >> [0]PETSC ERROR: > > >> > ------------------------------------------------------------------------ > > >> [0]PETSC ERROR: SNESSolve_LS() line 167 in src/snes/impls/ls/ls.c > > >> [0]PETSC ERROR: SNESSolve() line 2407 in src/snes/interface/snes.c > > >> [0]PETSC ERROR: main() line 38 in src/snes/examples/tutorials/ > ex47cu.cu > > >> application called MPI_Abort(MPI_COMM_WORLD, 72) - process 0 > > >> > > >> Then I tried to find the place in source with the problem, I changed > > >> the function in struct ApplyStencil to > > >> > > >> void operator()(Tuple t) { thrust::get<0>(t) = 1; } > > >> > > >> Result: > > >> [0]PETSC ERROR: --------------------- Error Message > > >> ------------------------------------ > > >> [0]PETSC ERROR: Floating point exception! > > >> [0]PETSC ERROR: Infinite or not-a-number generated in mdot, entry 0! > > >> [0]PETSC ERROR: > > >> > ------------------------------------------------------------------------ > > >> [0]PETSC ERROR: Petsc Development HG revision: > > >> d3e10315d68b1dd5481adb2889c7d354880da362 HG Date: Wed Apr 20 21:03:56 > > >> 2011 -0500 > > >> [0]PETSC ERROR: See docs/changes/index.html for recent updates. > > >> [0]PETSC ERROR: See docs/faq.html for hints about trouble shooting. > > >> [0]PETSC ERROR: See docs/index.html for manual pages. > > >> [0]PETSC ERROR: > > >> > ------------------------------------------------------------------------ > > >> [0]PETSC ERROR: ex47cu on a arch-linu named cn11 by kukushkinav Fri > > >> Apr 22 18:58:04 2011 > > >> [0]PETSC ERROR: Libraries linked from /home/kukushkinav/lib > > >> [0]PETSC ERROR: Configure run at Thu Apr 21 19:18:22 2011 > > >> [0]PETSC ERROR: Configure options --prefix=/home/kukushkinav > > >> --with-blas-lapack-dir=/opt/intel/composerxe-2011.0.084/mkl > > >> --with-mpi-dir=/opt/intel/impi/4.0.1.007/intel64/bin --with-cuda=1 > > >> --with-cusp=1 --with-thrust=1 > > >> --with-thrust-dir=/home/kukushkinav/include > > >> --with-cusp-dir=/home/kukushkinav/include > > >> [0]PETSC ERROR: > > >> > ------------------------------------------------------------------------ > > >> [0]PETSC ERROR: VecMDot() line 1146 in src/vec/vec/interface/rvector.c > > >> [0]PETSC ERROR: KSPGMRESClassicalGramSchmidtOrthogonalization() line > > >> 66 in src/ksp/ksp/impls/gmres/borthog2.c > > >> [0]PETSC ERROR: GMREScycle() line 161 in > src/ksp/ksp/impls/gmres/gmres.c > > >> [0]PETSC ERROR: KSPSolve_GMRES() line 244 in > > >> src/ksp/ksp/impls/gmres/gmres.c > > >> [0]PETSC ERROR: KSPSolve() line 426 in src/ksp/ksp/interface/itfunc.c > > >> [0]PETSC ERROR: SNES_KSPSolve() line 3107 in src/snes/interface/snes.c > > >> [0]PETSC ERROR: SNESSolve_LS() line 190 in src/snes/impls/ls/ls.c > > >> [0]PETSC ERROR: SNESSolve() line 2407 in src/snes/interface/snes.cС > > >> уважением, > > >> Евгений > > >> [0]PETSC ERROR: main() line 38 in src/snes/examples/tutorials/ > ex47cu.cu > > >> > > >> RedHat 5.5, Cuda 3.2 > > >> > > >> Question1: Is it my problem or a bug of the algorithm? > > >> > > >> Question2: Where can I find simple doc or example, which describe how > > >> to solve sparse linear systems on multi-GPU systems using PETSc? > > >> > > >> > > >> -- > > >> Best regards, > > >> Eugene > > > > > > > > > > > > > > >

1 0