You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/python-c.mdx
+94-22Lines changed: 94 additions & 22 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -77,7 +77,7 @@ The generated C/C++ bindings are in the auto-generated solver library.
77
77
In particular
78
78
79
79
* The header files are at `the_optimizer/the_optimizer_bindings.{h,hpp}`
80
-
* The static and dynamical library files are located in `the_optimizer/target/{debug,release}` (depending on whether it was a [*debug*] or [*release*] build)
80
+
* The static and dynamic library files are located in `the_optimizer/target/{debug,release}` (depending on whether it was a [*debug*] or [*release*] build)
81
81
82
82
Note that `the_optimizer` is the name given to the optimizer in the Python codegen above.
@@ -137,10 +140,61 @@ This is designed to follow a new-use-free pattern.
137
140
138
141
Function `{optimizer-name}_new` will allocate memory and setup a new solver instance and can be used to create as many solvers as necessary. Each solver instance can be used with `{optimizer-name}_solve` to solve the corresponding problem as many times as needed.
139
142
140
-
Parameter `u` is the starting guess and also the return of the decision variables and `params` is the array of static parameters. The size of `u` and `params` are `{optimizer-name}_NUM_DECISION_VARIABLES` and `{optimizer-name}_NUM_PARAMETERS` respectively.
143
+
Parameter `u` is the starting guess and also the return of the decision variables and `params` is the array of static parameters. The size of `u` and `params` are `{optimizer-name}_NUM_DECISION_VARIABLES` and `{optimizer-name}_NUM_PARAMETERS` respectively. Arguments `y0` and `c0` are optional: pass `0` (or `NULL`) to use the default initial Lagrange multipliers and penalty parameter.
144
+
145
+
The returned `exampleSolverStatus` always contains a coarse solver outcome in
146
+
`exit_status`. On success it also contains `error_code = 0` and an empty
147
+
`error_message`. If the solver fails internally, the bindings return a
148
+
structured error report with a nonzero `error_code` and a descriptive
149
+
`error_message`.
141
150
142
151
Finally, when done with the solver, use `{optimizer-name}_free` to release the memory allocated by `{optimizer-name}_new`.
143
152
153
+
## Handling errors
154
+
155
+
The C bindings always return a value of type `exampleSolverStatus`. This means
156
+
that solver calls do not report failure by returning `NULL` or by using a
157
+
separate exception-like mechanism. Instead, callers should inspect both
158
+
`exit_status` and `error_code`.
159
+
160
+
- `error_code = 0` means the solver call completed without an internal error
161
+
- `error_code != 0` means the solver failed and `error_message` contains a
162
+
descriptive explanation
163
+
- `exit_status` gives the coarse outcome of the solve attempt, such as
164
+
converged, reached the iteration limit, or failed because of a numerical
165
+
issue
166
+
167
+
The recommended pattern is:
168
+
169
+
1. Call `{optimizer-name}_solve(...)`
170
+
2. Check whether `status.error_code != 0`
171
+
3. If so, report `status.error_message` and treat the call as failed
172
+
4. Otherwise, inspect `status.exit_status` to determine whether the solver
173
+
converged or returned the best available non-converged iterate
174
+
175
+
For example:
176
+
177
+
```c
178
+
exampleSolverStatus status = example_solve(cache, u, p, 0, &initial_penalty);
179
+
180
+
if (status.error_code != 0) {
181
+
fprintf(stderr, "Solver failed: [%d] %s\n",
182
+
status.error_code, status.error_message);
183
+
example_free(cache);
184
+
return EXIT_FAILURE;
185
+
}
186
+
187
+
if (status.exit_status != exampleConverged) {
188
+
fprintf(stderr, "Warning: solver did not converge fully\n");
189
+
}
190
+
```
191
+
192
+
The generated C example follows exactly this pattern.
193
+
194
+
At the ABI level, callers are still responsible for passing valid pointers and
195
+
correctly sized arrays for `u`, `params`, and optional arguments such as `y0`.
196
+
Those are contract violations, not recoverable solver errors.
197
+
144
198
145
199
## Using the bindings in an app
146
200
@@ -155,26 +209,41 @@ The auto-generated example has the following form:
Copy file name to clipboardExpand all lines: open-codegen/CHANGELOG.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,7 +21,7 @@ Note: This is the Changelog file of `opengen` - the Python interface of OpEn
21
21
- Extended `RosConfiguration` so it can be used for both ROS and ROS2 package generation
22
22
- Breaking change: the direct interface (Python bindings) now has an API which mirrors that of the TCP interface: the method `solve` returns either a solution or an error object. Website documentation is updated. New unit tests are implemented. Note that `solver.run()` does not return the solution object directly, but rather works in the same way as the TCP interface: it returns a response object (instance of `SolverResponse`), on which the method `.get()` returns either a `SolverStatus` or `SolverError`.
23
23
- Added helpful `__repr__` methods to generated Python binding response/status/error objects, TCP solver response/error objects, and `GeneratedOptimizer` for easier inspection and debugging
24
-
- Updated generated TCP server and C interface templates to work with the richer Rust solver error model and expose better failure information to clients
24
+
- Updated generated TCP server and C interface templates to work with the richer Rust solver error model and expose better failure information to clients. Updated auto-generated `CMakeLists.txt` file. Tighter unit tests.
25
25
- ROS2 generated packages now publish detailed `error_code` and `error_message` fields, plus `STATUS_INVALID_REQUEST`, so invalid requests and solver failures are reported explicitly instead of being silently ignored
0 commit comments