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

Re: [petsc-dev] DMDA_*PERIODIC and DMDA_XYZGHOSTED
by Lisandro Dalcin 11 Mar '11

11 Mar '11

On 11 March 2011 13:16, Ethan Coon <ecoon(a)lanl.gov> wrote: > The IOR() intrinsic does this in every fortran compiler I've been able > to test (gnu, pgi, intel, absoft) (yes, I find it sad that I have that > many fortran compilers available to me here... I think we have nag > somewhere as well...). > > Will clean them out. > Hey, we have a serious issue with C++! Sorry, I've just realized. See below: $ cat cpp_enum.cpp enum Enum {A=0,B=1}; void foo(Enum e){} void test() {foo(A|B);} $ g++ cpp_enum.cpp cpp_enum.cpp: In function ‘void test()’: cpp_enum.cpp:3: error: invalid conversion from ‘int’ to ‘Enum’ cpp_enum.cpp:3: error: initializing argument 1 of ‘void foo(Enum)’ We have two options: 1) Change the argument of DMDASetBoundaryType to "int", do the same with the 'wrap' slot in DM_DA structure. 2) Change to the cleaner API I've suggested in my previous mail (with OK from Barry). -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

1 0

Re: [petsc-dev] DMDA_*PERIODIC and DMDA_XYZGHOSTED
by Ethan Coon 11 Mar '11

11 Mar '11

The IOR() intrinsic does this in every fortran compiler I've been able to test (gnu, pgi, intel, absoft) (yes, I find it sad that I have that many fortran compilers available to me here... I think we have nag somewhere as well...). Will clean them out. Ethan On Thu, 2011-03-10 at 19:37 -0600, Barry Smith wrote: > Ok get rid of them and we'll live with the consequences :-) > > barry > > On Mar 10, 2011, at 6:57 PM, Lisandro Dalcin wrote: > > > On 10 March 2011 21:45, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > >> > >> On Mar 10, 2011, at 6:22 PM, Lisandro Dalcin wrote: > >> > >>> On 10 March 2011 20:57, Ethan Coon <ecoon(a)lanl.gov> wrote: > >>>> Attached patch makes this change, and updates the website with the API > >>>> change. > >>>> > >>>> Also it fixes a few stray 'DAPeriodicType's in conf/adic*.init, which > >>>> I'm guessing was just missed in the previous change to DMDAPeriodicType? > >>> > >>> Do we really need backward compatibility DMDA_XYZPERIODIC and friends? > >> > >> Is the | business all fine and dandy for Fortran? If so then I agree we should remove the "noise". > >> > > > > Well, you can use '+' (with a bit care) in any Fortran, right?. This > > is the way the MPI standard does things for some enumerations (file > > modes, RMA assertions). > > > > However, if DMDA_XYZPERIODIC and friends do no go away because of > > Fortran issues, then we should definitely define > > DMDA_{XY|XZ|YZ}GHOSTED. > > > > > > -- > > Lisandro Dalcin > > --------------- > > CIMEC (INTEC/CONICET-UNL) > > Predio CONICET-Santa Fe > > Colectora RN 168 Km 472, Paraje El Pozo > > 3000 Santa Fe, Argentina > > Tel: +54-342-4511594 (ext 1011) > > Tel/Fax: +54-342-4511169 > -- ------------------------------------ Ethan Coon Post-Doctoral Researcher Applied Mathematics - T-5 Los Alamos National Laboratory 505-665-8289 http://www.ldeo.columbia.edu/~ecoon/ ------------------------------------

1 0

Re: [petsc-dev] Help with configure and cmake
by Jed Brown 11 Mar '11

11 Mar '11

