Fix DcValueVoltageInitializer

[geofjamg]

Please check if the PR fulfills these requirements (please use '[x]' to check the checkboxes, or submit the PR and then click the checkboxes)

• 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 ? If so, link to this issue using '#XXX' and skip the rest
No

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Bug fix

What is the current behavior? (You can also link to an open issue here)
There is too much hard coded parameters for the DC LF use for voltage angle init.

What is the new behavior (if this is a feature change)?
Only relevant parameters remains hard coded

Does this PR introduce a breaking change or deprecate an API? If yes, check the following:

• The Breaking Change or Deprecated label has been added
• The migration guide has been updated in the github wiki (What changes might users need to make in their application due to this PR?)

Other information:

(if any of the questions/checkboxes don't apply, please delete them entirely)

[geofjamg]

@annetill last commit fix the case_SyntheticUSA.mat divergence. It was because of generator active power target, not saved/restored by first DC LF

[annetill]

@annetill last commit fix the case_SyntheticUSA.mat divergence. It was because of generator active power target, not saved/restored by first DC LF

You mean that we have changed the targetP of generators without restoring it ? So it means that we have the same problem with loads in case of slack distribution on loads. So, I think that maybe the best fix is to use BusState as we do in security analysis (there is a dedicate method for active variables).

[geofjamg]

@annetill last commit fix the case_SyntheticUSA.mat divergence. It was because of generator active power target, not saved/restored by first DC LF

You mean that we have changed the targetP of generators without restoring it ? So it means that we have the same problem with loads in case of slack distribution on loads. So, I think that maybe the best fix is to use BusState as we do in security analysis (there is a dedicate method for active variables).

We cannot because BusState also save/restore voltage angle.

[annetill]

@annetill last commit fix the case_SyntheticUSA.mat divergence. It was because of generator active power target, not saved/restored by first DC LF

You mean that we have changed the targetP of generators without restoring it ? So it means that we have the same problem with loads in case of slack distribution on loads. So, I think that maybe the best fix is to use BusState as we do in security analysis (there is a dedicate method for active variables).

We cannot because BusState also save/restore voltage angle.

Yes I know, but we can maybe refactor that BusState for this prupose?

[geofjamg]

@annetill last commit fix the case_SyntheticUSA.mat divergence. It was because of generator active power target, not saved/restored by first DC LF

You mean that we have changed the targetP of generators without restoring it ? So it means that we have the same problem with loads in case of slack distribution on loads. So, I think that maybe the best fix is to use BusState as we do in security analysis (there is a dedicate method for active variables).

We cannot because BusState also save/restore voltage angle.

Yes I know, but we can maybe refactor that BusState for this prupose?

Done

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

97.0% Coverage
0.0% Duplication

[annetill]

Nice fix !