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
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
<[email protected]> 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
<[email protected]> wrote:
On Wed, Jun 26, 2019 at 4:11 PM Jed Brown <[email protected]> wrote:
Matthew Knepley <[email protected]> writes:
On Wed, Jun 26, 2019 at 3:42 PM Jed Brown via petsc-dev <
[email protected]> wrote:
"Smith, Barry F." <[email protected]> writes:
On Jun 26, 2019, at 1:53 PM, Jed Brown <[email protected]> wrote:
"Smith, Barry F." <[email protected]> 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/
