[petsc-dev] Reverse dependencies

[Jed Brown]

On Thu, Sep 13, 2012 at 8:50 AM, Barry Smith <bsmith at mcs.anl.gov> wrote:

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

Fine, so SNESInitializePackage() would call SNESKSPRegisterAll() and the
user should call one or the other if they don't use SNES but want to use
those KSP implementations.

Bear in mind that it'll work automatically with dynamic libraries since the
package is initialized when the shared lib is loaded. Now should we also
use the constructor trick to let the user skip this on all systems
supporting the attribute (most).


>
>     Barry
>
>    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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120913/ebc974c5/attachment.html>