[petsc-dev] Quad precision and external libraries

[Barry Smith]

> On Aug 22, 2016, at 1:44 PM, 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.  

   I never proposed a particular approach to denote what is supported; I certainly didn't suggest we should use several boolean. I wasn't aware that "reworked" was defined as "use a bunch of booleans".

> 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).