Discussion around intertemporal RAO POC

[Godelaine]

Describe the current behavior

No response

Describe the expected behavior

WE WILL ONLY FOCUS ON LINEAR PREVENTIVE OPTIMIZATION AT FIRST, as this already represents a lot of work with numerous new features for the RAO.

1. Data Management
   Load multiple cracs, multiple networks, make a multi timestamp unit object : RaoInputTS
   add gradient information for now in RaoInput : map< network element, double>

2. Launch a multi timestamp sensitivity computation
   document difference % SensitivityComputation

3. use LinearProblemBuilderMultiTS
   document difference % LinearProblemBuilder

4. GradientFiller
   puissance(timeindex3) - puissance(timeindex2) < gradient * (timeindex3 - timeindex2)

5. Multi TS Output
   for now, list raoResults

For now, no topos
Tests :

• cnec with max -1000, injection on first node
• same, but new cnec in the middle with opposite (and impossible to meet) needs

FOCUS ON CREATED OBJECTS:
1)RaoInputTS : Map<cracs, ts>, networks. For now, no optimized state etc (used for CastorOneStateOnly)
TODO : list other attributes in RaoInput and why we don't need them
2)

Describe the motivation

No response

Extra Information

No response

[bqth29]

Power Gradient Constraints

For power gradient constraints, I think that a simple record class can be used with the name PowerGradientConstraint. It should have 5 attributes:

• a string that contains the identifier of the network element (generator or load)
• a double value for the gradient value
• a variation direction (upward / downward) to whether the constraint applies to upward or downward set-point variations
• an optional timestamp to indicate from when the constraint applies (no timestamp means available all the time, until a possible end timestamp)
• an optional timestamp to indicate until when the constraint applies (no timestamp means available all the time, from a possible start timestamp)

public record PowerGradientConstraint(String networkElementId, double powerGradient,
                                      RangeAction.VariationDirection variationDirection,
                                      Optional<OffsetDateTime> validFrom,
                                      Optional<OffsetDateTime> validTo) {
}

For a first implementation, I believe that a simple Set<PowerGradientConstraint> will suffice in the input data.

[bqth29]

Linear Equation Update

Set-point value

The set-point and variation variables must now include a timestamp indexing alongside the range action and the state since the same remedial action can be used at different timestamps.

The set-point variation equation is the same as previously, linking the new set-point (i.e. the set-point at the end of the state) to the previous one (i.e. the set-point at the beginning of the state) using the variation variables:

$$A(r, s, t) = \pi(r, s, t) + \Delta^{+}(r, s, t) - \Delta^{-}(r, s, t)$$

where $\pi(r, s, t)$ is a function that returns the variable corresponding to the last time when the range action $r$ was used (time that occurs before the couple state $s$ - timestamp $t$).

The equation is rigorously the same as for single-timestamp RAO, except for the timestamp-wise indexing.

The function $\pi$ is implemented in the utility class RaoUtil for single-timestamp RAO and returns the variable corresponding to the last state at which the range action was available (or a double value corresponding to the initial set-point value in the network in case it was not available before).

For multi-timestamp RAO, the "last time the range action was used" is computed a bit differently. Indeed the time logic is now two-dimensional as it relies on both the state and the timestamp (whereas only states were used before). Thus for a given state $s$ and a given timestamp $t$, the notion of "state just before $s$" is computed as follows:

• if state $s$ is not preventive, then the previous state is the same as previously (i.e. instant just before for the same timestamp and same contingency - or preventive state for the same timestamp)
• if state $s$ is preventive, then the previous state is the preventive state of the timestamp just before $t$ (that we can denote by $t - 1$)

Gradient constraint

For the formal definition of gradient constraints, see this comment.

Given a range action $r$ at state $s$ and timestamp $t$, two power gradients constraints can apply on the set-point variation if the generating unit of $r$. One gradient can be used for upward variation, and another for downward variation. We respectively denote them by $\nabla p^{+}$ and $\nabla p^{-}$. Finally, we denote $\Delta \tau (t, t+1)$ the time between timestamp $t$ and the following timestamp $t + 1$.

The power gradient constraint indicates than the power of the generator unit cannot increase or decrease more than a given rate per unit of time. For preventive range actions, both upward and downward constraints can be written as follows:

