Public initType is not forwarded to the internal PI in five control wrappers #1

Scope

Following the LinkedIn discussion with Md Nazmul Hassan Chowdhury, this records a source-level initialization-interface mismatch at commit a7bba7863238510ea96658dc426a2cff35dc7a1d (current main checked on 24 October 2026). It does not establish an error in the MMC formulation or an effect on the published stability benchmarks.

Observed source relation

These wrappers expose an initType parameter but instantiate Modelica.Blocks.Continuous.PI with initType=Modelica.Blocks.Types.Init.InitialOutput rather than forwarding the wrapper parameter:

The same PI instances do forward x_start and y_start. A caller changing the wrapper's initType therefore does not change the initialization modifier supplied to its PI. For example, TestACdaxisModulation.mo:20 and TestACqaxisModulation.mo:12 explicitly request NoInit, but the nested PI still receives InitialOutput.

How to inspect / reproduce

1. Check out the exact commit above.
2. Inspect the five public initType declarations and their nested PI modifiers.
3. Instantiate one wrapper while changing only its public initType among NoInit, InitialState, InitialOutput and SteadyState.
4. Inspect the flattened model or initialization equations in a supported Modelica tool: the nested PI modifier remains InitialOutput in the current source.
5. For a numerical regression, choose a well-posed harness with distinct x_start and y_start values and nonzero PI input so the alternatives are distinguishable. Report flattened equations and any consistency/initialization diagnostics, rather than using only station examples already requesting InitialOutput.

Steps 1-2 and the test-model declarations were checked directly. Steps 3-5 describe the proposed tool-level regression; I have not executed Dymola or OpenModelica here.

Candidate repair and compatibility decision

Forward the public parameter at the five PI instances:

initType=initType

There is an explicit default-behavior decision: four wrappers currently advertise NoInit while actually forcing InitialOutput. Merely forwarding the parameter would change the effective default. If preserving historical default behavior is intended, changing those four public defaults to InitialOutput alongside forwarding would preserve that behavior for callers that omit the option while honoring explicit selections. VariableRefEnergyControl already defaults to InitialOutput.

If fixed InitialOutput is intentional instead, the public option should be removed, constrained or documented accordingly, rather than appearing selectable without affecting the nested PI.

Please confirm the intended initialization contract and compatibility choice before a patch is finalized.

Validation limits and attribution

Source inspection only, with exact version and paths retained. No Modelica compilation, simulation, full-suite replay or published-benchmark impact is claimed.

Massimiliano Brighindi (PHI-OMEGA / M), with AI-assisted source review. M guided tracing the declared initialization choice through the wrapper-to-PI relation; the diagnosis remains scoped to that concrete information loss.