[bug] initial_charge_state silently ignored in cluster_mode='intercluster_cyclic'/'cyclic'

[FBumann]

Pre-existing bug (not a linopy-v1 semantics issue) — surfaced while making the clustered-storage tests robust for #729.

Symptom

A Storage created with a numeric initial_charge_state but the default cluster_mode='intercluster_cyclic' (or 'cyclic') does not pin the initial SOC. The value is silently dropped, leaving the absolute SOC level unconstrained (degenerate).

fx.Storage('S', capacity_in_flow_hours=50, initial_charge_state=0.5, ...)  # default cluster_mode='intercluster_cyclic'
# after clustering+solve: charge_state can be all-zero — initial_charge_state=0.5 had no effect

Location

flixopt/components.py:1415 (InterclusterStorageModel._add_intercluster_linking):

if self.element.cluster_mode == 'intercluster_cyclic':
    self.add_constraints(soc_boundary[0] == soc_boundary[n], short_name='cyclic')  # initial_charge_state NOT applied
else:
    # only here is initial_charge_state pinned

The same applies to the base StorageModel 'cyclic' mode (_add_initial_final_constraints skips initial/final for independent/cyclic).

Root cause

In cyclic modes the level is tied start==end but never anchored to initial_charge_state, so the LP is degenerate in the absolute SOC level. A user who sets initial_charge_state gets no error/warning that it was ignored.

Impact

• Silent no-op of a user-set parameter (surprising; the value looks respected but isn't).
• Degenerate SOC level → solver-dependent charge_state trajectories. This is what made test_storage_cyclic_charge_discharge_pattern and test_expanded_storage assert non-unique values (fixed to assert determinate dynamics in fix: compatibility with linopy v1 arithmetic semantics #729; see [test robustness] Cyclic-cluster storage tests assert a non-unique (degenerate) SOC level #733).

Proposed fix (needs a design decision)

Either (a) warn/error when initial_charge_state is set together with a cyclic cluster_mode (it is contradictory), or (b) honor it by anchoring soc_boundary[0] == initial_charge_state in addition to (or instead of) the cyclic tie. Option (a) is the smaller, safer change.

Severity

Correctness/UX (silent parameter drop) + solution degeneracy. Objective and flow rates remain correct.

[FBumann]

Closing — on reflection this is not a bug.

cluster_mode='intercluster_cyclic' is periodic by definition (soc_boundary[0] == soc_boundary[last]), which is itself the 'initial == final' condition. For a cyclic store the absolute SOC level is fundamentally a free variable — only the per-step changes and the periodic boundary are determined — so an unpinned level is the correct behaviour, not a defect. Applying a numeric initial_charge_state on top of the cyclic tie would be redundant or over-constrain the cycle. Non-cyclic modes and non-clustered runs already honor initial_charge_state (the else branch).

The only conceivable follow-up is an optional warning when a non-default initial_charge_state is combined with a cyclic cluster_mode, but that's a minor UX nicety, not a correctness issue.

The genuine, actionable item — that the tests asserted this non-unique level — is already handled by asserting determinate dynamics instead (see #733 and PR #729). The drop=True v1 fix in that code block stands on its own (#731).