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