Support user-facing adaptivity in Python + doc improvements
Closes #29
This adds a dt_next parameter to run and run_single_step to support adapting the time step. Additionally, the generator returned by run supports receiving the next value of dt via the send method.
In addition, this change:
- Reduces code duplication between interpreter and codegen: the module dagrt.events_python is created to hold code for events
- Renames StepCompleted.current_state to StepCompleted.current_phase
- Improves the interpreter documentation
- Adds a dt attribute to StepFailed
- Makes a few stylistic fixes to the Python code generator
- Addresses an interface inconsistency between the interpreter and the code generator: while the code generator raised a StepError in the case of a Raise, the interpreter raised whichever type was supplied by the Raise statement. This change modifies the behavior of Raise in the interpreter to also raise a StepError. The previous behavior required the argument to Raise to be a Python exception type, which went against the language-agnosticity of the representation.
- Updates the adaptive_rk example to use the new adaptivity interface.
The version is bumped to 2019.5
Leap test (should not require any changes): leap!31
Merge request reports
Activity
added 4 commits
-
12ee1887...b488c8dd - 3 commits from branch
master
- 4e59e3ad - Merge branch 'master' into adaptive-dt
-
12ee1887...b488c8dd - 3 commits from branch
mentioned in commit leap@5a359bfe
mentioned in merge request leap!31
added 1 commit
- d59916a6 - Fix a sentence in the documentation for run_single_step
added 1 commit
- 0174acae - Actually fix interpreter code generation of Raise
added 1 commit
- dc617dc7 - Rewrite adaptive_rk example to use new adaptivity interface
- Resolved by Andreas Klöckner
most other languages that support coroutines.
Aka not Fortran. :) I mean, we could implement some coroutine-y thing in Fortran (if you want to see something gross like that, look at ARPACK's "reverse communication interface"), but I kind of don't want to.
My point is more that I'd like a single idiom to be usable across all languages. Fortran codegen as currently implemented kind of forces us to allow some stateful set-dt-at-the-end-of-a-phase thing, i.e. something decidedly un-fancy. If Python is fancier than that, then that leads to an inconsistency across languages that I would prefer to avoid.
mentioned in issue #33