Skip to content
Snippets Groups Projects

New AssignImplicit interface: Dagrt side

Open Matt Wala requested to merge new-implicit-interface into master
5 unresolved threads

This change modifies the way that AssignImplicit instructions represent systems of implicit equations in Dagrt.

The AssignImplicit instruction gains two attributes, input_expressions and params. The purpose of these attributes is to supply the important parts of the system of implicit equations directly to the user, rather than indirectly through a symbolic expression, which was the former interface. The old attributes expressions, other_params, and solve_variables are removed.

CodeBuilder is also updated to support the new interface.

This change is also a version bump.

See leap!40

cc: @cory

Edited by Matt Wala

Merge request reports

Pipeline #50952 passed

Pipeline passed for cb276db1 on new-implicit-interface

Test summary results are being parsed
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
318 320 system. This identifier is intended to match information about
319 321 solvers which is supplied by the user.
320 322
323 The contents of this dictionaries *input_expressions* and *params* are
324 deliberately under-specified and the details are expected to be documented
325 by the scheme designer.
  • 297 A tuple of strings. The names of the variables to assign with the
    298 results of solving for `solve_variables`
    297 A tuple of strings, the names of the variables that are assigned by this
    298 instruction. The assignees represent solutions to a single
    299 equation or a system of (implicit) equations.
    299 300
    300 .. attribute:: solve_variables
    301 .. attribute:: input_expressions
    301 302
    302 A tuple of strings, the names of the variables being solved for
    303 A dictionary mapping strings to (symbolic) expressions that are
    304 evaluated as the inputs to an equation solver. The expressions in this
    305 dictionary are tracked for dependency and transformation purposes.
    303 306
    304 .. attribute:: expressions
    307 For ease of organization only, the values in this dictionary are allowed
  • 318 320 system. This identifier is intended to match information about
    319 321 solvers which is supplied by the user.
    320 322
    323 The contents of this dictionaries *input_expressions* and *params* are
    324 deliberately under-specified and the details are expected to be documented
    325 by the scheme designer.
    326
    321 327 """
    • At this point, is AssignImplicit meaningfully different from a function call? The only difference I can see is the availability of the non-symbolic params, whose existence I question above.

    • Author Maintainer

      Not really. The main reason I think it's worth having is because we don't have a standardized interface for calling solvers the way we do for other entities such as right-hand side functions, and therefore creating function calls to solvers will necessarily require some amount of symbolic postprocessing. I also don't know of any other software that has a standardized interface we could adopt. (For comparison, ODEINT doesn't attempt to solve the problem that we are trying to, because their interface for implicit methods doesn't offer solver customization as far as I can tell.)

    • Please register or sign in to reply
  • 301 .. attribute:: input_expressions
    301 302
    302 A tuple of strings, the names of the variables being solved for
    303 A dictionary mapping strings to (symbolic) expressions that are
    304 evaluated as the inputs to an equation solver. The expressions in this
    305 dictionary are tracked for dependency and transformation purposes.
    303 306
    304 .. attribute:: expressions
    307 For ease of organization only, the values in this dictionary are allowed
    308 to contain nested tuples of expressions, though tuples are not
    309 otherwise generally supported in :mod:`dagrt` expressions.
    305 310
    306 A tuple of expressions, which represent the left hand sides of a
    307 system of (possibly nonlinear) equations. The solver will attempt
    308 to find a simultaneous root of the system.
    311 .. attribute:: params
  • 296 296
    297 A tuple of strings. The names of the variables to assign with the
    298 results of solving for `solve_variables`
    297 A tuple of strings, the names of the variables that are assigned by this
    298 instruction. The assignees represent solutions to a single
    299 equation or a system of (implicit) equations.
    299 300
    300 .. attribute:: solve_variables
    301 .. attribute:: input_expressions
    301 302
    302 A tuple of strings, the names of the variables being solved for
    303 A dictionary mapping strings to (symbolic) expressions that are
    304 evaluated as the inputs to an equation solver. The expressions in this
    305 dictionary are tracked for dependency and transformation purposes.
    303 306
    304 .. attribute:: expressions
    • It might be worthwhile retaining some notion of the system of equations that the solver is supposed to solve (e.g. for automated residual checks).

    • Author Maintainer

      My vote would be not to have this unless there's a compelling use case. As we discussed yesterday, this would involve duplicating information that's already present in the dictionaries. The system can be reconstructed on a case-by-case basis from that information.

    • Please register or sign in to reply
  • Thanks for working on this!

  • Matt Wala added 5 commits

    added 5 commits

    • d15e8172 - Generate documentation for CodeBuilder.assign_implicit
    • a5256719 - Improve AssignImplicit documentation
    • 80df5450 - markup consistency
    • 73981e18 - pronoun agreement
    • 67be2c73 - Improve doc clarity

    Compare with previous version

  • Matt Wala added 1 commit

    added 1 commit

    Compare with previous version

  • Author Maintainer

    This is ready to look at again @inducer

  • Please register or sign in to reply
    Loading