flexible TS implementation for user-defined timestepping

Barry Smith bsmith at mcs.anl.gov
Tue Sep 18 20:22:37 CDT 2007


  I do not see why 1,2, and 3 are incompatiable with an "algebra based"
TS level. It just requires a smart design.

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


More information about the petsc-dev mailing list