Add L-stable DIRK4 method, use to bootstrap A-stable DIRK4 #6084
Conversation
This method can be used as a starting method for AStableDirk4, or a more expensive 4th-order method in its own right. Refs idaholab#5701.
The AStableDirk4 method is a little strange in that it evaluates residuals *outside* of the current timestep. This can potentially be a problem for the first timestep, so by default we use a different 4th-order method, LStableDirk4, to compute the first timestep, and switch back to AStableDirk4 for subsequent timesteps.
Set Executioner/TimeIntegrator/safe_start=false in the tests file.
jwpeterson
force-pushed
the
lstable_dirk4
branch
from
956733c
to
7903676
Compare
|
Let me make a general comment here: while added capability is always cool... this may be getting out of hand. In general, code should only be added to MOOSE to add specific capability for a customer. Every piece of added code should be viewed as a maintenance burden. In this case: as we add more code to TimeIntegrators it becomes more difficult to evolve the time integration system, or even MOOSE in general. How many lines of code would need to change if we modified the TimeIntegration interfaces or infrastructure? How many tests would need to be fixed? There should be a cost/benefit analysis for every line of code we allow into the system. What are we going to get for the tradeoff in maintenance? Maybe it would be helpful to know what your overall goals are here. Are you adding the DIRK4 stuff as a stepping stone to something else? Can we ultimately remove it once you get there? Anyway: I'm not completely against this PR (it is adding capability, and it is tested, etc.) but we need to draw a line somewhere... |
|
@friedmud we have an LDRD milestone to add adaptive timestepping methods to MOOSE. These will be based on DIRK methods like this one. |
|
Alright... but why is that an LDRD milestone? Is there really a driving need for such high order methods that require tiny timesteps? Anyway... I won't fight it. I'm sure you guys have worked it out there. |
|
I'd say that our new LDRD isn't aligned with our physics goals. This is on purpose. NEAMS is now our #1 customer for driving the development of our physics based needs and all enhancements for those features are being billed as such. Our LDRD is for perpendicular research and experimental algorithms. I guess we're fortunate to have both funding sources. |
|
Nice - I inadvertently linked in a removed ticket! |
|
@jwpeterson and I chatted about this and it sounds like he has a good handle on the situation. I'll quietly step out of the way on this one ;-) |
OK, but who does #2 work for? |
Add L-stable DIRK4 method, use to bootstrap A-stable DIRK4
The
AStableDirk4method is a little strange in that it evaluates residuals outside of the current time step. This can potentially be a problem for the first time step, so by default we introduce a different 4th-order method,LStableDirk4, to compute the first timestep, and switch back toAStableDirk4(which is less expensive) for subsequent timesteps.Note that the
LStableDirk4method is also potentially useful in its own right, and can be more accurate thanAStableDirk4on certain problems (see plot below).