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

manual page for TSSetIJacobian()
by Barry Smith 07 Feb '11

07 Feb '11

It uses U0 but never explains what it is. It also calls a the "shift" but never explains what it is. Perhaps some notes explaining this stuff would make the solver more transparent. And a reference to further material that uses this approach would be great if it exists. Barry

1 0

PETSC_DIR/.dir-locals.el
by Satish Balay 07 Feb '11

07 Feb '11

Folks, If you get a message of the following type - when loading any petsc-dev sourcefile in emacs - the appropriate thing to do is choose '!' from below. [and the message won't come up again] Satish >>>>>> The local variables list in /home/balay/petsc-dev/ contains values that may not be safe (*). Do you want to apply it? You can type y -- to apply the local variables list. n -- to ignore the local variables list. ! -- to apply the local variables list, and permanently mark these values (*) as safe (in the future, they will be set automatically.) indent-tabs-mode : nil tab-width : 8 * show-trailing-whitespace : t <<<<<<<<

1 0

Re: [petsc-dev] configure issues
by Barry Smith 06 Feb '11

06 Feb '11

On Feb 6, 2011, at 12:16 AM, Jed Brown wrote: > Isn't this just making up for the editor (and perhaps static analysis challenges with Python)? As long as the definition is explicit, grep -r HAVE_FOO config/ should locate the definition. For the other direction, you can grep the source tree (fast if it's in memory or indexed). So how about a couple Emacs functions for this instead of writing fragile file system paths into the configuration macros? Getting them into etags would be good. > > >> On Feb 4, 2011 1:03 AM, "Barry Smith" <bsmith(a)mcs.anl.gov> wrote: >> >> >> On Feb 3, 2011, at 1:35 PM, Jed Brown wrote: >> >> > On Thu, Feb 3, 2011 at 16:27, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >> > >> > >> >> Then you are not going to like my next idea. I think that "configure" >> >> tests should be imbedded directly into the source code and evaluated at >> >> compile time to determine what gets built etc. In other words no distinction >> >> between configure and build time :-). >> >> >> > >> > How to handle tests that need to actually be executed, in a batch >> > environment? >> > >> > >> >> This also eliminates the possibility of "incorrect semantic information in >> >> comments" since the comments won't be "requires X Y and Z" but instead the >> >> actual tests. Having the test code for a functionality being in a different >> >> place than the use of a functionality is not a good model (the obvious >> >> problem with what I say is that the use might be in 50 places so should I >> >> have the same test in 50 places?) >> >> >> > >> > And should the test be executed in all 50 places, or should the result be >> > cached? Since C code is context dependent, it would be hard to prove that it >> > was actually the same test in all 50 places, even if it resided in a common >> > header. >> > >> >> Yes directly imbedding the tests is probably not practical but how about a naming convention that points directly to the test from the source. Now sometimes one has to hunt around to find the test associated with a particular #if since they could be in some many locations. For example instead of >> >> #if defined(PETSC_HAVE_FOO) where is the test of foo >> >> have >> >> #if defined(PETSC_HAVE_FOO_BUILDSYSTEM_CONFIG_MATTSCRAZYFILE_MATTSCRAZYMETHODINTHATFILE) >> >> now I can always go directly to the test. Ideally the links would be bi-directional but that is hard. >> >> Barry >> >> >> >> > On Thu, Feb 3, 2011 at 16:27, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >> > Configure is only slow because it has grown into this monster over time; a complete refactoring should bring it down to barely a minute or so. >> > >> > Even a minute is a long time compared to 3 seconds which is what an incremental build with a couple new/modified implementation files should take. >> > >> > But configure needs to run a lot of tests which involves invoking the compiler a lot of times (it needs to run the compiler on tiny test programs to generate understandable errors as soon as possible, squashing it together into a big compilation later is bad because errors become confusing). I'm not sure that <1 minute is achievable, but I hope it is. >> > >> > Then you are not going to like my next idea. I think that "configure" tests should be imbedded directly into the source code and evaluated at compile time to determine what gets built etc. In other words no distinction between configure and build time :-). >> > >> > How to handle tests that need to actually be executed, in a batch environment? >> > >> > This also eliminates the possibility of "incorrect semantic information in comments" since the comments won't be "requires X Y and Z" but instead the actual tests. Having the test code for a functionality being in a different place than the use of a functionality is not a good model (the obvious problem with what I say is that the use might be in 50 places so should I have the same test in 50 places?) >> > >> > And should the test be executed in all 50 places, or should the result be cached? Since C code is context dependent, it would be hard to prove that it was actually the same test in all 50 places, even if it resided in a common header. >> >

