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. PetscViewerVTKAddField is another example of code that uses PetscObject to avoid depending on a higher level type like Vec.
