> On Jul 24, 2017, at 10:44 PM, Matthew Knepley <[email protected]> wrote: > > On Mon, Jul 24, 2017 at 12:28 PM, Barry Smith <[email protected]> wrote: > > > On Jul 24, 2017, at 5:03 AM, Stefano Zampini <[email protected]> > > wrote: > > > > > > > > 2017-07-24 11:26 GMT+03:00 Lisandro Dalcin <[email protected]>: > > On 23 July 2017 at 21:42, Barry Smith <[email protected]> wrote: > > > > > > Then explicit methods could automatically use a solve to apply the > > > mass matrix inverse for each "right hand side" application and implicit > > > methods could automatically "drop in" the mass matrix with the shift when > > > a right hand side Jacobian is given also. Instead of requiring the user > > > to handle this themselves. Are there any gotcha's that I am missing or is > > > this relatively straightforward? > > > > > > > > > IMHO I think that it is not worth the complication. I value the generality > > of the current API, that already is somewhat cumbersome to maintain. > > Users providing the RHS function + mass matrix already know that they > > should do M^-1 * rhsvec to compute the rhs function. > > Then they get wrong or confusing information with TSAdjoint, not a good > thing. > > > > Same for the RHS jacobian. > > > > > > > > > Why wouldn't we have this interface? > > > > > > > > > What if the user provides MassMatrix + IFunction/IJacobian + > > RHSFunction/RHSJacobian? Are you going to handle all the possible > > scenarios? Error? dump a warning with PetscInfo? Users that will need such > > a new API usually don't read PetscInfo output > > Error > > > > > > > As usual, the problem is on defining the interface and the trade on > > performance and generality. But I'm definitely +1 on this. > > > > > Almost for sure MFEM must have this type of API. > > > > > > > > > No. AFAIK, sundials has it, not MFEM. > > Natively in MFEM, they just suppors explicit > > Sure but this can still be an explicit method (though it has a solve in > it). > > But I thought they were solving mass matrix systems all over the place? > One of the CEED benchmarks is solving a mass matrix system. > > I put this in 10 years ago, and you took it out :)
Yes, but we had a really crappy overly complicated and yet limited API then. > > I tend to side with Stefano that the implicit case handles this. 99% of > people using explicit use a lumped matrix too. Maybe 99% should not be using a lumped method and if there was proper support they won't use a lumped method. > > Matt > > > or SDIRK. They also have interface to TS and Sundials. > > > > See https://github.com/mfem/mfem/blob/master/examples/ex9.cpp#L329 for > > native explicit ode solvers in MFEM. > > See here for the virtual method that allows using SDIRK > > https://github.com/mfem/mfem/blob/master/examples/ex10.cpp#L91 > > Here for sundials https://github.com/mfem/mfem/tree/master/examples/sundials > > > > With that said, if you want to use TS through MFEM, here you have an > > example https://github.com/mfem/mfem/blob/master/examples/petsc/ex9p.cpp, > > which is meant to be illustrative of the capabilities of the > > IFunction/RHSFunction (and jacobians) API in PETSc, not efficiency. > > > > > > Stefano will love it for sure... > > > > > > -- > > Lisandro Dalcin > > ============ > > Research Scientist > > Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) > > Extreme Computing Research Center (ECRC) > > King Abdullah University of Science and Technology (KAUST) > > http://ecrc.kaust.edu.sa/ > > > > 4700 King Abdullah University of Science and Technology > > al-Khawarizmi Bldg (Bldg 1), Office # 0109 > > Thuwal 23955-6900, Kingdom of Saudi Arabia > > http://www.kaust.edu.sa > > > > Office Phone: +966 12 808-0459 > > > > > > > > -- > > Stefano > > > > > -- > 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 > > http://www.caam.rice.edu/~mk51/
