> On Aug 22, 2016, at 1:44 PM, Jed Brown <[email protected]> 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 <[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).
