flexible TS implementation for user-defined timestepping

Tue Sep 18 11:23:18 CDT 2007

On 9/18/07, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>   Yes, TS sucks and always has. I believe it sucks because
>
>   I think I disagree with Matt, in that I think a solid, flexible framework
> can be developed that is essentially still only algebraic (like SNES/KSP/PC).
> I would like to see the equation/discretization features "overlaid" the
> algebraic framework and not "protube" into the lower "algebraic" level.
>

And I have to agree with you, Barry. Indeed, I believe PESTSc should
start providing a very flexible, high-level framework for
timestepping.

Initially, the user should be in charge of completelly define the
functions/operators involved in the space-time discretization, and let
SNES/KSP solve them, or even let users define the way of advancing
from time level to time level. Of course, once this is available, Matt
can build on it in order to ask users less code for solving your
problems.

In my particular use case (NS eqs. with SUPG/PSPG stab.) it is not so
easy to completelly abastract the time discretization, as the
stabilization method depend on element sizes, time step, and the
(complete) residual of the PDE (except second spacial derivatives if
using linear elements). As such, I have to see my time-step problem as
a algebraic nonlinear problem in u^{n+1} wich could be written as:

F(t^{n+1}, u^{n+1}, t^n, u^n) = 0

this could even be more general in implicit multistep schemes:

F(t^{n+1},u^{n+1}, t^n, u^n) = G(t^{n-k},u^{n-k}), k>0

where G is an afine vector for the nonlinear problem with F.

I believe TS should support this kind of problems at the very high
level. Until now, it always assumed a time discretization for problems
of the type dU/dt = F(t,U). Almost all the features I've implemented
in my custom timestepper should be integrated in the TS interface.
Current TS types (beuler, cn, pseudo) are just a particular, simpler
case of the general case above.

Additionally, users should be able to completely define the way to
advance solution in time. An example from CFD: fractional-step like
(or pressure-splitting) method. Here, for advancing solution, you
possibly need a SNES (if you treat mommentum eqs. as nonlinear), or
one KSP (if mom. eqs. are linearized but coupled), or perhaps
one/three KSP's (for each mom. eq., where they can can have the same
or different sizes, depending in the way of treating boundary
conditions.)

All this said, I encourage you to take a look at my current code for
implicit nonlinear, and think a bit about how to define what a general
LINEAR problem should look. Then I can take the effort of updating
current TS implementations to cope with the general cases, and
subtypes to be inplemented inside this framework.

Regards,

>
> On Mon, 17 Sep 2007, Matthew Knepley wrote:
>
> > I think this example demonstrates my major problem with the current TS
> > implementation. I have had this problem since I was in grad school. We
> > would like to abstract different "methods" like CN for timestepping. This
> > is really abstracting the process of temporal discretization, and so far we
> > choose finite difference type discretizations. When these are combined
> > with FEM in space, this becomes difficult since we have no prescription for
> > constructing the operators we might need (like the identity in the FEM
> > space). Moreover, even when I added methods allowing the user to specify
> > these, the computation is not optimal since the parts are distended.
> >
> > Thus, as I have maintained for a while, I think the way forward is to give PETSc
> > some measure of control over not just the discretization, but the equation
> > handling. So far, I can only see how this might have in FEM, although FD is
> > probably not any harder. For each method, the provided weak form would be
> > altered to accomodate the time discretization. Eventually, I believe the right
> > thing to do is use Galerkin time discretizations as well since this allows local
> > optimization of the time steps, crucial to adaptivity.
> >
> >   Matt
> >
> > On 9/17/07, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> > > Current TS implementations never fited my needs. Why? My target
> > > application is solving incompressible NS equations with FEM and fully
> > > implicit schemes (trapezoidal rule with theta in [0.5, 1.0] ) and
> > > residual-based stabilization (SUPG/PSPG). Then I need to solve at each
> > > time step a nonlinear problem like F(t, u, t0, u0), where F is
> > > nonlinear in u. I'm surelly naive, and I could not accomodate my
> > > function and Jacobian code for the beuler/cn TS implementations.
> > >
> > > Futhermore, I've recently convinced some coworkers to take advance of
> > > SNES/TS features and my Python wrappers (petsc4py) to manage the the
> > > time evolution of some problems related to fluid-structure interaction
> > > and mesh movement (formulated as an optimization problem, only nodal
> > > positions change, not remeshing needed for many timesteps).
> > >
> > > In order to support those applications setups, I've wrote a new TS
> > > implemetation, which enables users to (almost) completely define the
> > > temporal evolution of their problems, with  pre/post solve/step
> > > methods and support for accept/reject steps and implementing timestep
> > > size control. Some of these features are available in some TS types,
> > > but not all-in-one.
> > >
> > > This code is available for review in petsc4py SVN repo (link below),
> > > an python example of this in action (very simple, just for testing all
> > > is working) is attached. Currently it only support implicit schemes
> > > and nonlinear problems, but I believe it can be extended to support
> > > explicit schemes and linear problems.
> > >
> > > http://petsc4py.googlecode.com/svn/trunk/petsc/lib/ext/src/ts/impls/implicit/user/
> > >
> > > I want to know the opinion of PETSc core developers and potential
> > > users ot this, and I hope anyone can provide suggestions for
> > > improvements. After that, I can push this to petsc-dev for general
> > > availability (in fact, the code is almost ready to be integrated in
> > > petsc).
> > >
> > > Perhaps in the long term, all this can be integrated in the generic TS
> > > interface if that is appropriate. Of course, this would require some
> > > (I hope minor) changes in TS interface, some additions, and a
> > > reimplementation of some default TS types
> > >
> > > Regards, and I'm waiting for your comments.
> > >
> > >
> > > --
> > > Lisandro Dalcín
> > > ---------------
> > > Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> > > Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> > > Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> > > PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> > > Tel/Fax: +54-(0)342-451.1594
> > >
> > >
> >
> >
> >

-- 
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594