On Mon, Feb 27, 2012 at 11:00, Matthew Knepley <knepley@gmail.com> 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.