On 12/2/10 5:49 PM, Barry Smith wrote: > On Dec 2, 2010, at 4:29 PM, William (Bill) E. Allcock wrote: > >> John, >> >> My first suggestion would be to use the petsc already built for Intrepid if >> that is an option. >> Either way, others have had luck using the local disks on the FEN to speed >> up their builds. I think someone may have even put together a script that >> trys to do that automagically. Not sure if that would work for you, but if >> you send mail to support, they should be able to provide details. > > Bill, > > This could be a great idea. From my perspective it would be good if it > was the "preferred" (even default) approach for large builds on system; > documented, promoted and supported by the support group. It has the added > benefit of decreasing the load on the file server that surely has a negative > affect on all users. >
Bill et al, Thanks for your replies. The issue we face is well illustrated by what happened over the last few days. We upgraded to petsc-3.1p4 a while back, and then we began changing the build systems for all of our stack (about 4 packages out of the 45 we have to have work for FACETS) that depend on PETSc, because the library structure changed. Once we make that change, we need to ensure that the new PETSC is built everywhere for us: ALCF, NERSC, linux clusters at Tech-X, GA, PPPL, OS X. The others went fairly quickly, but BGP/XL is always the most difficult for us, so we only just started on that recently. In this process, yesterday we found a critical bug in SuperLU, one that prevented us from linking. Satish kindly gave us a fix in a few hours. I am now building the fix. We will be operational later today, I hope, without putting additional burden on the ALCF staff. (This was the last hurdle for a full build of FACETS.) It seems that it is simply to much to ask all the sysadmins at all these places to upgrade for us when we want it done, so for packages in our critical path, like PETSc, we have decided to build them ourselves. Given that decision, we can and will start doing all builds in the local disks. This is a slight inconvenience given the lack of persistence. Best.......John PS - we have submitted an SBIR for trying to deal with all of these complex build issues across LCFs and other machines as well. If we get funded, we hope to work with ALCF. PPS - NCAR provides a /contrib directory for users to build software that might be of broad interest. This can again reduce demands on sysadmins.