[BDonnot]

No description provided.

[BDonnot]

A third one has been added: pmin / pmax for generator / battery

---

Generated by Claude Code

[BDonnot]

Fixed in 96d2ebd: api.rst now says the category holds five checks and lists them all: bus reactive capability, PQ → PV release, standby SVC switch-on, HVDC droop P saturation, and the slack machines' active power (LOW_P / HIGH_P against min_p / max_p, generators and storage units together). It also documents physical_violation_tol_vm_pu.

---

Generated by Claude Code

[BDonnot]

Stale per-row targets after turning compute_physical_violations off and on. gen_p_targets_dirty_ / gen_pv_release_targets_dirty_ are cleared on every run. But when the checks are off, physical_checks::before_solve returns immediately (physical_checks_impl.cuh:61) and uploads nothing. The flag isn't part of ScenarioSweepDriverConfig, so turning it back on reuses the same driver, which still holds the old targets. sync_targets then sees has && !dirty && driver_has and skips the upload.

Repro: checks on, set_injections_from_elements(A), compute() → checks off, set_injections_from_elements(B) (same row count), compute() (hot run: the flags are cleared, nothing is uploaded) → checks on, compute(). LOW_P/HIGH_P and PQ→PV release records are evaluated against A's set-points, not B's. The same applies to the set_gen_v release targets.

Suggested fix: clear the two flags only when the checks are on (i.e. when before_solve actually synced), or pass gen_p_targets_dirty_ || !phys_.compute_physical_violations-style state through.

---

Generated by Claude Code

[BDonnot]

Fixed in 96d2ebd. Both ScenarioSweepSession::run() and InjectionSweepSession::run() (the injection sweep also reuses its driver since the merge) now clear gen_p_targets_dirty_ / gen_pv_release_targets_dirty_ only on a run with compute_physical_violations on, so targets changed while the checks were off still reach the driver. In addition, turning the checks off now disarms the live driver (BatchPfDriver::disable_physical_checks), so a reused driver no longer runs the four kernels. Pinned by test_gen_p_violations.py::test_targets_changed_while_the_checks_were_off[InjectionSweepGPU|ScenarioSweepGPU], your repro: A, off, B, on.

---

Generated by Claude Code

[BDonnot]

v_base_dlpack() can point at freed memory, now by default. run() rebuilds the base state here whenever _wanted_reference_bus() differs from ref_bus_, and reference_slack='auto' is the new default. export_v_base_dlpack (dlpack_export.cu:117) makes the session the capsule's owner, but base_state_ is a unique_ptr that this line replaces. A tensor taken before compute() (torch.from_dlpack(inner.v_base_dlpack())) then reads freed GPU memory, although the Python docstring says the view lives as long as the solver.

Before this PR, this could only happen through ScenarioSweep generator contingencies (and CLAUDE.md documents it there); now it happens by default in contingency analysis with handle_disconnected_grid=True whenever a contingency strands the grid's reference.

Options: make the capsule own a shared_ptr to the base state (and turn base_state_ into one), or at least document it in ContingencyAnalysis*.v_base_dlpack as it already is for ScenarioSweep.

---

Generated by Claude Code

[BDonnot]

Fixed in 96d2ebd with the first option. base_state_ is now a std::shared_ptr<AcPfNrState> in both ContingencyAnalysisSession and ScenarioSweepSession, and export_v_base_dlpack / export_v_base_dlpack_ss make the capsule co-own it (std::static_pointer_cast<void>(self->base_state_)). A view taken before a rebuild keeps the previous base voltages alive instead of reading freed memory. The v_base_dlpack docstrings and CLAUDE.md say so. Pinned by test_scenario_sweep_gen_contingency.py::test_v_base_view_outlives_a_base_state_rebuild.

---

Generated by Claude Code

[BDonnot]

slack_rd_.sn_mva is used without being checked. The pre-pass converts the per-unit h_Sbus_base_ to MW with slack_rd_.sn_mva. Neither set_slack_redistribution_data (L779) nor _check_redistribute_slack (L791) checks that it matches the base h_Sbus_base_ is expressed on. ScenarioSweepSession::_check_redistribute_slack does (the "given with another sn_mva" error).

Failure: in array mode, set_slack_redistribution_data(..., sn_mva=1.0) on a grid in per-unit on 100 MVA under-counts an island's lost power 100×, so units aren't clamped and the report's mismatch_mw is wrong, with no error.

Note: this session only learns its sn_mva_ from set_branch_data(), so the check may need that, or an explicit sn_mva at construction.

---

Generated by Claude Code

[BDonnot]

Fixed in 96d2ebd. ContingencyAnalysisSession::_check_redistribute_slack now refuses participants whose sn_mva differs from the branch data's ("the slack participants were given with another sn_mva than the branch data's (set_branch_data)"), like the scenario sweep. As you noted, the session only learns sn_mva_ from set_branch_data(). But build_contingencies() already refuses to run without it, so by run() the branch data's sn_mva is always known, and the check runs there. Pinned by test_redistribute_slack.py::test_ca_refuses_participants_on_another_sn_mva.

---

Generated by Claude Code

[BDonnot]

Duplicated code (maintainability). This is a verbatim copy of ScenarioSweepSession::_wanted_reference_bus(): the same candidate rule (positive weight, has a P row), the same choose_reference_bus call and the same fallback. If the rule changes in one copy only (e.g. to exclude pre-pass-only units), contingency analysis and scenario sweep will quietly pick different references. A shared helper next to choose_reference_bus that takes the LedgerData would remove the duplication.

---

Generated by Claude Code

[BDonnot]

