December 2014 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Sean is going to love this
by Jed Brown 22 Dec '14

22 Dec '14

Sean Farley <sean.michael.farley(a)gmail.com> writes: > The only way to do this, in my experience, is if the package manager has > something like 'variants' (macports and homebrew have it, at least, I > don't know about others): > > port install petsc +superlu +mumps +mpich +hdf5 +hypre ... etc. I think variants are a crutch for poor plugin support. I would prefer for PETSc to offer these as plugins that can be built and distributed separately. Then one can install petsc-superlu, petsc-mumps, etc.

1 0

Re: [petsc-dev] Sean is going to love this
by Satish Balay 22 Dec '14

22 Dec '14

On Mon, 22 Dec 2014, Matthew Knepley wrote: > On Mon, Dec 22, 2014 at 8:31 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > > > In the past we've been not particularly supportive of getting PETSc in > > Linux package systems, in fact we've been a bit antagonistic. We should > > change this. > > > I have the same objection as before, namely that many of our users want > extra packages. Moreover, > even the ones that start with a plain vanilla installation often want to > add packages later. I think extra packages would not be a problem. Basically the model would be: - package all dependent packages - build petsc with all such dependent packages. Variants would be a problem. Some packaging systems support it for major packages [for ex: mpich vs openmpi, mpich-hdf5, openmpi-hdf5]. In PETSc case - we might have issues with some of the variants we support [real, complex, 64bit indices etc..] But even if we can't support all variants - just getting some of them available for users via packagemanagers would be an improvement. [for the variants that linux packages don't support - one would have to install from source - which is the current mode anyway] > Thus, I could see us being distributed by a package manager IF we > retained the ability to reconfigure and rebuild. I would like the > packaged version to retain all the configure stuff and ARCH > directory so that a user can call the reconfigure script with extra > arguments and rebuild the package themselves. I think the general mode is for 'packagers' interested in packaging petsc [for ex: Sean for MacPorts] - to package and to some extent support the package. If I understand Barry's note - we should make it easier for such interested folks to package PETSc. Satish

1 0

Re: [petsc-dev] Sean is going to love this
by Matthew Knepley 22 Dec '14

22 Dec '14