1 0

Re: [petsc-dev] configure issues
by Jed Brown 06 Feb '11

06 Feb '11

Isn't this just making up for the editor (and perhaps static analysis challenges with Python)? As long as the definition is explicit, grep -r HAVE_FOO config/ should locate the definition. For the other direction, you can grep the source tree (fast if it's in memory or indexed). So how about a couple Emacs functions for this instead of writing fragile file system paths into the configuration macros? On Feb 4, 2011 1:03 AM, "Barry Smith" <bsmith(a)mcs.anl.gov> wrote: On Feb 3, 2011, at 1:35 PM, Jed Brown wrote: > On Thu, Feb 3, 2011 at 16:27, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > >> Then you are not going to like my next idea. I think that "configure" >> tests should be imbedded directly into the source code and evaluated at >> compile time to determine what gets built etc. In other words no distinction >> between configure and build time :-). >> > > How to handle tests that need to actually be executed, in a batch > environment? > > >> This also eliminates the possibility of "incorrect semantic information in >> comments" since the comments won't be "requires X Y and Z" but instead the >> actual tests. Having the test code for a functionality being in a different >> place than the use of a functionality is not a good model (the obvious >> problem with what I say is that the use might be in 50 places so should I >> have the same test in 50 places?) >> > > And should the test be executed in all 50 places, or should the result be > cached? Since C code is context dependent, it would be hard to prove that it > was actually the same test in all 50 places, even if it resided in a common > header. > Yes directly imbedding the tests is probably not practical but how about a naming convention that points directly to the test from the source. Now sometimes one has to hunt around to find the test associated with a particular #if since they could be in some many locations. For example instead of #if defined(PETSC_HAVE_FOO) where is the test of foo have #if defined(PETSC_HAVE_FOO_BUILDSYSTEM_CONFIG_MATTSCRAZYFILE_MATTSCRAZYMETHODINTHATFILE) now I can always go directly to the test. Ideally the links would be bi-directional but that is hard. Barry > On Thu, Feb 3, 2011 at 16:27, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Configure is only slow because it has grown into this monster over time; a complete refactoring should bring it down to barely a minute or so. > > Even a minute is a long time compared to 3 seconds which is what an incremental build with a couple new/modified implementation files should take. > > But configure needs to run a lot of tests which involves invoking the compiler a lot of times (it needs to run the compiler on tiny test programs to generate understandable errors as soon as possible, squashing it together into a big compilation later is bad because errors become confusing). I'm not sure that <1 minute is achievable, but I hope it is. > > Then you are not going to like my next idea. I think that "configure" tests should be imbedded directly into the source code and evaluated at compile time to determine what gets built etc. In other words no distinction between configure and build time :-). > > How to handle tests that need to actually be executed, in a batch environment? > > This also eliminates the possibility of "incorrect semantic information in comments" since the comments won't be "requires X Y and Z" but instead the actual tests. Having the test code for a functionality being in a different place than the use of a functionality is not a good model (the obvious problem with what I say is that the use might be in 50 places so should I have the same test in 50 places?) > > And should the test be executed in all 50 places, or should the result be cached? Since C code is context dependent, it would be hard to prove that it was actually the same test in all 50 places, even if it resided in a common header.

1 0

configure issues
by Barry Smith 03 Feb '11

03 Feb '11

