On Nov 24, 2010, at 7:17 PM, Jed Brown wrote: > On Thu, Nov 25, 2010 at 01:45, Barry Smith <bsmith at mcs.anl.gov> wrote: > I just don't want an API explosion. You may be falling into the trap of > "just add one more method and it will make live better", pretty soon you have > 10,000 methods and your stuff is unusable (at least unusable to the average > Joe). > > Are you referring to this thread,
Actually just this thread. For example adding VecArrayGotten(Vec,PetscBool) > or the SubVector/SubMatrix-related stuff? My goal is to > > 1. Not rely on the dirty and brittle VecPlaceArray as the only way to extract > parts of vectors. > > 2. Not necessarily make copies of everything within FieldSplit (I think all > users of FieldSplit complain that it costs so much memory at present). They think it takes too much, but if we had real profiling of where the memory is used they would see that it is actually trivial. > > 3. Have a way of assembling matrices without top-level knowledge. > > TS ex14 is rough at the moment, I'll clean it up tomorrow, but it solves a > pretty cool problem, and the same code can assemble a single MPIAIJ matrix, > or the constituent pieces as part of a matrix format that just holds > constituent parts. And if the pieces are held separately, then the assembly > process uses blocking and takes advantage of (S)BAIJ, despite the fact that > not all parts have block structure, and it is different for different > physics. That is, we have > > J = [A B; C D] > > where A is logically SBAIJ(2) and comes out of a 3D problem, B and C have no > particular block structure, and D is BAIJ(3) and comes out of a 2D problem. > Being able to build both forms efficiently with a runtime option, while > reusing the assembly code for single-physics A and D *unmodified* is pretty > cool functionality, in my opinion. > > Also note that most users of VecNest will never call its (small) API > themselves. DMGetGlobalVector_Composite will call VecCreateNest (and no > other new functions) when the vec-type is VECNEST. An upcoming MatNest will > be similar (essentially one function, which the user does not normally call > themselves). MatNest is somewhat like MatDD, but has a more defined purpose > at the moment. We can cherry-pick the best parts of each later. Don't worry, eventually we'll figure out how half of the new methods you've introduced can be removed. Package APIs should grow when adding new functionality or code and then shrink back down once the developers really understand what they are doing, which takes some time. Barry > > Jed
