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 :) I tend to side with Stefano that the implicit case handles this. 99% of people using explicit use a lumped matrix too. 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/