Fixed in 96d2ebd. New choose_reference_bus_from_ledger(contingencies, Ybus_rm, ledger, forced, fallback) next to choose_reference_bus in contingency_analysis_helper.{hpp,cpp} holds the candidate rule (positive weight, has a P row), the call and the fallback. Both sessions' _wanted_reference_bus() now call it, so the two can no longer drift apart.

---

Generated by Claude Code

[BDonnot]

Calling set_gen_v() / set_contingency_gens() before set_injections*() breaks the next compute(). The skip mask is pushed right away, from set_gen_v() and set_contingency_gens(). C++ set_skipped_rows throws when its row count differs from the injections the session currently holds. Nothing re-derives the mask when set_injections* later changes the row count.

Repro: the session holds 10-row injections.

1. set_gen_v(<20 rows, some conflicting>) stores self._gen_v and pushes it (C++ set_gen_v accepts any row count), then raises row count must match set_injections() here. _push_gen_pv_release_targets() is never reached, so the release-check targets are stale too.
2. After set_injections_from_elements(<20 rows>), compute() fails with "set_skipped_rows()'s row count no longer matches". That names an internal API the facade user never called, and the only way out is to call set_gen_v again.

Suggested fix: derive and push the skip mask lazily at compute() time, or also call _update_skipped_rows() from set_injections* / set_topology.

---

Generated by Claude Code

[BDonnot]

Fixed in 96d2ebd for set_gen_v(). The facade now records the injections' row count (_n_injection_rows, set by set_injections / set_injections_from_elements), and set_gen_v pushes gen_v and the PQ → PV release targets before deriving the skip mask. If the row counts differ, it clears the skipped rows and marks them stale; compute() re-derives them (_update_skipped_rows) before run(). New injections also mark the mask stale. So set_gen_v(<20 rows>) followed by set_injections_from_elements(<20 rows>) then compute() works, and the release targets are no longer left stale. Pinned by test_gen_v.py::TestConflictingSetpoints::test_gen_v_may_change_row_count_before_the_injections.

Not changed: set_contingency_gens() with a row count different from the current injections is still refused straight away by the C++ session, with an explicit row-count error naming set_contingency_gens (not an internal API). It fails at the call, not at a later compute().

---

Generated by Claude Code

[BDonnot]

Duplicated code (maintainability). The violation_rel_tol property (docstring, getter, setter and the [0, 1) validation) is copy-pasted in both engines and both facades (8 def violation_rel_tol in src/gpusim2grid). The PR already moved the physical-check and slack-redistribution properties into shared mixins; a small limit-violations mixin would do the same here, and could also hold get_violations / violation_capacity.

---

Generated by Claude Code

[BDonnot]

Fixed in 96d2ebd. _limit_violations.py now has LimitViolationsEngineMixin (violation_tol, violation_rel_tol with its [0, 1) validation, violation_capacity) and LimitViolationsFacadeMixin (violation_rel_tol forwarded to the engine). The two engines and ContingencyAnalysisGPU / ScenarioSweepGPU inherit them instead of carrying copies. def violation_rel_tol now appears only in the two mixins.

---

Generated by Claude Code

[BDonnot]

Hot runs redo work that could be skipped (perf). On the persistent ScenarioSweep driver, every compute() with physical checks on re-uploads all four plans, reallocates every output buffer with assign(), re-runs the four single-thread n-case kernels, and waits on several cs.synchronize() calls, even when only the injections changed.

The plans and the n-case report only change when the plan or the base state changes. A generation counter could skip the upload and the n-case work, keeping just a fill() to reset the -1 sentinels. This matters for the BatchPowerFlow training loop.

---

Generated by Claude Code

[BDonnot]

Fixed in 96d2ebd. physical_checks::before_solve now builds a PhysicalSetupKey: a plan generation (PhysicalChecksConfig::plan_generation, bumped by every set_*_plan), the tolerances, residual tol, sn_mva, capacity, the generator-mask pointer, n_gen and the base case's convergence. When the key matches the driver's, the plan uploads, the assign() reallocations and the four n-case kernels (with their syncs) are skipped; only BatchPfDriver::reset_physical_outputs() runs (a thrust::fill re-seeding the -1 sentinels and truncated flags), plus the per-row target sync when they changed. The base-state generation is in the driver snapshot, so a base-state change is a cold driver and redoes the setup. With only the injections changing, a BatchPowerFlow training step pays a fill.

---

Generated by Claude Code

[BDonnot]

The docs now contradict each other. The exact receiving-side slope here is intentional and well justified: the adjoint needs it, and test_hvdc_droop_resistive_loss_slope_is_exact pins it. But the intro to this section (L140) still says results "match lightsim2grid bit-for-bit (to ~1e-15) on both the single solve and the batched … paths". As this note says, lightsim2grid's Jacobian lacks the (1−2·r·line_in) factor. So for a droop HVDC line with r != 0, the NR path differs: the converged state still matches to NR tolerance, but a fixed nb_iter / partially converged batch (e.g. direct_iter0_only) no longer matches to ~1e-15.

Suggest qualifying the L140 claim (e.g. "… except the Jacobian slope of a resistive droop HVDC line, see below, which changes the iterates but not the converged state").

---

Generated by Claude Code

[BDonnot]

Fixed in 96d2ebd. The L140 claim now reads "… match lightsim2grid bit-for-bit (to ~1e-15) … except on a grid with a droop HVDC line of non-zero resistance, whose receiving-side Jacobian slope gpusim2grid takes exactly (see Feature kernels below): that changes the NR iterates, not the converged state, so it still matches to the NR tolerance but a fixed nb_iter / partially converged batch (e.g. direct_iter0_only) no longer matches to ~1e-15."

---

Generated by Claude Code