[petsc-dev] Reverse dependencies

Barry Smith bsmith at mcs.anl.gov
Thu Sep 13 07:50:01 CDT 2012

On Sep 12, 2012, at 9:49 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> This patch seems to do two very unrelated things. More importantly, it makes libpetscmat depend on libpetscksp, thus breaking single-library=0. The register routine needs to be moved to src/ksp to fix this.

    Yup. My mistake.

     I don't like the idea of shoving it directly in KSPRegisterAll(). Instead what about KSPMatRegisterAll() that is called, like KSPRegisterAll() by KSPInitializePackage() 

     Similarly you would have SNESKSPRegisterAll() for your KSPPOLY.


   Note also the manual page for MatRegisterAll() should have a reference to KSPMatRegisterAll().

> In principle, I'd be fine with putting it in KSPRegisterAll. Instead of thinking of that routine as "register all implementations of KSP" (which it never truly meant), I think of it as "register all implementations of anything provided by the KSP package". The downside of that is that MatCreate calls MatInitializePackage, but does not call KSPInitializePackage, causing MatSetType(S,MATSCHURCOMPLEMENT) to fail when !defined(PETSC_USE_DYNAMIC_LIBRARIES) and KSPInitializePackage() has not been called.
> Unfortunately, I there isn't a way short of static constructors to initialize only those packages that are linked. With C++, we could have a static constructor that registered itself. With GCC and related compilers, we can use __attribute__((constructor)) to get a routine called before main (it would add the existing XXInitializePackage() to a list that PetscInitialize() would call later). Both of these options run code before main which means we have to be especially careful that it never causes an error because that is very confusing.
> On systems that don't support constructors, I think the user will have to call KSPInitializePackage themselves if they are going to MatSetType MATSCHURCOMPLEMENT before KSPCreate. I think this particular combination is extremely unlikely, but I have a similar issue with my new KSPPOLY (the implementation needs SNES to solve a constrained minimization problem) and that makes sense to use via -ksp_type poly when the user does not interact with SNES at all.
> changeset:   ec8eb69c0c42
> user:        Barry Smith <bsmith at mcs.anl.gov>
> date:        Thu Aug 23 08:03:00 2012 -0500
> files:       conf/test include/petscksp.h src/ksp/ksp/utils/schurm.c src/mat/interface/matregis.c
> description:
> added testexamples_opengl rule
> changed MatCreateSchurComplement to use the MatCreate_SchurComplement() paradigm

More information about the petsc-dev mailing list