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

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

21 Mar '11

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

Re: [petsc-dev] [petsc-maint #67637] Re: [petsc-users] Scalability of AO ?
by Jose E. Roman 21 Mar '11

21 Mar '11

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

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

21 Mar '11

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

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

21 Mar '11

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

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

21 Mar '11

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

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

21 Mar '11

On Mar 21, 2011, at 4:04 PM, Jed Brown wrote: > On Mon, Mar 21, 2011 at 21:57, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > We originally started with multiple libraries because in the 1990's PETSc libraries were "BIG" and made live hard for some filesystems and linkers. Now libpetsc.a is not big, by modern standards of big so is there any reason at all to keep the option of having lots of libraries (that don't get tested properly)? > > I still test that option, but only because I'm paranoid about developing cycles in the dependencies between different packages within petsc. Why do you care if there are dependencies? Admittedly that may make PETSc harder to develop and maintain but from the user point of view what is wrong with just having one big-assed blob? Barry > If there was another way to perform this sanity check, I would be fully in favor of getting rid of the option. I'm probably in favor of it regardless. > > On my machine, an optimized C libpetsc.so is between 5 and 10 MB depending on optimization flags. A debug C++ with Sieve is a bit over 100 MiB. That 100 MiB is significant on a low-memory platform, but on a low-memory machine, you would expect to link statically and then you only need lots of memory on the development machine.

1 0

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

21 Mar '11

On Mon, Mar 21, 2011 at 21:57, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > We originally started with multiple libraries because in the 1990's PETSc > libraries were "BIG" and made live hard for some filesystems and linkers. > Now libpetsc.a is not big, by modern standards of big so is there any reason > at all to keep the option of having lots of libraries (that don't get tested > properly)? > I still test that option, but only because I'm paranoid about developing cycles in the dependencies between different packages within petsc. If there was another way to perform this sanity check, I would be fully in favor of getting rid of the option. I'm probably in favor of it regardless. On my machine, an optimized C libpetsc.so is between 5 and 10 MB depending on optimization flags. A debug C++ with Sieve is a bit over 100 MiB. That 100 MiB is significant on a low-memory platform, but on a low-memory machine, you would expect to link statically and then you only need lots of memory on the development machine.

1 0

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

21 Mar '11