On Fri, Mar 11, 2011 at 13:02, Jose E. Roman <jroman(a)dsic.upv.es> wrote: > I have been adding support for cmake in SLEPc. My simple approach is: > 1) generate a SLEPcConfig.cmake file > 2) generate CMakeLists.txt with a cmakegen module adapted from petsc-dev > 3) run cmake with a cmakeboot module adapted from petsc-dev > > Step 3 loads RDict and uses 'script' to process all PETSc configuration. > The problem comes with prefix-based installations of PETSc, since 'script' > is not available. > Seems to me that necessary script support should be installed with prefix installs too. I do not understand why "script" is such a cumbersome beast to actually use, but it could be installed. However, exposing it to users turns much of BuildSystem into a public API. This does not seem like a good idea, especially with Barry's recent "cll" proposal for a much simpler alternative to parts of BuildSystem. As a long-term solution, I think we should install a pkgconfig file and/or a "petsc-config" script that knows about compilers, how to link shared versus static, etc. > Can anyone suggest a solution for this? Maybe use Jed's FindPETSc.cmake > module? > If you decide to use it, let me know if you find any problems. Writing significant logic in cmake-script is no fun.

1 0

Help with configure and cmake
by Jose E. Roman 11 Mar '11

11 Mar '11

I have been adding support for cmake in SLEPc. My simple approach is: 1) generate a SLEPcConfig.cmake file 2) generate CMakeLists.txt with a cmakegen module adapted from petsc-dev 3) run cmake with a cmakeboot module adapted from petsc-dev Step 3 loads RDict and uses 'script' to process all PETSc configuration. The problem comes with prefix-based installations of PETSc, since 'script' is not available. Can anyone suggest a solution for this? Maybe use Jed's FindPETSc.cmake module? Thanks. Jose

1 0

Re: [petsc-dev] Compiling petsc with superlu_dist, hypre and mumps on hopper II
by Satish Balay 10 Mar '11

10 Mar '11

Pushed this change. Satish On Thu, 10 Mar 2011, Barry Smith wrote: > > Perhaps we can have configure - not abort if 'mpiexec' not found? > > Sounds good. Have it not abort. perhaps a warning message? perhaps not no warning message needed. > > Barry > > > > > Satish > > > > ----- > > diff -r 88e278a08859 config/packages/MPI.py > > --- a/config/packages/MPI.py Sat Mar 05 14:24:18 2011 -0600 > > +++ b/config/packages/MPI.py Thu Mar 10 20:30:24 2011 -0600 > > @@ -155,7 +155,7 @@ > > self.mpiexec = 'Not_appropriate_for_batch_systems' > > self.addMakeMacro('MPIEXEC',self.mpiexec) > > return > > - mpiexecs = ['mpiexec -n 1', 'mpirun -n 1', 'mprun -n 1', 'mpiexec', 'mpirun', 'mprun'] > > + mpiexecs = ['mpiexec -n 1', 'mpirun -n 1', 'mprun -n 1', 'mpiexec', 'mpirun', 'mprun', '/bin/false'] > > path = [] > > if 'with-mpi-dir' in self.framework.argDB: > > path.append(os.path.join(os.path.abspath(self.framework.argDB['with-mpi-dir']), 'bin')) > >

1 0

Re: [petsc-dev] Compiling petsc with superlu_dist, hypre and mumps on hopper II
by Barry Smith 10 Mar '11

10 Mar '11

