On Apr 21, 2011, at 6:07 AM, Jed Brown wrote: > 2011/4/21 ??????? ??????? <ram at ibrae.ac.ru> > I think I understand this now. But it seems strange that the DAGetMatrix > procedure creates the matrix and I need call the MatDestroy after the "get" > proceure to properly free the memory. > > Indeed, it should be named DACreateMatrix().
Actually, eventually DAGetMatrix() will take a matrix as input so would be called something like DMMatFill() so please don't change any names yet. I want to get away from having objects create other objects, instead they would take the object already created and modify it. This gives the user finer control over the state of the object created, it's subclass etc. For example, we don't want to have to hardwire inside of DMGetMatrix() lists of every matrix class that will ever be added to PETSc. > > @petsc-dev > This comes up way too often and we've all agreed that it should change. Let's > do it before 3.2 is released. In what other cases does the following model > not hold? > > 1. XCreateY(X,...,&Y); user has ownership to the new Y and should destroy > with YDestroy(Y) > > 2. XGetY(X,...,&Y); user has a "cheap" reference to an object owned by X, > reference count is not incremented, no need to do anything when the user is > done with Y > > 3. XGetY(X,...,&Y); the new Y may require setup or other resources, user > calls XRestoreY(X,...,&Y) when they are finished with Y This mode is fine. Barry > > > I wish there was a nice naming convention to distinguish 2 from 3, but I > think we should shoot for no exceptions to following 1 versus (2,3). > > What about MatGetSubMatrix()? For internal use, e.g. in PCFieldSplit, I think > that model 3 would be better because it exposes more optimizations when > assembly is lagged.
