> On Jul 8, 2019, at 9:53 PM, Jakub Kruzik via petsc-dev > <petsc-dev@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?
Yes, this is my understanding. Good luck. Barry > > 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 >>> <petsc-dev@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@mcs.anl.gov> wrote: >>>> >>>> On Wed, Jun 26, 2019 at 4:11 PM Jed Brown <j...@jedbrown.org> wrote: >>>> Matthew Knepley <knep...@gmail.com> writes: >>>> >>>>> On Wed, Jun 26, 2019 at 3:42 PM Jed Brown via petsc-dev < >>>>> petsc-dev@mcs.anl.gov> wrote: >>>>> >>>>>> "Smith, Barry F." <bsm...@mcs.anl.gov> writes: >>>>>> >>>>>>>> On Jun 26, 2019, at 1:53 PM, Jed Brown <j...@jedbrown.org> wrote: >>>>>>>> >>>>>>>> "Smith, Barry F." <bsm...@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/ >
