Note that if we accept an im level it won't affect the user API (except for those using multiple libraries who have to add a library), users shouldn't need to change anything including include files. im would just be there to clarify there is a layer completely below Vec (and completely above sys) and the separate library helps determine though automatic testing if Vec code accidentally sneaks down into the im level. Is refactoring into an im level a major priority for me, no, but it looks like a minor reshuffling of code into a slightly better organization so I'm happy to take a look at a pull request. Essentially im has aways existed, this would just formalize it.
> On May 4, 2019, at 8:10 AM, Jed Brown <j...@jedbrown.org> wrote: > > Václav Hapla <vaclav.ha...@erdw.ethz.ch> writes: > >> 4. května 2019 14:21:31 GMT+03:00, Jed Brown <j...@jedbrown.org> napsal: >>> 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. >> >> At least DM contains Labels, > > Some DM implementations use DMLabel. > >> KSP contains PC, > > Yet there is PCKSP. > >> MatPartitioning contains Mat, > > This is the opposite inclusion. > >> SNES contains Linesearch, right? Although in case of pc, I think it >> deserves 1st level. > > A PC and a KSP both do the same thing (approximate the action of the inverse). > >> 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. > > Vec uses Layout and IS. VecScatter intimately uses all of these and is > needed for almost anything to do with parallel vectors.
