Security analysis functional logs #576
Conversation
Signed-off-by: Geoffroy Jamgotchian <geoffroy.jamgotchian@gmail.com>
Signed-off-by: Geoffroy Jamgotchian <geoffroy.jamgotchian@gmail.com>
Signed-off-by: Geoffroy Jamgotchian <geoffroy.jamgotchian@gmail.com>
| Network has 4 buses and 4 branches | ||
| Network balance: active generation=607.0 MW, active load=600.0 MW, reactive generation=0.0 MVar, reactive load=200.0 MVar | ||
| + Pre-contingency simulation | ||
| AC load flow complete with NR status 'CONVERGED' |
Signed-off-by: Geoffroy Jamgotchian <geoffroy.jamgotchian@gmail.com>
| AC load flow complete with NR status 'CONVERGED' | ||
| + Outer loop Distributed slack on generation | ||
| Iteration 0: failed to distribute slack bus active power mismatch, -1.4404045651219555 MW remains | ||
| + Outer loop Reactive limits |
There was a problem hiding this comment.
Maybe here another possible improvement: should we discard empty child reporters?
|
This is the very first time I try to use the reporter API in a real code. @flo-dup here is some issues to discuss that could improve the usability of the API: |
# Conflicts: # src/test/java/com/powsybl/openloadflow/sa/OpenSecurityAnalysisTest.java
|
Kudos, SonarCloud Quality Gate passed! |
| @@ -107,6 +107,10 @@ public Reporter getReporter() { | |||
| return reporter; | |||
| } | |||
|
|
|||
| public void setReporter(Reporter reporter) { | |||
There was a problem hiding this comment.
Here you're breaking in a way the way the reporter was at first designed... It sure is handy to put it in LfNetwork but it was first thought to be passed along all the methods and not retained, in the javadoc:
A reporter is not meant to be shared with other threads nor to be saved as a class parameter
There was a problem hiding this comment.
A LF network won't ever be shared between multiple threads as it is used as working data (including writing working data)
There was a problem hiding this comment.
it was first thought to be passed along all the methods
Sure not, this is a usage detail which has nothing to do with reporter API. The only thing that is clear is that it is not thread safe. From that it is up to each user to decide the best way to use it. In case of structural single thread part of the code it is ok to put it in the applicative thread context (and this is what LfNetwork is).
There was a problem hiding this comment.
Ok. I missed the thing that LfNetwork is (and will be) always working data and thus by nature will never be shared.
Please check if the PR fulfills these requirements (please use
'[x]'to check the checkboxes, or submit the PR and then click the checkboxes)Does this PR already have an issue describing the problem ? If so, link to this issue using
'#XXX'and skip the restNo
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Feature
What is the current behavior? (You can also link to an open issue here)
There is no functional logs for security analysis
What is the new behavior (if this is a feature change)?
Minimal functionnal logs have been added
Does this PR introduce a breaking change or deprecate an API? If yes, check the following:
Other information:
(if any of the questions/checkboxes don't apply, please delete them entirely)