On Feb 3, 2011, at 1:35 PM, Jed Brown wrote: > On Thu, Feb 3, 2011 at 16:27, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > >> Then you are not going to like my next idea. I think that "configure" >> tests should be imbedded directly into the source code and evaluated at >> compile time to determine what gets built etc. In other words no distinction >> between configure and build time :-). >> > > How to handle tests that need to actually be executed, in a batch > environment? > > >> This also eliminates the possibility of "incorrect semantic information in >> comments" since the comments won't be "requires X Y and Z" but instead the >> actual tests. Having the test code for a functionality being in a different >> place than the use of a functionality is not a good model (the obvious >> problem with what I say is that the use might be in 50 places so should I >> have the same test in 50 places?) >> > > And should the test be executed in all 50 places, or should the result be > cached? Since C code is context dependent, it would be hard to prove that it > was actually the same test in all 50 places, even if it resided in a common > header. > Yes directly imbedding the tests is probably not practical but how about a naming convention that points directly to the test from the source. Now sometimes one has to hunt around to find the test associated with a particular #if since they could be in some many locations. For example instead of #if defined(PETSC_HAVE_FOO) where is the test of foo have #if defined(PETSC_HAVE_FOO_BUILDSYSTEM_CONFIG_MATTSCRAZYFILE_MATTSCRAZYMETHODINTHATFILE) now I can always go directly to the test. Ideally the links would be bi-directional but that is hard. Barry > On Thu, Feb 3, 2011 at 16:27, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Configure is only slow because it has grown into this monster over time; a complete refactoring should bring it down to barely a minute or so. > > Even a minute is a long time compared to 3 seconds which is what an incremental build with a couple new/modified implementation files should take. > > But configure needs to run a lot of tests which involves invoking the compiler a lot of times (it needs to run the compiler on tiny test programs to generate understandable errors as soon as possible, squashing it together into a big compilation later is bad because errors become confusing). I'm not sure that <1 minute is achievable, but I hope it is. > > Then you are not going to like my next idea. I think that "configure" tests should be imbedded directly into the source code and evaluated at compile time to determine what gets built etc. In other words no distinction between configure and build time :-). > > How to handle tests that need to actually be executed, in a batch environment? > > This also eliminates the possibility of "incorrect semantic information in comments" since the comments won't be "requires X Y and Z" but instead the actual tests. Having the test code for a functionality being in a different place than the use of a functionality is not a good model (the obvious problem with what I say is that the use might be in 50 places so should I have the same test in 50 places?) > > And should the test be executed in all 50 places, or should the result be cached? Since C code is context dependent, it would be hard to prove that it was actually the same test in all 50 places, even if it resided in a common header.

1 0

Re: [petsc-dev] Trying to get the CMake instructions to work, unsuccessfully
by Richard Tran Mills 02 Feb '11

02 Feb '11

I should probably add that I was configuring with Configure Options: --configModules=PETSc.Configure --optionsModule=PETSc.compilerOptions --with-cc=gcc --with-fc=gfortran --with-cxx=g++ COPTFLAGS=-g FOPTFLAGS=-g CXXOPTFLAGS=-g --download-f-blas-lapack=1 --download-mpich=1 --download-hdf5=1 --download-hypre=1 --download-ml=1 --download-blacs=1 --download-scalapack=1 --download-parmetis=1 --download-plapack=1 --with-cmake=/usr/bin/cmake PETSC_ARCH=ubuntu-gnu_g --Richard On 2/2/2011 6:22 PM, Richard Tran Mills wrote: > Hi Jed, > > I get the following: > > ----- > rmills@ubuntu:~/proj/petsc-dev/ubuntu-gnu_g$ /usr/bin/cmake > /home/rmills/proj/petsc-dev -DCMAKE_C_FLAGS=' -Wall -Wwrite-strings > -Wno-strict-aliasing -Wno-unknown-pragmas -g' > -DCMAKE_C_COMPILER='/home/rmills/proj/petsc-dev/ubuntu-gnu_g/bin/mpicc' > -DCMAKE_Fortran_FLAGS='-Wall -Wno-unused-variable -g' > -DCMAKE_Fortran_COMPILER='/home/rmills/proj/petsc-dev/ubuntu-gnu_g/bin/mpif90' > CMake Error: The following variables are used in this project, but they are > set to NOTFOUND. > Please set them or make sure they are set and tested correctly in the CMake > files: > PETSC_STDC++_LIB (ADVANCED) > linked by target "petsc" in directory /home/rmills/proj/petsc-dev > > -- Configuring incomplete, errors occurred! > ----- > > --Richard > > On 2/2/2011 11:51 AM, Jed Brown wrote: >> '/usr/bin/cmake', '/home/rmills/proj/petsc-dev', '-DCMAKE_C_FLAGS= -Wall >> -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g', >> '-DCMAKE_C_COMPILER=/home/rmills/proj/petsc-dev/ubuntu-gnu_g/bin/mpicc', >> '-DCMAKE_Fortran_FLAGS= -Wall -Wno-unused-variable -g', >> '-DCMAKE_Fortran_COMPILER=/home/rmills/proj/petsc-dev/ubuntu-gnu_g/bin/mpif90' > -- Richard Tran Mills, Ph.D. | E-mail: rmills(a)climate.ornl.gov Computational Scientist | Phone: (865) 241-3198 Computational Earth Sciences Group | Fax: (865) 574-0405 Oak Ridge National Laboratory | http://climate.ornl.gov/~rmills