On Mar 10, 2011, at 8:54 PM, Satish Balay wrote: > On Thu, 10 Mar 2011, Barry Smith wrote: > >> >> On Mar 10, 2011, at 4:46 PM, fabien delalondre wrote: >> >>> Hi, >>> >>> Which argument should I pass to pass to compile petsc on hopper II with superlu_dist, hypre and mumps (download) ? Without external package --with-mpi=0 works fine but then the external packages complain about it (no mpi specified). I tried to use and also modify the arch-cray-xt5-opt.py configure file but I did not go through it yet (Invalid mpiexec specified: /usr/common/acts/PETSc/3.0.0/bin/mpiexec.aprun). Instead of wasting time, I guess you guys will provide an answer pretty quickly. >> >> Satish, >> >> Why does --with-mpiexec have to be set on hopper? And why to this crazy location that may not always exist? Requiring the user to set this beast to some strange thing at configure time is not reasonable. We need a model that doesn't require strange knowledge like this. >> > > The explanation for the strange thing in arch-cray-xt5-opt.py is: I > started off with a reconfigure.py file from a prior install by nersc > folks - so had some of this stuff in from there. [mpiexec.aprun is a > derivative of one of the scripts we have in PETSC_DIR/bin/mpiexec.*] > > Looks like --with-mpiexec=/bin/false would also work on this machine. > > currently mpiexec is checked by configure primarily for for 'make > test' stuff and 'check-mpi-shared' test. > > We now have --with-batch=1 that generally works for machines where > things can't be run directly. Here - on cray - configure seem to work > directly - without batch - and without mpiexec. > > Perhaps we can have configure - not abort if 'mpiexec' not found? Sounds good. Have it not abort. perhaps a warning message? perhaps not no warning message needed. Barry > > Satish > > ----- > diff -r 88e278a08859 config/packages/MPI.py > --- a/config/packages/MPI.py Sat Mar 05 14:24:18 2011 -0600 > +++ b/config/packages/MPI.py Thu Mar 10 20:30:24 2011 -0600 > @@ -155,7 +155,7 @@ > self.mpiexec = 'Not_appropriate_for_batch_systems' > self.addMakeMacro('MPIEXEC',self.mpiexec) > return > - mpiexecs = ['mpiexec -n 1', 'mpirun -n 1', 'mprun -n 1', 'mpiexec', 'mpirun', 'mprun'] > + mpiexecs = ['mpiexec -n 1', 'mpirun -n 1', 'mprun -n 1', 'mpiexec', 'mpirun', 'mprun', '/bin/false'] > path = [] > if 'with-mpi-dir' in self.framework.argDB: > path.append(os.path.join(os.path.abspath(self.framework.argDB['with-mpi-dir']), 'bin'))

1 0

Re: [petsc-dev] DMDABoundaryType
by Barry Smith 10 Mar '11

10 Mar '11

Sounds good to me. Barry On Mar 10, 2011, at 8:53 PM, Lisandro Dalcin wrote: > While updating petsc4py for the latest DMDA chages, and alto taking > into account some new in NumPy C API related to neighborhood > iterators, I've got new idea. What about the API below?: > > enum DMDABoundaryType: > DMDA_BOUNDARY_NONE = 0 > DMDA_BOUNDARY_GHOSTED = 1 > DMDA_BOUNDARY_MIRROR = 2 > DMDA_BOUNDARY_PERIODIC = 4 > > PetscErrorCode DMDASetBoundaryType(DM dm, DMDABoundaryType bx, > DMDABoundaryType by, DMDABoundaryType bz) > > Changes for GHOSTED and PERIODIC should be easy > (http://lkml.org/lkml/2000/8/25/132) ;-). > > The new MIRROR boundary type could be implemented later. > > > > -- > Lisandro Dalcin > --------------- > CIMEC (INTEC/CONICET-UNL) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1011) > Tel/Fax: +54-342-4511169

1 0

Re: [petsc-dev] Compiling petsc with superlu_dist, hypre and mumps on hopper II
by Satish Balay 10 Mar '11

10 Mar '11