We originally started with multiple libraries because in the 1990's PETSc libraries were "BIG" and made live hard for some filesystems and linkers. Now libpetsc.a is not big, by modern standards of big so is there any reason at all to keep the option of having lots of libraries (that don't get tested properly)? Barry On Mar 21, 2011, at 3:50 PM, Satish Balay wrote: > --with-single-library=0 doesn't get much testing these days. Perhaps > its time to get rid of this option.. > > satish > > On Mon, 21 Mar 2011, Sebastian Steiger wrote: > >> Oh, I forgot to say I'm using --with-single-library=0 for historical >> reasons. >> >> Sebastian >> >> >> On 03/21/2011 04:44 PM, Satish Balay wrote: >>> libpetsccharacteristic shouldn't exist even in the real build. >>> [all objs go into libpetsc.a]. Perhaps something is not in sync? >>> >>> asterix:/home/balay/spetsc/src/characteristic/impls/da>touch slda.c >>> asterix:/home/balay/spetsc/src/characteristic/impls/da>make >>> /home/balay/soft/linux64/mpich2-1.1/bin/mpicc -o slda.o -c -fPIC -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g3 -I/home/balay/spetsc/include -I/home/balay/spetsc/asterix64/include -I/home/balay/soft/linux64/mpich2-1.1/include -D__INSDIR__=src/characteristic/impls/da/ slda.c >>> /usr/bin/ar cr /home/balay/spetsc/asterix64/lib/libpetsc.a slda.o >>> if test -n ""; then /usr/bin/ar cr slda.lo; fi >>> /bin/rm -f slda.o slda.lo >>> asterix:/home/balay/spetsc/src/characteristic/impls/da> >>> >>> Satish >>> >>> >>> On Mon, 21 Mar 2011, Sebastian Steiger wrote: >>> >>>> Hong, Jose, >>>> >>>> I have rebuilt petsc-dev and successfully compiled. I also svn update'd >>>> slepc-dev and compiled the real version. But SLEPc-complex complains >>>> about not finding libpetsccharacteristic, and indeed it's only there in >>>> the real version of PETSc. However it's defined in some of the configure >>>> files and I suspect that's why SLEPc asks for it. >>>> >>>> Am I doing something wrong or is libpetsccharacteristic missing indeed >>>> in the complex PETSc build? >>>> >>>> Sebastian >>>> >>>> >>>> steiger@jaguarpf-login3:~/src/app-nemo/NEMO/libs/petsc-barry/build-cplx$ >>>> grep -inr characteristic conf* >>>> conf/rules:958: if [ "${LIBNAME}" = "libpetsccharacteristic" ]; >>>> then OTHERLIBS="${PETSC_DM_LIB_BASIC}" ; fi;\ >>>> conf/rules:959: if [ "${LIBNAME}" = "libpetscksp" ]; then >>>> OTHERLIBS="${HYPRE_LIB} ${PETSC_CHARACTERISTIC_LIB_BASIC}" ; fi;\ >>>> conf/variables:61:PETSC_CHARACTERISTIC_LIB_BASIC = -lpetsccharacteristic >>>> ${PETSC_DM_LIB_BASIC} >>>> conf/variables:62:PETSC_KSP_LIB_BASIC = -lpetscksp >>>> ${PETSC_CHARACTERISTIC_LIB_BASIC} >>>> conf/variables:72:PETSC_CHARACTERISTIC_LIB = ${C_SH_LIB_PATH} >>>> -L${PETSC_LIB_DIR} ${PETSC_CHARACTERISTIC_LIB_BASIC} >>>> ${PETSC_EXTERNAL_LIB_BASIC} >>>> conf/variables:92:SHLIBS = libpetscsys libpetscvec libpetscmat >>>> libpetscdm libpetsccharacteristic libpetscksp libpetscsnes libpetscts >>>> libpetsccontrib >>>> config/PETSc/Configure.py:256: >>>> self.addMakeMacro('PETSC_CHARACTERISTIC_LIB','${C_SH_LIB_PATH} >>>> ${PETSC_WITH_EXTERNAL_LIB}') >>>> config/PETSc/Configure.py:267: >>>> self.addMakeMacro('PETSC_CHARACTERISTIC_LIB','${PETSC_WITH_EXTERNAL_LIB}') >>>> config/PETSc/Configure.py:294: fd.write('\"Machine characteristics: >>>> %s\\n\"\n' % (platform.platform())) >>>> Binary file config/PETSc/Configure.pyc matches >>>> config/builder.py:858: dirs = map(lambda d: os.path.join(rootDir, >>>> 'src', d), ['inline', 'sys', 'vec', 'mat', 'dm', 'ksp', 'snes', 'ts', >>>> 'characteristic', 'docs', 'tops']) >>>> config/cmakegen.py:152: ('characteristic' , 'dm vec sys'), >>>> config/manifest.in:12:recursive-exclude src/characteristic/examples * >>>> config/BuildSystem/config/setsBackport.py:10:characteristic operation >>>> for sequences is subscripting with small >>>> config/BuildSystem/config/setsOrdered.py:11:characteristic operation for >>>> sequences is subscripting with small >>>> Binary file config/BuildSystem/config/setsOrdered.pyc matches >>>> Binary file config/cmakegen.pyc matches >>>> >>>> >>>> steiger@jaguarpf-login3:~/src/app-nemo/NEMO/libs/petsc-barry/build-cplx$ >>>> ls characteristic linux-complex/lib/* >>>> ls: characteristic: No such file or directory >>>> linux-complex/lib/libblacs.a linux-complex/lib/libparmetis.a >>>> linux-complex/lib/libpetscmat.a linux-complex/lib/libpetscsys.so >>>> linux-complex/lib/libpord.a >>>> linux-complex/lib/libcmumps.a linux-complex/lib/libpetscdm.a >>>> linux-complex/lib/libpetscmat.so linux-complex/lib/libpetscts.a >>>> linux-complex/lib/libscalapack.a >>>> linux-complex/lib/libdmumps.a linux-complex/lib/libpetscdm.so >>>> linux-complex/lib/libpetscsnes.a linux-complex/lib/libpetscts.so >>>> linux-complex/lib/libsmumps.a >>>> linux-complex/lib/libmetis.a linux-complex/lib/libpetscksp.a >>>> linux-complex/lib/libpetscsnes.so linux-complex/lib/libpetscvec.a >>>> linux-complex/lib/libsuperlu_dist_2.5.a >>>> linux-complex/lib/libmumps_common.a linux-complex/lib/libpetscksp.so >>>> linux-complex/lib/libpetscsys.a linux-complex/lib/libpetscvec.so >>>> linux-complex/lib/libzmumps.a >>>> >>>> >>>> >>>> On 03/21/2011 11:38 AM, Jose E. Roman wrote: >>>>> >>>>> El 21/03/2011, a las 16:16, Barry Smith escribió: >>>>> >>>>>> On Mar 21, 2011, at 10:01 AM, Sebastian Steiger wrote: >>>>>> >>>>>>> Hong, >>>>>>> >>>>>>> Thanks a lot for the effort. Unfortunately I have a problem testing the >>>>>>> stuff (that also applies to issue with the ASM preconditioner that Barry >>>>>>> is working on): I'm using a rather complicated build system that >>>>>>> incorporates real+complex PETSc+SLEPc. It seems to me that the current >>>>>>> SLEPc release does not work anymore with petsc-dev. >>>>>>> >>>>>>> So the only thing I could do is somehow compile a separate program that >>>>>>> reads matrices and vectors from file that are generated by my simulation >>>>>>> and then use that with petsc-dev. But that requires a few days if not >>>>>>> weeks of work for me, and I hate to say that my tight schedule is tight >>>>>>> until May. >>>>>>> >>>>>>> So I will probably have to wait with the testing on my side until >>>>>>> petsc-3.2 is out and then maybe another month until Jose and the SLEPc >>>>>>> guys have an update of SLEPc. Do you see another option? I'd be glad to >>>>>>> do some testing if it requires not too much effort. >>>>>>> >>>>>> It's best to just try to get SLEPc-dev working with PETSc-dev and do your testing in the proper place. >>>>>> >>>>>> Maybe Jose can tell us what needs updateing in SLEPc and someone can fix it if Jose doesn't have time at the moment. >>>>>> >>>>>> Barry >>>>>> >>>>> >>>>> I have just committed a change to synchronize slepc-dev with petsc-dev. Let me know if problems arise. >>>>> >>>>> Barry, there may be an inconsistency in the names of PETSC_REAL_MAX and PETSC_MIN_REAL. >>>>> >>>>> Jose >>>>> >>>> >>>> >>>> >> >> >>