On Mon, Dec 22, 2014 at 9:51 PM, Sean Farley <sean.michael.farley(a)gmail.com> wrote: > > > Matthew Knepley writes: > > > On Mon, Dec 22, 2014 at 8:31 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > >> > >> > >> In the past we've been not particularly supportive of getting PETSc in > >> Linux package systems, in fact we've been a bit antagonistic. We should > >> change this. > > > > > > I have the same objection as before, namely that many of our users want > > extra packages. Moreover, > > even the ones that start with a plain vanilla installation often want to > > add packages later. > > The only way to do this, in my experience, is if the package manager has > something like 'variants' (macports and homebrew have it, at least, I > don't know about others): > > port install petsc +superlu +mumps +mpich +hdf5 +hypre ... etc. > > > Thus, I could see us being distributed by a package manager IF we > retained > > the ability to reconfigure > > and rebuild. I would like the packaged version to retain all the > configure > > stuff and ARCH directory so > > that a user can call the reconfigure script with extra arguments and > > rebuild the package themselves. > > Sigh. I really don't want to get into why this is a bad idea > (reproducibility, stability, etc.). Not to mention, most package > I don't care about any of those as much as scientific capability and flexibility. > managers elevate permissions to root (or a special user) for the sole > purpose that a user doesn't muck up the installation tree. > > In the macports world, most PETSc requests come from dolfin (FEniCS) or > By the time they get Dolfin installation sorted out, I will be dead and the discussion will be moot. > PETSc4py, for what it's worth. > petsc4py already has a simple install through pip, and this is what motivates my desire to reconfigure. Thanks, 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] Sean is going to love this
by Sean Farley 22 Dec '14

22 Dec '14

Matthew Knepley writes: > On Mon, Dec 22, 2014 at 8:31 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >> >> >> In the past we've been not particularly supportive of getting PETSc in >> Linux package systems, in fact we've been a bit antagonistic. We should >> change this. > > > I have the same objection as before, namely that many of our users want > extra packages. Moreover, > even the ones that start with a plain vanilla installation often want to > add packages later. The only way to do this, in my experience, is if the package manager has something like 'variants' (macports and homebrew have it, at least, I don't know about others): port install petsc +superlu +mumps +mpich +hdf5 +hypre ... etc. > Thus, I could see us being distributed by a package manager IF we retained > the ability to reconfigure > and rebuild. I would like the packaged version to retain all the configure > stuff and ARCH directory so > that a user can call the reconfigure script with extra arguments and > rebuild the package themselves. Sigh. I really don't want to get into why this is a bad idea (reproducibility, stability, etc.). Not to mention, most package managers elevate permissions to root (or a special user) for the sole purpose that a user doesn't muck up the installation tree. In the macports world, most PETSc requests come from dolfin (FEniCS) or PETSc4py, for what it's worth.

1 0

Re: [petsc-dev] Sean is going to love this
by Matthew Knepley 22 Dec '14

22 Dec '14

On Mon, Dec 22, 2014 at 8:31 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > In the past we've been not particularly supportive of getting PETSc in > Linux package systems, in fact we've been a bit antagonistic. We should > change this. I have the same objection as before, namely that many of our users want extra packages. Moreover, even the ones that start with a plain vanilla installation often want to add packages later. Thus, I could see us being distributed by a package manager IF we retained the ability to reconfigure and rebuild. I would like the packaged version to retain all the configure stuff and ARCH directory so that a user can call the reconfigure script with extra arguments and rebuild the package themselves. Thanks, Matt > 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] Sean is going to love this
by Sean Farley 22 Dec '14

22 Dec '14

Barry Smith writes: > In the past we've been not particularly supportive of getting PETSc in Linux package systems, in fact we've been a bit antagonistic. We should change this. Well, knock me over with a feather.

1 0

Sean is going to love this
by Barry Smith 22 Dec '14

22 Dec '14

In the past we've been not particularly supportive of getting PETSc in Linux package systems, in fact we've been a bit antagonistic. We should change this. Barry

1 0

Fwd: [ideas-xsdk] common configure/cmake arguments for XSDK packages ready for testing
by Barry Smith 22 Dec '14

22 Dec '14

Redirecting Jed's question specifically for PETSc configure. Can we/should we save the modules setting at configure time and then check them always at make time? Is some environmental variable set that has a unique value based on the modules loaded? If this is a common problem for us then we should be doing this. Barry > Begin forwarded message: > > From: Jed Brown <jed(a)jedbrown.org> > To: Barry Smith <bsmith(a)mcs.anl.gov>, "Bartlett, Roscoe A." <bartlettra(a)ornl.gov> > Cc: "ideas-xsdk(a)lists.mcs.anl.gov" <ideas-xsdk(a)lists.mcs.anl.gov> > Subject: Re: [ideas-xsdk] common configure/cmake arguments for XSDK packages ready for testing > Date: December 22, 2014 at 1:08:39 PM CST > > Barry Smith <bsmith(a)mcs.anl.gov> writes: >> It is the issue of secretly mistakenly set values that is the reason for the environmental flag > > Also, can we detect when the user has changed their "module" settings? > A sizable fraction of support messages come from people using a > different environment to build than they used to configure. Cray uses > CC=cc in all cases, but "cc" has different behavior based on which > modules are used. Moreover, the Intel compiler behaves differently > based on which "gcc" is found in PATH. These changes invalidate > configure tests.

1 0

Re: [petsc-dev] memory leaks and other problems with cusp tests in master
by Karl Rupp 22 Dec '14

22 Dec '14

Hi Barry, > http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2014/12/20/examples_ma… I will have a look at it some time in January. I fear I won't find the time any earlier. Best regards, Karli

1 0

Re: [petsc-dev] Patch to fix vector allocation in ksp-fcg
by Barry Smith 21 Dec '14

21 Dec '14

Sascha, Thanks. I have put it in the branch barry/fix-ksp-fcg and next for testing. Barry > On Dec 20, 2014, at 6:38 PM, Sascha Schnepp <mail(a)saschaschnepp.net> wrote: > > Hello, > > yes, I am sorry, there was a bug in the patch. > > The problem occurred when the number of preallocated vectors was bigger than the max number of old directions to store - as in the options in runex60. It hadn’t checked this case. Again, sorry for that. > > I prepared a new patch which also replaces a PetscMin for a PetscMax but also swaps argument positions. I ran ex2, ex43 and ex60 with appropriate options in valgrind and got no errors. > > BTW: > valgrind is available for Mac through MacPorts again. > > Sascha > > > > > On 20 Dec 2014, at 18:17, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > > When I added this change src/ksp/ksp/examples/tutorials/ex60 make runex60 failed with valgrind errors. > > > > bsmith@es:/sandbox/bsmith/petsc/src/ksp/ksp/examples/tutorials$ /sandbox/bsmith/petsc/bin/petscmpiexec -valgrind -n 1 ./ex60 -ksp_monitor_short -ksp_rtol 1e-6 -diagfunc 1 -ksp_type fcg -ksp_fcg_mmax 1 -eta 0.1 > > ==14854== Invalid write of size 8 > > ==14854== at 0x5C32987: KSPAllocateVectors_FCG (fcg.c:37) > > ==14854== by 0x5C32FE2: KSPSetUp_FCG (fcg.c:77) > > ==14854== by 0x5BEBD69: KSPSetUp (itfunc.c:267) > > ==14854== by 0x5BED3E3: KSPSolve (itfunc.c:419) > > ==14854== by 0x403599: main (ex60.c:219) > > ==14854== Address 0xa49f720 is 0 bytes after a block of size 16 alloc'd > > ==14854== at 0x4C29BE8: memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > > ==14854== by 0x4F33A45: PetscMallocAlign (mal.c:27) > > ==14854== by 0x5C32D96: KSPSetUp_FCG (fcg.c:63) > > ==14854== by 0x5BEBD69: KSPSetUp (itfunc.c:267) > > ==14854== by 0x5BED3E3: KSPSolve (itfunc.c:419) > > ==14854== by 0x403599: main (ex60.c:219) > > ==14854== > > > > Thus I have removed this change. > > > > Barry > > > >> On Dec 19, 2014, at 8:18 AM, Sascha Schnepp <mail(a)saschaschnepp.net> wrote: > >> > >> Hello developers, > >> > >> I prepared a patch to fix the allocation of direction vectors in > >> KSPAllocateVectors_FCG within ksp-fcg. > >> > >> The fix consists only of replacing a PetscMin with a PetscMax. This > >> prevents vectors being allocated one-by-one instead of chunksize > >> of them once the preallocated ones (nprealloc) are exhausted. > >> > >> Let me know if you prefer a PR. > >> > >> Best, > >> Sascha > >> > >> > >> > >> -------------------------------------- > >> ETH Zurich > >> Sascha Schnepp > >> Institute of Geophysics - Geophysical Fluid Dynamics > >> NO H23, Sonneggstrasse 5, 8092 Zurich, Switzerland > >> > >> schnepps(a)ethz.ch > >> www.gfd.ethz.ch; www.saschaschnepp.net > >> > >> +41 44 632 0244 phone > >> > >> Consider encrypting your mail > >> Public Key ID: 0x67AC24EF > >> -------------------------------------- > >> > >> <Fix-to-KSPAllocateVectors_FCG.patch> > > > > <Fix-to-KSPAllocateVectors_FCG_2.patch>

1 0