<div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Sat, 4 May 2019 at 17:58, Smith, Barry F. via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov">petsc-dev@mcs.anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On May 4, 2019, at 7:36 AM, Václav Hapla <<a href="mailto:vaclav.hapla@erdw.ethz.ch" target="_blank">vaclav.hapla@erdw.ethz.ch</a>> wrote:<br>
> <br>
> <br>
> <br>
> 4. května 2019 14:21:31 GMT+03:00, Jed Brown <<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>> napsal:<br>
>> Noting this historic event of Barry endorsing the addition of a new<br>
>> acronym with no specific demonstrated need.<br>
>> <br>
>> Note that most/all packages contain objects other that that which they<br>
>> are named after.  ksp/pc/, dm/label/, mat/partition/, snes/linesearch,<br>
>> etc.<br>
> <br>
> At least DM contains Labels, KSP contains PC, MatPartitioning contains Mat, SNES contains Linesearch, right?<br>
> Although in case of pc, I think it deserves 1st level.<br>
<br>
  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. </blockquote><div dir="auto"><br></div><div dir="auto">I thought the funny directory structure was a direct result of the time when SLES got ripped out.</div><div dir="auto"><br></div><div dir="auto">That is, there used to be</div><div dir="auto">src/sles/ksp </div><div dir="auto">and </div><div dir="auto">src/sles/pc</div><div dir="auto">and rather than having ksp and pc as independent beasts living under src/ it was opted to keep them "coupled" wrt the directory tree and thus src/sles became src/ksp</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> <br>
> 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.<br>
> <br>
> Vaclav<br>
> <br>
>> <br>
>> "Smith, Barry F." <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> writes:<br>
>> <br>
>>>  Ok<br>
>>> <br>
>>> <br>
>>>> On May 4, 2019, at 12:45 AM, Václav Hapla<br>
>> <<a href="mailto:vaclav.hapla@erdw.ethz.ch" target="_blank">vaclav.hapla@erdw.ethz.ch</a>> wrote:<br>
>>>> <br>
>>>> <br>
>>>> <br>
>>>> 4. května 2019 1:08:09 GMT+03:00, "Smith, Barry F."<br>
>> <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> napsal:<br>
>>>>> <br>
>>>>> <br>
>>>>>> On May 3, 2019, at 5:00 PM, Hapla Vaclav<br>
>> <<a href="mailto:vaclav.hapla@erdw.ethz.ch" target="_blank">vaclav.hapla@erdw.ethz.ch</a>><br>
>>>>> wrote:<br>
>>>>>> <br>
>>>>>> <br>
>>>>>> <br>
>>>>>> OK, so index, idx, other idea?<br>
>>>>> <br>
>>>>> I'm not sure index is that informative (and not expansive enough).<br>
>>>>> petscdm.h means nothing, maybe something short that doesn't mean<br>
>>>>> anything?<br>
>>>> <br>
>>>> Ok, that directly suggests im. One can interpret is as index<br>
>> mapping/management.<br>
>>>> <br>
>>>>> <br>
>>>>>> <br>
>>>>>> If we would have layout, is, sf, section in the same subdir, I<br>
>> would<br>
>>>>> move there also ao and ltog.<br>
>>>>> <br>
>>>>> Sure<br>
>>>>> <br>
>>>>>> <br>
>>>>>> What about the headers - I guess having all those classes in one<br>
>>>>> would be easier to handle and avoid circular dependencies, and<br>
>> would<br>
>>>>> reflect the directory structure. But should we keep separate<br>
>>>>> petsc{ao,is,sf}.h, then I would suggest also separate<br>
>>>>> petsc{layout,section,ltog}.h<br>
>>>>> <br>
>>>>> Separate is better.<br>
>>>>> <br>
>>>>>> <br>
>>>>>> When we are at it, why we sometimes have <class>types.h and<br>
>> sometimes<br>
>>>>> not?<br>
>>>>> <br>
>>>>> We add these "as needed"; Jed can explain better exactly when they<br>
>> are<br>
>>>>> needed.<br>
>>>>> <br>
>>>>>> <br>
>>>>>> Vaclav<br>
>>>>>> <br>
>>>>>> (added CC to petsc-dev)<br>
>>>>>> <br>
>>>>>>> <br>
>>>>>>> <br>
>>>>>>>> map<br>
>>>>>>>> imap<br>
>>>>>>>> idxmap<br>
>>>>>>>> ... or something alike.<br>
>>>>>>>> <br>
>>>>>>>> Vaclav<br>
>>>>>>>> <br>
>>>>>>>>>> <br>
>>>>>>>>>> Vaclav<br>
>>>>>>>>>> <br>
>>>>>>>>>>> <br>
>>>>>>>>>>> Why not at lest make an additional level between Sys and Vec<br>
>> for<br>
>>>>> those sectioning utilities? Would make more sense to me.<br>
>>>>>>>>>>> <br>
>>>>>>>>>>> Vaclav<br>
<br>
</blockquote></div></div>