1 0

Re: [petsc-dev] [petsc-maint #67565] PaStiX broken with new Scotch.py
by Barry Smith 20 Mar '11

20 Mar '11

I have updated the PaStix tarball that is used and hacked the PaStiX.py file to get the thing to build. But it doesn't work because the PaStiX makefile input generated by PaStiX.py doesn't have the right flags for building with Scotch. Our French friends really need to just use autoconf and trash their hugely complicated makefile/configure system hack they have. They also need to know that in 2011 one does not need to ever include malloc.h explicitly in C code and having architecture specific flags like i686_mac is a big mistake and so unneeded. At the same time they should probably trash the whole business of having a scotch and a parallel scotch and just have one integrated system. Someone who has more patience than I, needs to go through PaStiX.py and go through the latest PaStiX makefile to determine exactly what needs to be set and how to get PaStiX build to use Scotch and Parmetis. Barry On Mar 20, 2011, at 2:05 PM, Jed Brown wrote: > After "builder2.py" deleted everything, I've been trying to rebuild my > configurations and PaStiX no longer works because it includes "scotch.h", > but new Scotch.py only installs "ptscotch.h". Consequently, > --download-pastix seems to be broken, I haven't tried to fix it. > > After "builder2.py" deleted everything, I've been trying to rebuild my configurations and PaStiX no longer works because it includes "scotch.h", but new Scotch.py only installs "ptscotch.h". Consequently, --download-pastix seems to be broken, I haven't tried to fix it.

1 0

Re: [petsc-dev] Builder update
by Jed Brown 20 Mar '11

20 Mar '11

WARNING: I ran "config/builder2.py clean" because I had a stale pickle. This ran "hg clean" because (we think) of some differences between Hg-1.7 and Hg-1.8 module system (Matt has been piggy-backing on Hg's module system). Of course that *deleted all test output in the source tree and all PETSC_ARCH configurations*. So be careful if you use builder2.py.

1 0