flexible TS implementation for user-defined timestepping

[Matthew Knepley]

On 9/18/07, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>   I do not see why 1,2, and 3 are incompatiable with an "algebra based"
> TS level. It just requires a smart design.

1) I put this in before as TSSetIdentityMatrix() which was the only way I could
    see doing it. That led to problem 2).

2) If the user gives me some arbitrary matrix, I do not see how to effectively
    combine operations. I have to do everything in series. This is not optimal,
    but might be not bad. However, we through away that method so I thought
    people disapproved.

3) This requires changing the discretization that the user has in his SNES
     functions. I do not see how to do this without an independent idea of both
     a) his equations and b) his discretization.

I really believe this is not jsut an issue of smart algebraic design,
and moreover
I believe that this is exactly why TS has never been written.

   Matt

>   Barry
>
>
> On Tue, 18 Sep 2007, Matthew Knepley wrote:
>
> > On 9/17/07, Matthew Knepley <knepley at gmail.com> 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.
> >
> > 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)?
> >
> >   3) Moreover, how can this scheme ever do spacetime formulations, which are
> >       much better for many problems?
> >
> >    Matt
> >
> > >   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