September 2007 - petsc-dev - mailman3.cels.anl.gov

Re: flexible TS implementation for user-defined timestepping
by Barry Smith 18 Sep '07

18 Sep '07

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(a)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(a)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/implici… > > > > > > 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 > > > > >

1 0

Re: flexible TS implementation for user-defined timestepping
by Matthew Knepley 18 Sep '07

18 Sep '07

On 9/18/07, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > On 9/18/07, Matthew Knepley <knepley(a)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(a)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/implici… > > > > > > > > > > > > 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

1 0

Re: flexible TS implementation for user-defined timestepping
by Lisandro Dalcin 18 Sep '07

18 Sep '07

On 9/18/07, Matthew Knepley <knepley(a)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. 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(a)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/implici… > > > > > > > > > > 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

1 0

Re: flexible TS implementation for user-defined timestepping
by Matthew Knepley 18 Sep '07

18 Sep '07

On 9/18/07, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > On 9/18/07, Matthew Knepley <knepley(a)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. 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. > > 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? The thesis of Anders Logg (also published as papers) is very good. Matt > > > On 9/17/07, Lisandro Dalcin <dalcinl(a)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/implici… > > > > > > > > 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

1 0

Re: flexible TS implementation for user-defined timestepping
by Lisandro Dalcin 18 Sep '07

18 Sep '07

On 9/18/07, Matthew Knepley <knepley(a)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(a)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/implici… > > > > > > 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

1 0

Re: flexible TS implementation for user-defined timestepping
by Matthew Knepley 18 Sep '07

18 Sep '07

On 9/17/07, Matthew Knepley <knepley(a)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(a)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/implici… > > > > 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

1 0

Re: flexible TS implementation for user-defined timestepping
by Lisandro Dalcin 18 Sep '07

18 Sep '07

On 9/18/07, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Yes, TS sucks and always has. I believe it sucks because > > I think I disagree with Matt, in that I think a solid, flexible framework > can be developed that is essentially still only algebraic (like SNES/KSP/PC). > I would like to see the equation/discretization features "overlaid" the > algebraic framework and not "protube" into the lower "algebraic" level. > And I have to agree with you, Barry. Indeed, I believe PESTSc should start providing a very flexible, high-level framework for timestepping. Initially, the user should be in charge of completelly define the functions/operators involved in the space-time discretization, and let SNES/KSP solve them, or even let users define the way of advancing from time level to time level. Of course, once this is available, Matt can build on it in order to ask users less code for solving your problems. In my particular use case (NS eqs. with SUPG/PSPG stab.) it is not so easy to completelly abastract the time discretization, as the stabilization method depend on element sizes, time step, and the (complete) residual of the PDE (except second spacial derivatives if using linear elements). As such, I have to see my time-step problem as a algebraic nonlinear problem in u^{n+1} wich could be written as: F(t^{n+1}, u^{n+1}, t^n, u^n) = 0 this could even be more general in implicit multistep schemes: F(t^{n+1},u^{n+1}, t^n, u^n) = G(t^{n-k},u^{n-k}), k>0 where G is an afine vector for the nonlinear problem with F. I believe TS should support this kind of problems at the very high level. Until now, it always assumed a time discretization for problems of the type dU/dt = F(t,U). Almost all the features I've implemented in my custom timestepper should be integrated in the TS interface. Current TS types (beuler, cn, pseudo) are just a particular, simpler case of the general case above. Additionally, users should be able to completely define the way to advance solution in time. An example from CFD: fractional-step like (or pressure-splitting) method. Here, for advancing solution, you possibly need a SNES (if you treat mommentum eqs. as nonlinear), or one KSP (if mom. eqs. are linearized but coupled), or perhaps one/three KSP's (for each mom. eq., where they can can have the same or different sizes, depending in the way of treating boundary conditions.) All this said, I encourage you to take a look at my current code for implicit nonlinear, and think a bit about how to define what a general LINEAR problem should look. Then I can take the effort of updating current TS implementations to cope with the general cases, and subtypes to be inplemented inside this framework. Regards, > > On Mon, 17 Sep 2007, Matthew Knepley 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. > > > > Thus, as I have maintained for a while, I think the way forward is to give PETSc > > some measure of control over not just the discretization, but the equation > > handling. So far, I can only see how this might have in FEM, although FD is > > probably not any harder. For each method, the provided weak form would be > > altered to accomodate the time discretization. Eventually, I believe the right > > thing to do is use Galerkin time discretizations as well since this allows local > > optimization of the time steps, crucial to adaptivity. > > > > Matt > > > > On 9/17/07, Lisandro Dalcin <dalcinl(a)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/implici… > > > > > > 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 > > > > > > > > > > > > -- 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

1 0

Re: flexible TS implementation for user-defined timestepping
by Barry Smith 17 Sep '07

17 Sep '07

Yes, TS sucks and always has. I believe it sucks because 1) it has gotten little thought and been built up piece-meal over the years; plus none of the PETSc developers has a proper grounding in ODE/differential algebraic equations. Yes we've taken classes and used them but we have not devoted our lives to them. 2) it has been used very little and so has not evolved well according to users needs. I think I disagree with Matt, in that I think a solid, flexible framework can be developed that is essentially still only algebraic (like SNES/KSP/PC). I would like to see the equation/discretization features "overlaid" the algebraic framework and not "protube" into the lower "algebraic" level. Barry On Mon, 17 Sep 2007, Matthew Knepley 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. > > Thus, as I have maintained for a while, I think the way forward is to give PETSc > some measure of control over not just the discretization, but the equation > handling. So far, I can only see how this might have in FEM, although FD is > probably not any harder. For each method, the provided weak form would be > altered to accomodate the time discretization. Eventually, I believe the right > thing to do is use Galerkin time discretizations as well since this allows local > optimization of the time steps, crucial to adaptivity. > > Matt > > On 9/17/07, Lisandro Dalcin <dalcinl(a)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/implici… > > > > 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 > > > > > > >

1 0

Re: flexible TS implementation for user-defined timestepping
by Matthew Knepley 17 Sep '07

17 Sep '07

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. Thus, as I have maintained for a while, I think the way forward is to give PETSc some measure of control over not just the discretization, but the equation handling. So far, I can only see how this might have in FEM, although FD is probably not any harder. For each method, the provided weak form would be altered to accomodate the time discretization. Eventually, I believe the right thing to do is use Galerkin time discretizations as well since this allows local optimization of the time steps, crucial to adaptivity. Matt On 9/17/07, Lisandro Dalcin <dalcinl(a)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/implici… > > 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

1 0

flexible TS implementation for user-defined timestepping
by Lisandro Dalcin 17 Sep '07

17 Sep '07

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/implici… 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

1 0