<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 14, 2016 at 3:24 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 think i'm understanding the concept now. Although i have another set<br>
of questions. If i am formulating a DAE (like in the linear stokes<br>
equation for example) it seems i am missing something to formulate the<br>
correct jacobian. The residual formulation with snes_mf or snes_fd<br>
works fine in terms of nonlinear convergence. If i use the hand coded<br>
jacobian the convergence is way slower, which is a reason for an<br>
incorrect jacobian formulation from my side (at least what i think<br>
right now). I should be able to test my jacobian with -snes_type test,<br>
even if i am using TS, right? This gives me a huge difference. I guess<br>
i am missing something in the formulation and thus in the<br>
implementation of the callbacks here.<br>
<br>
There is a small example attached.<br></blockquote><div><br></div><div>I will look at it. It would be really helpful for me if you would include the options you</div><div>run with, and perhaps a little output with the report.</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">
I appreciate your time and help.<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Nov 10, 2016 at 4:45 PM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> On Thu, Nov 10, 2016 at 9:38 AM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
>><br>
>> Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
>><br>
>> > On Thu, Nov 10, 2016 at 1:31 AM, Julian Andrej <<a href="mailto:juan@tf.uni-kiel.de">juan@tf.uni-kiel.de</a>><br>
>> > wrote:<br>
>> ><br>
>> >> 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>
>> >><br>
>> ><br>
>> > The manual is always a lagging resource because we are trying things<br>
>> > out.<br>
>><br>
>> This has been explained in the manual similarly to your email for<br>
>> several years.  If anyone has a suggestion for how to make it better,<br>
>> we'd like to hear.  The typical syndrome is that once you learn it, the<br>
>> description suddenly makes sense and you wonder why you were ever<br>
>> confused.  It takes feedback from people just learning the material to<br>
>> make the explanation more clear.<br>
>><br>
>> > I learned about this by reading examples. The idea is the<br>
>> > following. We have an implicit definition of our timestepping method<br>
>> ><br>
>> >   F(u, grad u, u_t, x, t) = 0<br>
>><br>
>> It doesn't make sense to write grad u as a separate argument here.<br>
><br>
><br>
> Sorry, that is just how I think of it, not the actual interface.<br>
><br>
>><br>
>> Also, is `x` meant to be coordinates or some other statically prescribed<br>
><br>
><br>
> Coordinates, as distinct from u. Again this is my fault.<br>
><br>
>><br>
>> data?  It can't be actively changing if you expect a generic TS to be<br>
>> convergent.  (It's not an argument to the function.)  So really, you<br>
>> have:<br>
>><br>
>>   F(u, u_t, t) = 0<br>
>><br>
>> > which is not unlike a Lagrangian description of a mechanical system. The<br>
>> > Jacobian can be considered<br>
>> > formally to have two parts,<br>
>> ><br>
>> >   dF/du and dF/du_t<br>
>> ><br>
>> > just as in the Lagrangian setting. The u_tShift variable is the<br>
>> > multiplier<br>
>> > for dF/du_t so that you actually<br>
>> > form<br>
>> ><br>
>> >   dF/du + u_tShift dF/du_t<br>
>><br>
>> We're taking the total derivative of F with respect to u where u_t has<br>
>> been _defined_ as an affine function of u, i.e., shift*u+affine.<br>
>> u_tShift comes from the chain rule.  When computing the total<br>
>> derivative, we have<br>
>><br>
>>   dF/du + dF/du_t du_t/du.<br>
>><br>
>><br>
>> >> 2. Is DMProjectFunction necessary _before_ TSSolve? This acts like an<br>
>> >> initial condition if i'm not mistaken.<br>
>> >><br>
>> ><br>
>> > Yes, this is the initial condition.<br>
>> ><br>
>> ><br>
>> >> 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>
>> >><br>
>> ><br>
>> > Jed is the only one who understands this completely.<br>
>><br>
>> That's a stretch -- several other people have developed sophisticated TS<br>
>> implementations.<br>
><br>
><br>
> Matt does not understand this completely.<br>
><br>
>><br>
>><br>
>> > However, I guess by "mass action" you mean the dF/du_t term. In the<br>
>> > explicit methods, you just have u_t + ..., so<br>
>> ><br>
>> >   dF/du_t = M<br>
>> ><br>
>> > for finite element methods. So you are putting that there in<br>
>> > FormIJacobian(). In the simplest<br>
>> > case of backwards Euler then u_tShift would be 1/dt.<br>
>><br>
>> Specifically, for implicit methods, and many semi-implicit methods, we<br>
>> don't need M separate.<br>
><br>
><br>
> Yes.<br>
><br>
>    Matt<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>