drto 0.0.0__py3-none-any.whl
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- drto/__init__.py +16 -0
- drto-0.0.0.dist-info/METADATA +122 -0
- drto-0.0.0.dist-info/RECORD +5 -0
- drto-0.0.0.dist-info/WHEEL +4 -0
- drto-0.0.0.dist-info/licenses/LICENSE +28 -0
drto/__init__.py
ADDED
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
# Copyright (c) 2026 Devin Griffith
|
|
2
|
+
# SPDX-License-Identifier: BSD-3-Clause
|
|
3
|
+
"""drto: dynamic real-time optimization for Pyomo models.
|
|
4
|
+
|
|
5
|
+
Receding-horizon NMPC and moving horizon estimation for ``pyomo.dae`` models.
|
|
6
|
+
Design phase: the framework is recorded in DESIGN.md and AGENTS.md. No
|
|
7
|
+
functionality yet.
|
|
8
|
+
"""
|
|
9
|
+
from importlib.metadata import PackageNotFoundError, version
|
|
10
|
+
|
|
11
|
+
try:
|
|
12
|
+
__version__ = version("drto")
|
|
13
|
+
except PackageNotFoundError: # not installed (e.g. running from a source tree)
|
|
14
|
+
__version__ = "0.0.0"
|
|
15
|
+
|
|
16
|
+
__all__ = ["__version__"]
|
|
@@ -0,0 +1,122 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: drto
|
|
3
|
+
Version: 0.0.0
|
|
4
|
+
Summary: Dynamic real-time optimization: receding-horizon NMPC and moving horizon estimation for Pyomo models.
|
|
5
|
+
Project-URL: Homepage, https://github.com/devin-griff/drto
|
|
6
|
+
Project-URL: Repository, https://github.com/devin-griff/drto
|
|
7
|
+
Project-URL: Issues, https://github.com/devin-griff/drto/issues
|
|
8
|
+
Author-email: Devin Griffith <dwg176@gmail.com>
|
|
9
|
+
License-Expression: BSD-3-Clause
|
|
10
|
+
License-File: LICENSE
|
|
11
|
+
Keywords: dae,dynamic-optimization,mhe,moving-horizon-estimation,nmpc,pyomo,receding-horizon
|
|
12
|
+
Classifier: Development Status :: 1 - Planning
|
|
13
|
+
Classifier: Intended Audience :: Science/Research
|
|
14
|
+
Classifier: License :: OSI Approved :: BSD License
|
|
15
|
+
Classifier: Programming Language :: Python :: 3
|
|
16
|
+
Classifier: Topic :: Scientific/Engineering :: Mathematics
|
|
17
|
+
Requires-Python: >=3.10
|
|
18
|
+
Requires-Dist: pyomo>=6.8.1
|
|
19
|
+
Provides-Extra: dev
|
|
20
|
+
Requires-Dist: pytest; extra == 'dev'
|
|
21
|
+
Requires-Dist: pytest-cov; extra == 'dev'
|
|
22
|
+
Provides-Extra: examples
|
|
23
|
+
Requires-Dist: jupyter; extra == 'examples'
|
|
24
|
+
Requires-Dist: matplotlib; extra == 'examples'
|
|
25
|
+
Requires-Dist: numpy; extra == 'examples'
|
|
26
|
+
Description-Content-Type: text/markdown
|
|
27
|
+
|
|
28
|
+
# drto
|
|
29
|
+
|
|
30
|
+
Dynamic real-time optimization: receding-horizon optimization and
|
|
31
|
+
estimation for Pyomo models, with advanced-step NMPC as the headline
|
|
32
|
+
capability and moving horizon estimation as the planned follow-on.
|
|
33
|
+
|
|
34
|
+
## The six modes
|
|
35
|
+
|
|
36
|
+
drto runs one declared model in any of six modes, the 2x3 grid of
|
|
37
|
+
{steady-state, dynamic} by {simulation, optimization, estimation}. You
|
|
38
|
+
write the model once; the mode fixes what is free and what the objective
|
|
39
|
+
is.
|
|
40
|
+
|
|
41
|
+
| | Simulation | Optimization | Estimation |
|
|
42
|
+
| --- | --- | --- | --- |
|
|
43
|
+
| **Steady-state** | solve the model at equilibrium | economic RTO | data reconciliation |
|
|
44
|
+
| **Dynamic** | integrate the model forward | NMPC / D-RTO | moving horizon estimation |
|
|
45
|
+
|
|
46
|
+
Down the columns: simulation frees nothing and solves the model as given;
|
|
47
|
+
optimization frees the controls and adds a cost; estimation frees the
|
|
48
|
+
states and fits them to measurements. Across the rows: steady-state
|
|
49
|
+
collapses the model to a single equilibrium point, dynamic keeps the time
|
|
50
|
+
horizon. The optimization and estimation columns are duals (NMPC with MHE,
|
|
51
|
+
RTO with reconciliation), so one declaration surface serves both.
|
|
52
|
+
|
|
53
|
+
The near-term focus is the optimization column: dynamic NMPC/D-RTO, whose
|
|
54
|
+
ideal, real-time, and advanced-step execution variants are the headline,
|
|
55
|
+
plus steady-state RTO. Estimation is the planned follow-on.
|
|
56
|
+
|
|
57
|
+
## Declaring a control problem
|
|
58
|
+
|
|
59
|
+
drto is declaration-first, and each declaration tags a Pyomo component you
|
|
60
|
+
already wrote: a Variable, a Constraint, or a Parameter. You build your dynamic model as
|
|
61
|
+
an ordinary `pyomo.dae` model, then point the declarations at its pieces;
|
|
62
|
+
drto assembles the horizon problem and runs the loop. It bolts onto an
|
|
63
|
+
existing model rather than replacing how you build one. The pieces are the
|
|
64
|
+
object types of an optimal control problem (the dynamic-optimization
|
|
65
|
+
mode):
|
|
66
|
+
|
|
67
|
+
| DRTO object type | Pyomo object type | Declaration | What it is |
|
|
68
|
+
| --- | --- | --- | --- |
|
|
69
|
+
| State | Variable | `declare_state(m.z, ...)` | A differential state. drto reads its dynamics from the state's `DerivativeVar`. |
|
|
70
|
+
| Control | Variable | `declare_control(m.u, ..., wrt=m.t, profile=...)` | A manipulated input, the decision variable. The `profile` flag sets its parameterization (piecewise-constant, ...) via pyomo-cvp. |
|
|
71
|
+
| Tracking stage cost | Constraint | `declare_tracking_stage_cost(m.tracking_stage_con)` | Equality defining the setpoint-tracking running cost; its left-hand-side scalar goes in the objective. The setpoint it references is the declared steady-state Param (below). |
|
|
72
|
+
| Economic stage cost | Constraint | `declare_economic_stage_cost(m.economic_stage_con)` | Equality defining the economic running cost; the same objective the steady-state RTO mode uses. |
|
|
73
|
+
| Tracking terminal cost | Constraint | `declare_tracking_terminal_cost(m.tracking_terminal_con)` | Equality defining the terminal tracking cost; its left-hand-side scalar goes in the objective. |
|
|
74
|
+
| Initial condition | Constraint | `declare_initial_condition(m.init_con)` | Equality anchoring the initial state; left-hand side is the state at t0, right-hand side the feedback. |
|
|
75
|
+
| Terminal constraint | Constraint | `declare_terminal_constraint(m.terminal_con)` | Constraint on the states at the final time; the terminal set the final state must lie in. |
|
|
76
|
+
| Steady-state target | Parameter | `declare_steady_state(m.z_ss)` | The state setpoint the tracking costs drive toward; populated by the steady-state/RTO solve. |
|
|
77
|
+
| Steady-state control target | Parameter | `declare_steady_state_control(m.u_ss)` | The control setpoint the tracking costs drive toward. |
|
|
78
|
+
|
|
79
|
+
Conventions drto enforces on those constraints: the cost and
|
|
80
|
+
initial-condition constraints are equalities whose left-hand side is the
|
|
81
|
+
scalar the declaration is about (the cost term, or the anchored state); a
|
|
82
|
+
terminal constraint may reference only states at the final time, which is
|
|
83
|
+
what separates it from a path constraint. The objective is drto's own: it
|
|
84
|
+
sums the declared cost terms that are live in the current mode, so a mode
|
|
85
|
+
drops a term just by leaving out its constraint.
|
|
86
|
+
|
|
87
|
+
Two things you never declare, because they already live in the model: the
|
|
88
|
+
**dynamics** are read from the `pyomo.dae` `DerivativeVar`s of the
|
|
89
|
+
declared states, and the **path constraints** are the state variables'
|
|
90
|
+
own upper and lower bounds.
|
|
91
|
+
|
|
92
|
+
The vocabulary is the optimal-control literature's own (stage cost,
|
|
93
|
+
terminal cost, terminal constraint), so a model reads the way the theory
|
|
94
|
+
does. The other modes reuse the same model: simulation drops the cost, and
|
|
95
|
+
estimation swaps the initial condition for a soft arrival cost and adds the
|
|
96
|
+
estimation pieces below.
|
|
97
|
+
|
|
98
|
+
## Declaring an estimation problem
|
|
99
|
+
|
|
100
|
+
Estimation is the dual half (moving horizon estimation, the planned
|
|
101
|
+
follow-on), and it declares its own pieces the same way. MHE fits the model
|
|
102
|
+
to a moving window of measurements, so the free variables and the objective
|
|
103
|
+
terms differ, but the conventions carry over: each declaration tags a Var,
|
|
104
|
+
a Constraint, or a Param, and drto assembles the estimation objective from
|
|
105
|
+
the live cost terms.
|
|
106
|
+
|
|
107
|
+
| DRTO object type | Pyomo object type | Declaration | What it is |
|
|
108
|
+
| --- | --- | --- | --- |
|
|
109
|
+
| Estimated parameter | Variable | `declare_estimated_parameter(m.theta, ...)` | Unknown model parameters to estimate, constant over the window. Shared with steady-state data reconciliation. |
|
|
110
|
+
| Disturbance | Variable | `declare_disturbance(m.w, ...)` | Process-noise variables (`dz/dt = f + w`) the estimator adjusts to fit the data, penalized by their covariance. |
|
|
111
|
+
| Measurement | Parameter | `declare_measurement(m.y_meas, ...)` | The measured values in the estimation cost residuals; a mutable Param drto refreshes each step. |
|
|
112
|
+
| Estimation stage cost | Constraint | `declare_estimation_stage_cost(m.est_stage_con)` | Equality defining the running estimation cost: measurement residual plus process-noise penalty over the window. |
|
|
113
|
+
| Estimation terminal cost | Constraint | `declare_estimation_terminal_cost(m.est_terminal_con)` | Equality for the current-time measurement residual (no process noise leads out of the last point). |
|
|
114
|
+
| Arrival cost | Constraint | `declare_arrival_cost(m.arrival_con)` | Equality for the soft prior on the window's initial state; its weight is updated by covariance propagation. |
|
|
115
|
+
|
|
116
|
+
The arrival cost is the soft dual of the control side's initial condition,
|
|
117
|
+
and the estimation stage and terminal costs are the measurement-fitting
|
|
118
|
+
counterparts of the tracking costs.
|
|
119
|
+
|
|
120
|
+
## Status
|
|
121
|
+
|
|
122
|
+
Design phase: see [DESIGN.md](DESIGN.md). No code yet.
|
|
@@ -0,0 +1,5 @@
|
|
|
1
|
+
drto/__init__.py,sha256=QhLtJfOJr7_zenD154sdQ39fjtLIGCt6qRVx99OXQmI,541
|
|
2
|
+
drto-0.0.0.dist-info/METADATA,sha256=y_g4tdLdWyMIEnfUkutREVU7dfKNgcKOCFfDgstnOow,7650
|
|
3
|
+
drto-0.0.0.dist-info/WHEEL,sha256=lCkmxWfQsSc9CfIClYeavTdQeEX2toPqufh9gI35EQA,87
|
|
4
|
+
drto-0.0.0.dist-info/licenses/LICENSE,sha256=XhOi3_0uj4sbflwX12UbtzxieBuVBOuiGdTv5GIbgpY,1501
|
|
5
|
+
drto-0.0.0.dist-info/RECORD,,
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
BSD 3-Clause License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026, Devin Griffith
|
|
4
|
+
|
|
5
|
+
Redistribution and use in source and binary forms, with or without
|
|
6
|
+
modification, are permitted provided that the following conditions are met:
|
|
7
|
+
|
|
8
|
+
1. Redistributions of source code must retain the above copyright notice, this
|
|
9
|
+
list of conditions and the following disclaimer.
|
|
10
|
+
|
|
11
|
+
2. Redistributions in binary form must reproduce the above copyright notice,
|
|
12
|
+
this list of conditions and the following disclaimer in the documentation
|
|
13
|
+
and/or other materials provided with the distribution.
|
|
14
|
+
|
|
15
|
+
3. Neither the name of the copyright holder nor the names of its
|
|
16
|
+
contributors may be used to endorse or promote products derived from
|
|
17
|
+
this software without specific prior written permission.
|
|
18
|
+
|
|
19
|
+
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
|
|
20
|
+
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
21
|
+
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
|
|
22
|
+
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
|
|
23
|
+
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
24
|
+
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
|
|
25
|
+
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
|
|
26
|
+
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
|
|
27
|
+
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
|
28
|
+
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|