On Sun, May 6, 2012 at 8:34 PM, Barry Smith <[email protected]> wrote:
I think it belongs in the DM (or the matrix if it was put in the matrix). When you select a subpart of the DM that new DM should contain the near null space for the subpart. The DM associated with the field defining IS is where all properties should go, not the IS itself. Of course, we really have not yet solidified the getting of the new DM for the field yet, maybe after the release.
I do not necessarily disagree in principle, but right now we don;t give smaller DMs, we give ISes. So I think my proposal is the one that works now. Second, I think we should be very careful using opaque objects for this. I consider this a failure when I did it for parts of the system for preconditioning, which was later changed to ISes in FieldSplit. Talking to PETSc, the Lord of Linear Algebra, in sets of integers is the right thing to do. It allows other people to stick their own stuff in place of ours easily, without junking it up with a lots of wrapper objects. Matt
Barry
On May 6, 2012, at 6:30 PM, Matthew Knepley wrote:
On Sun, May 6, 2012 at 7:15 PM, Jed Brown <[email protected]> wrote: Matt introduced this concept, he says the IS is a better place to attach things.
http://petsc.cs.iit.edu/petsc/petsc-dev/rev/2ad289ac99e0
I don't understand why the IS is better (because it's mostly immutable?). I'm worried that putting it there is going to be fragile because the near null space is not a property of an IS at all.
Its not a property of your matrix either, or you would not need me to tell you. Its a property of the operator. The operator is defined by the DM. The near null space is actually a property of a suboperator, defined by the DM using a field (we are not allowing arbitrary divisions). The representation of a field in PETSc is an IS ( http://www.mcs.anl.gov/petsc/petsc-dev/docs/manualpages/DM/DMCreateFieldIS.h...) so it makes sense to attach field information to the IS. Moreover, it makes a hell of a lat more sense to attach an auxiliary operator (like L_p) to this IS than to a matrix.
Furthermore, this scheme is completely workable in a nested context. The user can specify the IS, or pull out the DM IS and play with it, without a bunch of cumbersome copies hanging around that we do not want and can't destroy. That is what would happen with persistent submatrices. Lastly, I am running this for PyLith and it works great.
Matt
-- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener
-- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener