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

Re: [petsc-dev] Bug in petsc-dev?
by Barry Smith 22 Mar '11

22 Mar '11

On Mar 22, 2011, at 11:08 AM, Thomas Witkowski wrote: > Could some of you test the very small attached example? I make use of the current petsc-dev, OpenMPI 1.4.1 and GCC 4.2.4. In this environment, using 4 nodes, I get the following output, which is wrong: > > [3] BCAST-RESULT: 812855920 > [2] BCAST-RESULT: 450385 > [1] BCAST-RESULT: 450385 > [0] BCAST-RESULT: 450385 > > The problem occurs only when I run the code on different nodes. When I start mpirun on only one node with four threads You mean 4 MPI processes? > or I make use of a four core system, everything is fine. valgrind and Allinea DDT, both say that everything is fine. So I'm really not sure where the problem is. Using PETSc 3.1-p8 there is no problem with this example. Would be quite interesting to know if some of you can reproduce this problem or not. Thanks for any try! Replace the PetscInitialize() and PetscFinalize() with MPI_Init() and MPI_Finalize() and remove the include petsc.h now link under old and new PETSc and run under the different systems. I'm thinking you'll still get the wrong result without the Petsc calls indicating that it is an MPI issue. Barry > > Thomas > > <test.c>

1 0

Re: [petsc-dev] Should pARMS converge in parallel?
by Jed Brown 22 Mar '11

22 Mar '11

On Tue, Mar 22, 2011 at 17:05, Jose E. Roman <jroman(a)dsic.upv.es> wrote: > Based on feedback received from one of the pARMS developers, I am attaching > a patch that modifies some default values. > > Jed, can you push again? > done

1 0

Bug in petsc-dev?
by Thomas Witkowski 22 Mar '11

22 Mar '11

Could some of you test the very small attached example? I make use of the current petsc-dev, OpenMPI 1.4.1 and GCC 4.2.4. In this environment, using 4 nodes, I get the following output, which is wrong: [3] BCAST-RESULT: 812855920 [2] BCAST-RESULT: 450385 [1] BCAST-RESULT: 450385 [0] BCAST-RESULT: 450385 The problem occurs only when I run the code on different nodes. When I start mpirun on only one node with four threads or I make use of a four core system, everything is fine. valgrind and Allinea DDT, both say that everything is fine. So I'm really not sure where the problem is. Using PETSc 3.1-p8 there is no problem with this example. Would be quite interesting to know if some of you can reproduce this problem or not. Thanks for any try! Thomas

1 0

Re: [petsc-dev] Should pARMS converge in parallel?
by Jose E. Roman 22 Mar '11

22 Mar '11

El 18/03/2011, a las 19:29, Jed Brown escribió: > On Fri, Mar 18, 2011 at 19:14, Jose E. Roman <jroman(a)dsic.upv.es> wrote: > I am attaching a patch that sets default values that should work irrespective of the number of processors, even without flexible solvers. > > Jed, can you commit the changes? > > Thanks, pushed. Based on feedback received from one of the pARMS developers, I am attaching a patch that modifies some default values. Jed, can you push again? Jose

1 0

