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

[Jed Brown]

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." <bsmith at mcs.anl.gov> writes:

>   Ok
>
>
>> On May 4, 2019, at 12:45 AM, Václav Hapla <vaclav.hapla at erdw.ethz.ch> wrote:
>> 
>> 
>> 
>> 4. května 2019 1:08:09 GMT+03:00, "Smith, Barry F." <bsmith at mcs.anl.gov> napsal:
>>> 
>>> 
>>>> On May 3, 2019, at 5:00 PM, Hapla Vaclav <vaclav.hapla at erdw.ethz.ch>
>>> 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