New AssignImplicit interface: Dagrt side
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
Merge request reports
Activity
mentioned in merge request leap!40
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. changed this line in version 3 of the diff
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 changed this line in version 3 of the diff
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 """ 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.)
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 input_expressions
are meant to be evaluated at runtime, whileparams
contains compile-time information. I've usedparams
to include information about the component id of the right-hand side function.Edited by Matt Wala
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 - Resolved by Matt Wala
This is ready to look at again @inducer