Skip to content
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

Merged
merged 13 commits into from
Mar 24, 2020
Merged

Introduction of non linear shunt compensators #1202

merged 13 commits into from
Mar 24, 2020

Conversation

miovd
Copy link
Contributor

@miovd miovd commented Mar 4, 2020

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 ?
fix #900
fix #87

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

  • 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:
This PR only deals with the change of API. XIIDM serialization and deserialization will be done in another PR.

@miovd miovd added the Breaking Change API is broken label Mar 4, 2020
@miovd miovd added this to PR in progress in Evolutions IIDM via automation Mar 4, 2020
@miovd miovd changed the base branch from master to evolution_xiidm/1.2 March 4, 2020 08:06
@miovd miovd changed the base branch from evolution_xiidm/1.2 to master March 4, 2020 08:08
@miovd miovd force-pushed the new_shunt_api branch 3 times, most recently from dca9f3a to 8a332a1 Compare March 4, 2020 14:50
@miovd miovd changed the title [WIP] Introduction of non linear shunt compensators Introduction of non linear shunt compensators Mar 4, 2020
@miovd miovd requested a review from mathbagu March 4, 2020 15:03
Copy link
Contributor

@mathbagu mathbagu left a 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


ShuntCompensatorAdder setMaximumSectionCount(int maximumSectionCount);
ShuntCompensatorNonLinearModelAdder newNonLinearModel();
Copy link
Contributor

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);

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?

Copy link
Contributor Author

@miovd miovd Mar 9, 2020

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".

Copy link
Contributor Author

@miovd miovd Mar 9, 2020

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);
}
Copy link
Contributor

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

Copy link
Contributor Author

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).

Copy link
Contributor Author

@miovd miovd Mar 9, 2020

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?

ValidationUtil.checkSectionNumber(ShuntCompensatorAdderImpl.this, sectionNum);
if (sections.containsKey(sectionNum)) {
throw new ValidationException(ShuntCompensatorAdderImpl.this, "a section is already defined at this number");
}
Copy link
Contributor

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

Copy link
Contributor Author

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.


<M extends ShuntCompensatorModel> M getModel(Class<M> modelType);

void setShuntCompensator(ShuntCompensatorImpl shuntCompensator);
Copy link
Contributor

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comment above

Copy link
Contributor

@mathbagu mathbagu left a 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()
Copy link
Contributor

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?

Copy link
Contributor Author

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?

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.

Copy link
Contributor Author

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...

@miovd
Copy link
Contributor Author

miovd commented Mar 18, 2020

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?

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>
Signed-off-by: RALAMBOTIANA MIORA <miora.ralambotiana@rte-france.com>
Signed-off-by: RALAMBOTIANA MIORA <miora.ralambotiana@rte-france.com>
Copy link

@agnesLeroy agnesLeroy left a 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

@sonarcloud
Copy link

sonarcloud bot commented Mar 24, 2020

Kudos, SonarCloud Quality Gate passed!

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities (and Security Hotspot 0 Security Hotspots to review)
Code Smell A 0 Code Smells

86.5% 86.5% Coverage
0.0% 0.0% Duplication

@miovd miovd merged commit 7e9d21f into master Mar 24, 2020
Evolutions IIDM automation moved this from PR in progress to Merged PR Mar 24, 2020
@miovd miovd deleted the new_shunt_api branch March 24, 2020 16:55
miovd added a commit that referenced this pull request Apr 20, 2020
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
@miovd miovd mentioned this pull request Apr 20, 2020
4 tasks
miovd added a commit that referenced this pull request Apr 20, 2020
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
miovd added a commit that referenced this pull request Apr 21, 2020
miovd added a commit that referenced this pull request Jun 11, 2020
miovd added a commit that referenced this pull request Jun 12, 2020
miovd added a commit that referenced this pull request Jun 12, 2020
miovd added a commit that referenced this pull request Jun 24, 2020
This reverts commit f60b5da.

Signed-off-by: RALAMBOTIANA MIORA <miora.ralambotiana@rte-france.com>
miovd added a commit that referenced this pull request Jun 25, 2020
This reverts commit f60b5da.

Signed-off-by: RALAMBOTIANA MIORA <miora.ralambotiana@rte-france.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Evolutions IIDM
  
Merged PR
Development

Successfully merging this pull request may close these issues.

Change of Shunt Compensator IIDM model Add a gPerSection parameter in the ShuntCompensator class
3 participants