Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow IMEX solvers for stiff problems #165

Open
JoshuaLampert opened this issue Dec 4, 2024 · 4 comments
Open

Allow IMEX solvers for stiff problems #165

JoshuaLampert opened this issue Dec 4, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@JoshuaLampert
Copy link
Owner

Currently, we wrap every semidiscretization in an ODEProblem. However, some equations contain stiff terms, such as the Svärd-Kalisch equations with $\alpha = 0$ and/or $\gamma = 0$ or the KdV equation (once implemented). Therefore, it would be nice to split up the rhs into a non-stiff part and a stiff part, which are then stored as a SplitODEProblem. This allows using IMEX time integrators.

@JoshuaLampert JoshuaLampert added the enhancement New feature or request label Dec 4, 2024
@JoshuaLampert
Copy link
Owner Author

Two additional thoughts:

  • Do we want to create a SplitODEProblem for every equation, i.e. also for those without stiff part by setting the stiff function simply to zero or do we want to stick an ODEProblem for these equations? In the latter case we could probably add a trait has_stiff_terms(equations) or something like that and dispatch on that. Do you see a disadvantage of the first option, @ranocha?
  • If we want to use a SplitODEProblem for the Svärd-Kalisch equations, we probably need to use the mass_matrix argument from the SplitFunction instead of explicitly solving the linear system by our own. Is there a problem with that or is this maybe even benefitial?

@ranocha
Copy link
Collaborator

ranocha commented Dec 5, 2024

Setting up a SplitODEProblem for non-stiff problems has an additional overhead. I don't know how much but we should investigate this before deciding how to proceed. Conceptually, it would be simpler if an ODE problem can just be an ODEProblem.

@ranocha
Copy link
Collaborator

ranocha commented Dec 5, 2024

I have not used the mass matrix formulation lately, so we need to check. However, we need to ensure that it works as desired, since the mass matrix depends on the state and does not occur (in a non-trivial form) for all components.

@JoshuaLampert
Copy link
Owner Author

I have not used the mass matrix formulation lately, so we need to check. However, we need to ensure that it works as desired, since the mass matrix depends on the state and does not occur (in a non-trivial form) for all components.

Yes, that's true. However, it might work with a MatrixOperator from SciMLOperators.jl, see https://docs.sciml.ai/SciMLOperators/stable/interface/#Operator-update. We can provide an update_func taking the state variables. If and how well that works would need to be tested of course. See also https://discourse.julialang.org/t/state-dependent-mass-matrix/40238/5.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants