[petsc-dev] ugliness due to missing lapack routines
Karl Rupp
rupp at mcs.anl.gov
Thu Feb 7 11:55:11 CST 2013
Hi Barry,
>> In fact Matt can also generate the appropriate zdot_() when needed so ugly crap like
>> /* handle complex dot() with special code */
>>
>> How are you going to avoid a namespace collision here? The problem isn't that the function doesn't exist, it's that we can't determine its binary interface.
>
> Crap you are right. We'll need to come up with some other solution UNLESS the BLAS library version of them are in their separate .o files so we can pick up the generated one in libpetsc.a and it won't ever load the one in the blas library.
Since this is only BLAS-related, we should move all the BLAS-calls to a
separate package with the sole purpose of providing a unified (binary)
interface for the PETSc core. This will allow us to keep the PETSc core
clean and put all the ugly stuff in that 'unification sublibrary'. This
should eliminate any BLAS-related CPP usage from the PETSc core.
> Sometime I will send a detailed email explaining why I wish to totally eradicate CPP.
This is a noble goal with my full support, yet very hard to achieve. How
do we want to tackle CHKERRQ for example? I don't know of any other way
of extracting file names and line numbers without blowing up the code
base. If you are aiming towards compiler-driven code
development/generation by having the full AST available, we could still
play a few compatibility-tricks to make this work for a handful of macros.
Best regards,
Karli
More information about the petsc-dev
mailing list