Fix SensitivityFactorModelReader

[annetill]

• Do you want to request a feature or report a bug?

• What is the current behavior?

In case of BUS_VOLTAGE function type, it seams that these following lines force as bus id the id of the bus view:

            if (factor.getFunctionType() == SensitivityFunctionType.BUS_VOLTAGE) {
                Bus bus = new IdBasedBusRef(factor.getFunctionId()).resolve(network, TopologyLevel.BUS_BRANCH)
                    .orElseThrow(() -> new PowsyblException("The bus ref for '" + factor.getFunctionId() + "' cannot be resolved."));
                functionId = bus.getId();
            }

Consequently, it forces the sensitivity analysis implementation to be based on the bus/view. It is an issue if for example we want to simulate a switch contingency and in the same time a factor that contains a function of type BUS_VOLTAGE.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

• What is the expected behavior?

Leave the simulator decides and ask the id of the bus breaker view.

• What is the motivation / use case for changing the behavior?

• Please tell us about your environment:

  • PowSyBl Version: ...
  • OS Version: ...

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it)

[sylvlecl]

Consequently, it forces the sensitivity analysis implementation to be based on the bus/view.

Not really, it just forces the implementation to map its results on the bus view. But indeed there is an issue because of the modification of buses during the computation. There is the same issue for security analysis and "bus results".

Brain storming about possible solutions:

• decide that we only take "bus breaker" buses as input, or more fine-grained localizations such as terminals ...
• provide multiple outputs for buses that are split during computation. Note that it can be interesting to know that a bus has indeed been split. However it will enforce the user to plan for this rare case: is it a good thing or a bad thing ?
• provide a special status in output if the required bus is split
• throw an exception if the required bus is split: not OK, otherwise computations will "randomly" fail
• add an option to let the user decide between the above behaviours
• else?