Re: [petsc-dev] [petsc-maint #67637] Re: [petsc-users] Scalability of AO ?
by Matthew Knepley 21 Mar '11

21 Mar '11

On Mon, Mar 21, 2011 at 6:11 PM, Jed Brown <jed(a)59a2.org> wrote: > On Tue, Mar 22, 2011 at 00:06, Matthew Knepley <petsc-maint(a)mcs.anl.gov > >wrote: > > > 3) It should go into TS > > > Really? It depends on a specific DM implementation. If you offered up a > generic algebraic interface, then it could just be a normal explicit TS. > But > it seems to me that DM is a better choice for particle tracking, at least > all the spatial queries and such. > Rationale: The function of characteristic is to handle the material derivative in a timestepping method. Caveats: I agree that the current implementation is dependent on DMDA. This should be remedied. Matt > On Tue, Mar 22, 2011 at 00:06, Matthew Knepley <petsc-maint(a)mcs.anl.gov>wrote: > >> 3) It should go into TS > > > Really? It depends on a specific DM implementation. If you offered up a > generic algebraic interface, then it could just be a normal explicit TS. But > it seems to me that DM is a better choice for particle tracking, at least > all the spatial queries and such. > > -- 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] [petsc-maint #67637] Re: [petsc-users] Scalability of AO ?
by Jed Brown 21 Mar '11

21 Mar '11

On Tue, Mar 22, 2011 at 00:21, Satish Balay <petsc-maint(a)mcs.anl.gov> wrote: > for now pushed the ts change - so the complex + single-library=0 build > should work. > I finished this by moving it to src/ts/characteristic. The cmake build puts it in the correct shared library now.

1 0

Re: [petsc-dev] [petsc-maint #67637] Re: [petsc-users] Scalability of AO ?
by Satish Balay 21 Mar '11

21 Mar '11

On Mon, 21 Mar 2011, Jed Brown wrote: > On Tue, Mar 22, 2011 at 00:06, Matthew Knepley <petsc-maint(a)mcs.anl.gov>wrote: > > > 3) It should go into TS > > > Really? It depends on a specific DM implementation. If you offered up a > generic algebraic interface, then it could just be a normal explicit TS. But > it seems to me that DM is a better choice for particle tracking, at least > all the spatial queries and such. for now pushed the ts change - so the complex + single-library=0 build should work. Satish

1 0

Re: [petsc-dev] [petsc-maint #67637] Re: [petsc-users] Scalability of AO ?
by Jed Brown 21 Mar '11

21 Mar '11

On Tue, Mar 22, 2011 at 00:06, Matthew Knepley <petsc-maint(a)mcs.anl.gov>wrote: > 3) It should go into TS Really? It depends on a specific DM implementation. If you offered up a generic algebraic interface, then it could just be a normal explicit TS. But it seems to me that DM is a better choice for particle tracking, at least all the spatial queries and such.

1 0

Re: [petsc-dev] [petsc-maint #67637] Re: [petsc-users] Scalability of AO ?
by Matthew Knepley 21 Mar '11

21 Mar '11

On Mon, Mar 21, 2011 at 5:36 PM, Satish Balay <petsc-maint(a)mcs.anl.gov>wrote: > Hm - why did I think Dmitry added libcharacteristic.a? I can't > figureout who added this library - so > > Matt, Barry - Should it go into libpetscdm.a? 1) I added it a few years ago 2) It holds the method of characteristics 3) It should go into TS Matt > > Satish > > On Mon, 21 Mar 2011, Satish Balay wrote: > > > Dmitry, > > > > We can't have a library disappear between real/complex builds. Is > > there a different library that can take in these symbols? > > > > Note: not all petsc objects get a library of their own. For eg: IS > > goes into libpetscvec etc.. > > > > Satish > > > > > > On Mon, 21 Mar 2011, Jose E. Roman wrote: > > > > > src/characteristic/makefile has #requiresscalar real, so > libcharacteristic.a is not created with-scalar-type=complex. > > > 'make test' fails in this case. > > > > > > Also, with cmake builds: > > > Scanning dependencies of target petsccharacteristic > > > make[2]: *** No rule to make target > `CMakeFiles/petsccharacteristic.dir/build'. Stop. > > > make[1]: *** [CMakeFiles/petsccharacteristic.dir/all] Error 2 > > > make[1]: *** Waiting for unfinished jobs.... > > > > > > Jose > > > > > > > > > El 21/03/2011, a las 22:20, Satish Balay escribió: > > > > > > > added > > > > > > > > satish > > > > > > > > On Mon, 21 Mar 2011, Barry Smith wrote: > > > > > > > >> > > > >> Maybe we just need to force Satish to have a nightly build that > checks the several library tests. > > > >> > > > >> Barry > > > >> > > > >> On Mar 21, 2011, at 4:10 PM, Jed Brown wrote: > > > >> > > > >>> On Mon, Mar 21, 2011 at 22:07, Barry Smith <bsmith(a)mcs.anl.gov> > wrote: > > > >>> Why do you care if there are dependencies? Admittedly that may make > PETSc harder to develop and maintain > > > >>> > > > >>> Exactly. > > > >>> > > > >>> but from the user point of view what is wrong with just having one > big-assed blob? > > > >>> > > > >>> It doesn't matter for users. > > > >>> > > > >>> (But a circular dependency would make executables grow so its > existence might matter to someone using only Mat+Vec in an extremely > low-memory environment.) > > > >> > > > >> > > > >> > > > > > > > > > > > > > > > > > > -- 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] [petsc-maint #67637] Re: [petsc-users] Scalability of AO ?
by Satish Balay 21 Mar '11

21 Mar '11

Hm - why did I think Dmitry added libcharacteristic.a? I can't figureout who added this library - so Matt, Barry - Should it go into libpetscdm.a? Satish On Mon, 21 Mar 2011, Satish Balay wrote: > Dmitry, > > We can't have a library disappear between real/complex builds. Is > there a different library that can take in these symbols? > > Note: not all petsc objects get a library of their own. For eg: IS > goes into libpetscvec etc.. > > Satish > > > On Mon, 21 Mar 2011, Jose E. Roman wrote: > > > src/characteristic/makefile has #requiresscalar real, so libcharacteristic.a is not created with-scalar-type=complex. > > 'make test' fails in this case. > > > > Also, with cmake builds: > > Scanning dependencies of target petsccharacteristic > > make[2]: *** No rule to make target `CMakeFiles/petsccharacteristic.dir/build'. Stop. > > make[1]: *** [CMakeFiles/petsccharacteristic.dir/all] Error 2 > > make[1]: *** Waiting for unfinished jobs.... > > > > Jose > > > > > > El 21/03/2011, a las 22:20, Satish Balay escribió: > > > > > added > > > > > > satish > > > > > > On Mon, 21 Mar 2011, Barry Smith wrote: > > > > > >> > > >> Maybe we just need to force Satish to have a nightly build that checks the several library tests. > > >> > > >> Barry > > >> > > >> On Mar 21, 2011, at 4:10 PM, Jed Brown wrote: > > >> > > >>> On Mon, Mar 21, 2011 at 22:07, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > >>> Why do you care if there are dependencies? Admittedly that may make PETSc harder to develop and maintain > > >>> > > >>> Exactly. > > >>> > > >>> but from the user point of view what is wrong with just having one big-assed blob? > > >>> > > >>> It doesn't matter for users. > > >>> > > >>> (But a circular dependency would make executables grow so its existence might matter to someone using only Mat+Vec in an extremely low-memory environment.) > > >> > > >> > > >> > > > > > > > > > > >

1 0