<div dir="ltr">We should move the discussion to a gitlab issue, where we document what is the model we would like to follow, because, at present, we really don't have a model. For example<div><br><div>[szampini@localhost petsc]$ git grep MatCreateSeqAIJ include/petscmat.h<br>include/petscmat.h:PETSC_EXTERN PetscErrorCode MatCreateSeqAIJMKL(MPI_Comm,PetscInt,PetscInt,PetscInt,const PetscInt[],Mat*);<br>include/petscmat.h:PETSC_EXTERN PetscErrorCode MatCreateSeqAIJ(MPI_Comm,PetscInt,PetscInt,PetscInt,const PetscInt[],Mat*);<br>include/petscmat.h:PETSC_EXTERN PetscErrorCode MatCreateSeqAIJCRL(MPI_Comm,PetscInt,PetscInt,PetscInt,const PetscInt[],Mat*);<br>include/petscmat.h:PETSC_EXTERN PetscErrorCode MatCreateSeqAIJWithArrays(MPI_Comm,PetscInt,PetscInt,PetscInt[],PetscInt[],PetscScalar[],Mat*);<br>include/petscmat.h:PETSC_EXTERN PetscErrorCode MatCreateSeqAIJFromTriple(MPI_Comm,PetscInt,PetscInt,PetscInt[],PetscInt[],PetscScalar[],Mat*,PetscInt,PetscBool);<br>include/petscmat.h:PETSC_EXTERN PetscErrorCode MatCreateSeqAIJCUSPARSE(MPI_Comm,PetscInt,PetscInt,PetscInt,const PetscInt[],Mat*);<br>include/petscmat.h:PETSC_EXTERN PetscErrorCode MatCreateSeqAIJViennaCL(MPI_Comm,PetscInt,PetscInt,PetscInt,const PetscInt[],Mat*);<br></div><div><br></div><div>[szampini@localhost petsc]$ git grep DMPlexCreate include/petscdm.h<br></div><div><br></div><div>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....)</div></div><div><br></div><div>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.</div><div><br></div><div>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)?</div><div>  </div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno gio 19 set 2019 alle ore 15:44 Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Thu, Sep 19, 2019 at 8:09 AM Jed Brown <<a href="mailto:jed@jedbrown.org" target="_blank">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">Václav Hapla via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov" target="_blank">petsc-dev@mcs.anl.gov</a>> writes:<br>
<br>
> 19. září 2019 12:23:43 SELČ, Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> napsal:<br>
>>On Thu, Sep 19, 2019 at 6:21 AM Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>><br>
>>wrote:<br>
>><br>
>>> On Thu, Sep 19, 2019 at 6:20 AM Stefano Zampini<br>
>><<a href="mailto:stefano.zampini@gmail.com" target="_blank">stefano.zampini@gmail.com</a>><br>
>>> wrote:<br>
>>><br>
>>>> So why it is in the vec package?<br>
>>>><br>
>>><br>
>>> Its in IS, so if anything it should go in petscis.h. I will move it<br>
>>there.<br>
>>><br>
>><br>
>>Now that we are doing this. I think petscsf.h belongs there too, not<br>
>>just<br>
>>the types.<br>
><br>
> The is directory just groups different utility classes dealing with integer mappings. Probably just from historical reasons. I don't think they should be considered belonging to the IS package. I don't see a point in including it all in petscis.h. Why e.g. users of KSP should implicitly include all this stuff when they don't need it.<br>
<br>
I would rather move toward headers including only *types.h from their<br>
dependencies.  Reducing such dependencies is a breaking change so we<br>
need to be judicious and document it, but adding dependencies<br>
gratuitously is the wrong direction, IMO.  (It slows down incremental<br>
rebuilds of PETSc and user code.)<br>
</blockquote></div><br clear="all"><div>Having to make delicate changes in several places just to add a header is a crazy development process. We have to have</div><div>an easy rule, and preferably a check that it is done the way we want.</div><div><br></div><div>I put in the fix I think you are suggesting.</div><div><br></div><div>   Matt</div>-- <br><div dir="ltr"><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>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Stefano</div>