Simplify Data Handling by not reusing the same FLowSystem object in multiple Calculations (use a copy)

[FBumann]

Simplify Data Handling by not reusing the same FLowSystem object in multiple Calculations (use a copy)

Problem Description

When a single FlowSystem instance is used across multiple Calculation objects, it can lead to data contamination, model overwriting, and state confusion that can cause unexpected results and difficult-to-debug issues.

Currently, this is cared for inside flixopt, but is quite painful to maintain, test and keep robust.

Issues Identified

1. Data Contamination

• Modifications in one calculation affect all others sharing the same FlowSystem
• Parameter changes are not isolated between calculations

2. Shared Elements

• Elements (FLow, Bus, Effect, ...) are shared across Calculations, as the full FlowSystem is.

2. Model Overwriting

• do_modeling() calls overwrite the Models of the Elements
• Previous calculation models are lost
• Only the last calculation's model is retained

3. State Confusion

• transform_data() can only be called once successfully
• Subsequent calls on shared FlowSystem produce warnings
• Transformation state is shared across all calculations

Expected Behavior

Each Calculation should have an independent FlowSystem (including independent Elements and Interfaces) to ensure:

• ✅ Isolated modifications between calculations
• ✅ Preserved models for each calculation
• ✅ Independent transformation state
• ✅ Predictable and debuggable behavior

Proposed Solution

Automatic Copying of FlowSystem

Automatically create a copy when FlowSystem is reused:

class Calculation:
    def __init__(self, label, flow_system):
        if flow_system._used_by_a_calculation:
            flow_system = flow_system.copy()
        # ... rest of init

Currently used Workarounds to prevent issues

• TimeSeries class: Managing original timeseries data, resetting, selection of a subset (SegmentedCalculation) etc.
• exporting the FLowSystem to xarray.Datasetafter solve to preserve its state (for Results)

Expected Upsides

• Much easier handling of Data (TimeSeries, TimeSeriesCollection might not be needed anymore)
• Generally improved import/export of Elements and FlowSystem to and from file/dict/json...
• Simplified aggregation of Data over full FLowSystem or only some Elements (through xr.Dataset)
• Streamlined I/O for FlowSystem

The current behavior violates the principle of least surprise and makes the library error-prone for common use cases.

[FBumann]

Closed somewhere in #348