flexible TS implementation for user-defined timestepping
Lisandro Dalcin
dalcinl at gmail.com
Tue Sep 18 12:08:59 CDT 2007
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.
> 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?
> > 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
More information about the petsc-dev
mailing list