[petsc-dev] Quad precision and external libraries

[Jed Brown]

This design problem of using a boolean flag (or several flags) to denote
a set appears often in PETSc.  We have types for denoting sets and we
should always use that in new code.  We usually fix the legacy issues
when they cause a problem.  I would probably switch this instance to
something like

  self.requiresprecision = ['single', 'double']

Barry Smith <bsmith at mcs.anl.gov> writes:

>   package.py has
>
>     self.double           = 0   # 1 means requires double precision
>
> but this should be reworked to allow indicating if a package supports single, double, and __float128 then each package/xxx.py should list what it supports.
>
>    Barry
>
>
>
>> On Aug 22, 2016, at 12:44 PM, Patrick Sanan <patrick.sanan at gmail.com> wrote:
>> 
>> It seems to be possible to configure and build PETSc with
>> quad/__float128 precision only to find that your code won't run
>> because the external package you were planning on using doesn't
>> support quad precision (as it usually won't).
>> 
>> It seems that configure will not prevent you from building with
>> external packages which don't support quad precision; instead, the
>> make process will simply skip some things, as controlled by
>> "#requiresprecision double" in local makefiles.  This means that you
>> will eventually notice the problem when you get a link error during
>> "make test", like
>> 
>> Undefined symbols for architecture x86_64:
>>  "_MatSolverPackageRegister_SuiteSparse", referenced from:
>>      import-atom in libpetsc.dylib
>> 
>> It seems like this behavior includes a lot of the popular external
>> packages (including several sparse direct solvers, which is how this
>> was noticed), based on grepping the src/ tree for "requiresprecision".
>> 
>> There is also at least one package (SuperLU) that is missing this
>> flag. For instance, I can configure, build, and test with no visible
>> problems with these configure options with master (on my OS X laptop
>> with gcc from macports):
>> --with-precision=__float128 --download-superlu --with-cc=gcc
>> --with-cxx=g++ --with-fc=gfortran --download-mpich
>> --download-f2cblaslapack
>> 
>> I then only see failure when I try to use the external package. e.g.
>> for KSP ex1:
>> 
>> $ ./ex1 -pc_type lu -pc_factor_mat_solver_package superlu -ksp_converged_reason
>> Linear solve did not converge due to DIVERGED_PCSETUP_FAILED iterations 0
>>               PCSETUP_FAILED due to FACTOR_NUMERIC_ZEROPIVOT
>> ...
>> 
>> So, if I haven't made any false assumptions yet,
>> 1. it'd be easy to add any missing "#requiresprecision double" lines
>> to more makefiles (though I'm not sure what to do re single precision,
>> for packages like SuperLU that support single and double).
>> 2.  It also might be worth going further to modify the BuildSystem to
>> allow packages to specify precision-dependency there. (And if that's
>> the way to go, note that in /lib/petsc/conf/rules there are also
>> procedures for real/complex and C/C++ conditional compilation, which
>> would likely affect external packages in the same way).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20160822/7e692e1e/attachment.sig>