[petsc-users] PetscFE and TS

Jed Brown jed at jedbrown.org
Thu Nov 10 09:38:57 CST 2016


Matthew Knepley <knepley at gmail.com> writes:

> On Thu, Nov 10, 2016 at 1:31 AM, Julian Andrej <juan at tf.uni-kiel.de> wrote:
>
>> I'm getting the correct solution now, thanks! There are still a few
>> open questions.
>>
>> 1. The mass term is necessary _and_ using the u_tShift value if i
>> provide the jacobian. After reading the manual countless times, i
>> still don't get what the u_tShift value tells me in this context. Are
>> there any resources which you could point me to?
>>
>
> The manual is always a lagging resource because we are trying things
> out. 

This has been explained in the manual similarly to your email for
several years.  If anyone has a suggestion for how to make it better,
we'd like to hear.  The typical syndrome is that once you learn it, the
description suddenly makes sense and you wonder why you were ever
confused.  It takes feedback from people just learning the material to
make the explanation more clear.

> I learned about this by reading examples. The idea is the
> following. We have an implicit definition of our timestepping method
>
>   F(u, grad u, u_t, x, t) = 0

It doesn't make sense to write grad u as a separate argument here.
Also, is `x` meant to be coordinates or some other statically prescribed
data?  It can't be actively changing if you expect a generic TS to be
convergent.  (It's not an argument to the function.)  So really, you
have:

  F(u, u_t, t) = 0

> which is not unlike a Lagrangian description of a mechanical system. The
> Jacobian can be considered
> formally to have two parts,
>
>   dF/du and dF/du_t
>
> just as in the Lagrangian setting. The u_tShift variable is the multiplier
> for dF/du_t so that you actually
> form
>
>   dF/du + u_tShift dF/du_t

We're taking the total derivative of F with respect to u where u_t has
been _defined_ as an affine function of u, i.e., shift*u+affine.
u_tShift comes from the chain rule.  When computing the total
derivative, we have

  dF/du + dF/du_t du_t/du.

>> 2. Is DMProjectFunction necessary _before_ TSSolve? This acts like an
>> initial condition if i'm not mistaken.
>>
>
> Yes, this is the initial condition.
>
>
>> 3. A more in depth question i guess. Where is the "mass action"
>> formed? As i could see by stepping through the debugger, there is just
>> a formed action for the residual equation. It seems way over my
>> understanding how this formulation works out. I'd also appreciate
>> resources on that if thats possible.
>>
>
> Jed is the only one who understands this completely. 

That's a stretch -- several other people have developed sophisticated TS
implementations.

> However, I guess by "mass action" you mean the dF/du_t term. In the
> explicit methods, you just have u_t + ..., so
>
>   dF/du_t = M
>
> for finite element methods. So you are putting that there in
> FormIJacobian(). In the simplest
> case of backwards Euler then u_tShift would be 1/dt.

Specifically, for implicit methods, and many semi-implicit methods, we
don't need M separate.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20161110/5d7c91a4/attachment.pgp>


More information about the petsc-users mailing list