<div dir="ltr">On Thu, Jan 24, 2013 at 1:12 PM, Satish Balay <span dir="ltr"><<a href="mailto:balay@mcs.anl.gov" target="_blank">balay@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, 24 Jan 2013, Barry Smith wrote:<br>
<br>
><br>
><br>
> Begin forwarded message:<br>
><br>
> > From: Philip Papadopoulos <<a href="mailto:philip.papadopoulos@gmail.com">philip.papadopoulos@gmail.com</a>><br>
> > Subject: Re: [petsc-maint #149715] Making a PetSc Roll and Rocks Module<br>
> > Date: January 24, 2013 9:48:36 AM CST<br>
> > To: "Schneider, Barry I." <<a href="mailto:bschneid@nsf.gov">bschneid@nsf.gov</a>><br>
> > Cc: Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>><br>
> ><br>
> > Dear Barry^2,<br>
> ><br>
> > The major observation about the build process is that building the software so that it can livesw-<br>
> > in a standard OS package is more work than it should be. Here is the standard "meme".<br>
> > Suppose you have three directories:<br>
> > sw-src<br>
> > tmpoot/sw-install<br>
> > sw-install<br>
> ><br>
> > sw-src: the source directory tree for building the sw package (eg petsc-3.3-p5)<br>
> > sw-install: the directory where one wants sw installed on the final system. We use something<br>
> > like /opt/petsc/compiler/mpi/interconnect/petsc-version/petsc-arch<br>
> ><br>
> > the last directory is an artifact of the way many people build software for packaging. Instead of<br>
> > installing into sw-install directly, you install into a tmproot/sw-install. Then you direct the package<br>
> > manager to grab all files in tmproot/sw-install to put in the package. The package itself will<br>
> > strip off the tmproot leading directory. In other words the package labels all files as sw-install/.<br>
> ><br>
> > 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,<br>
> > 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<br>
> > mounting bit of legerdemain.<br>
> ><br>
> > 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. (<a href="http://git.rocksclusters.org/cgi-bin/gitweb.cgi?p=core/python/.git;a=blob;f=src/python-2/Makefile;h=ced6cc1c6eb6a4f70dd0f3e1b0ccd1ac1e40f989;hb=HEAD" target="_blank">http://git.rocksclusters.org/cgi-bin/gitweb.cgi?p=core/python/.git;a=blob;f=src/python-2/Makefile;h=ced6cc1c6eb6a4f70dd0f3e1b0ccd1ac1e40f989;hb=HEAD</a>) shows a Makefile for python that supports this.<br>
<br>
</div></div>We do support this install with DESTDIR. It might have rough edges -<br>
but its supporsed to work the same way any other package that supports<br>
it.<br>
<br>
One difference though is - since we also suppor the alternate<br>
orngaization [default] for inplace install with PETSC_ARCH - one has<br>
to use this PETSC_ARCH during the prefix build process aswell. [but<br>
then PETSC_ARCH is nolonger used/needed after that]<br>
<br>
i.e<br>
configure --prefix=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch1 PETSC_ARCH=build1<br>
make PETSC_ARCH=build1 all<br>
make install PETSC_ARCH=build1 install DESTDIR=/tmp/dest1<br>
<package up from DESTDIR, and install as root:><br>
Now user does:<br>
make PETSC_DIR=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch1 ex1<br>
<br>
configure [different options] --prefix=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch2 PETSC_ARCH=build2<br>
make PETSC_ARCH=build2 all<br>
make install PETSC_ARCH=build2 install DESTDIR=/tmp/dest2<br>
<package up from DESTDIR, and install as root:><br>
Now user does:<br>
make PETSC_DIR=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch2 ex1<br></blockquote><div><br></div><div style>Satish, would you mind putting this little blurb on the installation page in the section about</div><div style>
using prefix? I could not find this anywhere in our documentation.</div><div style><br></div><div style> Thanks,</div><div style><br></div><div style> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
etc.<br>
<br>
There could be rough edges to this process as most folks use inplace<br>
install. But if it doesn't work for you we should fix.<br>
<div class="im"><br>
> > Ultimately we create packages of software to simplify a number of things. Including update of installed software on many machines.<br>
> ><br>
> > 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.<br>
<br>
</div>The stuff petsc creates is in petscvariables for the consumption by<br>
'make' and the only env variable the user needs [in this case with<br>
prefix install] is PETSC_DIR [as shown above for a prefix install].<br>
<br>
Since this PETSC_DIR value is a prefix specfied to configure [for eg:<br>
--prefix=/opt/petsc/compiler/mpi/interconnect/petsc-version/arch2] its<br>
value is known only to rocks pakcage builder. So it would know how to<br>
create the correct module [or whatever mechanicsm used to<br>
indentify/use] for a given petsc install.<br>
<span class="HOEnZb"><font color="#888888"><br>
Satish<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> ><br>
> > Hope this helps.<br>
> ><br>
> ><br>
> > On Thu, Jan 24, 2013 at 2:44 AM, Schneider, Barry I. <<a href="mailto:bschneid@nsf.gov">bschneid@nsf.gov</a>> wrote:<br>
> > Barry,<br>
> > 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.<br>
> ><br>
> > -----Original Message-----<br>
> > From: Barry Smith [mailto:<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>]<br>
> > Sent: Wednesday, January 23, 2013 10:19 PM<br>
> > To: Schneider, Barry I.<br>
> > Subject: Re: [petsc-maint #149715] Making a PetSc Roll and Rocks Module<br>
> ><br>
> ><br>
> > Barry,<br>
> ><br>
> > 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.<br>
> ><br>
> > Barry<br>
> ><br>
> > On Jan 23, 2013, at 6:13 PM, "Schneider, Barry I." <<a href="mailto:bschneid@nsf.gov">bschneid@nsf.gov</a>> wrote:<br>
> ><br>
> > > Barry,<br>
> > > 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 anythi<br>
ng 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 will be used by an even larger number of sites. We are talking about many thousands of users. So, I guess what I am really asking is whether you are interested enough in what Phil learned to perhaps modify the current PetSc so that it is easier for users to install or make available the technology for folks to make their own rolls. Of course, you could decide that is not on your agenda and that's fine. But if you capitalize on our experience and your great software that would be wonderful and perhaps offer users alternatives to the current way of doing things that would make life easier.<br>
> > ><br>
> > > **************************************************<br>
> > > Dr Barry I. Schneider<br>
> > > Program Director for Cyberinfrastructure Past Chair, APS Division of<br>
> > > Computational Physics Physics Division National Science Foundation<br>
> > > 4201 Wilson Blvd.<br>
> > > Arlington, VA 22230<br>
> > > Phone:<a href="tel:%28703%29%20292-7383" value="+17032927383">(703) 292-7383</a><br>
> > > FAX:<a href="tel:%28703%29%20292-9078" value="+17032929078">(703) 292-9078</a><br>
> > > Cell:<a href="tel:%28703%29%20589-2528" value="+17035892528">(703) 589-2528</a><br>
> > > **************************************************<br>
> > ><br>
> > ><br>
> > > -----Original Message-----<br>
> > > From: Barry Smith [mailto:<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>]<br>
> > > Sent: Wednesday, January 23, 2013 5:56 PM<br>
> > > To: <a href="mailto:petsc-maint@mcs.anl.gov">petsc-maint@mcs.anl.gov</a>; Schneider, Barry I.<br>
> > > Subject: Re: [petsc-maint #149715] Making a PetSc Roll and Rocks<br>
> > > Module<br>
> > ><br>
> > ><br>
> > > Barry,<br>
> > ><br>
> > > Thanks for the feedback. We actually desire to support "system" installs just as easily as "home directory" installs, though our documentation emphasizes "home directory" installs since we feel that is most practical for more users. We'd be interested in more specifics on the difficulties and any suggestions there may be to make the process (especially for multiple compilers/mpis) easier. That is what could we have done differently to make it easier for you?<br>
> > ><br>
> > > Thanks<br>
> > ><br>
> > > Barry<br>
> > ><br>
> > > On Jan 23, 2013, at 1:59 PM, "Schneider, Barry I." <<a href="mailto:bschneid@nsf.gov">bschneid@nsf.gov</a>> wrote:<br>
> > ><br>
> > >> I thought I might pass on the following to the folks maintaining PetSc. Recently we had the occasion to make a Rocks roll and module to be used on a local cluster here at NSF. Phil Papadopoulos the developer of Rocks at SDSC took the time to help us to do that not simply because we wanted it but also because he wanted to be able to know how to do it and distribute it to a much larger set users of NSF resources and also on out NSF supported platforms. Here are his comments. Perhaps if you feel there are things that could be made easier that would be great. It also could be useful to you directly.<br>
> > >><br>
> > >> BTW, Petsc is kind of a bear to package -- they really expect you to build it in your home directory :-).<br>
> > >> I took the time to make the roll pretty flexible in terms of compiler/mpi/network support to build various versions.<br>
> > >> This was modeled after other Triton rolls so that it is consistent with other software -- it likely becomes part of the standard SDSC software stack, so this was a good thing to do all the way around.<br>
> > >><br>
> > >> I'm about ready to add this to our code repository, it will show up on <a href="http://git.rocksclusters.org" target="_blank">git.rocksclusters.org</a><<a href="http://git.rocksclusters.org" target="_blank">http://git.rocksclusters.org</a>> tomorrow morning.<br>
> > >><br>
> > >><br>
> > >> **************************************************<br>
> > >> Dr Barry I. Schneider<br>
> > >> Program Director for Cyberinfrastructure Past Chair, APS Division of<br>
> > >> Computational Physics Physics Division National Science Foundation<br>
> > >> 4201 Wilson Blvd.<br>
> > >> Arlington, VA 22230<br>
> > >> Phone:<a href="tel:%28703%29%20292-7383" value="+17032927383">(703) 292-7383</a><br>
> > >> FAX:<a href="tel:%28703%29%20292-9078" value="+17032929078">(703) 292-9078</a><br>
> > >> Cell:<a href="tel:%28703%29%20589-2528" value="+17035892528">(703) 589-2528</a><br>
> > >> **************************************************<br>
> > >><br>
> > >><br>
> > ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Philip Papadopoulos, PhD<br>
> > University of California, San Diego<br>
> > <a href="tel:858-822-3628" value="+18588223628">858-822-3628</a> (Ofc)<br>
> > <a href="tel:619-331-2990" value="+16193312990">619-331-2990</a> (Fax)<br>
><br>
> </div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>