1 0

Re: [petsc-dev] Trying to get the CMake instructions to work, unsuccessfully
by Richard Tran Mills 02 Feb '11

02 Feb '11

Hi Jed, I get the following: ----- rmills@ubuntu:~/proj/petsc-dev/ubuntu-gnu_g$ /usr/bin/cmake /home/rmills/proj/petsc-dev -DCMAKE_C_FLAGS=' -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g' -DCMAKE_C_COMPILER='/home/rmills/proj/petsc-dev/ubuntu-gnu_g/bin/mpicc' -DCMAKE_Fortran_FLAGS='-Wall -Wno-unused-variable -g' -DCMAKE_Fortran_COMPILER='/home/rmills/proj/petsc-dev/ubuntu-gnu_g/bin/mpif90' CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: PETSC_STDC++_LIB (ADVANCED) linked by target "petsc" in directory /home/rmills/proj/petsc-dev -- Configuring incomplete, errors occurred! ----- --Richard On 2/2/2011 11:51 AM, Jed Brown wrote: > '/usr/bin/cmake', '/home/rmills/proj/petsc-dev', '-DCMAKE_C_FLAGS= -Wall > -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g', > '-DCMAKE_C_COMPILER=/home/rmills/proj/petsc-dev/ubuntu-gnu_g/bin/mpicc', > '-DCMAKE_Fortran_FLAGS= -Wall -Wno-unused-variable -g', > '-DCMAKE_Fortran_COMPILER=/home/rmills/proj/petsc-dev/ubuntu-gnu_g/bin/mpif90' -- Richard Tran Mills, Ph.D. | E-mail: rmills(a)climate.ornl.gov Computational Scientist | Phone: (865) 241-3198 Computational Earth Sciences Group | Fax: (865) 574-0405 Oak Ridge National Laboratory | http://climate.ornl.gov/~rmills

1 0

Re: [petsc-dev] Trying to get the CMake instructions to work, unsuccessfully
by Jed Brown 02 Feb '11

02 Feb '11

On Wed, Feb 2, 2011 at 13:37, Richard Tran Mills <rmills(a)climate.ornl.gov>wrote: > But farther down in the configure.log I find > > Invoking: ['/usr/bin/cmake', '/home/rmills/proj/petsc-dev', > '-DCMAKE_C_FLAGS= -Wall -Wwrite-strings -Wno-strict-aliasing > -Wno-unknown-pragmas -g', > '-DCMAKE_C_COMPILER=/home/rmills/proj/petsc-dev/ubuntu-gnu_g/bin/mpicc', > '-DCMAKE_Fortran_FLAGS= -Wall -Wno-unused-variable -g', > '-DCMAKE_Fortran_COMPILER=/home/rmills/proj/petsc-dev/ubuntu-gnu_g/bin/mpif90'] > Booting CMake in PETSC_ARCH failed: > CMake process failed with status 1 > > in the output associated with configureFortranFlush. So it looks like the > CMake "boot" is failing. Can you offer any advice on how to proceed? I will set up stdout/stderr capturing in the next day or two (when I am at my computer). For now, could you cd $PETSC_ARCH, invoke the command line above, and paste the full error message?

1 0

Re: [petsc-dev] Trying to get the CMake instructions to work, unsuccessfully
by Satish Balay 02 Feb '11

02 Feb '11

