[petsc-dev] circular dependencies SLEPc

[Matthew Knepley]

On Mon, Jul 8, 2019 at 9:53 PM Jakub Kruzik via petsc-dev <
petsc-dev at mcs.anl.gov> wrote:

> Just to clarify, the suggested solution is a plug-in sitting anywhere in
> the PETSc source tree with postponed compilation and using
> __attribute__((constructor)) to register (as in libCEED) for static
> libraries?
>
> I could try to do that for the computation of eigenvector-based
> deflation space for PCDeflation next week.
>

Jakub, I am also interested in doing this. I want it to be as easy as
possible. Let me know what you are doing.

  Thanks,

     Matt


> Jakub
>
> On 7/8/19 5:49 PM, Smith, Barry F. via petsc-dev wrote:
> >     Sorry for the confusion surrounding this issue. Your code needs to
> go in its own standalone library that links against both PETSc and SLEPc.
> You can just the mechanism Jed suggested to have your library call
> PCRegister() when it is utilized (see previous emails/discussion). You
> could perhaps look at how the ctetgen package utilizes the PETSc compile
> system and copy that for your makefile and SLEPc, of course.
> >
> >      Once you have the "framework" that does this you could make a PR
> labeled something like WIP and ask for help in getting the details right.
> >
> >     Barry
> >
> >
> >> On Jul 8, 2019, at 9:58 AM, Pierre Jolivet via petsc-dev <
> petsc-dev at mcs.anl.gov> wrote:
> >>
> >> Hello,
> >> I’m not sure what’s the status about this issue.
> >> I’m trying to register a PC that is using EPSSolve during PCSetUp, but
> it’s falling because of undefined references to EPSSomething when linking
> libpetsc.so
> >> How could I fix this, appart from removing my PC from PETSc and
> compiling this as a separate library (the idea would be to merge my PC in
> PETSc, so that would be rather counterproductive in the end)?
> >>
> >> Thanks,
> >> Pierre
> >>
> >>> On 27 Jun 2019, at 1:04 AM, Matthew Knepley via petsc-dev <
> petsc-dev at mcs.anl.gov> wrote:
> >>>
> >>> On Wed, Jun 26, 2019 at 4:11 PM Jed Brown <jed at jedbrown.org> wrote:
> >>> Matthew Knepley <knepley at gmail.com> writes:
> >>>
> >>>> On Wed, Jun 26, 2019 at 3:42 PM Jed Brown via petsc-dev <
> >>>> petsc-dev at mcs.anl.gov> wrote:
> >>>>
> >>>>> "Smith, Barry F." <bsmith at mcs.anl.gov> writes:
> >>>>>
> >>>>>>> On Jun 26, 2019, at 1:53 PM, Jed Brown <jed at jedbrown.org> wrote:
> >>>>>>>
> >>>>>>> "Smith, Barry F." <bsmith at mcs.anl.gov> writes:
> >>>>>>>
> >>>>>>>>   It is still a PC, it may as part of its computation solve an
> >>>>> eigenvalue problem but its use is as a PC, hence does not belong in
> SLEPc.
> >>>>>>> Fine; it does not belong in src/ksp/pc/.
> >>>>>>    Why not? From the code mangement point of view that is the
> perfect
> >>>>> place for it. It just depends on an external package in the same way
> that
> >>>>> PCHYPRE depends on an external library. Having it off in some other
> >>>>> directory src/plugins would serve no purpose. Of course making sure
> it
> >>>>> doesn't get compiled into -lpetsc may require a tweak to the make
> >>>>> infrastructure. Make could, for example, skip plugin subdirectories
> for
> >>>>> example.
> >>>>>
> >>>>> I think it's confusing to have code that is part of libpetsc.so
> >>>>> alongside code that is not (e.g., won't be accessible to users unless
> >>>>> they also build SLEPc and link the plugin).
> >>>>>
> >>>>>>    BTW: Matt's perverse use of SNES from DMPLEx could also be fixed
> to
> >>>>>>    work this way instead of the disgusting PetscObject casting used
> to
> >>>>>>    cancel the SNES object.
> >>>>> That code could be part of libpetscsnes.so.
> >>>>>
> >>>> What? I thought I moved everything to SNES a long time ago.
> >>> I thought there was a place where SNES was cast to PetscObject.  There
> >>> is DMAddField, but it's different.
> >>>
> >>> I can't find it right now. Yeah, AddField is waiting for a true
> Discretization object.
> >>> I think its spelled G-O-D-O-T.
> >>>
> >>> PetscViewerVTKAddField is another example of code that uses PetscObject
> >>> to avoid depending on a higher level type like Vec.
> >>>
> >>> Viewer is a weird mixin with everything.
> >>>
> >>>     Matt
> >>>
> >>> --
> >>> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which their
> experiments lead.
> >>> -- Norbert Wiener
> >>>
> >>> https://www.cse.buffalo.edu/~knepley/
>
>

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20190708/8082e0e6/attachment.html>