[petsc-dev] [petsc-maint] circular dependency [nightlybuilds did not catch]

[Dave May]

On Sat, 4 May 2019 at 17:58, Smith, Barry F. via petsc-dev <
petsc-dev at mcs.anl.gov> wrote:

>
>
> > On May 4, 2019, at 7:36 AM, Václav Hapla <vaclav.hapla at erdw.ethz.ch>
> wrote:
> >
> >
> >
> > 4. května 2019 14:21:31 GMT+03:00, Jed Brown <jed at jedbrown.org> napsal:
> >> Noting this historic event of Barry endorsing the addition of a new
> >> acronym with no specific demonstrated need.
> >>
> >> Note that most/all packages contain objects other that that which they
> >> are named after.  ksp/pc/, dm/label/, mat/partition/, snes/linesearch,
> >> etc.
> >
> > At least DM contains Labels, KSP contains PC, MatPartitioning contains
> Mat, SNES contains Linesearch, right?
> > Although in case of pc, I think it deserves 1st level.
>
>   If you git grep KSP  in the PC directory you see the problem with trying
> to decompose PC and KSP. KSP is above PC because it uses PC,  but PC
> implementations use KSP like crazy so PC is not below KSP. This is
> reflected in the "funny" directory structure.


I thought the funny directory structure was a direct result of the time
when SLES got ripped out.

That is, there used to be
src/sles/ksp
and
src/sles/pc
and rather than having ksp and pc as independent beasts living under src/
it was opted to keep them "coupled" wrt the directory tree and thus
src/sles became src/ksp







>
> >
> > Whereas e.g. Layout, SF, Section do not contain IS and also otherwise
> they are basically unrelated except they all arrange some kind of index
> mapping. And there are multiple utils ar different levels and nobody knows
> where to put what. Plus all those have absolutely nothing in common with
> Vec.
> >
> > Vaclav
> >
> >>
> >> "Smith, Barry F." <bsmith at mcs.anl.gov> writes:
> >>
> >>>  Ok
> >>>
> >>>
> >>>> On May 4, 2019, at 12:45 AM, Václav Hapla
> >> <vaclav.hapla at erdw.ethz.ch> wrote:
> >>>>
> >>>>
> >>>>
> >>>> 4. května 2019 1:08:09 GMT+03:00, "Smith, Barry F."
> >> <bsmith at mcs.anl.gov> napsal:
> >>>>>
> >>>>>
> >>>>>> On May 3, 2019, at 5:00 PM, Hapla Vaclav
> >> <vaclav.hapla at erdw.ethz.ch>
> >>>>> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> OK, so index, idx, other idea?
> >>>>>
> >>>>> I'm not sure index is that informative (and not expansive enough).
> >>>>> petscdm.h means nothing, maybe something short that doesn't mean
> >>>>> anything?
> >>>>
> >>>> Ok, that directly suggests im. One can interpret is as index
> >> mapping/management.
> >>>>
> >>>>>
> >>>>>>
> >>>>>> If we would have layout, is, sf, section in the same subdir, I
> >> would
> >>>>> move there also ao and ltog.
> >>>>>
> >>>>> Sure
> >>>>>
> >>>>>>
> >>>>>> What about the headers - I guess having all those classes in one
> >>>>> would be easier to handle and avoid circular dependencies, and
> >> would
> >>>>> reflect the directory structure. But should we keep separate
> >>>>> petsc{ao,is,sf}.h, then I would suggest also separate
> >>>>> petsc{layout,section,ltog}.h
> >>>>>
> >>>>> Separate is better.
> >>>>>
> >>>>>>
> >>>>>> When we are at it, why we sometimes have <class>types.h and
> >> sometimes
> >>>>> not?
> >>>>>
> >>>>> We add these "as needed"; Jed can explain better exactly when they
> >> are
> >>>>> needed.
> >>>>>
> >>>>>>
> >>>>>> Vaclav
> >>>>>>
> >>>>>> (added CC to petsc-dev)
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> map
> >>>>>>>> imap
> >>>>>>>> idxmap
> >>>>>>>> ... or something alike.
> >>>>>>>>
> >>>>>>>> Vaclav
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Vaclav
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Why not at lest make an additional level between Sys and Vec
> >> for
> >>>>> those sectioning utilities? Would make more sense to me.
> >>>>>>>>>>>
> >>>>>>>>>>> Vaclav
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20190504/d7d13abc/attachment-0001.html>