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