On Sep 13, 2010, at 12:35 PM, Jed Brown wrote:
> I was just chatting with Aron and two issues came up. First, he is
> successfully linking PESSL, but configure currently has
>
> raise RuntimeError('Cannot use PESSL instead of ESSL!')
>
> (apparently this was patched to let it through). Why this guard, it
> prevents user code from calling PESSL.
Does PESSL have some of the same symbols in it as ESSL? If it has any
symbols that are identical but map to different functions there would be a
problem. We haven't messed with PESSL in many, many years so perhaps they fixed
this? Also PESSL use to use threads to do some of its parallelism. In our MPI
on every core model of PETSc this doesn't make sense because the cores will be
over subscribed with several PESSL threads per core. Basically it use to be if
you linked PESSL into PETSc things didn't work properly. If that is fixed then
the check could be removed.
>
>
> Additionally, he has built PETSc with both Lapack and ESSL (linking
> Lapack first so those symbols resolve to the standard interface). This
> is a problem since PETSc dispatches on PETSC_HAVE_ESSL to determine the
> interface of LAPACKgeev (even though it is getting the standard Lapack
> one in the scenario above), I think it should test which version of this
> function it has and dispatch on PETSC_HAVE_ESSL_GEEV.
You really don't want to link LAPACK first because then basically you get
the LAPACK versions of the codes which (one would presume) are slower then the
same interfaces in ESSL (otherwise why bother using ESSL). The reason we say
you must link to LAPACK in addition to ESSL is because ESSL used to not have
all the functionality of LAPACK (again maybe the fixed this over the years).
Maybe you no longer need to also link LAPACk (wait a minute, this is IBM, they
probably didn't fix this).
When is KAUST going to grow a brain and order a IBM Blue Waters machine as
the next machine and not a IBM Blue Gene?
Barry
>
> Jed
