Yeah, thanks for pointing out my mistake. Next time i'm going to think one more time before writing ;)
On Fri, Oct 21, 2016 at 12:17 PM, Lawrence Mitchell <lawrence.mitch...@imperial.ac.uk> wrote: > >> On 21 Oct 2016, at 08:26, Julian Andrej <j...@tf.uni-kiel.de> wrote: >> >> On Thu, Oct 20, 2016 at 5:18 PM, Matthew Knepley <knep...@gmail.com> wrote: >>> On Thu, Oct 20, 2016 at 9:42 AM, Julian Andrej <j...@tf.uni-kiel.de> wrote: >>>> >>>> Thanks for the suggestion. I guess DMCreateSubDM can work, but is >>>> cumbersome to handle for the normal solution process since the mass >>>> matrix for example is not a seperate field. >>> >>> >>> I did not understand what you meant by "parts of the physics". If you just >>> want to make a different operator, then swap out the PetscDS from the DM. >>> That holds the pointwise functions and discretizations. >>> >> >> Yes, its basically a different operator! Thats a really smart design, >> i can just create different PetscDS objects and stick them in to >> assemble the operator. >> >> /* Assemble mass operator */ >> DMSetDS(dm, ds_mass); >> DMPlexSNESComputeJacobianFEM(dm, dummy, ctx->M, ctx->M, NULL); >> /* Assemble laplacian operator */ >> DMSetDS(dm, ds_laplacian); >> DMPlexSNESComputeJacobianFEM(dm, dummy, ctx->J, ctx->J, NULL); >> >> There is one thing that bothers me just a bit. Everytime you call >> DMSetDS the old PetscDS object is destroyed and you have to reacreate >> the object in case you want to reassemble that operator. >> >> src/dm/interface/dm.c:3889: ierr = PetscDSDestroy(&dm->prob);CHKERRQ(ierr); > > All objects in PETSc are refcounted. So this just drops the reference that > the DM is holding to the DS. As long as you're still holding a reference in > your code (you haven't called PetscDSDestroy) then this does not actually > deallocate the DS, just decrements the refcount. > > Lawrence
