Re: [petsc-dev] On remaining libMesh-PETsc fieldsplit interface cleanup

[Smith, Barry F. via petsc-dev]

> On Apr 1, 2019, at 8:19 PM, Matthew Knepley via petsc-dev 
> <petsc-dev@mcs.anl.gov> wrote:
> 
> On Mon, Apr 1, 2019 at 9:12 PM Boris Boutkov via petsc-dev 
> <petsc-dev@mcs.anl.gov> wrote:
> Hello all,
> 
> I've been working on the libMesh - PETSc interface for utilizing 
> gmg/fieldsplit on the command line by creating DMShells; things are seemingly 
> in pretty good shape at this point, so thanks much for the support along the 
> way!
> 
> The last lingering issue of the implementation is that I still have a little 
> bit of dependency on PETSc private/dmimpl.h. In short, during our 
> implementation of DMCreateSubDM I try and get some of the parent DMs function 
> pointers, specifically dm->ops->{coarsen, refine, createinterpolation, 
> createrestriction, and createsubdm}, which then I set for the subDM using 
> DMShellSet* by passing in the parent DM pointer directly.
> 
> I'd like to remove this private dmimpl.h dependency but removing the header 
> gives me compilation errors - "invalid use of incomplete type" pointing to 
> PETsc DM struct for the above calls. As far as I understand it, this means 
> that I would need public API similar to the DMShellSet* methods but now 
> instead DMShellGet*.
> 
> If the above's the case, any reason this doesn't exist yet outside of lack of 
> prior need? And how much work would introducing this require? Or of course 
> please let me know if there's some simple way around this that I may be 
> missing.
> 
> No, we just needed someone to ask. We will do this exactly like we do 
> MATSHELL. We have to create an Enum that indexes
> the DM methods. Then you can pass the Enum value when you Set/Get the 
> methods. Its not hard, just some coding. Want to try :)

   Actually this is not the way DMShell works, DMShell works the way PCSHELL 
works, each set function is its own function (for example 
DMShellSetCreateGlobalVector)  and there is no enum of operations (like 
MatOperations). Given the current DMSHELL API it makes sense to just provide 
DMShellGetXX() for each DM operation.

   Barry

  Well you may well ask, why we have two different approaches for different 
PETSc objects/classes. I am asking. And well you may.

  I don't have any rational for having two different approaches, lack of good 
code reviews in the past? Should we evolve towards using the same approach for 
all XXXSHELL subclasses in the future? Perhaps. 


   I 
> 
>    Thanks,
> 
>      Matt
> Thanks as always for your time,
> 
> - Boris
> 
> 
> 
> 
> 
> -- 
> 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/