ty-design-opt-mpe-modeling

DesignOptMpe — parameter design, estimation, and optimization

Scope

• In scope: DesignOpt / MPE / parameter estimation / optimization tasks that require the DesignOptMpe Python module inside Sysplorer, experiment loops, multi-boundary and steady-state estimation, residual design, custom external optimizers, batch-simulation-backed objective evaluation, and integration with Sysplorer models.
• Out of scope: Unrelated ModelingPy surface APIs (use get_api_document), pure Modelica / Sysblock modeling execution (use domain skills + modeling_path_router), and response optimization tasks that belong to ty-design-opt-mro-modeling.

Hard rules

1. Session first: session_manager(action="health" | "ensure") before any run_sysplorer_api that touches Sysplorer.
2. Never call ClearAll or ChangeDirectory from scripts or tools; unload with model_manager(action="unload") when needed.
3. DesignOptMpe is not documented via the main Help() namespace—use import + ListFunctions() / help() in run_sysplorer_api, plus corpus text in references/ and resources_retrieval on corpus design_opt_mpe_api.
4. Import the toolboxes explicitly:

import mworks.sysplorer.DesignOptMpe as mpe
import mworks.sysplorer.DesignOptExp as exp

1. Missing data policy: do not invent parameter names, bounds, variable mappings, time windows, boundary values, or measurement columns. If they are not discoverable, ask for them or state the default you are about to use.
2. Custom optimizer path: when the user asks for a custom algorithm, a high-performance external algorithm, a hybrid strategy, or the built-in MPE algorithms are too limiting, switch to the custom batch-optimization path in this skill.
3. Batch simulation path: for custom optimizers that evaluate many candidates, prefer DesignOptExp.InitialBatchSimulate(...) and DesignOptExp.BatchSimulate(...) instead of repeated single-run estimation calls.
4. Failure penalty: if one candidate causes any required boundary simulation to fail, assign the candidate objective directly to 1e300.
5. Model dependency policy: when the user provides a model file, ask whether it depends on libraries beyond Modelica. If the user provides library names, include them in the run configuration and load them before model open/check/optimization. If the user does not provide them or is unsure, infer dependencies from the model text and installed library folders, then use the inferred libraries internally.
6. Preflight dependency order: dependency inference and loading must happen before CheckModel, TranslateModel, InitialBatchSimulate, or short simulation checks. CheckModel and TranslateModel can block on missing libraries, so do not rely on them as the first missing-library detector.
7. Algorithm adapter policy: if the user names a custom algorithm that is not built in, first research whether it can optimize an expensive black-box scalar objective over numeric parameter vectors. If feasible, connect it through an optimizer adapter instead of changing the residual or batch-simulation core. If infeasible or too evaluation-hungry for Sysplorer simulation, explain the blocker and suggest a feasible alternative.
8. User-facing algorithm wording: when listing supported algorithms to users, list native algorithms, built-in custom algorithms, and "external optimizer adapters". Do not expose internal adapter runner names, config field names, callback names, or implementation classes unless the user asks for implementation details or a config/script artifact.