Skip to content
Snippets Groups Projects

Support user-facing adaptivity in Python + doc improvements

Open Matt Wala requested to merge adaptive-dt into master
1 unresolved thread

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

Edited by Matt Wala

Merge request reports

Pipeline #20500 passed

Pipeline passed for ee59d1a1 on adaptive-dt

The target branch master does not exist. Please restore it or use a different target branch.
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Andreas Klöckner resolved all threads

    resolved all threads

    • I like all the other changes, but the generator-based time step setting kind of rubs me the wrong way because it's Python-only. I would prefer a procedure to set the time step that is uniform across all targets if possible.

    • Author Maintainer

      I don't agree. That idiom is not specific to Python. We can use the same pattern in most other languages that support coroutines.

    • 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.

    • Author Maintainer

      run() is also not compatible with Fortran because it’s a generator. Are you suggesting we get rid of run() too?

    • Please register or sign in to reply
  • Matt Wala mentioned in issue #33

    mentioned in issue #33

  • Consensus from meeting:

    • Introduce InputOpportunity event, to allow communicating requested time steps and other parameters to running code
    • Make the entire execution model coroutine-based
    • Don't expose phase boundaries to the user
  • Please register or sign in to reply
    Loading