[petsc-dev] TS Equation Type

Matthew Knepley knepley at gmail.com
Mon Dec 5 16:23:24 CST 2016


On Mon, Dec 5, 2016 at 4:06 PM, Emil Constantinescu <emconsta at mcs.anl.gov>
wrote:

> On 12/5/16 3:28 PM, Matthew Knepley wrote:
>
>> On Mon, Dec 5, 2016 at 1:32 PM, Emil Constantinescu
>> <emconsta at mcs.anl.gov <mailto:emconsta at mcs.anl.gov>> wrote:
>>
>>     This was introduced to allow for full flexibility in ARKIMEX: i.e.,
>>     use IMEX or just the implicit part. It makes a difference whether
>>     the equation is implicit F(u,u_dot) = 0 (possibly a DAE), or just
>>     u_dot=f(u). The former has more restrictions and the algorithm is a
>>     bit more costly and complicated.
>>
>>     TS_EQ_UNSPECIFIED reverts to the original use of ARKIMEX: u_dot =
>>     f(u) + g(u).
>>
>>     Additional types are introduced for future use.
>>
>>
>> This is not a useful answer since it gives us no idea how to procede.
>> Its more like an encyclopedia entry.
>>
>
> I guess I don't understand the question. This setting is used only in
> -ts_type arkimex because it has implications to how the equation is
> interpreted -- see above; the user is not required to set it and we are not
> going to do so. This setting is not meant to be used as a selection tool.
> We rely on the user to use the appropriate solver. E.g., if the equation is
> implicit the user should not use explicit RK and so on...


This is not about selection, this is about information. We want the TS
solver to tell use which formulation it is expecting, either u_t = G(u, t),
or F(u, u_t, t) = 0.

   Matt


>
> Emil
>
>    Matt
>>
>>
>>
>>     Emil
>>
>>
>>     On 12/5/16 10:26 AM, Brad Aagaard wrote:
>>
>>         Matt and the rest of the PETSc developers,
>>
>>         This issue is not whether the TS is linear or nonlinear, but
>>         whether it
>>         is explicit or implicit. As far as I can tell only TS type
>>         Implicit-Explicit Runge Kutta makes use of the equation_type.
>>
>>         The equations types defined in petscts.h are:
>>
>>           TS_EQ_UNSPECIFIED               = -1,
>>           TS_EQ_EXPLICIT                  = 0,
>>           TS_EQ_ODE_EXPLICIT              = 1,
>>           TS_EQ_DAE_SEMI_EXPLICIT_INDEX1  = 100,
>>           TS_EQ_DAE_SEMI_EXPLICIT_INDEX2  = 200,
>>           TS_EQ_DAE_SEMI_EXPLICIT_INDEX3  = 300,
>>           TS_EQ_DAE_SEMI_EXPLICIT_INDEXHI = 500,
>>           TS_EQ_IMPLICIT                  = 1000,
>>           TS_EQ_ODE_IMPLICIT              = 1001,
>>           TS_EQ_DAE_IMPLICIT_INDEX1       = 1100,
>>           TS_EQ_DAE_IMPLICIT_INDEX2       = 1200,
>>           TS_EQ_DAE_IMPLICIT_INDEX3       = 1300,
>>           TS_EQ_DAE_IMPLICIT_INDEXHI      = 1500
>>
>>         For PyLith we would like the TS implementation (type) to set the
>>         equation type so we can detect whether the user has specified an
>>         implicit or explicit algorithm and set the residual and Jacobian
>>         functions appropriately. For example, the user may want to solve
>> the
>>         linear elasticity equation for a quasi-static problem with
>>         implicit time
>>         stepping or a dynamic problem with explicit time stepping.
>>
>>         Brad
>>
>>         On 12/03/2016 12:20 PM, Matthew Knepley wrote:
>>
>>             On Sat, Dec 3, 2016 at 2:18 PM, Barry Smith
>>             <bsmith at mcs.anl.gov <mailto:bsmith at mcs.anl.gov>
>>             <mailto:bsmith at mcs.anl.gov <mailto:bsmith at mcs.anl.gov>>>
>> wrote:
>>
>>
>>                 > On Dec 3, 2016, at 11:58 AM, Matthew Knepley
>>             <knepley at gmail.com <mailto:knepley at gmail.com>
>>             <mailto:knepley at gmail.com <mailto:knepley at gmail.com>>> wrote:
>>                 >
>>                 > Right now, TS just leaves the equation type as
>>             undetermined, and
>>             never queries it except for the IMEX methods. This seems
>> really
>>             strange to me. If we choose a linear TS solver, shouldn't it
>>             set the
>>             type to LINEAR, and likewise for nonlinear? Then a user
>>             could query
>>             this for information. We want to do just that in PyLith.
>>
>>                   Is your concern that many of the examples never bother
>>             to set the
>>                 type?
>>
>>
>>             Yes, since I want to query this to see what formulation the
>>             user expects.
>>
>>
>>                 Or that not enough error checking is done that the set
>>             type works
>>                 with solution method selected by the user?
>>
>>
>>             No
>>
>>
>>                 I think these are just oversights and you should go
>>             ahead and add
>>                 these in the examples and code where appropriate.
>>
>>
>>             Will do.
>>
>>                Matt
>>
>>
>>
>>                    Barry
>>
>>                 >
>>                 >    Matt
>>                 >
>>                 > --
>>                 > What most experimenters take for granted before they
>>             begin their
>>                 experiments is infinitely more interesting than any
>>             results to which
>>                 their experiments lead.
>>                 > -- Norbert Wiener
>>
>>
>>
>>
>>             --
>>             What most experimenters take for granted before they begin
>> their
>>             experiments is infinitely more interesting than any results
>>             to which
>>             their experiments lead.
>>             -- Norbert Wiener
>>
>>
>>
>>
>>
>> --
>> What most experimenters take for granted before they begin their
>> experiments is infinitely more interesting than any results to which
>> their experiments lead.
>> -- Norbert Wiener
>>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20161205/d8566a4c/attachment.html>


More information about the petsc-dev mailing list