[petsc-dev] circular dependencies SLEPc

[Jed Brown]

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.

PetscViewerVTKAddField is another example of code that uses PetscObject
to avoid depending on a higher level type like Vec.