I think there is some stuff on stdout. configure should capture this and place it in configure.log. Satish On Wed, 2 Feb 2011, Richard Tran Mills wrote: > Hmm. I see in my configure.log that configureCMake succeeds: > > ================================================================================ > TEST configureCMake from > PETSc.utilities.CMake(/home/rmills/proj/petsc-dev/config/PETSc/utilities/CMake.py:21) > TESTING: configureCMake from > PETSc.utilities.CMake(config/PETSc/utilities/CMake.py:21) > Check various things about cmake > Checking for program /usr/bin/cmake...found > Defined make macro "CMAKE" to "/usr/bin/cmake" > ================================================================================ > > But farther down in the configure.log I find > > Invoking: ['/usr/bin/cmake', '/home/rmills/proj/petsc-dev', > '-DCMAKE_C_FLAGS= -Wall -Wwrite-strings -Wno-strict-aliasing > -Wno-unknown-pragmas -g', > '-DCMAKE_C_COMPILER=/home/rmills/proj/petsc-dev/ubuntu-gnu_g/bin/mpicc', > '-DCMAKE_Fortran_FLAGS= -Wall -Wno-unused-variable -g', > '-DCMAKE_Fortran_COMPILER=/home/rmills/proj/petsc-dev/ubuntu-gnu_g/bin/mpif90'] > Booting CMake in PETSC_ARCH failed: > CMake process failed with status 1 > > in the output associated with configureFortranFlush. So it looks like the > CMake "boot" is failing. Can you offer any advice on how to proceed? > > Thanks, > Richard > > On 2/2/2011 11:21 AM, Jed Brown wrote: > > On Wed, Feb 2, 2011 at 13:12, Richard Tran Mills <rmills(a)climate.ornl.gov > > <mailto:[email protected]>> wrote: > > > > Thanks for your responses. However, that is the first thing that I > > tried: > > > > rmills@ubuntu:~/proj/petsc-dev$ make -C ubuntu-gnu_g/ > > make: Entering directory `/home/rmills/proj/petsc-dev/ubuntu-gnu_g' > > make: *** No targets specified and no makefile found. Stop. > > make: Leaving directory `/home/rmills/proj/petsc-dev/ubuntu-gnu_g' > > > > Then I assumed that the instructions meant to say 'cmake', not 'make'. > > What is supposed to generate the makefile that gets used? > > > > > > configure should have generated petsc-dev/ubuntu-gnu_g/Makefile if cmake was > > found. Try > > rm -r CMake* ubuntu-gnu_g/CMake* > > # reconfigure if ubuntu-gnu_g/conf/PETScConfig.cmake is missing > > # otherwise you can just run config/cmakeboot.py (faster) > > make -C ubuntu-gnu_g > >

1 0

Re: [petsc-dev] Trying to get the CMake instructions to work, unsuccessfully
by Richard Tran Mills 02 Feb '11

02 Feb '11

Hmm. I see in my configure.log that configureCMake succeeds: ================================================================================ TEST configureCMake from PETSc.utilities.CMake(/home/rmills/proj/petsc-dev/config/PETSc/utilities/CMake.py:21) TESTING: configureCMake from PETSc.utilities.CMake(config/PETSc/utilities/CMake.py:21) Check various things about cmake Checking for program /usr/bin/cmake...found Defined make macro "CMAKE" to "/usr/bin/cmake" ================================================================================ But farther down in the configure.log I find Invoking: ['/usr/bin/cmake', '/home/rmills/proj/petsc-dev', '-DCMAKE_C_FLAGS= -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g', '-DCMAKE_C_COMPILER=/home/rmills/proj/petsc-dev/ubuntu-gnu_g/bin/mpicc', '-DCMAKE_Fortran_FLAGS= -Wall -Wno-unused-variable -g', '-DCMAKE_Fortran_COMPILER=/home/rmills/proj/petsc-dev/ubuntu-gnu_g/bin/mpif90'] Booting CMake in PETSC_ARCH failed: CMake process failed with status 1 in the output associated with configureFortranFlush. So it looks like the CMake "boot" is failing. Can you offer any advice on how to proceed? Thanks, Richard On 2/2/2011 11:21 AM, Jed Brown wrote: > On Wed, Feb 2, 2011 at 13:12, Richard Tran Mills <rmills(a)climate.ornl.gov > <mailto:[email protected]>> wrote: > > Thanks for your responses. However, that is the first thing that I tried: > > rmills@ubuntu:~/proj/petsc-dev$ make -C ubuntu-gnu_g/ > make: Entering directory `/home/rmills/proj/petsc-dev/ubuntu-gnu_g' > make: *** No targets specified and no makefile found. Stop. > make: Leaving directory `/home/rmills/proj/petsc-dev/ubuntu-gnu_g' > > Then I assumed that the instructions meant to say 'cmake', not 'make'. > What is supposed to generate the makefile that gets used? > > > configure should have generated petsc-dev/ubuntu-gnu_g/Makefile if cmake was > found. Try > rm -r CMake* ubuntu-gnu_g/CMake* > # reconfigure if ubuntu-gnu_g/conf/PETScConfig.cmake is missing > # otherwise you can just run config/cmakeboot.py (faster) > make -C ubuntu-gnu_g -- Richard Tran Mills, Ph.D. | E-mail: rmills(a)climate.ornl.gov Computational Scientist | Phone: (865) 241-3198 Computational Earth Sciences Group | Fax: (865) 574-0405 Oak Ridge National Laboratory | http://climate.ornl.gov/~rmills

1 0