[petsc-dev] Quad precision and external libraries

[Barry Smith]

   Thanks

> On Aug 22, 2016, at 2:20 PM, Patrick Sanan <patrick.sanan at gmail.com> wrote:
> 
> 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).