<div dir="ltr"><div dir="ltr">On Wed, Jun 26, 2019 at 4:11 PM Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> writes:<br>
<br>
> On Wed, Jun 26, 2019 at 3:42 PM Jed Brown via petsc-dev <<br>
> <a href="mailto:petsc-dev@mcs.anl.gov" target="_blank">petsc-dev@mcs.anl.gov</a>> wrote:<br>
><br>
>> "Smith, Barry F." <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> writes:<br>
>><br>
>> >> On Jun 26, 2019, at 1:53 PM, Jed Brown <<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>> wrote:<br>
>> >><br>
>> >> "Smith, Barry F." <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> writes:<br>
>> >><br>
>> >>>  It is still a PC, it may as part of its computation solve an<br>
>> eigenvalue problem but its use is as a PC, hence does not belong in SLEPc.<br>
>> >><br>
>> >> Fine; it does not belong in src/ksp/pc/.<br>
>> ><br>
>> >   Why not? From the code mangement point of view that is the perfect<br>
>> place for it. It just depends on an external package in the same way that<br>
>> PCHYPRE depends on an external library. Having it off in some other<br>
>> directory src/plugins would serve no purpose. Of course making sure it<br>
>> doesn't get compiled into -lpetsc may require a tweak to the make<br>
>> infrastructure. Make could, for example, skip plugin subdirectories for<br>
>> example.<br>
>><br>
>> I think it's confusing to have code that is part of libpetsc.so<br>
>> alongside code that is not (e.g., won't be accessible to users unless<br>
>> they also build SLEPc and link the plugin).<br>
>><br>
>> >   BTW: Matt's perverse use of SNES from DMPLEx could also be fixed to<br>
>> >   work this way instead of the disgusting PetscObject casting used to<br>
>> >   cancel the SNES object.<br>
>><br>
>> That code could be part of libpetscsnes.so.<br>
>><br>
><br>
> What? I thought I moved everything to SNES a long time ago.<br>
<br>
I thought there was a place where SNES was cast to PetscObject.  There<br>
is DMAddField, but it's different.<br></blockquote><div><br></div><div>I can't find it right now. Yeah, AddField is waiting for a true Discretization object.</div><div>I think its spelled G-O-D-O-T.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
PetscViewerVTKAddField is another example of code that uses PetscObject<br>
to avoid depending on a higher level type like Vec.<br>
</blockquote></div><br clear="all"><div>Viewer is a weird mixin with everything.</div><div><br></div><div>   Matt</div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>