added: NonLinModelDAE for differential and algebraic equations + sim! support - #442
Merged
Conversation
There is no possible ambiguity in the camel-casing this way.
This is more consistent with julia base style
If it is a supertype it is necessarily abstract. It's more concise like this.
The continuity constraint is a linear constraint.
It will be consistent with upcoming `A0` and `Ā` vectors with the algebraic variables.
This is clearer like this since it's only in the `LinModel` case that the steady-state is computed.
This is not strictly needed to update the state, but it is still useful to compute it, for diagnosis (e.g. with `getinfo`). Otherwise this specific value is never explicitly computed.
Now `a0` is at the same position for `OC` and `TC`, to simplify the logic in `f!` method.
This computation is expensive so it's better to skip it if the provided `h!` argument is not a function of the algebraic variable.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #442 +/- ##
==========================================
- Coverage 97.17% 96.93% -0.24%
==========================================
Files 27 28 +1
Lines 6270 6600 +330
==========================================
+ Hits 6093 6398 +305
- Misses 177 202 +25
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Member
Author
|
The failling test on Win11 and LTS is unrelated. Seems to be an issue with and old manifest file and the cache on GitHub actions. |
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
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.
The new$\mathbf{Z}$ and the nonlinear inequality constraint $\mathbf{g}$ ):
SimModeltype introduces the support of plant model expressed as differential and algebraic equation (DAE) systems. The API and the code base rely on the following notation (to avoid any confusions with the decision variablePure discrete-time DAEs are not supported for now. This PR added the functionalities for open-loop simulations of DAEs using collocation methods (
TrapezoidalCollocationorOrthogonalCollocation). The following generic functions now supportNonLinModelDAEobjects:evaloutput(model::NonLinModelDAE, d) -> y: solve the algebraic equation (if required, see below) and compute the current outputupdatestate!(model::NonLinModelDAE, u, d) -> xnext: solve the collocation problem and compute the next stategetinfo(model::NonLinModelDAE) -> info: return information post-solving for troubleshooting, for examplesim!(model::NonLinMidelDAE, N, u, <kw args>) -> res: quick open-loop simulations, similar other model types.As described in #332 and the docstring, the open-loop simulation code base uses
JuMP.jl,MOI.VectorNonlinearOracleandDifferentiationInterface.jlto solve the two nonlinear root problems ofevalouputandupdatestate!. They both useIpopt.jland denseForwardDiff.jlJacobians by default. Note thatSparseConnectivityTracer.jlwill analyze the system and return an error if it is not strictly proper. Also note thatevaloutputwill skip the algebraic equation solving if it is not required, according toSparseConnectivityTracer.jl.To global goal here is to support plant model generated by acausal modeling tools like
ModelingToolkit.jl, since they typically produces DAEs instead of ODEs. I still want to mention that ODEs are insanely simpler in terms of algorithmic complexity, soNonLinModelobjects for ODEs should be used when possible to reduce the dimensions and complexity (thanks to multiple dispatch!).Important
NonLinMPCandMovingHorizonEstimatordo not supportNonLinModelDAEobjects for now.Related to #332