[petsc-users] TS question 1: how to stop explicit methods because they do not use SNES(VI)?

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:

>> On Feb 14, 2017, at 9:36 PM, Jed Brown <jed at jedbrown.org> wrote:
>> 1. fluid splitting to isolate the acoustic wave (stiff)
>> 
>> 2. fluid containing everything but the acoustic wave (non-stiff)
>> 
>> 3. fast reactions
>> 
>> 4. slow reactions
>> 
>> 5. structure
>> 
>
>  Ok, great examples! Are there any commonalities that can be leveraged
>  in a better TS API than we currently have? Since there are these
>  "families" of potential splittings can't we do better than saying
>  "oh, that is all up to the (often naive and inexperienced) user"?
>  Like the old days of the "templates" book, since there are a bunch of
>  confusing, overlapping families of Krylov methods and preconditioners
>  we'll just write a book instead of writing code? I'm not saying that
>  my API is the best or even good but surely we can do better than just
>  leaving it to the users. AND, of course, since I don't care about
>  backward compatibility :-) what we do for an API now can evolve over
>  time as we better understand what should be represented in the API
>  and what shouldn't?

My reluctance to create an API is that I don't know of any useful
universal abstractions.  I'm concerned that anything we do will
ultimately be more complicated, less transparent, and less efficient
than sticking with the existing interface.  I'm open to suggestions.

>> Note that when using conservative variables, every one of these splits
>> requires evaluation of the equation of state (reactions rate
>> coefficients depend on Temperature, structure boundary condition
>> requires pressure and shear stress).  This doesn't even have
>> viscoelastics, sedimentation, or a turbulence model.
>
>   Ok, then where is the equation of state in TS? Since it is a
>   universal abstraction ("every one"), according to you, why isn't it
>   represented in TS? What else should TS have that is common to many
>   simulations?

So in a finite volume method, you may or may not transform to
characteristic or primitive variables in cells, reconstruct a piecewise
linear/polynomial representation in each cell, perhaps with limiting,
then evaluate it at quadrature points on faces.  At the faces, you need
to solve a Riemann problem which will require solving for a pressure or
a special nonlinear "average".  Equations of state are often either
tabulated or involve extensive series expansions.  Sometimes they are
described by implicit functions which you have to solve numerically
using a rootfinder.  This is an arbitrary example that makes my point
about complexity of equations of state:

http://www.mrc-eng.com/Downloads/Moist%20Air%20Props%20English.pdf

For finite element methods, these computations take place at quadrature
points within each element and generally don't involve a reconstruction
or limiting step.  There are also flux-splitting finite volume methods
that do not solve Riemann problems (it is still necessary to evaluate
the equation of state because the flux function depends on it).

A similar situation exists in models of plasticity or other highly
nonlinear solids.

This is a material modeling issue so I don't see how it has anything to
do with TS.  It is not uncommon for these material models to be the most
time-consuming part of residual computation.  In that situation, the
incremental cost of evaluating all the terms is negligible when you have
the equation of state evaluated at a quadrature point.  (Geometric terms
may be similar, but it's not an extreme effect for complicated
problems.)  So if you evaluate those terms 1-5 separately, it may cost
about 5x more than evaluating them together.  Do you really want to
encourage people to split them?  Note that if the user has a switch in
their code, it can be done at the quadrature point level (or batches of
quadrature points) and thus impose at most 2x overhead (solving the
equation of state once in the IFunction and once in the RHSFunction).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20170214/c25fb7f2/attachment.pgp>