Conversation
Would allow PETSc to use coloring to speed up finite difference calculation of the system Jacobian.
Seems to work well for the IMEX/diffusion-nl problem Doesn't converge for the IMEX/drift-wave problem.
If model was not split, then previously the RHS function was treated as a convective (explicit) part. Now switched so that unsplit models are treated as entirely diffusive (implicit)
When using coloring to calculate the Jacobian, re-use the Jacobian 4 times by default.
o IMEX-BDF2 solver can now handle constraints as part of the implicit solve. This can be used to solve for potential, for example. o Added examples/IMEX/drift-wave-constraint which solves for the potential phi as a constraint rather than inside the RHS. o Moved generic and duplicated variable loading code from IDA solver to Solver base class. o Changed error handling in Solver::save_vars(). Now throws exception with useful error message, rather than returning error code.
The linear flag in the diffusive() RHS function call is now set when the Jacobian is being calculated using coloring.
Conflicts: src/solver/impls/imex-bdf2/imex-bdf2.cxx
Added a small section to the user manual on the IMEX-BDF2 solver, and added some example code for solving with constraints.
Member
|
I think line 590 of imex-bdf2.cxx may need modifying to support PETSc<3.4. |
In 3.4 SNESDefaultComputeJacobianColor was renamed to SNESComputeJacobianDefaultColor
Member
|
I find that using the matrix_free=true approach leads to errors unless I specify |
Contributor
Author
|
Hi David, I found it worked with preconditioning. Is this for the IMEX/diffusion-nl Ben On 3 February 2016 at 09:46, David Dickinson notifications@github.com
|
Member
|
This is actually for the gyro-fluid model that I'm working on. I'm using v3.4.5 and I'm running with |
Member
|
Ah sorry, it looks like this was from an unclean build. |
Also introduces higher order schemes (up to fourth order). This commit involves a substantial restructuring of the original imex-bdf code in order to make it easier to change the order of the scheme. Introduced imex-bdf3 and imex-bdf4 schemes. Adaptivity possible (set adaptive = true). This requires use of significantly more complicated coefficients (see code for reference) but general structure of scheme essentially unchanged. Error estimated by comparing solution with requested order scheme and one order lower. Rough argument then used to decide how to change the timestep. This argument works ok for requested order >=3, a little bit trickier when order = 2. Some things to note are: 1. Changing the timestep frequently can significantly increase the number of implicit solves required. The nadapt option aims to help control this. 2. Recommend order >=3 when adaptive. Whilst this commit introduces a fully tested and working feature there are some outstanding elements that are intended to be addressed in the future: 1. Add documentation of all input parameters (comments in code should be enough for now). 2. Catch failures of the SNESSolve call to allow a repeat with a smaller timestep (if desired) rather than aborting as done currently. 3. Develop automatic decision making for how often to check the error when adaptive. 4. Investigate alternative schemes (e.g. TVB rather than BDF). Some outstanding issues/concerns also exist: 1. MMS time test (non-adaptive) gives 2nd order for 3rd and 4th order schemes in some situations (depends on relative size of explicit and implicit ddt values). 2. Use of two SNES solve object could possibly lead to a drift in results used for the error checking over time (most likely leading to a slightly smaller timestep than needed). This is because if the KSP tolerances are not tight enough the SNES solve can be slightly dependent on the previous result, which means the high and low order solvers, which have slightly different solutions from the previous stage, could give different results. 3. Adaptivity may struggle if the explicit scheme is limiting the timestep. This isn't tested but could be a slight issue. May want to introduce a cfl like parameter which allows us to add some safety margin to our timestep estimate.
bendudson
added a commit
that referenced
this pull request
Feb 22, 2016
Major changes/improvements to the IMEX-BDF2 solver - Adaptive timestepping and higher order schemes (BDF3) - Coloring for faster finite difference Jacobian calculation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds support for algebraic constraints and finite difference Jacobian approximation using coloring to the IMEX-BDF2 solver
New example IMEX/drift-wave-constraint
Some documentation in README.md files and the user manual