LightSim2Grid 1.0.0__tar.gz → 1.0.0rc2__tar.gz

{lightsim2grid-1.0.0 → lightsim2grid-1.0.0rc2}/CHANGELOG.rst

@@ -21,6 +21,7 @@ Change Log
   (keep check for boundaries and all for python API instead) [see `TODO DEBUG MODE` in c++ code]
 - improve speed
 - code parrallelism directly in the `Computer` and `SecurityAnalysisCPP` classes
+- a mode to do both `Computer` and `SecurityAnalysisCPP`
 - use the "multi slack hack" (see issue #50) for SecurityAnalysis or Computer for example
 - code `helm` powerflow method
 - interface with gridpack (to enforce q limits for example)
@@ -117,365 +118,11 @@ TODO: add a CI job that builds one of the example C++ algorithm plugins
       ``test_plugin_against_installed`` job each cover half of this (the former builds
       lightsim2grid itself with the flag but does not touch a plugin; the latter builds a
       plugin but never with the flag) -- neither exercises the combination.
-TODO: Levenberg-Marquardt damping (a.k.a. Tikhonov-regularized Newton) : adding small decreasing
+TODO: Levenberg-Marquardt damping (a.k.a. Tikhonov-regularized Newton) : adding small decreasing 
       lambba coefficients to the diagonal of J to improve its conditionning.
-TODO: a "combine mode" axis for ``ScenarioSweepCPP`` choosing between the current
-      row-aligned / zipped semantics (row `i`'s injection paired with row `i`'s
-      contingency) and a cartesian one ("every registered contingency x every
-      injection profile").
 
-[1.0.0] 2026-08-28
+[1.0.0] 2026-xx-yy
 --------------------
-- [BREAKING] **solver cache reuse is now automatic and on by default**, per solver family.
-  A powerflow reuses what the previous one of the same family built -- the compact bus labelling,
-  ``Ybus`` / ``Sbus``, the PV / PQ split, the slack weights -- and only re-stamps what the grid
-  reports as modified since. Every powerflow marks its own family "in sync" on the way out, so
-  ``LSGrid.unset_changes()`` is no longer needed: it is a no-op whenever reuse is enabled, and is
-  kept purely for backward compatibility. Worth ~24% of the time of a powerflow on a 14-bus grid,
-  and nothing has to be called to get it.
-  This is breaking for code that modifies the grid through a path that bypasses ``LSGrid``'s own
-  ``change_*`` / ``deactivate_*`` / ``reactivate_*`` methods (direct manipulation of the C++
-  containers, for instance). Such code used to get away with it as long as it never called
-  ``unset_changes()``; now it must say so with ``prevent_cache_reuse()`` (or the narrower
-  ``tell_recompute_ybus`` / ``tell_recompute_sbus``), or turn reuse off altogether with
-  ``allow_cache_reuse(False)``. Everything that goes through the public API is unaffected: a
-  completeness sweep over every mutating ``LSGrid`` method (``src/tests/test_cache_reuse.cpp``)
-  checks that the cached and the fully-rebuilt answer agree.
-- [ADDED] ``LSGrid.allow_cache_reuse(bool)`` / ``allow_ac_cache_reuse`` / ``allow_dc_cache_reuse``
-  and their ``get_*`` counterparts: turn cache reuse off (durably) for one family or both. The
-  answer is identical either way, so this is a debugging switch ("is this wrong number a caching
-  artefact?") and an escape hatch for code that mutates the containers directly.
-- [ADDED] ``LSGrid.prevent_cache_reuse()`` / ``prevent_ac_cache_reuse()`` / ``prevent_dc_cache_reuse()``:
-  a one-shot invalidation of what a family cached (as opposed to the ``allow_*`` mode above).
-  ``prevent_cache_reuse()`` is the new name of ``tell_solver_need_reset()``, which still exists and
-  behaves identically. Both are now documented rather than tagged "internal, do not use".
-- [BREAKING] the AC and the DC solver families no longer share ANY solver-side data.
-  ``slack_weights``, the PV split and the PQ split were single members overwritten by whichever
-  family solved last -- unlike ``Ybus`` / ``Sbus`` / the id maps, which were already per family.
-  That is what made a "nothing changed" claim unsound across families, and it prevented per-family
-  cache reuse. Each family now owns its own, exposed as ``get_ac_pv_solver`` / ``get_dc_pv_solver``
-  and the ``pq`` / ``slack_weights`` equivalents. The family-less ``get_pv_solver`` /
-  ``get_pq_solver`` / ``get_slack_weights_solver`` are unchanged in spirit and answer for the AC
-  family once an AC powerflow has run, falling back to DC otherwise -- which also fixes them:
-  they used to relabel whatever the last solve left behind with the AC bus mapping.
-- [BREAKING] ``LightSimBackend`` no longer carries the ``_last_dc`` workaround (a
-  ``tell_solver_need_reset()`` before the first AC powerflow following a DC one, comment:
-  "otherwise might segfault"). It existed only because the two solver families shared their
-  cached solver-side data; they no longer do, so a DC powerflow before an AC one on the same
-  backend is simply safe, and the AC family keeps its cache across it. The private
-  ``_last_dc`` attribute is removed with it. Covered by ``TestDcThenAcSameBackend`` in
-  ``lightsim2grid/tests/test_DoNothingACDC.py``.
-- [FIXED] ``LSGrid.set_sn_mva()`` did not invalidate anything. ``sn_mva`` is the base power of the
-  whole per-unit system: it is passed to ``fillYbus`` / ``fillBdc`` and divides ``fillSbus_me``, so
-  a powerflow run after it, on a grid whose cache was considered in sync, solved the previous base
-  power's system. Found by the completeness sweep described above.
-- [FIXED] ``dc_pf()`` returned the voltage MAGNITUDES of a previous call. DC solves for angles
-  only, so the magnitudes it reports are the ones it was handed -- but ``BaseDCAlgo`` skipped
-  ``Vm_ = V.array().abs()`` unless ``_solver_control.has_v_changed()``, which asks whether the
-  GRID's voltage setpoints changed and says nothing about the vector just passed in. Two
-  ``dc_pf()`` calls with different ``Vinit`` therefore returned the first call's magnitudes for
-  every bus not pinned by a controller, whenever the solver control said "nothing changed" -- ie
-  after every ``unset_changes()``, which ``LightSimBackend`` calls after each step. The guard is
-  removed: it saved one ``abs()`` over ``nb_bus`` doubles next to a sparse triangular solve of the
-  same dimension.
-- [FIXED] a diverging powerflow left the algorithm's internal state (half-converged iterate,
-  factorization of a system it gave up on) in place for the next call, and threw away nothing.
-  The algorithm is now reset on divergence, and the next powerflow of that family rebuilds its
-  internals -- while the DATA built for the diverged solve, which is a correct picture of the grid,
-  is kept and stays reusable.
-- [ADDED] the rule that **nothing the solvers cache ever crosses a serialization boundary** is now
-  pinned by tests (``[serialization]`` in ``src/tests/test_cache_reuse.cpp``,
-  ``TestDeserializedGridStartsCold`` in ``lightsim2grid/tests/test_cache_reuse.py``). ``StateRes``
-  carries the elements; the bus labelling, ``Ybus`` / ``Sbus``, the pv-pq split, the slack weights
-  and the change-tracking flags are all derived from them and are rebuilt from them, so a grid
-  restored from a pickle or a binary file always starts with a cold cache. That was already true
-  (``set_state`` resets the solver state), but nothing checked it and the reset carries a "see if
-  it's worth the trouble NOT to do it" TODO -- which is exactly the change these tests now block.
-  The reasoning is a security one, not a performance one: a cache read from a file is a second copy
-  of state that ``check_grid()`` cannot verify against the elements it claims to describe (it can
-  validate an index; it cannot validate "this really is the admittance matrix of this grid"), and a
-  well-formed-looking matrix would be solved without complaint.
-- [FIXED] ``LSGrid.set_state()`` read the serialized bus-connectivity snapshot (``BUS_STATUS_ID``)
-  back into the two solver-cache snapshots. It was immediately overwritten by the reset that follows,
-  so nothing was ever wrong -- but it made a file the nominal source of cache metadata. The field is
-  still written by ``get_state()`` (the layout is unchanged); it is simply no longer read back.
-- [FIXED] ``LSGrid.unset_changes()`` could make the next powerflow **segfault**. It told the grid
-  "the cached solver-side data matches me", for the AC *and* the DC family at once, and nothing
-  checked that claim. Three sequences -- all of them documented usage -- therefore entered the
-  "nothing to rebuild" path with a default-constructed (empty) id map / Ybus / Sbus and indexed
-  them with bus ids in the hundreds::
-
-      unset_changes(); ac_pf();           # nothing was ever built
-      dc_pf(); unset_changes(); ac_pf();  # what was built belongs to the other family
-      ac_pf(); unset_changes(); dc_pf();  # idem
-
-  Release wheels are built ``-O3 -DNDEBUG``, so this was an out-of-bounds read, not an error.
-  ``LightSimBackend.runpf`` already carried a python-side workaround for the second one (the
-  ``self._last_dc`` ``tell_solver_need_reset()``, comment: "otherwise might segfault"), and
-  ``check_solution`` guarded against the first one locally with ``id_me_to_ac_solver_.size() > 0``.
-  The check now lives where the reuse decision is made instead: ``_pre_process_solver_impl``
-  verifies, in a handful of integer comparisons, that the data the flags describe is actually
-  there, and falls back to a full rebuild otherwise. A wrong "nothing changed" can now cost time,
-  never memory safety.
-- [ADDED] ``InjectionSweepCPP`` (python wrapper ``lightsim2grid.injectionSweep.InjectionSweep``), a
-  third batch algorithm. It computes exactly what ``TimeSeriesCPP`` computes -- one powerflow per row
-  of the injection matrices, on a fixed grid topology -- with exactly the same interface, and differs
-  only in how each computation is initialized: ``TimeSeriesCPP`` warm starts a step with the solution
-  of the step before it (they are consecutive instants of a *time* series), while ``InjectionSweepCPP``
-  starts every step from the same voltage -- the one given to ``compute_Vs``, or the "n" powerflow
-  result when ``init_from_n_powerflow`` is set -- exactly like ``ContingencyAnalysisCPP`` does for
-  each of its contingencies.
-  Use it when the "steps" are independent scenarios rather than consecutive instants: their results
-  then do not depend on the steps computed before them, nor on the order they are given in, and the
-  batch can be spread over several threads (``nb_thread``).
-  Both classes are two instantiations of one C++ template (``ls2g::BaseInjectionSweep<BatchInitKind>``
-  in ``batch_algorithm/BaseInjectionSweep.hpp``), so they cannot drift apart: the init policy is a
-  single compile-time parameter, and everything else -- inputs, results, bindings -- is shared.
-- [BREAKING] (c++ API only) ``batch_algorithm/TimeSeries.hpp`` / ``.cpp`` are renamed to
-  ``batch_algorithm/BaseInjectionSweep.hpp`` / ``.cpp``: the file now holds both ``ls2g::TimeSeries``
-  and ``ls2g::InjectionSweep`` (two aliases of the same template), so naming it after either one of
-  them would be misleading. C++ code including the old path must update the include; nothing changes
-  on the python side. Both class names are unchanged.
-- [ADDED] ``nb_thread`` moved up from ``ContingencyAnalysisCPP`` to the common batch base class, so
-  every batch algorithm whose computations are independent of one another gets it. It is now
-  available on ``InjectionSweepCPP`` as well, where each thread solves a contiguous range of steps
-  with its own solver (the admittance matrix is shared read-only, since the topology is fixed --
-  unlike ``ContingencyAnalysisCPP``, which needs a copy per thread to emulate the disconnections).
-  Results are bit-for-bit independent of ``nb_thread``. ``thread_init_time()`` moved up with it.
-- [BREAKING] ``TimeSeriesCPP.nb_thread = n`` now raises a ``RuntimeError`` for ``n > 1`` (the
-  attribute did not exist before, so no working code can break). Its steps are chained, so splitting
-  them into per-thread ranges would break the chain and make the voltages depend on the number of
-  threads; the error points at ``InjectionSweepCPP``, which computes the same injections in parallel.
-  ``nb_thread = 1`` (and any value below, which is clamped to 1) stays legal.
-- [FIXED] ``TimeSeriesCPP`` solved each step against an **incomplete injection vector**. It does not
-  use the ``Sbus`` the gridmodel builds: it rebuilds its own, per step, out of the four matrices the
-  caller passes to ``compute_Vs`` -- generator and static-generator ACTIVE power, and load active +
-  reactive power -- plus the hvdc term taken from the grid. But ``LSGrid::fillSbus_me`` stamps rather
-  more than that, and everything else was silently dropped:
-  storage units (active AND reactive: absent altogether), REACTIVE_POWER-mode SVCs (absent
-  altogether), the reactive setpoint of a generator whose ``voltage_regulator_on`` is false, a static
-  generator's reactive setpoint, and -- in DC -- the phase-shifter term
-  ``TrafoContainer::hack_Sbus_for_dc_phase_shifter``. The powerflow converged happily on an injection
-  the caller never asked for; on a 4-bus feeder the individual omissions were worth 0.032, 0.052,
-  0.066 and 0.081 pu of voltage error respectively. DC was affected too, since
-  ``compute_one_powerflow`` falls back to the gridmodel's ``Pbus_`` only when NO complex ``Sbus`` is
-  supplied, which is not the ``TimeSeries`` case.
-  The remainder is now **derived rather than enumerated**: the complete per-unit injection the
-  gridmodel just built (``Sbus_`` in ac, ``Pbus_`` in dc) minus the same reconstruction ``compute_Vs``
-  performs, evaluated at the gridmodel's own target values. What is left over is by construction
-  everything the per-step matrices do not carry, so an element type added to ``fillSbus_me`` later is
-  picked up for free -- an enumeration falling behind is precisely what caused this bug.
-  ``ContingencyAnalysisCPP`` (and ``SecurityAnalysis``, which wraps it) was never affected: it passes
-  the gridmodel's own complete ``Sbus_`` straight to the solver.
-- [ADDED] a stale-solver-state case to ``src/tests/test_batch_voltage_control.cpp``: run ``ac_pf``,
-  then change the grid so a bus leaves the solver (which makes the AC maps stale AND too long, worse
-  than merely empty), then ``dc_pf`` (which rebuilds only the DC maps), then a batch -- which inherits
-  the grid's AC algorithm, since ``LSGrid::change_algorithm`` routes a DC type to the separate
-  ``_dc_algo`` slot and so asking the GRID for DC never switches a batch over. The batch must still
-  reproduce a clean single-shot ``ac_pf``, which it does because it works on a copy of the grid whose
-  copy constructor ``reset()`` the solver state and whose ``prepare_solver_input_base`` rebuilds it
-  under ``tell_all_changed()``. Being a C++ test it runs under the valgrind pass of the C++ suite and
-  the ASan/UBSan + Eigen-assertion builds, where a too-long index that stays inside the heap would
-  still be caught.
-- [BREAKING] (c++ API only) ``batch_algorithm/BaseInjectionSweep.hpp`` / ``.cpp`` and
-  ``batch_algorithm/ContingencyAnalysis.hpp`` / ``.cpp`` are removed, replaced by
-  ``batch_algorithm/BaseBatchSweep.hpp`` / ``.cpp`` (plus two new small headers,
-  ``batch_algorithm/YbusPolicy.hpp`` / ``.cpp`` and ``batch_algorithm/SbusPolicy.hpp`` /
-  ``.cpp``): a single class template ``ls2g::BaseBatchSweep<YbusPolicy, SbusPolicy,
-  BatchInitKind>``, policy-parameterized on what varies per step in the admittance
-  matrix (nothing, or a contingency) and in the injection (nothing, or per-step
-  values). ``TimeSeries``, ``InjectionSweep`` and ``ContingencyAnalysis`` are now three
-  aliases of it -- same behavior, same C++ and python public API as before (the
-  policy-only, contingency-only and injection-only methods are gated with
-  ``std::enable_if`` so each alias only exposes what it always exposed); nothing
-  changes on the python side for these three. C++ code including the old paths must
-  update its ``#include``.
-- [ADDED] ``ScenarioSweepCPP`` (python wrapper ``lightsim2grid.scenarioSweep.ScenarioSweep``),
-  the 4th instantiation of ``ls2g::BaseBatchSweep``: varies both the injection AND a
-  contingency (a line / trafo disconnection) per row, independently and row-aligned --
-  row ``i`` of the injection matrices is solved together with row ``i`` of the
-  contingency mask. Built up with a new setter-based API (see below) rather than a
-  single bundled call: ``modify_gen_p`` / ``modify_sgen_p`` / ``modify_load_p`` /
-  ``modify_load_q`` for the injection, ``set_contingency_lines`` /
-  ``set_contingency_trafos`` (dense boolean masks, shape ``(n_simul, n_line)`` /
-  ``(n_simul, n_trafo)``, ``True`` = "deactivate this branch for this row") for the
-  contingency, then ``compute(Vinit, max_iter, tol)``. Deliberately a *different* API
-  from ``ContingencyAnalysisCPP``'s ``add_n1`` / ``add_nk`` (a set of distinct
-  contingencies applied to one shared base injection) -- the two usages do not unify
-  cleanly, so ``ScenarioSweepCPP`` does not have ``add_n1`` / ``add_nk`` and
-  ``ContingencyAnalysisCPP`` does not have ``set_contingency_lines`` /
-  ``set_contingency_trafos``. See ``docs/scenario_sweep.rst``.
-- [ADDED] ``ScenarioSweepCPP`` now also has ``ContingencyAnalysisCPP``'s
-  ``handle_disconnected_grid`` mode and inline limit-violation checking
-  (``compute_limit_violations`` / ``violation_threshold`` / ``get_violations`` /
-  ``get_violations_n``), same names and semantics on both classes, and both return the
-  same ``LimitViolation`` objects. Deliberately **no** ``converged`` / ``converged_n`` on
-  ``ScenarioSweepCPP``: a non-converged row's ``get_violations()`` entry already carries a
-  ``GRID`` / ``NOT_SIMULATED``-or-``DIVERGENCE`` sentinel violation, so a separate
-  convergence flag would be redundant (``ContingencyAnalysisCPP``'s own ``converged`` /
-  ``converged_n`` are unchanged). A diverging pre-batch "n" powerflow (the shared base
-  case every row in the batch is solved relative to) now also stamps this same
-  ``GRID`` / ``DIVERGENCE`` sentinel into ``get_violations_n()`` and every row of
-  ``get_violations()``, instead of leaving them as empty lists indistinguishable from
-  "converged, nothing found". As on ``ContingencyAnalysisCPP``, toggling
-  ``compute_limit_violations`` clears the whole object (registered contingencies,
-  injections, ``handle_disconnected_grid``, ...) -- set it *before* configuring
-  anything else. ``lightsim2grid.scenarioSweep.ScenarioSweep`` gains a ``run()`` method
-  reusing the existing ``PreContingencyResult`` / ``ContingencyResult`` /
-  ``SecurityAnalysisResult`` dataclasses from ``lightsim2grid.contingencyAnalysis``
-  (``contingency_name`` is always ``None`` there, unlike ``ContingencyAnalysis.run()``).
-- [ADDED] a new setter-based API -- ``modify_gen_p`` / ``modify_sgen_p`` /
-  ``modify_load_p`` / ``modify_load_q`` + ``compute(Vinit, max_iter, tol)`` -- is now
-  also available on ``TimeSeriesCPP`` / ``InjectionSweepCPP``, alongside their existing
-  bundled ``compute_Vs`` call (kept, not removed, deprecated via docstring only). Unlike
-  ``compute_Vs``, which requires all four matrices every call, any axis you never set
-  defaults to the grid's own current target value, broadcast across every row --
-  applies to ``ScenarioSweepCPP`` too. Every setter shares one row-count lock: the
-  first one called fixes the number of simulations, every later one (across all
-  setters, including ``set_contingency_lines`` / ``set_contingency_trafos`` on
-  ``ScenarioSweepCPP``) is checked against it immediately, instead of only at
-  ``compute()`` time as ``compute_Vs``'s equivalent check did.
-- [FIXED] ``ScenarioSweepCPP`` (non-``handle_disconnected_grid`` path) used to abandon every
-  row after the first one that failed to converge (a contingency that islands the grid is a
-  routine, expected outcome for this class, not an exceptional one) -- later rows were left as
-  all-zero voltages with an empty, misleadingly "converged, nothing found"-looking violation
-  list. Each row of ``ScenarioSweepCPP`` is independent (unlike ``TimeSeriesCPP``, whose rows
-  chain), so it now keeps going past a failing row, exactly like ``ContingencyAnalysisCPP``
-  already did; ``get_status()`` still correctly reports 0 for the batch as a whole.
-- [FIXED] ``ScenarioSweep.run()`` (the python wrapper) raised on any per-row failure instead of
-  reporting it through the sentinel-violation mechanism its own docstring describes --
-  ``compute()`` is now called with ``ignore_errors=True`` internally, matching
-  ``ContingencyAnalysis.run()``'s behavior (only a diverging shared pre-batch "n" case, which
-  makes the whole result meaningless, still surfaces as an unmistakable ``GRID`` /
-  ``DIVERGENCE`` sentinel rather than a silent empty list).
-- [FIXED] ``ScenarioSweepCPP::compute_flows`` / ``compute_power_flows`` did not detect a
-  ``modify_*`` / ``set_contingency_lines`` / ``set_contingency_trafos`` call made after
-  ``compute()`` without a following ``compute()`` -- unlike ``ContingencyAnalysisCPP``'s
-  equivalent guard (a registered-contingency-count check), a count comparison cannot catch this
-  on ``ScenarioSweepCPP``, since its row-count lock already forbids changing the row count
-  itself; only the row *content* changes. Both methods now raise in that situation instead of
-  silently mixing a new mask/injection with stale voltages from the previous ``compute()``.
-- [FIXED] ``lightsim2grid.scenarioSweep.ScenarioSweep``'s ``compute_limit_violations`` setter
-  reset ``self.__computed`` but not the cached ``_line_mask`` / ``_trafo_mask`` (there is no
-  C++-side getter for them), even though it clear()s the masks C++-side -- the next ``run()``
-  could derive ``element_ids`` / ``element_names`` from a stale cache. Both are now reset too.
-- [FIXED] ``modify_sgen_p`` (on both ``lightsim2grid.timeSerie.TimeSerie`` -- and so, by
-  inheritance, ``lightsim2grid.injectionSweep.InjectionSweep`` -- and
-  ``lightsim2grid.scenarioSweep.ScenarioSweep``) validated ``ndim`` but not the column count,
-  unlike ``modify_gen_p`` / ``modify_load_p`` / ``modify_load_q``; the C++ side still caught it,
-  just with a less immediately actionable error. Consistency fix only.
-- [ADDED] ``src/tests/test_timeseries_sbus.cpp`` and ``lightsim2grid/tests/test_timeseries_sbus.py``:
-  a one-step time series fed the grid's OWN injections must reproduce ``ac_pf`` / ``dc_pf`` exactly.
-  Covers each dropped element kind separately and all of them together, in ac and in dc, plus a
-  multi-step case (the remainder is constant, so it has to reach every row) and a control grid whose
-  whole injection the per-step matrices already covered. Eight of the nine C++ cases fail without the
-  fix.
-- [FIXED] a generator could not remotely regulate a bus that another generator already
-  regulated *locally* -- the grid was refused outright with
-  ``LSGrid::fill_voltage_control_solver_data: generator N regulates bus X which has no voltage (Vm)
-  unknown`` -- even though the configuration is perfectly well posed. Two machines holding one bus
-  simply form a control group: one bordered voltage row, one reactive unknown each, and a sharing
-  row splitting the reactive duty in proportion to their ``qmax - qmin`` ranges, exactly as two
-  *remote* controllers on one bus already did.
-  The cause was the order in which buses are classified. ``GeneratorContainer::fillpv`` knew how to
-  keep a controller's OWN bus out of the PV set (a remote regulator leaves its own bus PQ), but
-  nothing stopped a LOCAL regulator from claiming a bus that somebody else regulated remotely. That
-  bus then had no ``Vm`` unknown, so ``VoltageControl::register_in`` got ``vm_col == -1`` for it, the
-  group's voltage row was never given its ``+1`` entry, and the row came out structurally EMPTY --
-  a singular Jacobian. The check that refused the grid was really reporting the misclassification,
-  not a property of the configuration.
-  Bus classification now runs the other way round: ``LSGrid::get_group_controlled_buses`` collects
-  every bus an active *remote* generator or an active voltage-mode SVC aims at, ``LSGrid::fillpv_pq``
-  keeps those out of PV, and ``fill_voltage_control_solver_data`` enrols the local regulators sitting
-  on them -- generators and voltage-regulating hvdc converter stations alike -- as members of the
-  group. Buses regulated only by things standing on them are deliberately untouched: several machines
-  sharing a bus and all regulating it locally remains the ordinary PV case, with the per-bus reactive
-  redistribution of ``GeneratorContainer::set_q``.
-  Three configurations start working as a result: a remote controller onto a locally regulated bus,
-  a remote controller onto a slack bus pinned by its own generator (the slack generator joins the
-  group and MultiSlack grants the free ``Vm``), and -- separately, by giving the regulated-bus check
-  the ``has_free_q`` escape hatch the controller-bus check already had -- a remote controller onto a
-  slack bus that nothing pins. Disagreeing setpoints between a local and a remote regulator of one
-  bus are now reported by the group's own check (``conflicting voltage setpoints``) rather than as a
-  bus-classification error.
-  Two things stay refused, on purpose. A remote regulator SHARING ITS OWN BUS with a local regulator
-  has no solution at all: whatever reactive power it injects there is absorbed one-for-one by the
-  machine holding that bus' magnitude, so it has no influence on its remote target -- no
-  reclassification can help, and the "its OWN bus has no reactive (Q) equation" error still fires.
-  Voltage-regulating hvdc converter stations take part on the same footing as generators. A VSC
-  station with ``voltage_regulator_on`` pins its own bus through the very same PV path, so it is
-  enrolled into the group whenever a controller claims that bus -- two new controller kinds,
-  ``VoltageControlSolverData::HVDC_SIDE_1`` / ``HVDC_SIDE_2``, with the hvdc LINE id as ``elem_id``
-  and the solved reactive output written back to the station. Its sharing key is a reactive range in
-  MVAr, the same currency as a generator's, so a mixed generator/station group shares reactive power
-  correctly (a group of a local generator, a remote generator and a station splits ``Q`` three ways
-  by range).
-  Note for voltage-mode SVCs: their regulated bus now leaves the PV path as well, which is what makes
-  the classification uniform, but an SVC still has to be the only controller of its bus in v1 (its
-  sharing key is a susceptance range, not a reactive range, so mixed SVC/generator sharing has no
-  defined semantics yet). Such a grid is therefore still refused -- now by that restriction, which
-  names the real limitation.
-- [ADDED] ``src/tests/test_voltage_control_reclassify.cpp`` and
-  ``lightsim2grid/tests/test_voltage_control_reclassify.py``: the classification rule itself, the
-  newly-supported configurations (including the reactive split, and hvdc stations sharing a bus with
-  generators on either end of the line), the ones that must stay refused, and regression guards that
-  several purely local regulators on one bus -- and a lone voltage-regulating station -- still take
-  the classical PV path and produce bit-identical voltages.
-- [FIXED] remote voltage control (remote-regulating generators and voltage-mode SVCs) and the free
-  ``Vm`` unknown of a distributed-slack participant were **silently ignored** by every batch
-  algorithm -- ``TimeSeriesCPP``, ``ContingencyAnalysisCPP`` and ``SecurityAnalysis``, ie everything
-  going through ``BaseBatchSolverSynch``. The powerflow still converged and still returned plausible
-  voltages, they were just the voltages of a grid with no such regulation: a silent wrong answer, not
-  an error. ``LSGrid::ac_pf`` was unaffected.
-  The NR extensions do not receive their data as solver arguments; they reach back into the
-  ``LSGrid`` through the algorithm's ``lsgrid_ptr`` and read its *member* solver-side labelling
-  (``LSGrid::get_free_vm_slack_solver_buses`` for ``Base``,
-  ``LSGrid::fill_hvdc_droop_solver_data`` for ``Hvdc``,
-  ``LSGrid::fill_voltage_control_solver_data`` for ``VoltageControl``).
-  ``ac_pf``/``dc_pf``/``check_solution`` pass those members straight to ``pre_process_solver``, so
-  they are always current there; the batch algorithms own local mapping vectors and pass those
-  instead, against a private *copy* of the grid whose copy constructor ``reset()`` all of it to
-  empty. ``_pre_process_solver_impl`` wrote only the FORWARD map (``id_me_to_ac_solver_``) back onto
-  the grid, so ``id_ac_solver_to_me_`` and ``slack_bus_id_ac_solver_`` stayed empty -- and empty is
-  indistinguishable from "this grid has no controller": ``fill_voltage_control_solver_data`` returns
-  on its ``nb_bus_solver == 0`` guard and ``get_free_vm_slack_solver_buses`` on its ``slack.empty()``
-  one, both without a word. The sync now covers the reverse map and both slack vectors, AC and DC.
-  The ``Hvdc`` angle-droop extension was never affected: it only ever read the forward map, the one
-  that was already synced (there is now a regression test pinning that too).
-  Two consequences worth knowing about. A grid whose voltage-control configuration is not supported
-  in v1 now raises from ``fill_voltage_control_solver_data`` in the batch path as it always did in
-  the single-shot one, where before it was quietly accepted and solved without the regulation. The
-  restriction is on buses whose voltage magnitude is *already determined* -- a controller may not
-  regulate the slack, nor a PV bus pinned by a local regulator, since neither owns a ``Vm`` unknown
-  for the bordered row to act on; several controllers sharing one regulated bus is fine and always
-  was (one voltage row, one ``Q`` column each, plus a sharing row splitting ``Q`` by
-  ``qmax - qmin``). And under
-  ``ContingencyAnalysis``'s ``handle_disconnected_grid`` mode, a contingency that strands a regulated
-  bus is now reported as a ``DIVERGENCE`` instead of converging with the regulation dropped: bus
-  masking is deliberately a value-only edit that must not touch the ``J`` pattern, so the bordered
-  voltage row survives against a bus the mask pins, and the system has no solution. An honest
-  non-result rather than a confident wrong one.
-- [ADDED] ``src/tests/test_batch_voltage_control.cpp``: solves the same grid single-shot through
-  ``LSGrid::ac_pf`` and through ``TimeSeries`` / ``ContingencyAnalysis``, and requires the voltages
-  to agree -- for a remote-regulating generator, two generators sharing one regulated bus, a
-  voltage-mode SVC (flat and sloped), a free-``Vm`` distributed-slack participant, and an hvdc angle
-  droop.
-- [ADDED] ``TimeSeriesCPP`` / ``ContingencyAnalysisCPP`` (and so ``SecurityAnalysis``, which wraps the
-  latter) gained a string-based ``change_algorithm(name)`` overload and a ``get_algo_name()`` accessor,
-  matching what ``LSGrid`` already had (``AlgorithmSelector::change_algorithm(const std::string&)``) --
-  needed to select a plugin solver, or a built-in with no dedicated ``AlgorithmType`` enum member (eg
-  ``NRRefactorRetry_KLU``), for a batch computation, which was previously impossible: only the
-  enum-based overload was exposed, and ``AlgorithmType::Custom`` (what such solvers collapse onto) is
-  rejected by ``change_algorithm(AlgorithmType)``. Also bound ``available_algorithm_names()`` on both
-  classes for the same reason -- previously only ``available_default_algorithms()`` (the enum-only,
-  plugin-blind list) was exposed.
-- [FIXED] two bugs this exposed, both the same "propagate the algorithm via ``AlgorithmType`` instead of
-  by registry name" mistake: (1) ``BaseBatchSolverSynch``'s constructor inherited the source ``LSGrid``'s
-  AC algorithm via ``get_algo_type()`` (the enum), so constructing a ``TimeSeries`` /
-  ``ContingencyAnalysis`` / ``SecurityAnalysis`` from a grid running a plugin or no-enum-member solver
-  raised immediately; (2) ``ContingencyAnalysis``'s multi-threaded path (``nb_thread > 1``) rebuilt each
-  per-thread solver the same lossy way. Both now propagate by name (``get_algo_name()`` /
-  ``get_algo().get_name()``). See ``test_batch_algorithm_solver_selection.py`` for the regression tests.
 - [ADDED] closed the last two gaps in the benchmark narrative-generation work above:
 
   - ``benchmarks/benchmark_grid_size.py`` gained a ``generate_narrative`` (recycling vs no-recycling,
@@ -1989,139 +1636,6 @@ TODO: a "combine mode" axis for ``ScenarioSweepCPP`` choosing between the curren
   before the class was renamed from ``SecurityAnalysis``.
 - [FIXED] translated the last remaining French comments in ``pyproject.toml`` to English,
   for consistency with the rest of the (English-only) documentation and codebase.
-- [ADDED] ``ContingencyAnalysisCPP.violation_threshold`` (mirrored by the python
-  ``ContingencyAnalysis.violation_threshold``): a ``float`` in ``]0., 1.]``, default
-  ``1.0``, applied to every check performed when ``compute_limit_violations`` is ``True``,
-  so that near-limit situations can be reported before they actually breach 100% of a
-  limit. It is the fraction of the usable range still considered acceptable, so lowering it
-  makes every check stricter (more violations reported, never fewer). Each of the three
-  checks owns one interval, running from a "healthy" anchor to the limit that can be
-  violated, and the threshold moves that limit towards its anchor -- one linear
-  interpolation, ``effective_limit = threshold * limit + (1 - threshold) * anchor``, for all
-  three:
-
-  - ``CURRENT``: anchor ``0``, limit ``limit_a`` -- violates when
-    ``value >= threshold * limit_a``. A line's usable range really is ``[0, limit_a]``, so
-    this reduces to plainly scaling the limit;
-  - ``LOW_VOLTAGE``: anchor ``vn_kv``, limit ``vmin_kv`` -- violates when
-    ``v <= threshold * vmin + (1 - threshold) * vn``;
-  - ``HIGH_VOLTAGE``: anchor ``vn_kv``, limit ``vmax_kv`` -- violates when
-    ``v >= threshold * vmax + (1 - threshold) * vn``.
-
-  A voltage bound has no natural "zero" end, which is why the bus nominal voltage is used as
-  its anchor (operating limits are conventionally expressed as +/- x% of it). Anchoring both
-  voltage checks there -- rather than on each other -- keeps them independent: the
-  ``LOW_VOLTAGE`` verdict never depends on ``vmax_kv`` and vice versa. It also means the two
-  effective bounds converge towards the anchor from their own side and can never cross, so
-  no bus is ever reported as both too low and too high (the sole exception being a band
-  fully collapsed onto nominal, ``vmin == vn == vmax``, where a bus sitting exactly at
-  nominal satisfies both and is reported once, as ``LOW_VOLTAGE``). The anchor is the
-  nominal voltage *clamped into* ``[vmin_kv, vmax_kv]``: a band is not required to bracket
-  it -- a 380 kV level declared with an operating range of ``[390, 450]`` kV is ordinary
-  practice on the European 400 kV network -- and clamping keeps each bound moving inwards
-  only, without rejecting such a grid. Where the band does bracket the nominal voltage (the
-  overwhelmingly common case) the clamp does nothing.
-
-  The reported ``LimitViolation.value`` / ``.limit`` are never rescaled (still the value
-  reached and the limit as configured); only the test deciding whether to report is shifted.
-  The default ``1.0`` reproduces the previous, threshold-less behaviour (modulo the strict
-  ``>`` / ``<`` comparisons becoming ``>=`` / ``<=``, which only differ if a value lands
-  exactly on its limit). A value outside ``]0., 1.]`` (or ``NaN``) is rejected. Like
-  ``nb_thread`` / ``handle_disconnected_grid`` this is a plain runtime knob affecting only
-  the next ``compute()``, with one asymmetry: *lowering* it discards any already-computed
-  results (they would under-report), while *raising* it keeps them (a stricter result is a
-  superset of a looser one). Unlike ``compute_limit_violations``, neither case clears the
-  registered contingencies.
-- [ADDED] a bus configured with a minimum voltage above its maximum
-  (``vmin_kv > vmax_kv``, see ``LSGrid.set_bus_voltage_limits``) now raises a
-  ``RuntimeError`` during a ``ContingencyAnalysis`` limit-violation check, instead of being
-  silently reported as an arbitrary one of ``LOW_VOLTAGE`` / ``HIGH_VOLTAGE``. That is a
-  genuine input error, and the only way the two effective voltage bounds can end up crossed
-  (see ``violation_threshold`` above).
-- [ADDED] ``src/tests/test_powerflow_algorithm.cpp``: a C++ (Catch2) test suite for the
-  Newton-Raphson system itself (``src/core/powerflow_algorithm/NRSystem*``) and its
-  ``MultiSlack`` / ``VoltageControl`` / ``Hvdc`` extensions. It drives an ``NRSystem``
-  phase by phase, the way ``NRAlgo::compute_pf`` does, and checks the internal
-  consistency the grid-level tests cannot see: the augmented Jacobian is square and
-  matches ``total_state_variables()``, every bus -> row / column map stays in range and
-  agrees with the ledger's registration pair lists, no Jacobian row or column is
-  structurally empty (which is how an unresolved feature entry shows up), a
-  ``status_droop`` flip changes values but not the sparsity pattern (so a linear solver
-  may reuse its symbolic factorization), bus masking is a pure value-level edit, and
-  ``clear_jacobian`` leaves a system that rebuilds bit-identically.
-- [ADDED] two jobs in ``.github/workflows/sanitizers.yml`` running the C++ (Catch2) test
-  suite under ASan + UBSan and under re-enabled Eigen / libstdc++ assertions
-  (``__SANITIZE=1`` / ``__DEBUG_ASSERTS=1``). The suite already ran under valgrind
-  (``cpp_unit_tests.yml``), but an index that is wrong while still inside its allocation
-  is invisible to both valgrind and ASan -- only the assertion build catches it. The test
-  binary itself (not just ``lightsim2grid_core``) is now compiled and linked with the
-  sanitizer flags, see ``src/tests/CMakeLists.txt``.
-- [ADDED] ``modify_gen_v`` on ``TimeSeriesCPP`` / ``InjectionSweepCPP`` /
-  ``ScenarioSweepCPP`` (python: ``TimeSerie.modify_gen_v`` /
-  ``ScenarioSweep.modify_gen_v``, the latter inherited "for free" by
-  ``InjectionSweep``): a new per-step axis, the target generator voltage magnitude
-  (``vm_pu``), shape ``(n_simul, n_gen)``. Unlike ``modify_gen_p`` / ``modify_sgen_p`` /
-  ``modify_load_p`` / ``modify_load_q``, this does **not** feed the injection (``Sbus``)
-  at all: a PV bus's magnitude is not part of Newton-Raphson's unknown vector, so it
-  never moves during a solve once seeded -- ``modify_gen_v`` only re-seeds ``|V|`` at
-  each voltage-regulating generator's regulated bus immediately before that row's solve
-  (``GeneratorContainer::set_vm``, a new overload taking an explicit per-generator
-  vm vector, alongside the existing single-arg overload reading the grid's own
-  ``target_vm_pu``). Left unset (the default), every row keeps using the grid's own
-  ``target_vm_pu``, exactly as before this setter existed.
-- [IMPROVED] speed (DC batch algorithms -- ``TimeSeriesCPP`` / ``InjectionSweepCPP`` /
-  ``ContingencyAnalysisCPP`` / ``ScenarioSweepCPP``): a DC solve no longer builds the
-  complex voltage every row. ``BaseDCAlgo::compute_pf_dc`` only ever *outputs* the bus
-  angles (``theta``, the linear solve's actual result) -- the magnitude ``Vm_`` is a
-  pure, unmodified echo of the caller's input, and the complex ``V_`` it used to build
-  from both (a ``std::polar`` / hardware ``sincos`` call per bus) existed only so
-  downstream code could read it back. That downstream code (``compute_amps_flows`` /
-  ``compute_active_power_flows``) was then immediately un-building it again with
-  ``.arg()`` (and, for the current-limit checks, ``check_current_violations`` did the
-  same) -- a full sin/cos-then-atan2 round trip, per bus, per row, for values that were
-  never actually needed in complex form. A new ``BaseAlgo::set_lazy_v`` toggle (DC-only;
-  a no-op default for AC / plugin solvers) lets ``BaseBatchSweep`` skip that entirely:
-  the per-row sweep now accumulates only ``theta`` (a plain real matrix), and the flow
-  computations read it directly, with no ``.arg()``. The (small, per-generator) voltage
-  magnitude is reconstructed only if/when something actually asks for it --
-  ``get_voltages()`` (lazily, cached on first call) or the amps flows (which do need
-  ``|V|`` for the per-unit-to-amps conversion) -- from the grid's own target voltages
-  plus ``modify_gen_v``, if set, the exact same (tiny) input the row loop itself already
-  used, never from a stored per-row matrix. Bit-for-bit identical results (covered by
-  the existing DC / ``modify_gen_v`` / current-limit-violation cases across
-  ``src/tests/test_injection_sweep.cpp``, ``test_timeseries_sbus.cpp``,
-  ``test_batch_voltage_control.cpp`` and ``test_scenario_sweep_violations.cpp``); the
-  "handle disconnected grid" mode (``ContingencyAnalysisCPP`` / ``ScenarioSweepCPP``) is
-  unaffected and keeps building the complex voltage eagerly, as it already needs
-  per-row current-limit checks whenever that mode is combined with
-  ``compute_limit_violations``.
-- [FIXED] ``BaseBatchSweep``'s ``_run_range`` aborted the whole remaining range on the first
-  row that failed to solve (was non-invertible, or diverged) for **every** instantiation,
-  not just ``TimeSeriesCPP``. The abort condition was keyed on
-  ``SbusPolicy::supports_vary && !YbusPolicy::supports_contingency``, which happens to be
-  true for ``TimeSeriesCPP`` (correctly abort: each row is warm-started from the previous
-  one, so nothing past a failure is meaningful) but was *also* true for
-  ``InjectionSweepCPP`` (each row is independent of the others and of their order, per its
-  own docstring -- a later row must not be abandoned just because an earlier, unrelated one
-  failed). ``ContingencyAnalysisCPP`` / ``ScenarioSweepCPP`` were unaffected in practice
-  (they go through the masked ``_run_range_masked`` path instead), but the same policy
-  combination would have hit them too under ``handle_disconnected_grid``. The abort is now
-  keyed directly on the real criterion, ``BatchInitKind::FromPreviousStep`` (chained rows),
-  which is true only for ``TimeSeriesCPP``. Every other row still gets its own zero-row /
-  ``NOT_SIMULATED``-or-``DIVERGENCE`` sentinel via the existing ``_store_row_status``, same as
-  a genuinely diverging row already got; only rows *after* it, which used to be silently
-  skipped, are now actually attempted.
-- [ADDED] ``nb_converged()`` on every batch algorithm (``TimeSeriesCPP`` /
-  ``InjectionSweepCPP`` / ``ContingencyAnalysisCPP`` -- and so ``SecurityAnalysis``, which
-  wraps it -- / ``ScenarioSweepCPP``), next to the existing ``nb_solved()``: the count of
-  powerflows, among those ``nb_solved()`` attempted, that actually converged. Always
-  ``<= nb_solved()`` -- a row skipped outright (a non-invertible / islanding admittance
-  matrix, on ``ContingencyAnalysisCPP`` / ``ScenarioSweepCPP``) never reaches the solver at
-  all, so it counts towards neither. Implemented once, on the shared
-  ``BaseBatchSolverSynch`` base, by threading a new ``int & nb_converged`` out-parameter
-  alongside the existing ``nb_solved`` one through ``compute_one_powerflow`` and every
-  caller up to ``_compute_threaded`` (including its per-thread accumulate-then-merge
-  logic), so all four classes get it identically and cannot drift apart.
 
 [0.13.1]  2026-04-21
 --------------------
@@ -2152,7 +1666,6 @@ TODO: a "combine mode" axis for ``ScenarioSweepCPP`` choosing between the curren
   This means that calls like "from lightsim2grid_cpp import XXX" will not work. To replace them 
   you  need to perform "from lightsim2grid.lightsim2grid_cpp import XXX"
 - [FIXED] some compilation issues on some systems (*eg* windows when using c++23 standard)
-- [FIXED] some issues with "copy on write" and pandas 3 when init from pandapower grid.
 - [IMPROVED] cleaner `cktso_lib` (`from lightsim2grid.compilation_options import cktso_lib`) : the file name and extension are omitted
 - [IMPROVED] easier build by relying on cmake and scikit_build_core to build the cpp part
 - [IMPROVED] SuiteSparse to version 7.12.2 (2026-02-05)
@@ -2160,7 +1673,7 @@ TODO: a "combine mode" axis for ``ScenarioSweepCPP`` choosing between the curren
 [0.12.2] 2026-02-05
 ----------------------
 - [FIXED] an issue with shunt buses (was set to 1 even if they were disconnected)
-- [FIXED] a warning when applying actions on generator voltage setpoints (due to NaN)
+- [FIXED] a warning when applying actions on generator votlage setpoints (due to NaN)
 - [FIXED] pandapower grid could be modified when importing a grid from pandapower.
 - [IMPROVED] add a test to make sure generator types are available if using
   `dist_slack_non_renew` information.

{lightsim2grid-1.0.0 → lightsim2grid-1.0.0rc2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.2
 Name: lightsim2grid
-Version: 1.0.0
+Version: 1.0.0rc2
 Summary: LightSim2grid implements a c++ backend targeting the Grid2Op platform.
 Author-Email: Benjamin Donnot <benjamin.donnot@rte-france.com>
 Classifier: Development Status :: 4 - Beta
@@ -67,12 +67,10 @@ this package should not be used for detailed power system computations or simula
   addition to grid2op's own environments -- see
   [LSGrid module](https://lightsim2grid.readthedocs.io/en/latest/network.html) (`lightsim2grid.gridmodel`
   / `GridModel` are the older, deprecated names for `lightsim2grid.network` / `LSGrid`).
-- **Multi-threaded contingency (n-1) analysis**, time-series, injection-sweep and scenario-sweep
-  computation, all much faster than stepping through grid2op one scenario / contingency at a time --
-  see [Contingency Analysis](https://lightsim2grid.readthedocs.io/en/latest/security_analysis.html) and
-  [Time series](https://lightsim2grid.readthedocs.io/en/latest/time_series.html). Every one of these
-  batch classes exposes `nb_solved()` / `nb_converged()` and a per-row `converged_mask()`, so a failing
-  row is diagnosable without re-running the batch one row at a time.
+- **Multi-threaded contingency (n-1) analysis** and time-series computation, both much faster than
+  stepping through grid2op one scenario / contingency at a time -- see
+  [Contingency Analysis](https://lightsim2grid.readthedocs.io/en/latest/security_analysis.html) and
+  [Time series](https://lightsim2grid.readthedocs.io/en/latest/time_series.html).
 - **Fast binary serialization** (`save_binary` / `load_binary`) of a grid, in addition to the standard
   pickle support -- see
   [Fast binary serialization](https://lightsim2grid.readthedocs.io/en/latest/binary_serialization.html).

{lightsim2grid-1.0.0 → lightsim2grid-1.0.0rc2}/README.md

@@ -35,12 +35,10 @@ this package should not be used for detailed power system computations or simula
   addition to grid2op's own environments -- see
   [LSGrid module](https://lightsim2grid.readthedocs.io/en/latest/network.html) (`lightsim2grid.gridmodel`
   / `GridModel` are the older, deprecated names for `lightsim2grid.network` / `LSGrid`).
-- **Multi-threaded contingency (n-1) analysis**, time-series, injection-sweep and scenario-sweep
-  computation, all much faster than stepping through grid2op one scenario / contingency at a time --
-  see [Contingency Analysis](https://lightsim2grid.readthedocs.io/en/latest/security_analysis.html) and
-  [Time series](https://lightsim2grid.readthedocs.io/en/latest/time_series.html). Every one of these
-  batch classes exposes `nb_solved()` / `nb_converged()` and a per-row `converged_mask()`, so a failing
-  row is diagnosable without re-running the batch one row at a time.
+- **Multi-threaded contingency (n-1) analysis** and time-series computation, both much faster than
+  stepping through grid2op one scenario / contingency at a time -- see
+  [Contingency Analysis](https://lightsim2grid.readthedocs.io/en/latest/security_analysis.html) and
+  [Time series](https://lightsim2grid.readthedocs.io/en/latest/time_series.html).
 - **Fast binary serialization** (`save_binary` / `load_binary`) of a grid, in addition to the standard
   pickle support -- see
   [Fast binary serialization](https://lightsim2grid.readthedocs.io/en/latest/binary_serialization.html).

{lightsim2grid-1.0.0 → lightsim2grid-1.0.0rc2}/lightsim2grid/__init__.py

@@ -6,7 +6,7 @@
 # SPDX-License-Identifier: MPL-2.0
 # This file is part of LightSim2grid, LightSim2grid implements a c++ backend targeting the Grid2Op platform.
 
-__version__ = "1.0.0"
+__version__ = "1.0.0.rc2"
 
 __all__ = [
     "newtonpf",
@@ -104,14 +104,6 @@ except ImportError as exc_:  # noqa: F841
     # grid2op is not installed, the TimeSeries module will not be available
     pass
 
-try:
-    from lightsim2grid.injectionSweep import InjectionSweep  # noqa: F401
-    __all__.append("InjectionSweep")
-    __all__.append("injectionSweep")
-except ImportError as exc_:  # noqa: F841
-    # grid2op is not installed, the InjectionSweep module will not be available
-    pass
-
 try:
     from lightsim2grid.contingencyAnalysis import ContingencyAnalysis  # noqa: F401
     __all__.append("contingencyAnalysis")
@@ -119,15 +111,7 @@ try:
 except ImportError as exc_:  # noqa: F841
     # grid2op is not installed, the SecurtiyAnalysis module will not be available
     pass
-
-try:
-    from lightsim2grid.scenarioSweep import ScenarioSweep  # noqa: F401
-    __all__.append("ScenarioSweep")
-    __all__.append("scenarioSweep")
-except ImportError as exc_:  # noqa: F841
-    # grid2op is not installed, the ScenarioSweep module will not be available
-    pass
-
+    
 try:
     from lightsim2grid.rewards import N1ContingencyReward  # noqa: F401
     __all__.append("rewards")