On Thu, 10 Mar 2011, Barry Smith wrote: > > On Mar 10, 2011, at 4:46 PM, fabien delalondre wrote: > > > Hi, > > > > Which argument should I pass to pass to compile petsc on hopper II with superlu_dist, hypre and mumps (download) ? Without external package --with-mpi=0 works fine but then the external packages complain about it (no mpi specified). I tried to use and also modify the arch-cray-xt5-opt.py configure file but I did not go through it yet (Invalid mpiexec specified: /usr/common/acts/PETSc/3.0.0/bin/mpiexec.aprun). Instead of wasting time, I guess you guys will provide an answer pretty quickly. > > Satish, > > Why does --with-mpiexec have to be set on hopper? And why to this crazy location that may not always exist? Requiring the user to set this beast to some strange thing at configure time is not reasonable. We need a model that doesn't require strange knowledge like this. > The explanation for the strange thing in arch-cray-xt5-opt.py is: I started off with a reconfigure.py file from a prior install by nersc folks - so had some of this stuff in from there. [mpiexec.aprun is a derivative of one of the scripts we have in PETSC_DIR/bin/mpiexec.*] Looks like --with-mpiexec=/bin/false would also work on this machine. currently mpiexec is checked by configure primarily for for 'make test' stuff and 'check-mpi-shared' test. We now have --with-batch=1 that generally works for machines where things can't be run directly. Here - on cray - configure seem to work directly - without batch - and without mpiexec. Perhaps we can have configure - not abort if 'mpiexec' not found? Satish ----- diff -r 88e278a08859 config/packages/MPI.py --- a/config/packages/MPI.py Sat Mar 05 14:24:18 2011 -0600 +++ b/config/packages/MPI.py Thu Mar 10 20:30:24 2011 -0600 @@ -155,7 +155,7 @@ self.mpiexec = 'Not_appropriate_for_batch_systems' self.addMakeMacro('MPIEXEC',self.mpiexec) return - mpiexecs = ['mpiexec -n 1', 'mpirun -n 1', 'mprun -n 1', 'mpiexec', 'mpirun', 'mprun'] + mpiexecs = ['mpiexec -n 1', 'mpirun -n 1', 'mprun -n 1', 'mpiexec', 'mpirun', 'mprun', '/bin/false'] path = [] if 'with-mpi-dir' in self.framework.argDB: path.append(os.path.join(os.path.abspath(self.framework.argDB['with-mpi-dir']), 'bin'))

1 0

DMDABoundaryType
by Lisandro Dalcin 10 Mar '11

10 Mar '11

While updating petsc4py for the latest DMDA chages, and alto taking into account some new in NumPy C API related to neighborhood iterators, I've got new idea. What about the API below?: enum DMDABoundaryType: DMDA_BOUNDARY_NONE = 0 DMDA_BOUNDARY_GHOSTED = 1 DMDA_BOUNDARY_MIRROR = 2 DMDA_BOUNDARY_PERIODIC = 4 PetscErrorCode DMDASetBoundaryType(DM dm, DMDABoundaryType bx, DMDABoundaryType by, DMDABoundaryType bz) Changes for GHOSTED and PERIODIC should be easy (http://lkml.org/lkml/2000/8/25/132) ;-). The new MIRROR boundary type could be implemented later. -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

1 0

Re: [petsc-dev] DMDA_*PERIODIC and DMDA_XYZGHOSTED
by Barry Smith 10 Mar '11

10 Mar '11

Ok get rid of them and we'll live with the consequences :-) barry On Mar 10, 2011, at 6:57 PM, Lisandro Dalcin wrote: > On 10 March 2011 21:45, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >> >> On Mar 10, 2011, at 6:22 PM, Lisandro Dalcin wrote: >> >>> On 10 March 2011 20:57, Ethan Coon <ecoon(a)lanl.gov> wrote: >>>> Attached patch makes this change, and updates the website with the API >>>> change. >>>> >>>> Also it fixes a few stray 'DAPeriodicType's in conf/adic*.init, which >>>> I'm guessing was just missed in the previous change to DMDAPeriodicType? >>> >>> Do we really need backward compatibility DMDA_XYZPERIODIC and friends? >> >> Is the | business all fine and dandy for Fortran? If so then I agree we should remove the "noise". >> > > Well, you can use '+' (with a bit care) in any Fortran, right?. This > is the way the MPI standard does things for some enumerations (file > modes, RMA assertions). > > However, if DMDA_XYZPERIODIC and friends do no go away because of > Fortran issues, then we should definitely define > DMDA_{XY|XZ|YZ}GHOSTED. > > > -- > Lisandro Dalcin > --------------- > CIMEC (INTEC/CONICET-UNL) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1011) > Tel/Fax: +54-342-4511169

1 0