[petsc-dev] Handling ESSL + Lapack and PESSL

[Aron Ahmadia]

Jed, I went back and recompiled a PETSc that didn't make use of the KTH
LAPACK/CBLAS build, so the problem definitely lies within the daxpy calls to
the essl library, and not PETSc's interpretation of the interface.  At this
point the potential culprits are misaligned memory or some bad
initialization to the multithreaded ESSL.  In the past I've used the
smp-friendly ESSL without any trouble, so I am surprised that this code is
throwing illegal instruction signals.  I am rebuilding PETSc now to point to
the single-threaded BG ESSL.  If this fails as well I will get some help
from the IBM guys to shed some light on what's going on.

--Aron

On Mon, Sep 13, 2010 at 2:59 PM, Aron Ahmadia <aron.ahmadia at kaust.edu.sa>wrote:

> ESSL contains a BLAS, but you can get a nice standard LAPACK/CBLAS on
> BlueGene by following these instructions:
> http://www.pdc.kth.se/resources/computers/bluegene/LAPACK-CBLAS/LAPACK-CBLAS-build
>
> A
>
>
> On Mon, Sep 13, 2010 at 2:55 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>>
>> On Sep 13, 2010, at 1:56 PM, Jed Brown wrote:
>>
>> > On Mon, 13 Sep 2010 13:42:05 -0500, Barry Smith <bsmith at mcs.anl.gov>
>> wrote:
>> >> My point is not only do they get a slower GEEV but they get a slower
>> >> everything in LAPACK. [...] Why not just use LAPACK?
>> >
>> > Yup, I get your point.  But Lapack usually needs a BLAS, and the
>> > original (flawed) idea was that a fast BLAS would produce a competitive
>> > Lapack.
>> >
>>    What, Jack made a mistake? Never.
>>
>>    Does ESSL itself contain "the BLAS" or is there also a libblas type
>> thingy on the IBM you could link against?
>>
>>    None of this really matters because you are still stuck writing the
>> configure test for geev.
>>
>>    Barry
>>
>>
>> > Jed
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100914/90c9209c/attachment.html>