[petsc-dev] Making a PetSc Roll and Rocks Module
the usual naming scheme is just the version number, but for petsc, most supercomputing centers use %version-%arch the installer will copy the file into $MODULEPATH/petsc/%version-%arch, or the user to $HOME/.modulefiles Of course, %version-%arch is a really silly name out of context. How about petsc-%version-%arch, somewhere within $PETSC_DIR/$PETSC_ARCH, or $PETSC_DIR/$PETSC_ARCH/modulefiles/%version-%arch ? Blaise On Jan 24, 2013, at 6:19 PM, Satish Balay balay at mcs.anl.gov wrote: On Thu, 24 Jan 2013, Matthew Knepley wrote: On Thu, Jan 24, 2013 at 3:42 PM, Blaise A Bourdin bourdin at lsu.edu wrote: I am attaching a very basic module file for reference. One would need to update petsc_dir and petsc_arch upon deploying these, or perhaps configure can do it. I actually use this to easily switch between builds and debug / optimized versions Pushed something that writes your simple module file to lib/modules/PETSc.mod. It would now be good to get feedback to make this the right thing. The name conflists with f90 modules. Perhaps there is a different notation for software modules? Also for prefix install we should set PETSC_ARCH= And for inplace install - do we also add PETSC_DIR/bin to PATH? Satish -- Department of Mathematics and Center for Computation Technology Louisiana State University, Baton Rouge, LA 70803, USA Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin
[petsc-dev] Making a PetSc Roll and Rocks Module
On Jan 24, 2013, at 6:37 PM, Satish Balay balay at mcs.anl.gov wrote: On Fri, 25 Jan 2013, Blaise A Bourdin wrote: the usual naming scheme is just the version number, but for petsc, most supercomputing centers use %version-%arch the installer will copy the file into $MODULEPATH/petsc/%version-%arch, or the user to $HOME/.modulefiles Of course, %version-%arch is a really silly name out of context. How about petsc-%version-%arch, somewhere within $PETSC_DIR/$PETSC_ARCH, or $PETSC_DIR/$PETSC_ARCH/modulefiles/%version-%arch ? And PETSC_ARCH has no singificance with prefix install [the significant text is in the prefix-path - and one doesn't have to match PETSC_ARCH to this significant text] True. I actually realized that as I was hitting send BTW: Is the following notation ok? [google didn't help] prepend-path PATH /home/balay/spetsc/asterix64/bin:/home/balay/spetsc/bin It seems to work, but prepend-path PATH /home/balay/spetsc/asterix64/bin prepend-path PATH /home/balay/spetsc/bin may be safer. Both will break under windows, but I don't think it is a problem, really Blaise I have some fixes [except for the modfile name] which I can push. thanks, Satish Blaise On Jan 24, 2013, at 6:19 PM, Satish Balay balay at mcs.anl.gov wrote: On Thu, 24 Jan 2013, Matthew Knepley wrote: On Thu, Jan 24, 2013 at 3:42 PM, Blaise A Bourdin bourdin at lsu.edu wrote: I am attaching a very basic module file for reference. One would need to update petsc_dir and petsc_arch upon deploying these, or perhaps configure can do it. I actually use this to easily switch between builds and debug / optimized versions Pushed something that writes your simple module file to lib/modules/PETSc.mod. It would now be good to get feedback to make this the right thing. The name conflists with f90 modules. Perhaps there is a different notation for software modules? Also for prefix install we should set PETSC_ARCH= And for inplace install - do we also add PETSC_DIR/bin to PATH? Satish -- Department of Mathematics and Center for Computation Technology Louisiana State University, Baton Rouge, LA 70803, USA Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin
[petsc-dev] Making a PetSc Roll and Rocks Module
Begin forwarded message: From: Philip Papadopoulos philip.papadopoulos at gmail.com Subject: Re: [petsc-maint #149715] Making a PetSc Roll and Rocks Module Date: January 24, 2013 9:48:36 AM CST To: Schneider, Barry I. bschneid at nsf.gov Cc: Barry Smith bsmith at mcs.anl.gov Dear Barry^2, The major observation about the build process is that building the software so that it can livesw- in a standard OS package is more work than it should be. Here is the standard meme. Suppose you have three directories: sw-src tmpoot/sw-install sw-install sw-src: the source directory tree for building the sw package (eg petsc-3.3-p5) sw-install: the directory where one wants sw installed on the final system. We use something like /opt/petsc/compiler/mpi/interconnect/petsc-version/petsc-arch the last directory is an artifact of the way many people build software for packaging. Instead of installing into sw-install directly, you install into a tmproot/sw-install. Then you direct the package manager to grab all files in tmproot/sw-install to put in the package. The package itself will strip off the tmproot leading directory. In other words the package labels all files as sw-install/. So the build issue that I ran into is that the build directory and/or the tmproot directory path becomes embedded into a large number of files (include files, mod files, etc). To get around this, I did a bind mount of (tmproot/sw-install -- /sw-install) and told petsc to install into /sw-install. I consider that to be a hack, but petsc isn't the only software that I've run into that requires this mounting bit of legerdemain. Many software packages will support a dest= or DESTDIR variable for make install that supports the installation into a tmproot directory but leaves no trace of tmproot in any of its configuration files. (http://git.rocksclusters.org/cgi-bin/gitweb.cgi?p=core/python/.git;a=blob;f=src/python-2/Makefile;h=ced6cc1c6eb6a4f70dd0f3e1b0ccd1ac1e40f989;hb=HEAD) shows a Makefile for python that supports this. Ultimately we create packages of software to simplify a number of things. Including update of installed software on many machines. The other issue is not really an issue, but a request. When petsc is built it creates a petscvariables (or similarly named) file with lots of environment variables. It would be terrific if it could also create an environment modules files with this same information. Users often want different versions/different configs of the same software and environment modules is now standard in Redhat/CentOS distributions. Hope this helps. On Thu, Jan 24, 2013 at 2:44 AM, Schneider, Barry I. bschneid at nsf.gov wrote: Barry, I am sending this to Phil Papadopoulos and he can make much more precise recommendations. Glad you have thick skins. Being at NSF requires the same physiology. -Original Message- From: Barry Smith [mailto:bsmith at mcs.anl.gov] Sent: Wednesday, January 23, 2013 10:19 PM To: Schneider, Barry I. Subject: Re: [petsc-maint #149715] Making a PetSc Roll and Rocks Module Barry, By far the most common email we get is regarding installation, so we are always trying to understand how to improve that process. If we can eliminate just 20 percent of installation problems that would save us a great deal of work, so yes, any critique/suggestions are greatly appreciated, and after all these years we have thick skins so can survive even the harshest suggestions. Barry On Jan 23, 2013, at 6:13 PM, Schneider, Barry I. bschneid at nsf.gov wrote: Barry, First, thanks for getting back to me so quickly. I view this as a way to make things easier for everyone for a library that is really invaluable to many of us. Phil P. is a pro at making rolls and modules for the Rocks distribution of CentOS that is widely used in the NSF cyberinfrastructure and by others. I am both a program manager for the XSEDE project and a large user as well so I appreciate the ability to use the library in its most transparent fashion. After Phil did his thing we tested it and it worked perfectly on our cluster. Basically, you load the module and any associated modules such as the Intel compiler and appropriate MPI module and then you just use it. No screwing around with building and the rest of it. That's the good news. Of course, you need to make a roll for every specific combination of compiler and MPI but I believe what Phil has learned makes that pretty straightforward to do. While I cannot speak for Phil, I would expect that anything he learned would be available to you folks if that's what you wanted. The next step for us will be to incorporate what we did in the Rocks distribution which will eventually propagate to lots of users. Eventually, there will be an XSEDE distribution which
[petsc-dev] Making a PetSc Roll and Rocks Module
On Thu, Jan 24, 2013 at 12:51 PM, Barry Smith bsmith at mcs.anl.gov wrote: Begin forwarded message: *From: *Philip Papadopoulos philip.papadopoulos at gmail.com *Subject: **Re: [petsc-maint #149715] Making a PetSc Roll and Rocks Module * *Date: *January 24, 2013 9:48:36 AM CST *To: *Schneider, Barry I. bschneid at nsf.gov *Cc: *Barry Smith bsmith at mcs.anl.gov Dear Barry^2, The major observation about the build process is that building the software so that it can livesw- in a standard OS package is more work than it should be. Here is the standard meme. Suppose you have three directories: sw-src tmpoot/sw-install sw-install sw-src: the source directory tree for building the sw package (eg petsc-3.3-p5) sw-install: the directory where one wants sw installed on the final system. We use something like /opt/petsc/compiler/mpi/interconnect/petsc-version/petsc-arch the last directory is an artifact of the way many people build software for packaging. Instead of installing into sw-install directly, you install into a tmproot/sw-install. Then you direct the package manager to grab all files in tmproot/sw-install to put in the package. The package itself will strip off the tmproot leading directory. In other words the package labels all files as sw-install/. So the build issue that I ran into is that the build directory and/or the tmproot directory path becomes embedded into a large number of files (include files, mod files, etc). To get around this, I did a bind mount of (tmproot/sw-install -- /sw-install) and told petsc to install into /sw-install. I consider that to be a hack, but petsc isn't the only software that I've run into that requires this mounting bit of legerdemain. Many software packages will support a dest= or DESTDIR variable for make install that supports the installation into a tmproot directory but leaves no trace of tmproot in any of its configuration files. ( http://git.rocksclusters.org/cgi-bin/gitweb.cgi?p=core/python/.git;a=blob;f=src/python-2/Makefile;h=ced6cc1c6eb6a4f70dd0f3e1b0ccd1ac1e40f989;hb=HEAD) shows a Makefile for python that supports this. Okay, we should be able to do that anyway I guess. I will do it (probably with Satish helping me). Ultimately we create packages of software to simplify a number of things. Including update of installed software on many machines. The other issue is not really an issue, but a request. When petsc is built it creates a petscvariables (or similarly named) file with lots of environment variables. It would be terrific if it could also create an environment modules files with this same information. Users often want different versions/different configs of the same software and environment modules is now standard in Redhat/CentOS distributions. We already create a PETSc.mk file for pkgconfig, so doing another one is not hard. Here is us doing that: https://bitbucket.org/petsc/petsc-dev/src/b94b5d6f0ee5d4de5a64fc5f0d1a4e01c743cf04/config/PETSc/Configure.py?at=default#cl-108 and the Dump() function sets up the information in the petscvariables file by calling addMakeMacro(). Care to try it yourself? I do not know the format for a modules file. We are always available to help. Thanks, Matt Hope this helps. On Thu, Jan 24, 2013 at 2:44 AM, Schneider, Barry I. bschneid at nsf.govwrote: Barry, I am sending this to Phil Papadopoulos and he can make much more precise recommendations. Glad you have thick skins. Being at NSF requires the same physiology. -Original Message- From: Barry Smith [mailto:bsmith at mcs.anl.gov] Sent: Wednesday, January 23, 2013 10:19 PM To: Schneider, Barry I. Subject: Re: [petsc-maint #149715] Making a PetSc Roll and Rocks Module Barry, By far the most common email we get is regarding installation, so we are always trying to understand how to improve that process. If we can eliminate just 20 percent of installation problems that would save us a great deal of work, so yes, any critique/suggestions are greatly appreciated, and after all these years we have thick skins so can survive even the harshest suggestions. Barry On Jan 23, 2013, at 6:13 PM, Schneider, Barry I. bschneid at nsf.gov wrote: Barry, First, thanks for getting back to me so quickly. I view this as a way to make things easier for everyone for a library that is really invaluable to many of us. Phil P. is a pro at making rolls and modules for the Rocks distribution of CentOS that is widely used in the NSF cyberinfrastructure and by others. I am both a program manager for the XSEDE project and a large user as well so I appreciate the ability to use the library in its most transparent fashion. After Phil did his thing we tested it and it worked perfectly on our cluster. Basically, you load the module and any associated modules such as the Intel compiler and appropriate MPI module and then you just
[petsc-dev] Making a PetSc Roll and Rocks Module
On Thu, 24 Jan 2013, Barry Smith wrote: Begin forwarded message: From: Philip Papadopoulos philip.papadopoulos at gmail.com Subject: Re: [petsc-maint #149715] Making a PetSc Roll and Rocks Module Date: January 24, 2013 9:48:36 AM CST To: Schneider, Barry I. bschneid at nsf.gov Cc: Barry Smith bsmith at mcs.anl.gov Dear Barry^2, The major observation about the build process is that building the software so that it can livesw- in a standard OS package is more work than it should be. Here is the standard meme. Suppose you have three directories: sw-src tmpoot/sw-install sw-install sw-src: the source directory tree for building the sw package (eg petsc-3.3-p5) sw-install: the directory where one wants sw installed on the final system. We use something like /opt/petsc/compiler/mpi/interconnect/petsc-version/petsc-arch the last directory is an artifact of the way many people build software for packaging. Instead of installing into sw-install directly, you install into a tmproot/sw-install. Then you direct the package manager to grab all files in tmproot/sw-install to put in the package. The package itself will strip off the tmproot leading directory. In other words the package labels all files as sw-install/. So the build issue that I ran into is that the build directory and/or the tmproot directory path becomes embedded into a large number of files (include files, mod files, etc). To get around this, I did a bind mount of (tmproot/sw-install -- /sw-install) and told petsc to install into /sw-install. I consider that to be a hack, but petsc isn't the only software that I've run into that requires this mounting bit of legerdemain. Many software packages will support a dest= or DESTDIR variable for make install that supports the installation into a tmproot directory but leaves no trace of tmproot in any of its configuration files. (http://git.rocksclusters.org/cgi-bin/gitweb.cgi?p=core/python/.git;a=blob;f=src/python-2/Makefile;h=ced6cc1c6eb6a4f70dd0f3e1b0ccd1ac1e40f989;hb=HEAD) shows a Makefile for python that supports this. We do support this install with DESTDIR. It might have rough edges - but its supporsed to work the same way any other package that supports it. One difference though is - since we also suppor the alternate orngaization [default] for inplace install with PETSC_ARCH - one has to use this PETSC_ARCH during the prefix build process aswell. [but then PETSC_ARCH is nolonger used/needed after that] i.e configure --prefix=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch1 PETSC_ARCH=build1 make PETSC_ARCH=build1 all make install PETSC_ARCH=build1 install DESTDIR=/tmp/dest1 package up from DESTDIR, and install as root: Now user does: make PETSC_DIR=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch1 ex1 configure [different options] --prefix=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch2 PETSC_ARCH=build2 make PETSC_ARCH=build2 all make install PETSC_ARCH=build2 install DESTDIR=/tmp/dest2 package up from DESTDIR, and install as root: Now user does: make PETSC_DIR=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch2 ex1 etc. There could be rough edges to this process as most folks use inplace install. But if it doesn't work for you we should fix. Ultimately we create packages of software to simplify a number of things. Including update of installed software on many machines. The other issue is not really an issue, but a request. When petsc is built it creates a petscvariables (or similarly named) file with lots of environment variables. It would be terrific if it could also create an environment modules files with this same information. Users often want different versions/different configs of the same software and environment modules is now standard in Redhat/CentOS distributions. The stuff petsc creates is in petscvariables for the consumption by 'make' and the only env variable the user needs [in this case with prefix install] is PETSC_DIR [as shown above for a prefix install]. Since this PETSC_DIR value is a prefix specfied to configure [for eg: --prefix=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch2] its value is known only to rocks pakcage builder. So it would know how to create the correct module [or whatever mechanicsm used to indentify/use] for a given petsc install. Satish Hope this helps. On Thu, Jan 24, 2013 at 2:44 AM, Schneider, Barry I. bschneid at nsf.gov wrote: Barry, I am sending this to Phil Papadopoulos and he can make much more precise recommendations. Glad you have thick skins. Being at NSF requires the same physiology. -Original Message- From: Barry Smith [mailto:bsmith at mcs.anl.gov] Sent: Wednesday, January 23, 2013 10:19 PM To: Schneider, Barry I. Subject: Re: [petsc-maint #149715] Making a PetSc Roll
[petsc-dev] Making a PetSc Roll and Rocks Module
On Thu, Jan 24, 2013 at 1:12 PM, Satish Balay balay at mcs.anl.gov wrote: On Thu, 24 Jan 2013, Barry Smith wrote: Begin forwarded message: From: Philip Papadopoulos philip.papadopoulos at gmail.com Subject: Re: [petsc-maint #149715] Making a PetSc Roll and Rocks Module Date: January 24, 2013 9:48:36 AM CST To: Schneider, Barry I. bschneid at nsf.gov Cc: Barry Smith bsmith at mcs.anl.gov Dear Barry^2, The major observation about the build process is that building the software so that it can livesw- in a standard OS package is more work than it should be. Here is the standard meme. Suppose you have three directories: sw-src tmpoot/sw-install sw-install sw-src: the source directory tree for building the sw package (eg petsc-3.3-p5) sw-install: the directory where one wants sw installed on the final system. We use something like /opt/petsc/compiler/mpi/interconnect/petsc-version/petsc-arch the last directory is an artifact of the way many people build software for packaging. Instead of installing into sw-install directly, you install into a tmproot/sw-install. Then you direct the package manager to grab all files in tmproot/sw-install to put in the package. The package itself will strip off the tmproot leading directory. In other words the package labels all files as sw-install/. So the build issue that I ran into is that the build directory and/or the tmproot directory path becomes embedded into a large number of files (include files, mod files, etc). To get around this, I did a bind mount of (tmproot/sw-install -- /sw-install) and told petsc to install into /sw-install. I consider that to be a hack, but petsc isn't the only software that I've run into that requires this mounting bit of legerdemain. Many software packages will support a dest= or DESTDIR variable for make install that supports the installation into a tmproot directory but leaves no trace of tmproot in any of its configuration files. ( http://git.rocksclusters.org/cgi-bin/gitweb.cgi?p=core/python/.git;a=blob;f=src/python-2/Makefile;h=ced6cc1c6eb6a4f70dd0f3e1b0ccd1ac1e40f989;hb=HEAD) shows a Makefile for python that supports this. We do support this install with DESTDIR. It might have rough edges - but its supporsed to work the same way any other package that supports it. One difference though is - since we also suppor the alternate orngaization [default] for inplace install with PETSC_ARCH - one has to use this PETSC_ARCH during the prefix build process aswell. [but then PETSC_ARCH is nolonger used/needed after that] i.e configure --prefix=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch1 PETSC_ARCH=build1 make PETSC_ARCH=build1 all make install PETSC_ARCH=build1 install DESTDIR=/tmp/dest1 package up from DESTDIR, and install as root: Now user does: make PETSC_DIR=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch1 ex1 configure [different options] --prefix=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch2 PETSC_ARCH=build2 make PETSC_ARCH=build2 all make install PETSC_ARCH=build2 install DESTDIR=/tmp/dest2 package up from DESTDIR, and install as root: Now user does: make PETSC_DIR=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch2 ex1 Satish, would you mind putting this little blurb on the installation page in the section about using prefix? I could not find this anywhere in our documentation. Thanks, Matt etc. There could be rough edges to this process as most folks use inplace install. But if it doesn't work for you we should fix. Ultimately we create packages of software to simplify a number of things. Including update of installed software on many machines. The other issue is not really an issue, but a request. When petsc is built it creates a petscvariables (or similarly named) file with lots of environment variables. It would be terrific if it could also create an environment modules files with this same information. Users often want different versions/different configs of the same software and environment modules is now standard in Redhat/CentOS distributions. The stuff petsc creates is in petscvariables for the consumption by 'make' and the only env variable the user needs [in this case with prefix install] is PETSC_DIR [as shown above for a prefix install]. Since this PETSC_DIR value is a prefix specfied to configure [for eg: --prefix=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch2] its value is known only to rocks pakcage builder. So it would know how to create the correct module [or whatever mechanicsm used to indentify/use] for a given petsc install. Satish Hope this helps. On Thu, Jan 24, 2013 at 2:44 AM, Schneider, Barry I. bschneid at nsf.gov wrote: Barry, I am sending this to Phil Papadopoulos and he can make much more precise recommendations. Glad you have
[petsc-dev] Making a PetSc Roll and Rocks Module
On Thu, 24 Jan 2013, Matthew Knepley wrote: We do support this install with DESTDIR. It might have rough edges - but its supporsed to work the same way any other package that supports it. One difference though is - since we also suppor the alternate orngaization [default] for inplace install with PETSC_ARCH - one has to use this PETSC_ARCH during the prefix build process aswell. [but then PETSC_ARCH is nolonger used/needed after that] i.e configure --prefix=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch1 PETSC_ARCH=build1 make PETSC_ARCH=build1 all make install PETSC_ARCH=build1 install DESTDIR=/tmp/dest1 package up from DESTDIR, and install as root: Now user does: make PETSC_DIR=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch1 ex1 configure [different options] --prefix=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch2 PETSC_ARCH=build2 make PETSC_ARCH=build2 all make install PETSC_ARCH=build2 install DESTDIR=/tmp/dest2 package up from DESTDIR, and install as root: Now user does: make PETSC_DIR=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch2 ex1 Satish, would you mind putting this little blurb on the installation page in the section about using prefix? I could not find this anywhere in our documentation. pushed https://bitbucket.org/petsc/petsc-3.3/commits/74a42cc43dcfbd1850b7689385b6f1b5 [and updated website with it] Satish
[petsc-dev] Making a PetSc Roll and Rocks Module
I am attaching a very basic module file for reference. One would need to update petsc_dir and petsc_arch upon deploying these, or perhaps configure can do it. I actually use this to easily switch between builds and debug / optimized versions Blaise wrote: On Thu, 24 Jan 2013, Matthew Knepley wrote: We do support this install with DESTDIR. It might have rough edges - but its supporsed to work the same way any other package that supports it. One difference though is - since we also suppor the alternate orngaization [default] for inplace install with PETSC_ARCH - one has to use this PETSC_ARCH during the prefix build process aswell. [but then PETSC_ARCH is nolonger used/needed after that] i.e configure --prefix=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch1 PETSC_ARCH=build1 make PETSC_ARCH=build1 all make install PETSC_ARCH=build1 install DESTDIR=/tmp/dest1 package up from DESTDIR, and install as root: Now user does: make PETSC_DIR=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch1 ex1 configure [different options] --prefix=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch2 PETSC_ARCH=build2 make PETSC_ARCH=build2 all make install PETSC_ARCH=build2 install DESTDIR=/tmp/dest2 package up from DESTDIR, and install as root: Now user does: make PETSC_DIR=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch2 ex1 Satish, would you mind putting this little blurb on the installation page in the section about using prefix? I could not find this anywhere in our documentation. pushed https://bitbucket.org/petsc/petsc-3.3/commits/74a42cc43dcfbd1850b7689385b6f1b5 [and updated website with it] Satish -- Department of Mathematics and Center for Computation Technology Louisiana State University, Baton Rouge, LA 70803, USA Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin -- next part -- An HTML attachment was scrubbed... URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130124/1c1710b1/attachment.html -- next part -- A non-text attachment was scrubbed... Name: 3.3 Type: application/octet-stream Size: 493 bytes Desc: 3.3 URL: http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130124/1c1710b1/attachment.obj
[petsc-dev] Making a PetSc Roll and Rocks Module
On Fri, 25 Jan 2013, Blaise A Bourdin wrote: the usual naming scheme is just the version number, but for petsc, most supercomputing centers use %version-%arch the installer will copy the file into $MODULEPATH/petsc/%version-%arch, or the user to $HOME/.modulefiles Of course, %version-%arch is a really silly name out of context. How about petsc-%version-%arch, somewhere within $PETSC_DIR/$PETSC_ARCH, or $PETSC_DIR/$PETSC_ARCH/modulefiles/%version-%arch ? And PETSC_ARCH has no singificance with prefix install [the significant text is in the prefix-path - and one doesn't have to match PETSC_ARCH to this significant text] True. I actually realized that as I was hitting send For now I've changed name to '%version-%arch'. Perhaps we should provide a configure option --with-module-name=foobar [for situations where the user can provide a prefered name] BTW: Is the following notation ok? [google didn't help] prepend-path PATH /home/balay/spetsc/asterix64/bin:/home/balay/spetsc/bin It seems to work, but For now - I've pushed the above notation. Satish
