Describe the current behavior

It is currently possible to create a new current limits (or an active or apparent power limits) directly from the branch or from the flowslimitsholder itself. This is not a good practice as it conceals the operations performed on the OperationalLimitsGroup: its potential creation and/or its potential setting as selected.

Describe the expected behavior

From the Branch/FlowsLimitsHolder, it should be possible to manipulate easily OperationalLimitsGroup (and not LoadingLimits).
From the OperationalLimitsGroup, it should be possible to manipulate easily LoadingLimits.

That implies:

• The creation of new LoadingLimits from the Branch/FlowsLimitsHolder should be deprecated.
• Some methods overloads currently exist at Branch/FlowsLimitsHolder level but do not exist at OperationalLimitsGroup level (newCurrentLimits(CurrentLimits limits)...). They should be available there too.
• Some methods could be added to facilitate the creation of an OperationalLimitsGroup like: getOrCreateSelectedOperationalLimitsGroup(String limitsGroupId), that would:
  • get OperationalLimitsGroup with limitsGroupId if it already exists
  • create it if it doesn't exist
  • in all cases set it as active
    (note: this is what is currently being done in FlowsLimitsHolder.newCurrentLimits with a default limitsGroupId)

Describe the motivation

Generic limits processing on Branch/FlowsLimitsHolder is not possible as depending on the identifiable, one would have to call 3 different methods (getCurrentLimits, getCurrentLimits1, getCurrentLimits2 // newCurrentLimits, newCurrentLimits1, newCurrentLimits2...).
By having this intermediate step where one can easily (in one method call) get or create a selected OperationalLimitsGroup, processing could then be factored (just getCurrentLimits // newCurrentLimits...).

Extra Information

No response