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 <[email protected]> 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 <[email protected]> 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).
signature.asc
Description: PGP signature
