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

[Stefano Zampini]

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

[szampini at localhost petsc]$ git grep MatCreateSeqAIJ include/petscmat.h
include/petscmat.h:PETSC_EXTERN PetscErrorCode
MatCreateSeqAIJMKL(MPI_Comm,PetscInt,PetscInt,PetscInt,const
PetscInt[],Mat*);
include/petscmat.h:PETSC_EXTERN PetscErrorCode
MatCreateSeqAIJ(MPI_Comm,PetscInt,PetscInt,PetscInt,const PetscInt[],Mat*);
include/petscmat.h:PETSC_EXTERN PetscErrorCode
MatCreateSeqAIJCRL(MPI_Comm,PetscInt,PetscInt,PetscInt,const
PetscInt[],Mat*);
include/petscmat.h:PETSC_EXTERN PetscErrorCode
MatCreateSeqAIJWithArrays(MPI_Comm,PetscInt,PetscInt,PetscInt[],PetscInt[],PetscScalar[],Mat*);
include/petscmat.h:PETSC_EXTERN PetscErrorCode
MatCreateSeqAIJFromTriple(MPI_Comm,PetscInt,PetscInt,PetscInt[],PetscInt[],PetscScalar[],Mat*,PetscInt,PetscBool);
include/petscmat.h:PETSC_EXTERN PetscErrorCode
MatCreateSeqAIJCUSPARSE(MPI_Comm,PetscInt,PetscInt,PetscInt,const
PetscInt[],Mat*);
include/petscmat.h:PETSC_EXTERN PetscErrorCode
MatCreateSeqAIJViennaCL(MPI_Comm,PetscInt,PetscInt,PetscInt,const
PetscInt[],Mat*);

[szampini at localhost petsc]$ git grep DMPlexCreate include/petscdm.h

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....)

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)?



Il giorno gio 19 set 2019 alle ore 15:44 Matthew Knepley <knepley at gmail.com>
ha scritto:

> On Thu, Sep 19, 2019 at 8:09 AM Jed Brown <jed at jedbrown.org> wrote:
>
>> Václav Hapla via petsc-dev <petsc-dev at mcs.anl.gov> writes:
>>
>> > 19. září 2019 12:23:43 SELČ, Matthew Knepley <knepley at gmail.com>
>> napsal:
>> >>On Thu, Sep 19, 2019 at 6:21 AM Matthew Knepley <knepley at gmail.com>
>> >>wrote:
>> >>
>> >>> On Thu, Sep 19, 2019 at 6:20 AM Stefano Zampini
>> >><stefano.zampini at gmail.com>
>> >>> wrote:
>> >>>
>> >>>> So why it is in the vec package?
>> >>>>
>> >>>
>> >>> Its in IS, so if anything it should go in petscis.h. I will move it
>> >>there.
>> >>>
>> >>
>> >>Now that we are doing this. I think petscsf.h belongs there too, not
>> >>just
>> >>the types.
>> >
>> > 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.
>>
>> I would rather move toward headers including only *types.h from their
>> dependencies.  Reducing such dependencies is a breaking change so we
>> need to be judicious and document it, but adding dependencies
>> gratuitously is the wrong direction, IMO.  (It slows down incremental
>> rebuilds of PETSc and user code.)
>>
>
> Having to make delicate changes in several places just to add a header is
> a crazy development process. We have to have
> an easy rule, and preferably a check that it is done the way we want.
>
> I put in the fix I think you are suggesting.
>
>    Matt
> --
> 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/
> <http://www.cse.buffalo.edu/~knepley/>
>


-- 
Stefano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20190919/b2f7093e/attachment.html>