[petsc-dev] Quad precision and external libraries

[Patrick Sanan]

On Mon, Aug 22, 2016 at 11:44 AM, Jed Brown <jed at jedbrown.org> wrote:
> 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']
I created an issue on bitbucket
https://bitbucket.org/petsc/petsc/issues/142/improve-package-precision-dependency
>
> 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).