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:
> > 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.
>
> Indeed. If a user has the code (like me), I can benefit from having an
> object being able of managing the time-steping (only for the temporal
> axis), and configurable with many pre/post solve/step user-defined
> routines plus a way to implement time-step size control, also through
> user provided routine. All this should be seen as the highest-level
> interface to TS. It does not provide very much, as all interfaces
> generally do. Next, having this, he can tailor specific applications,
> for linear/nonlinear implict/explicit finite diferences/ finite
> elements methods.

I am not being clear enough. I do not think this interface really
helps the user.
In fact, I think it helps less than the current interface. For
instance, I want to
use CN. Right now, I can get that method, even if I do not know how to code CN.
I do not see that in your proposal. Now, this can only do simple FD, and cannot
assemble the entire operator at once. However, at least I do not need to know
CN, or RK, etc., to use it.

Perhaps I am misunderstanding your proposal, but I do not see the user savings.
There seem to be a lot of hooks that do nothing by default. If I have
to write all
the code myself, why not just give me solve(). Maybe you can illustrate it with
an example that shows the savings.

  Matt

> Matt, please see my proposal as an interface change (actually
> extension) to TS. It is very general, and as such, you can build
> implementations in order to alleviate user to write all the (parallel)
> code. But I insist that having many 'hooks' for pre/post solve/step
> and time-step control in the generic TS interface would be really
> useful.
>
>
> > The thesis of Anders Logg (also published as papers) is very good.
>
> I'll try to search for it ASAP. Thanks.
>
>
> >
> > > > > 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
> >
> >
>
>
> --
> 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