Fix generator targetP update in AC-DC networks

[bperr]

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)
• A PR or issue has been opened in all impacted repositories (if any)

Does this PR already have an issue describing the problem?

No

What kind of change does this PR introduce?

Bug fix

What is the current behavior?

For a load flow with an AC-DC network, several LfNetwork are created with their components (LfBus, LfBranch, etc...) and then copied into one unique LfAcDcNetwork. This network is the one used in for load flow computation.
However the elements (i.e. LfBus) inside have a method getNetwork() which returns their original LfNetwork (i.e. not the LfAcDcNetwork).

This may cause non convergence of the load flow.
Indeed, in the DistributedSlackOuterLoop, the targetP attribute of genererators/loads may be modified. The following lines in setTargetP() method allows to notify the AcTargetVector that is must be updated at the beginning of the next Newtown-Raphson iteration.

for (LfNetworkListener listener : bus.getNetwork().getListeners()) {
    listener.onGenerationActivePowerTargetChange(this, oldTargetP, targetP);
}

However, the LfNetwork returned by bus.getNetwork() is as mentioned the original LfNetwork of the LfBus, which has no listeners (they are stored in the LfAcDcNetwork).
Therefore, the AcTargetVector is never notified that it must be updated and the load flow does not converge.

What is the new behavior (if this is a feature change)?

The correction proposed here consist in adding the listerners of the LfAcDcNetwork to the LfNetwork objects stored inside it. Thus, a LfBus getNetwork() method still returns the original LfNetwork, but it has access to the listeners added to the LfAcDcNetwork

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

• Yes
• No

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

Other information:

Two others options are possible:

• During the creation of the LfAcDcNetwork modify the network attribute of all elements (LfBus, LfBranch, etc...) so that getNetwork() returns the LfAcDcNetworkobject.
  This imply adding a setNetwork()method to the LfElement interface which might have larger consequences
• Refactor the creation of LfAcDcNetwork object to add direclty the elements inside it (do not create any LfNetwork beforehand. This require more development and might complexify the management of several synchronous components and DC components in the same object.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud