On Sat, 4 May 2019 at 17:58, Smith, Barry F. via petsc-dev < [email protected]> wrote:
> > > > On May 4, 2019, at 7:36 AM, Václav Hapla <[email protected]> > wrote: > > > > > > > > 4. května 2019 14:21:31 GMT+03:00, Jed Brown <[email protected]> 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." <[email protected]> writes: > >> > >>> Ok > >>> > >>> > >>>> On May 4, 2019, at 12:45 AM, Václav Hapla > >> <[email protected]> wrote: > >>>> > >>>> > >>>> > >>>> 4. května 2019 1:08:09 GMT+03:00, "Smith, Barry F." > >> <[email protected]> napsal: > >>>>> > >>>>> > >>>>>> On May 3, 2019, at 5:00 PM, Hapla Vaclav > >> <[email protected]> > >>>>> 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 > >
