[petsc-dev] Master broken after changes to PetscSection headers

[Smith, Barry F.]

> On Sep 19, 2019, at 11:22 AM, Jed Brown via petsc-dev <petsc-dev at mcs.anl.gov> wrote:
> 
> Stefano Zampini <stefano.zampini at gmail.com> writes:
> 
>> So, for example, including petscmat.h we get all the constructors,
>> including "petscdm.h" we don't get DMPlexCreate... (BTW, this should
>> spelled DMCreatePlex if we follow the Mat convention....)
> 
> That's a legacy convention for DM.  There is a usage difference in that
> anyone calling DMPlexCreate will also call lots of other DMPlex*
> functions, but a caller of MatCreateAIJ may not call any MatAIJ*
> functions.  I don't personally care whether DMPlexCreate is changed to
> DMCreatePlex.
> 
>> If we plan to do any change, we should do it right before a release. Making
>> it after, it will be a pain managing maint fixes and merges to master.
>> 
>> I'm of the opinion that "petsc.h" should expose everything PETSc offers,
>> including API. But what about "petscksp.h" for example? Should it only
>> expose its *types.h dependencies? or the full API for all the objects down
>> the hierarchy? (PC,Mat,Vec,IS etc)?
> 
> I would prefer only the *types.h, but that's a very disruptive change.

   It exposes everything below and that is the user model. If you want to solve linear systems you include petscksp.h and for general circumstances you don't need to include more than that if you want to solve nonlinear systems include petscksnes.h etc.  I don't see this ever changing. 

   Now exactly what is not "general circumstances" that is open for discussion. For example petscpc.h exposes all the PC APIs but petscdm.h does not expose all the DM APIs each major class has its own include. The thinking is that each of the PC subclass APIs is pretty small so just include them all while some of the DM subclasses are huge (bigger than they will eventually once the FE/FV etc stuff is removed but still big) so don't force all of them onto everyone and in addition if the user is using DM they are aware of exactly what DM they are using (it is usually just one) so it is reasonable to have a separate include. 

   Barry