flexible TS implementation for user-defined timestepping

[Matthew Knepley]

On 9/18/07, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>
> On Tue, 18 Sep 2007, Matthew Knepley wrote:
>
> > 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.
>
>     Hmmm, maybe this is the key point in our disconnect. I did not envision that
> the user could simply take a function they use for SNES and pop it into TS
> (somehow) to get a time-stepping algorithm. Nor do I see this is a useful goal.
> If the user is doing A nonlinear equation they should use SNES, if they are
> solving a differential/algebraic equation they should use TS and never the twain
> should meet. (That is one does not graduate up to TS from SNES, in the way
> one does not graduate up from KSP to SNES.)

I can accept that the user might have to change the function. However, if we
cannot swap methods in the way we can swap KSP or SNES, what is the value
for the user? That is the point I am trying to make. I can see how to do many
FD methods if I have the identity, but see no approach to FEM. So maybe we
can be more specific about:

  a) What class of methods we can support interchangably

  b) What interface is necessary to support these methods

   Matt

   Matt

>    Barry
>
> Of course the TS implementations should generally use SNES when possible.
>
>
> >  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