Skip to content

2 — Structured as a time-stepping simulator, despite eCalc's computation not being stateful #1697

Description

@patnr

Part of a set of structural observations — see #1695 (index) for context.

Description

eCalc isn't a simulator in the sense a reservoir or process simulator is: there's no state where timestep t's output depends on timestep t-1's output.

  • Mentions of "previous" in the codebase refer to a compressor train at a single instant — a spatial dependency within one timestep's solve, not a temporal one.
  • The only things that genuinely span the time axis are simple reductions: cumulative volumes and yearly emission intensity. Neither requires sequential evaluation — both are embarrassingly parallel operations, not state.

Despite that, the control flow is written as a stepping simulator: construct fresh objects each timestep, compute, store keyed by timestep, reassemble afterward. This hinders parallelization and adds complexity that isn't buying anything (Pydantic construction overhead per timestep, the Periods.get_period_indices linear scan referenced in the Period/pandas issue).

Examples

Business/User Value

If the per-timestep computation is confirmed independent (which the "previous" references and the reduction-only temporal logic suggest), restructuring around vectorized/embarrassingly-parallel evaluation rather than sequential stepping would simplify the control flow, enable parallelization, and remove a source of avoidable per-timestep overhead, without changing results.

Files

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions