Skip to content

Stage 1.17: cellpycore.curves — spec'd capacity/OCV curve extraction #118

Description

@jepegit

Part of Stage 1 — behavior-preserving construction (see the Stage-1 tracking issue). Stage 0: jepegit/cellpy#439. Plan documents live in the shared workspace: cellpy-workspace/architecture-plan/ (the architecture-plan repo; formerly architecture-plan/) (alongside the cellpy and cellpy-core repos). Everything in Stage 1 lands on master with the full suite green; nothing flips user-visible behavior.

Goal

Gated on the #438 decision (curve-schema home): a curves.py module + CurveCols
schema + docs/data_format_specifications/curve_table.md, porting get_cap /
get_ccap / get_dcap / get_ocv selection logic (interpolation, taper trimming,
forth-and-forth, steptable override) polars-native and schema-injected — the
extractors.py introduction pattern (issue #23) applied to curves.

Why

The most-used data API in the cellpy ecosystem currently returns frames with unspec'd,
hard-coded column names (headers report §5: "an implicit contract between cellreader
and four utils modules"). Moving it into core with a spec closes gap G4 and unblocks
utils waves 2–3. The Stage-0 snapshots (jepegit/cellpy#433) are the parity oracle.

Links (workspace)

Acceptance

  • Spec doc + CurveCols + spec-conformance test (the test_config_columns.py pattern).
  • Parity vs the #433 snapshots across the option matrix; intentional differences
    documented, not silent.
  • Release tagged for cellpy re-pin.

Metadata

Metadata

Assignees

No one assigned

    Labels

    cellpy2-stage1cellpy 2 Stage 1: behavior-preserving construction

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions