[petsc-dev] SNES, Coloring, DM, and TS

[Matthew Knepley]

On Mon, Feb 27, 2012 at 11:16 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120227/31db95ef/attachment.html>