On 4 May 2019, at 00:27, Smith, Barry F. <[email protected]<mailto:[email protected]>> wrote:
On May 3, 2019, at 4:22 PM, Hapla Vaclav <[email protected]<mailto:[email protected]>> wrote: On 2 May 2019, at 23:41, Smith, Barry F. <[email protected]<mailto:[email protected]>> wrote: On May 2, 2019, at 2:00 PM, Hapla Vaclav <[email protected]<mailto:[email protected]>> wrote: On 2 May 2019, at 20:17, Hapla Vaclav <[email protected]<mailto:[email protected]>> wrote: On 2 May 2019, at 18:20, Jed Brown <[email protected]<mailto:[email protected]>> wrote: Matthew Knepley <[email protected]<mailto:[email protected]>> writes: On Thu, May 2, 2019 at 12:02 AM Jed Brown <[email protected]<mailto:[email protected]>> wrote: Matthew Knepley <[email protected]<mailto:[email protected]>> writes: On Wed, May 1, 2019 at 8:56 PM Smith, Barry F. <[email protected]<mailto:[email protected]>> wrote: I don't think Layout (or Map as it used to be called) was ever in sys. I just looked at the new offending code, it definitely doesn't belong in sys. How did it get passed the code reviews? And strange that it didn't get detected by the nightlies as soon as it was incorrectly merged into master? I cannot understand why you think Layout does not belong in Sys. It is nothing more than a partition, which is not tied to a Vec, or anything. PetscSF is not associated with Vec, but still lives in src/vec/. I did not put it there. Barry put it there six years ago. https://bitbucket.org/petsc/petsc/commits/95fce210c9a5323d60d47a8c3b992a28141ecb57 The concept of partitioning problem-sized data doesn't really exist in src/sys/ apart from PetscSplitOwnership(), which is much more raw than PetscLayout and could arguably move to src/vec/. In the opposite way, I would say it makes more sense to group SplitOwnership, Section, SF in a separate place apart from Vec, like an IS library. I don't see the point; you'd be hard-pressed to split petscvec from petscis without circular dependencies. The concept of global indexing is closer to Vec than the (rank, offset) indexing of SF (which is why I put SF in sys/ to begin with), but they all involve problem-sized distribution concepts. Section, SF and Layout are completely separate concepts and classes and they have nothing to do with vector. For example Layout is used by Vec, IS and Mat equally. Section mainly by DM. I seem to agree with Matt. Even vec/is doesn't make sense. I never got this directory tree. Is there a motivation to lower the number of directories in src? This is the class directory structure under src/vec: ./pf ./vscat ./is ./is/sf ./is/ao ./is/is ./is/is/utils ./is/utils ./vec ./vec/utils ./vec/utils/tagger ./vec/utils/matlab I really think it is broken. It raises questions like: How SF and IS are related? What's the difference between vec/is and vec/is/is? Between vec/is/utils and vec/is/is/utils? Etc. What about having something like src/vec src/vec/vscat src/vec/tagger src/vec/matlab src/vec/pf src/is src/is/ao src/is/ltog src/utils/layout src/utils/section src/utils/sf The last three could have a common header file petscutils.h. The header inclusion hierarchy would be petscsys.h petscutils.h petscis.h petscvec.h petscmat.h Utils is a meaningless term, it could be mean anything. I think that having both utils and is is too fine a granularity and unnecessary, just one level that captures layout, is, sf, section should be fine. What to call it? For lack of a better name and historic reasons maybe is? If we're going to update this directory subtree, I would personally love to avoid repeating the same name at two different levels. Good point. What these classes have in common is they map indices to indices (even IS can be considered a mapping from 0,1,... to arbitrary index sequence). So I would suggest index idx I got in trouble before from the mathematicians for using the word map, (Map used to be the name of PetscLayout) so I want to avoid that. OK, so index, idx, other idea? If we would have layout, is, sf, section in the same subdir, I would move there also ao and ltog. 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 When we are at it, why we sometimes have <class>types.h and sometimes not? 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
