Support of validation level for missing permanent limit

[annetill]

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

Does this PR already have an issue describing the problem?

No

What kind of change does this PR introduce?

Feature

What is the current behavior?

If a LoadingLimit has temporary limits, the permanent limit is mandatory. This is imposed by the way the limit violations detection works. When importing an IIDM network, if a permanent limit is missing :

• the network is rejected for IIDM version >= v1.12
• the permanent limit is computed from the 1st temporary limit's value.

At this subject, see #2636

With this principle, it is not possible to import a network (especially of an older IIDM version) and prompt a user for the missing permanent limits.

What is the new behavior (if this is a feature change)?
With this PR, it is possible have IIDM networks with missing permanent limits (either created via the API or imported) as long as the validation level is EQUIPMENT.

When importing an IIDM network, it is possible to override its minimum validation level. To do this, you should use the following import parameter: iidm.import.minimal-validation-level: EQUIPMENT.

Operational limits are now considered by the validation level mechanism:

• When adding operational limits on a network element with a missing permanent limit, or when settting a permanent limit to Double.NaN, the operation will:

  • succeed if the validation level is EQUIPMENT;
  • fail if the minimum validation level is not EQUIPMENT;
  • succeed if the validation level is not EQUIPEMENT, but the minimum validation level is. In this case, the validation level will be lowered to EQUIPMENT.

• When only a missing permanent limit prevents a network to be in STEADY_STATE_HYPOTHESIS level, using the LoadingLimits.setPermanentLimit(...) method to define it a value will increase the validation level of the network to STEADY_STATE_HYPOTHESIS.

Note that all operational limits are taken into account to determine the validation level. It is also the case for the operational limits defined in a non-selected OperationalLimitsGroup (the group is not currently used for the corresponding network element).

Does this PR introduce a breaking change or deprecate an API?

• Yes
• No

If yes, please check if the following requirements are fulfilled

• The Breaking Change or Deprecated label has been added
• The migration steps are described in the following section

What changes might users need to make in their application due to this PR? (migration steps)

The following utilitary methods:

• ValidationUtil.checkLoadingLimits(...);
• ValidationUtil.checkPermanentLimit(...);

now take two additional parameters:

• boolean throwException: should the method throw an exception when a missing permanent limit is detected?
• ReportNode reportNode: the reportNode to use to log potential errors. You can use ReportNode.NO_OP if you are not interested by this log.

Other information:

[olperr1]

I think it is important to have this.
This relies on the ValidationUtil.checkIdentifiable(...) method which should now consider the limits to determine the validation level of a network.

[olperr1]

I pushed modifications to take the limits into account when determining the validation level of the network.

I chose to consider all the OperationalLimitsGroups (the selected and the unselected) since it is easier to do: when considering only the selected ones, the validation level should be checked every time the selected operationalLimitsGroup is changed for any limits holder.

[miovd]

Mostly okay for me, only small remarks

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
98.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud