-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduction of non linear shunt compensators #1202
Conversation
dca9f3a
to
8a332a1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will redo a complete review soon
iidm/iidm-impl/src/main/java/com/powsybl/iidm/network/impl/ShuntCompensatorLinearModelImpl.java
Show resolved
Hide resolved
...cripting/src/main/groovy/com/powsybl/iidm/network/scripting/ShuntCompensatorExtension.groovy
Outdated
Show resolved
Hide resolved
iidm/iidm-api/src/main/java/com/powsybl/iidm/network/ShuntCompensatorModel.java
Show resolved
Hide resolved
iidm/iidm-api/src/main/java/com/powsybl/iidm/network/ShuntCompensatorNonLinearModel.java
Show resolved
Hide resolved
ampl-converter/src/main/java/com/powsybl/ampl/converter/AmplNetworkWriter.java
Outdated
Show resolved
Hide resolved
iidm/iidm-api/src/main/java/com/powsybl/iidm/network/ShuntCompensator.java
Show resolved
Hide resolved
|
||
ShuntCompensatorAdder setMaximumSectionCount(int maximumSectionCount); | ||
ShuntCompensatorNonLinearModelAdder newNonLinearModel(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be discussed: should we design the API like we did for the extension:
newModel(ShuntCompensatorLinearModelAdder.class);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think that choosing the same design here could improve the user experience?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is mostly to keep an easy way to add a custom model... but doesn't it make the API more complex? (as in, it may make it more difficult to understand what "model" refers to)? Maybe we should keep newLinearModel
, newNonLinearModel
and add newModel(...)
?
EDIT I am not sure that the denomination "shunt model" is standard. In CGMES for example, "shunt models" are not mentioned, the concepts are directly "non linear shunt" and "linear shunt".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After some thinking, I do not think it is a good idea to implement a newModel(...)
method, I am not sure we want to extend the possibilities of shunt models. It is different from extensions where this is the purpose of the API.
@Override | ||
public void setShuntCompensator(ShuntCompensatorImpl shuntCompensator) { | ||
this.shuntCompensator = Objects.requireNonNull(shuntCompensator); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about this: the model should be attached to the ShuntCompensator in the constructor, like it's done for tap changer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't work as tapchangers are created when the transformer is already built, which is not the case for models (they are created at the same time since it does not make sense to create a shunt without model).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can check however that the shunt is only defined once. Is it enough for you?
iidm/iidm-impl/src/main/java/com/powsybl/iidm/network/impl/AbstractShuntCompensatorModel.java
Outdated
Show resolved
Hide resolved
iidm/iidm-impl/src/main/java/com/powsybl/iidm/network/impl/AbstractShuntCompensatorModel.java
Outdated
Show resolved
Hide resolved
ValidationUtil.checkSectionNumber(ShuntCompensatorAdderImpl.this, sectionNum); | ||
if (sections.containsKey(sectionNum)) { | ||
throw new ValidationException(ShuntCompensatorAdderImpl.this, "a section is already defined at this number"); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's strange to not replace the section whereas it's totally allowed later? It's not really important but it's questioning me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if choosing to replace a section in a built model and creating the same section twice while building the whole model is the same thing? I think the second case is more probably an error but I may be mistaken. We can delete this validation condition and consider it is allowed to rewrite a section while building the model.
iidm/iidm-impl/src/main/java/com/powsybl/iidm/network/impl/ShuntCompensatorAdderImpl.java
Outdated
Show resolved
Hide resolved
|
||
<M extends ShuntCompensatorModel> M getModel(Class<M> modelType); | ||
|
||
void setShuntCompensator(ShuntCompensatorImpl shuntCompensator); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure this method should be available
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comment above
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please check again if everything in the merging view is implemented? I think we should have adapter for the model since you have a backward link. Is it required to have this link?
static double getMaximumB(ShuntCompensator self) { | ||
if (ShuntCompensatorModelType.LINEAR == self.getModelType()) { | ||
// forward bPerSection * maximumSectionCount for linear shunts | ||
return self.getModel(ShuntCompensatorLinearModel.class).getbPerSection() * self.getModel().getMaximumSectionCount() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it a bad idea to keep the getMaximumB in all shunt model and provide a convenient function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue is that we used to have getMaximumB
for linear shunts which returned the susceptance of the highest section (not the actual maximum susceptance) so if we put it in the shunt model, we would have several possibilities:
- either keep this behavior for linear shunt but for non linear shunt it returns the actual maximum susceptance
- or change the behavior and in any case, it returns the actual maximum susceptance
- or keep this behavior for linear shunt and for non linear shunt it returns the susceptance of the highest section too
In any case, I find it too confusing... What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My opinion would be that it should return the actual maximum susceptance regardless of the model, as indicated by its name. Maybe another function could return the susceptance of the highest section for linear shunts if needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with you, but isn't it deceitful to change the behavior of the method? Or I guess we could say that the previous one was buggy as when it was first implemented, it didn't take into account the case where the susceptance per section was negative...
You're right... I will think about it but I think I will have to implement an adapter for the shunt models. |
Signed-off-by: RALAMBOTIANA MIORA <miora.ralambotiana@rte-france.com>
Signed-off-by: RALAMBOTIANA MIORA <miora.ralambotiana@rte-france.com>
Signed-off-by: RALAMBOTIANA MIORA <miora.ralambotiana@rte-france.com>
Signed-off-by: RALAMBOTIANA MIORA <miora.ralambotiana@rte-france.com>
Signed-off-by: RALAMBOTIANA MIORA <miora.ralambotiana@rte-france.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MioRtia thanks for your changes, it looks good to me now
Kudos, SonarCloud Quality Gate passed!
|
This reverts commit 7e9d21f. Signed-off-by: RALAMBOTIANA MIORA <miora.ralambotiana@rte-france.com> # Conflicts: # iidm/iidm-tck/src/test/java/com/powsybl/iidm/network/tck/AbstractShuntCompensatorTest.java
This reverts commit 7e9d21f. Signed-off-by: RALAMBOTIANA MIORA <miora.ralambotiana@rte-france.com> # Conflicts: # iidm/iidm-tck/src/test/java/com/powsybl/iidm/network/tck/AbstractShuntCompensatorTest.java
This reverts commit f60b5da. Signed-off-by: RALAMBOTIANA MIORA <miora.ralambotiana@rte-france.com>
This reverts commit f60b5da. Signed-off-by: RALAMBOTIANA MIORA <miora.ralambotiana@rte-france.com>
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 ?
fix #900
fix #87
Does this PR introduce a breaking change or deprecate an API?
Yes.
Other information:
This PR only deals with the change of API. XIIDM serialization and deserialization will be done in another PR.