<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 10, 2016 at 1:31 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">I'm getting the correct solution now, thanks! There are still a few<br>
open questions.<br>
<br>
1. The mass term is necessary _and_ using the u_tShift value if i<br>
provide the jacobian. After reading the manual countless times, i<br>
still don't get what the u_tShift value tells me in this context. Are<br>
there any resources which you could point me to?<br></blockquote><div><br></div><div>The manual is always a lagging resource because we are trying things out. I learned about this</div><div>by reading examples. The idea is the following. We have an implicit definition of our timestepping</div><div>method</div><div><br></div><div>  F(u, grad u, u_t, x, t) = 0</div><div><br></div><div>which is not unlike a Lagrangian description of a mechanical system. The Jacobian can be considered</div><div>formally to have two parts,</div><div><br></div><div>  dF/du and dF/du_t</div><div><br></div><div>just as in the Lagrangian setting. The u_tShift variable is the multiplier for dF/du_t so that you actually</div><div>form</div><div><br></div><div>  dF/du + u_tShift dF/du_t</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. Is DMProjectFunction necessary _before_ TSSolve? This acts like an<br>
initial condition if i'm not mistaken.<br></blockquote><div><br></div><div>Yes, this is the initial condition.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. A more in depth question i guess. Where is the "mass action"<br>
formed? As i could see by stepping through the debugger, there is just<br>
a formed action for the residual equation. It seems way over my<br>
understanding how this formulation works out. I'd also appreciate<br>
resources on that if thats possible.<br></blockquote><div><br></div><div>Jed is the only one who understands this completely. However, I guess by "mass action"</div><div>you mean the dF/du_t term. In the explicit methods, you just have u_t + ..., so</div><div><br></div><div>  dF/du_t = M</div><div><br></div><div>for finite element methods. So you are putting that there in FormIJacobian(). In the simplest</div><div>case of backwards Euler then u_tShift would be 1/dt.</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">
Thanks again.<br>
<span class="HOEnZb"><font color="#888888"><br>
Julian<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Wed, Nov 9, 2016 at 9:25 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> On Wed, Nov 9, 2016 at 8:14 AM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
>><br>
>> On Wed, Nov 9, 2016 at 7:52 AM, Julian Andrej <<a href="mailto:juan@tf.uni-kiel.de">juan@tf.uni-kiel.de</a>> wrote:<br>
>>><br>
>>> I tried the example with different signs for the forcing, so this<br>
>>> might be a mistake by me, yes. it doesn't change anything though. I<br>
>>> also have to correct myself, the time for the callback in<br>
>>> PetscDSAddBoundary changes correctly! Although u_t in all other<br>
>>> callbacks seems to remain zero.<br>
>>><br>
>>> I am out of ideas on my side though :)<br>
>><br>
>><br>
>> The bug is that the boundary conditions are not being properly enforced. I<br>
>> am fixing it now.<br>
>> Thanks for the simple example demonstrating this. It made it much much<br>
>> easier to debug.<br>
><br>
><br>
> I think this works. Let me know if you agree.<br>
><br>
> There is the business of u_t on the boundary, which is not handled right<br>
> now. I am putting that<br>
> in, but the homogeneous values for that is still alright here.<br>
><br>
>   Thanks,<br>
><br>
>      Matt<br>
><br>
>><br>
>>     Matt<br>
>><br>
>>><br>
>>> On Wed, Nov 9, 2016 at 2:33 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>><br>
>>> wrote:<br>
>>> > On Wed, Nov 9, 2016 at 12:32 AM, Julian Andrej <<a href="mailto:juan@tf.uni-kiel.de">juan@tf.uni-kiel.de</a>><br>
>>> > wrote:<br>
>>> >><br>
>>> >> I tested a few other things and it turned out that the function added<br>
>>> >> as a dirichlet boundary condition via PetscDSAddBoundary doesn't<br>
>>> >> receive the time values correctly (PetscReal time is always 0.0).<br>
>>> ><br>
>>> ><br>
>>> > I will check out your example and fix this. However, I wonder if there<br>
>>> > is a<br>
>>> > bug in your implementation:<br>
>>> ><br>
>>> > void f0_temp(PetscInt dim, PetscInt Nf, PetscInt NfAux,<br>
>>> >           const PetscInt uOff[], const PetscInt uOff_x[], const<br>
>>> > PetscScalar<br>
>>> > u[], const PetscScalar u_t[], const PetscScalar u_x[],<br>
>>> >           const PetscInt aOff[], const PetscInt aOff_x[], const<br>
>>> > PetscScalar<br>
>>> > a[], const PetscScalar a_t[], const PetscScalar a_x[],<br>
>>> >           PetscReal t, const PetscReal x[], PetscScalar f0[])<br>
>>> > {<br>
>>> >   f0[0] = u_t[0] - 2.0;<br>
>>> > }<br>
>>> ><br>
>>> > I get<br>
>>> ><br>
>>> >   du/dt - \Delta u = -2<br>
>>> ><br>
>>> > so that if u = x^2 + y^2 + 2t, then<br>
>>> ><br>
>>> >   2 - (2 + 2) = -2<br>
>>> ><br>
>>> > so you would want u_t + 2.<br>
>>> ><br>
>>> > If you give the Laplacian the opposite sign, this is an unstable<br>
>>> > formulation.<br>
>>> ><br>
>>> >   Thanks,<br>
>>> ><br>
>>> >      Matt<br>
>>> ><br>
>>> >><br>
>>> >> I also see no effect adding DMTSSetIJacobianLocal vs. not setting the<br>
>>> >> jacobian function. The analytic solution i used in my attached example<br>
>>> >> is the same as in the src/ts/examples/tutorials/<wbr>ex32.c.<br>
>>> >><br>
>>> >> Am i doing anything obviously wrong here? My next step would be to try<br>
>>> >> if assembling the matrices myself and writing a custom<br>
>>> >> IFunction/IJacobian which assembles the different parts of the matrix<br>
>>> >> like M and J for the stiff ODE with nontrivial mass matrix (see manual<br>
>>> >> section of TS -> F = M u' - f) but i think this should be obsolete<br>
>>> >> right?<br>
>>> >><br>
>>> >> Appreciate your help.<br>
>>> >><br>
>>> >> Regards<br>
>>> >> Julian<br>
>>> >><br>
>>> >> On Mon, Nov 7, 2016 at 10:49 AM, Julian Andrej <<a href="mailto:juan@tf.uni-kiel.de">juan@tf.uni-kiel.de</a>><br>
>>> >> wrote:<br>
>>> >> > Hello,<br>
>>> >> ><br>
>>> >> > i'm using PetscFE in combination with SNES and a hand written<br>
>>> >> > backward<br>
>>> >> > euler solver right now and like to hand that over to TS. I have been<br>
>>> >> > fiddling quite a while getting TS to work with PetscFE and have<br>
>>> >> > encountered a few unclarities.<br>
>>> >> ><br>
>>> >> > I have looked at examples which are outdated i guess<br>
>>> >> > (src/ts/examples/tutorials/<wbr>ex32.c) and i am confused on how i have<br>
>>> >> > to<br>
>>> >> > formulate the discretization of the jacobian and the residual. It<br>
>>> >> > seems obvious to use the DMTSSetIFunctionLocal and<br>
>>> >> > DMTSSetIJacobianLocal functions because there are prepared wrappers<br>
>>> >> > from DMPlexTSComputeIFunctionFEM and DMPlexTSComputeIJacobianFEM.<br>
>>> >> ><br>
>>> >> > I need a Mass matrix for my problem, is that formed from the<br>
>>> >> > function<br>
>>> >> > space information or do i have to form it myself? Is there any<br>
>>> >> > working<br>
>>> >> > example which uses PetscFE and TS to form the DMTSSetIFunctionLocal<br>
>>> >> > and DMTSSetIJacobianLocal? (grepping the tree tells me "no"<br>
>>> >> > unfortunately).<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<br>
>> experiments is infinitely more interesting than any results to which their<br>
>> experiments 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>