[petsc-dev] SuperLU link error on BGP FEN

[John R. Cary]

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.