<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 21, 2016 at 2:26 AM, Julian Andrej <span dir="ltr"><<a href="mailto:juan@tf.uni-kiel.de" target="_blank">juan@tf.uni-kiel.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Oct 20, 2016 at 5:18 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> On Thu, Oct 20, 2016 at 9:42 AM, Julian Andrej <<a href="mailto:juan@tf.uni-kiel.de">juan@tf.uni-kiel.de</a>> wrote:<br>
>><br>
>> Thanks for the suggestion. I guess DMCreateSubDM can work, but is<br>
>> cumbersome to handle for the normal solution process since the mass<br>
>> matrix for example is not a seperate field.<br>
><br>
><br>
> I did not understand what you meant by "parts of the physics". If you just<br>
> want to make a different operator, then swap out the PetscDS from the DM.<br>
> That holds the pointwise functions and discretizations.<br>
><br>
<br>
</span>Yes, its basically a different operator! Thats a really smart design,<br>
i can just create different PetscDS objects and stick them in to<br>
assemble the operator.<br>
<br>
  /* Assemble mass operator */<br>
  DMSetDS(dm, ds_mass);<br>
  DMPlexSNESComputeJacobianFEM(<wbr>dm, dummy, ctx->M, ctx->M, NULL);<br>
  /* Assemble laplacian operator */<br>
  DMSetDS(dm, ds_laplacian);<br>
  DMPlexSNESComputeJacobianFEM(<wbr>dm, dummy, ctx->J, ctx->J, NULL);<br>
<br>
There is one thing that bothers me just a bit. Everytime you call<br>
DMSetDS the old PetscDS object is destroyed and you have to reacreate<br>
the object in case you want to reassemble that operator.<br>
<br>
src/dm/interface/dm.c:3889:  ierr = PetscDSDestroy(&dm->prob);<wbr>CHKERRQ(ierr);<br>
<br>
Maybe it is just my specific use case but something to think about.</blockquote><div><br></div><div>If you want to keep them around, you should do this</div><div><br></div><div>DMGetDS(dm, &oldds);</div><div>PetscObjectReference(oldds);</div><div>DMSetDS(dm, newds);</div><div><do  stuff></div><div>DMSetDS(dm, oldds);</div><div>PetscObjectDeferefence(oldds);</div><div><br></div><div>  Thanks,</div><div><br></div><div>     Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
>><br>
>> src/snes/examples/tutorials/<wbr>ex77 handles a seperate field for the<br>
>> nullspace, if anyone is interested in that.<br>
>><br>
>> An intuitive way was just copying the DM and describing a new problem on<br>
>> it.<br>
>><br>
>>   DM dm_mass;<br>
>>   PetscDS ds_mass;<br>
>>   Vec dummy;<br>
>>   PetscInt id = 1;<br>
>>   petsc_call(<wbr>DMCreateGlobalVector(dm, &dummy));<br>
>>   petsc_call(DMClone(ctx->dm, &dm_mass));<br>
>>   petsc_call(DMGetDS(dm_mass, &ds_mass));<br>
>>   petsc_call(<wbr>PetscDSSetDiscretization(ds_<wbr>mass, 0, (PetscObject)fe));<br>
>>   petsc_call(PetscDSSetJacobian(<wbr>ds_mass, 0, 0, mass_kernel, NULL, NULL,<br>
>> NULL));<br>
>>   petsc_call(PetscDSAddBoundary(<wbr>ds_mass, PETSC_TRUE, "wall", "marker",<br>
>> 0, 0, NULL, (void (*)())ctx->exact_funcs[0], 1, &id, ctx));<br>
>>   petsc_call(DMCreateMatrix(dm_<wbr>mass, &ctx->M));<br>
>>   petsc_call(<wbr>DMPlexSNESComputeJacobianFEM(<wbr>dm_mass, dummy, ctx->M,<br>
>> ctx->M, NULL));<br>
>><br>
>> is this an intended way to assemble a jacobian based on a weak form?<br>
>> The memory overhead for a DM copy isn't huge on the first sight.<br>
><br>
><br>
> Its O(1).<br>
><br>
>><br>
>> And a much more important question. Is there any mathematical<br>
>> description how exactly you handle dirichlet boundary conditions here?<br>
><br>
><br>
> Right now, you can do two things:<br>
><br>
>   1) Handle it yourself<br>
><br>
> or<br>
><br>
>   2) eliminate particular dofs<br>
><br>
> If you use 2), these dofs are eliminated from the global vector. They remain<br>
> in the<br>
> local vector, and boundary values are inserted before local vectors are<br>
> passed to<br>
> assembly routines.<br>
><br>
>    Matt<br>
><br>
<br>
</div></div>Thank you again for your help and suggestions.<br>
<br>
Regards<br>
<span class="HOEnZb"><font color="#888888">Julian<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
>><br>
>> On first sight it looks like condensing the nodes only to<br>
>> non-essential nodes and then projecting them back in the solution<br>
>> vector. If thats teh case I don't understand how you "augment" the<br>
>> solution with the boundary nodes.<br>
>><br>
>> Regards<br>
>> Julian<br>
>><br>
>><br>
>> On Wed, Oct 19, 2016 at 11:51 AM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>><br>
>> wrote:<br>
>> > On Tue, Oct 18, 2016 at 7:38 AM, Julian Andrej <<a href="mailto:juan@tf.uni-kiel.de">juan@tf.uni-kiel.de</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Hi,<br>
>> >><br>
>> >> i have general question about PetscFE. When i want to assemble certain<br>
>> >> parts of physics separately, how can i do that? I basically want to<br>
>> >> assemble matrices/vectors from the weak forms on the same DM (and<br>
>> >> avoid copying the DM) and use them afterwards. Is there a convenient<br>
>> >> way for doing that?<br>
>> >><br>
>> >> The "workflow" i'm approaching is something like:<br>
>> >><br>
>> >> - Setup the DM<br>
>> >> - Setup discretization (spaces and quadrature) for each weak form i<br>
>> >> want to compute<br>
>> >> - Compute just the weak form i want right now for a specific<br>
>> >> discretization and field.<br>
>> >><br>
>> >> The reason is i need certain parts of the "complete" Jacobian for<br>
>> >> computations of eigenproblems and like to avoid computing those more<br>
>> >> often than needed.<br>
>> ><br>
>> ><br>
>> > The way I envision this working is to use DMCreateSubDM(). It should<br>
>> > extract<br>
>> > everything correctly for the subset of fields you select. However, I<br>
>> > have<br>
>> > not<br>
>> > extensively tested, so if something is wrong let me know.<br>
>> ><br>
>> >   Thanks,<br>
>> ><br>
>> >      Matt<br>
>> ><br>
>> >><br>
>> >> Regards<br>
>> >> Julian<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > What most experimenters take for granted before they begin their<br>
>> > experiments<br>
>> > is infinitely more interesting than any results to which their<br>
>> > experiments<br>
>> > lead.<br>
>> > -- Norbert Wiener<br>
><br>
><br>
><br>
><br>
> --<br>
> What most experimenters take for granted before they begin their experiments<br>
> is infinitely more interesting than any results to which their experiments<br>
> lead.<br>
> -- Norbert Wiener<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>