On Mon, Feb 27, 2012 at 11:16 AM, Jed Brown <[email protected]> wrote:
On Mon, Feb 27, 2012 at 11:00, Matthew Knepley <[email protected]> wrote:
I don't see why this is a dependency loop.
1. The callback interface is duplicated.
2. DM callbacks should provide a way for the called code to get access to the TS or DM so that users aren't prevented from doing hacky things.
Having DM hold the callbacks is a problem. But don't we have them in the context arg?
As a related matter, I'm stuck with a reference counting loop where I want to attach special Vecs to a DM. I can wrap them in a PetscContainer to circumvent the code that checks for reference cycles, but that makes freeing them delicate. We could make a named cache similar to DM work vectors, but where restored Vecs are not available for reuse.
I know that rationale for having Vecs know about a DM (output), which I don't like. What is the rationale for having DMs know about a certain Vec?
A TS wants to solve a nonlinear problem using FAS, so it needs to implement a callback on levels. So it coarsens the grid, but it also needs to coarsen the affine vectors so that it can define the finite-step problem on coarse levels.
Same issue for lots of cases where a user needs to save grid setup, coefficient fields, etc on levels so that it is available in a callback. It's natural to compose those vectors with the DM, but that creates a reference loop.
Aren't they just passed in? Or do you mean auxiliary vectors? 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