On Tue, Feb 28, 2012 at 12:13, Matthew Knepley <knepley at gmail.com> wrote:
> But this is what is causing the trouble. Vecs need to hold a DM to tell > them how to write themselves, but DMs need > those Vecs to pass to sovlers. These are very different jobs, and thus > cause loops. > Most possible loops are managed by deterministic ordering of destruction. Work vectors are counted. If the only problem we need to solve is reference count cycle analysis for PetscObjectCompose, we can do that. It sounds like at present, nobody has complained loudly about DM becoming the one-stop place for defining the problem to be solved (at least the nonlinear problem). Is that true? So do we move DMSetFunction() to DMSetSNESFunction() and add DMSetTSIFunction(), etc? To avoid the dependency loop, those methods would actually live in src/snes and src/ts, but their argument would be a DM. The actual evaluation context for SNES would be composed with the DM, so it wouldn't actually reside in _p_DM. Do we preserve SNESSetFunction() which would do SNESGetDM() and DMSetSNESFunction(). If no DM had been set, SNESGetDM() would create a dummy DM just as a place to attach its containers. The DMComputeSNESFunction() would always be called by SNESComputeFunction(). If the DM was just the dummy, it would call straight through to the user's implementation, even forwarding the SNES along as the context. If the user had called DMSetSNESFunction() (or DMDASetLocalSNESFunction(), etc), that version would be called. (This is similar to current logic, but dispatch _always_ goes through some DM, even if it's just a dummy to hold function pointers.) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120228/1443eb0d/attachment.html>
