flexible TS implementation for user-defined timestepping

[Matthew Knepley]

On 9/18/07, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> On 9/18/07, Matthew Knepley <knepley at gmail.com> wrote:
> > Okay "algebra only" crowd, I agree this would be great. However, please address
> > the two problems I identify in the above paragraph, namely:
> >
> >   1) How can you handle user-discretized operators, like the identity, which are
> >       necessary for any of these schemes?
> >
> >   2) Even if you get these from the user, how can you efficiently implement the
> >       scheme, since what we really want is assembly of the entire F() at each
> >       timestep (in method of lines)?
>
> When I has talking about a scheme like:
>
> F(t^{n+1},u^{n+1}, t^n, u^n) = G(t^{n-k},u^{n-k}), k>0
>
> here F and G are the entire F() and G(). At the very high-level, the
> user is in charge of providing them. Next, we can build on this to
> alleviate the user in such task. Your work on Mesh object, and tools
> like FIAT+FCC could be really handy for this. Moreover, if you want to
> solve dU/dt = F(t,u) using implicit beuler and finite diferences, it
> is not much burden for the user to do some vector axpy/scale to build
> the function, and some matrix shift/scale for the jacobian. Completely
> abstracting the time-integation of the temporal integration scheme
> seems to be really hard. Of course, we can provide code for beuler /
> cn / trapezoidal rule for the particular case dU/dt = F(t,U) like
> PETSc already does.

However, now I am forced to ask what benefit the user is really getting. He has
to code the entire method, so we are really not providing the timestepping
scheme. It seems that the only benefit beyond SNES is that we save some
vectors (u^{n-k}) for him. This does not seem like much.

> >   3) Moreover, how can this scheme ever do spacetime formulations, which are
> >       much better for many problems?
>
> You catched me!. I do not really know much about those formulations.
> Could you please suggest some reading in order to think about this?

The thesis of Anders Logg (also published as papers) is very good.

  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
> > > >
> > > >
> > >
> > >
> > > --
> > > 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
> >
> >
>
>
> --
> 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
>
>


-- 
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