ty-sysblock-batch-param-modeling

Sysblock Batch Parameter Objects

Scope

• In scope: GetModelParamValues, SetModelParamValues, full component parameter-object retrieval, partial field reads, dict / dataclass payload handling, standard single-parameter coordination around GetModelParamValue / SetModelParamValue, and generation of per-module parameter-reference notes from screenshots plus JSON samples.
• Out of scope: Sysblock topology construction, DesignOpt toolboxes, Modelica physical modeling, and direct external use of Utils/param_normalize.py.
• Routing priority: When a task is about reading or updating many fields of one component at once, or about documenting a module's parameter-object mapping, prefer this skill over repeated single-field SetModelParamValue(...) calls or ad hoc note writing.

Hard Rules

1. Call session_manager(action="health" | "ensure") before any call_code(mode="run_sysplorer_api") script that touches Sysplorer.
2. Never call ClearAll or ChangeDirectory from generated scripts.
3. Use the public Python APIs GetModelParamValues and SetModelParamValues as the documented batch parameter entry points.
4. Treat Utils/param_normalize.py as an internal implementation detail, not a user-facing API.
5. If only one or two scalar fields need to change, SetModelParamValue is still valid. If a whole configuration object is needed, use GetModelParamValues first and then write back with SetModelParamValues.
6. When generating module parameter notes, distinguish three field classes explicitly:
   • main writable fields
   • reference fields
   • internally handled fields that should not appear in the note
7. Do not generate a new module note from guesses alone. If the user has not provided the module's parameter-dialog screenshot and JSON sample, ask for them first, or ask for other reliable reference materials.
8. In the final module note, output conclusions only. Do not mention source-material traces such as "according to screenshot", "according to JSON", or similar wording.