$$\Delta^{+}(r, s, t) \leq \nabla p^{+}(r, t) \Delta \tau (t, t + 1)$$

$$\Delta^{-}(r, s, t) \leq \nabla p^{-}(r, t) \Delta \tau (t, t + 1)$$

TODO: For post-outage states, sum variations?
only use preventive for now
how not to invert variation direction between preventive and curative?
we do not want $\Delta^{+}(prev) &gt; 0$ and $\Delta^{-}(cur) &gt; 0$

The PowerGradientConstraintFiller thus needs all the power gradient constraints and all the range-action variables all all timestamps to be used.

TemporalState

Reuse single-timestamp RAO linear problem API

TODO

[bqth29]

Handling different data for each timestamp

Some classes must be used for several timestamps (CRAC, network, RAO parameters, RAO result, ...) so it would make sense using a general interface for handling temporal data.

For this purpose, we can take inspiration form PowSyBl's ZonalData and create an equivalent system for time data that can be called TemporalData.

public interface TemporalData<T> {
    Map<OffsetDateTime, T> getDataPerTimestamp();

    default Optional<T> getData(OffsetDateTime timestamp) {
        return Optional.ofNullable(getDataPerTimestamp().get(timestamp));
    }

    void add(OffsetDateTime timestamp, T data);
}

That way, there will be a common handling of temporal data, no matter which class is being processed.

[bqth29]

Outputs

For the first implementation, the easiest is to simply return a TemporalData<RaoResult>.

public static TemporalData<RaoResult> run(TemporalData<RaoInput> raoInputs, TemporalData<RaoParameters> raoParameters, Set<PowerGradientConstraint> powerGradientConstraints) {
        TemporalData<RaoResult> raoResults = ...;
        // TODO
        return raoResults;
    }

[bqth29]

Multiple-timestamps sensitivity computation

For multiple-timestamps sensitivity computation, we have to keep in mind that a remedial action at a given timestamp can have a direct effect on a CNEC several timestamps later. Indeed, if a PST range action is only available at timestamp 1, some CNECs at timestamp 10 are directly impacted by the tap of the PST.

Thus, for the sensitivity computation of timestamp $t$, only the CNECs of timestamp $t$ are required but all the remedial actions of all the timestamps before $t$ ($t$ included) are required too.

This can be done more subtly by considering only the remedial actions for the timestamp closest to $t$ at which they are available. But this requires more work and could be the subject of a future refactoring. Initially, it will be sufficient to run a sensitivity computation with all the previous remedial actions.

A simple code example is given below:

public static TemporalData<SensitivityResult> runSensitivityComputation(TemporalData<Crac> cracs, TemporalData<Network> networks, ToolProvider toolProvider) {
        TemporalData<SensitivityResult> sensitivityResults = new TemporalDataImpl<>();
        List<OffsetDateTime> sortedTimestamps = cracs.getDataPerTimestamp().keySet().stream().sorted().toList();
        Set<RangeAction<?>> previousRangeActions = new HashSet<>();
        sortedTimestamps.forEach(
            timestamp -> {
                Network network = networks.getData(timestamp).orElseThrow();
                Crac crac = cracs.getData(timestamp).orElseThrow();
                previousRangeActions.addAll(crac.getRangeActions());
                SensitivityComputer sensitivityComputer = SensitivityComputer.create()
                    .withToolProvider(toolProvider)
                    .withCnecs(crac.getFlowCnecs())
                    .withRangeActions(previousRangeActions)
                    .build();
                sensitivityComputer.compute(network);
                sensitivityResults.add(timestamp, sensitivityComputer.getSensitivityResult());
            }
        );
        return sensitivityResults;
    }

[bqth29]

Input data

Input name	Keep	Details
Crac	YES	Paramount mandatory data
Network	YES	Paramount mandatory data
networkVariantId	NO	Optional, we can simply use default variant
optimizedState	NO	Used for OneStateOnly but in practice, only used for preventive permieter in the code. Besides, first POC only tackles preventive optimization.
perimeter	NO	Used for OneStateOnly but in practice, only used for preventive permieter in the code. Besides, first POC only tackles preventive optimization.
refProg	YES but ignore for first POC	More complex behavior to add in a future development
glsk	YES but ignore for first POC	More complex behavior to add in a future development

We will also need one set of RAO Parameters per timestamp