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

[Hapla Vaclav]

On 4 May 2019, at 00:27, Smith, Barry F. <bsmith at mcs.anl.gov<mailto:bsmith at mcs.anl.gov>> wrote:



On May 3, 2019, at 4:22 PM, Hapla Vaclav <vaclav.hapla at erdw.ethz.ch<mailto:vaclav.hapla at erdw.ethz.ch>> wrote:



On 2 May 2019, at 23:41, Smith, Barry F. <bsmith at mcs.anl.gov<mailto:bsmith at mcs.anl.gov>> wrote:



On May 2, 2019, at 2:00 PM, Hapla Vaclav <vaclav.hapla at erdw.ethz.ch<mailto:vaclav.hapla at erdw.ethz.ch>> wrote:



On 2 May 2019, at 20:17, Hapla Vaclav <vaclav.hapla at erdw.ethz.ch<mailto:vaclav.hapla at erdw.ethz.ch>> wrote:



On 2 May 2019, at 18:20, Jed Brown <jed at jedbrown.org<mailto:jed at jedbrown.org>> wrote:

Matthew Knepley <knepley at gmail.com<mailto:knepley at gmail.com>> writes:

On Thu, May 2, 2019 at 12:02 AM Jed Brown <jed at jedbrown.org<mailto:jed at jedbrown.org>> wrote:

Matthew Knepley <knepley at gmail.com<mailto:knepley at gmail.com>> writes:

On Wed, May 1, 2019 at 8:56 PM Smith, Barry F. <bsmith at mcs.anl.gov<mailto:bsmith at mcs.anl.gov>>
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20190503/875292dd/attachment-0001.html>