Date   
Release notes

RALAMBOTIANA Miora
 

Hi TSC members,

Some of you may have noticed that a draft of the release notes for the next release of powsybl-core (3.2.0) has been created on the release page of the repository.
Please update it when you are merging a PR on the repository, it will ease future releases' generation!

Thanks a lot.

Miora

2020 roadmap

TILLOY Anne
 

Hi TSC members,

 

The LF Energy asks me to have a roadmap for 2020 with the main features for PowSyBl organization. Please take a few minutes to complete the following file:

 

https://github.com/powsybl/.github/blob/master/ROADMAP.md

 

You can also send me an e-mail with the roadmap elements.

 

I also have to present in the next TAC (Technical Advisory Council, next Tuesday) our main goals. As an example, one of our goals is to have a CIM-CGMES based workflow that can import IGMs, merge them, make some modifications and export the updated European network in one or several CIM-CGMES files.

 

Thanks a lot.

 

Anne.



"Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message."

Re: IIDM Versionning - questions

JAMGOTCHIAN Geoffroy
 

Hi,

 

What was the initial issue? If it was to be able to generate old IIDM data for out dated applications (so not supporting last IIDM standard) it won’t work at all as XIIDM will be different/incompatible and not loadable.

 

Geoffroy

 

De : powsybl-tsc@... [mailto:powsybl-tsc@...] De la part de RALAMBOTIANA Miora via Lists.Lfenergy.Org
Envoyé : vendredi 10 janvier 2020 11:17
À : powsybl-tsc@...
Objet : Re: [powsybl-tsc] IIDM Versionning - questions

 

Hi,

Rather than throwing an exception when trying to serialize an IIDM network in a uncompatible previous version, it has been proposed to use network's extensions to serialize it as accurately as possible and keep new information in extensions (compatible with the previous version). I am not really sure about this workaround, what do you think?

Miora



"Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message."

Re: [IIDM] Regulations modelization

JAMGOTCHIAN Geoffroy
 

Hi,

 

It makes sense to me but I am not sure everything is ready on extension side  to support this kind of “critical” extension.

I am thinking in particular about the lack of adder support with extensions, the lack of API/impl decoupling.

Sure it is already the case  today, adding extension data is not as clear as base data for the previous reason

(like gen.addExtension(MyExt.class, new MyExt(gen,  … lots of param …), but I think before moving base data to extension we should rework on extension modelling in IIDM API.

We could get inspiration on how builder have been added in AFS keeping a good API/impl design.

 

Geoffroy

 

De : powsybl-tsc@... [mailto:powsybl-tsc@...] De la part de RALAMBOTIANA Miora via Lists.Lfenergy.Org
Envoyé : vendredi 10 janvier 2020 11:12
À : powsybl-tsc@...
Objet : [powsybl-tsc] [IIDM] Regulations modelization

 

Hi all,

We were thinking yesterday with Mathieu of modeling new regulation (shunt's regulation particularly) as extensions rather than attributes (by boolean attribute regulating, double attribute voltageSetpoint, etc.) from now on.

The pros were the following:

  • It would allow to harmonize regulations for equipment that regulates similarly
  • Regulations are not always mandatory during simulations (e.g. simple loadflows) where the point of IIDM core modeling was to be used in all kind of simulations

Eventually, we would also change existing regulation attributes to model them as extensions as well.
What do you think? Do you agree?

Miora



"Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message."

Re: IIDM Versionning - questions

RALAMBOTIANA Miora
 

Hi,

Rather than throwing an exception when trying to serialize an IIDM network in a uncompatible previous version, it has been proposed to use network's extensions to serialize it as accurately as possible and keep new information in extensions (compatible with the previous version). I am not really sure about this workaround, what do you think?

Miora

[IIDM] Regulations modelization

RALAMBOTIANA Miora
 

Hi all,

We were thinking yesterday with Mathieu of modeling new regulation (shunt's regulation particularly) as extensions rather than attributes (by boolean attribute regulating, double attribute voltageSetpoint, etc.) from now on.

The pros were the following:
  • It would allow to harmonize regulations for equipment that regulates similarly
  • Regulations are not always mandatory during simulations (e.g. simple loadflows) where the point of IIDM core modeling was to be used in all kind of simulations
Eventually, we would also change existing regulation attributes to model them as extensions as well.
What do you think? Do you agree?

Miora

Re: Creation of new repositories #poll

Luis María Zamarreño García
 

I see no problem in keeping the handling of "core" CGMES profiles (EQ, TP, SV) in powsybl-core, and the other profiles in repositories related to the functions for which they provide more specific data: information for drawing diagrams is not needed for building analysis tools for the network. CGMES tries to cover many different things, we do not have to keep them all in the same repository.

Re: Split powsybl-core repository

BAGUE Mathieu
 

I propose to add maintainers (you right, we have to!) once everyone agree the final proposal!

PS: Thanks for mentioning the typo, I fix it

Re: Split powsybl-core repository

MURGEY Sebastien
 

Hi,

I agree with this proposition. A good addition would be to define also the associated maintainers. I imagine that I will be a/the maintainer of powsybl-capacity-calculation (typo in your message :) ).
I just do not really know if it is a good thing to keep sensitivity calculation as part of "capacity calculation" domain, but as a first step, while it is not used by anyone else, why not.

Regards,
Sébastien

Split powsybl-core repository

BAGUE Mathieu
 
Edited

Hi all,
Geoffroy and I started a discussion about the content of powsybl-core and the opportunity to well separate this repository because:
- it is relatively big enough to be splitted
- modules are heterogeneous, and hard to maintain because functionnally too different

We want to share our proposal to discuss the best way to split powsybl-core:
  • powsybl-itools: this repository would contain the itools packager maven plugin, and maybe the powsybl-tools module
  • powsybl-commons: this repository would contain the common modules (commons, computation?, config)
  • powsybl-grid: this repository would contain IIDM modules (API, impl), and all the converters (UCTE, CGMES, iEEE). It's mainly a renaming of the current powsybl-core repository
  • powsybl-time-series: this repository would contain all modules relative to TS
  • powsybl-loadflow: this repository would contain the LF API and the OpenLF implementation
  • powsybl-security-analysis: this repository would contain the modules relative to SA (contingencies, security analysis, actions...). It could be better tested, if it depends on powsybl-loadflow repository because we coul use the OpenLF implementation. Not possible today, due to a cyclic dependency
  • powsybl-dynamic-simulation: this repository would contain the dynamic-simulation API and the dynawo integration
  • powsybl-capacity-calculation: this repository would contain the sensitivity calculation API and maybe the balance adjustment modules

Please, give us your feedback about this. I probably forgot some modules so don't hesitate to mention it. I will update this message.

Best,
Mathieu

Re: Creation of new repositories #poll

JAMGOTCHIAN Geoffroy
 

Hi,


We have designed additional profiles management in a very modular way (IIDM extensions + CGMES post processor plugin).

For th powsybl-cgmes-gl its contains not only the web service but also a Maven module that will be pusblished to Maven central containing IIDM extensions + CGMES post processor.

Same for DL profile in powsybl-single-line-diagram.

So with this kind of design it doesn't really matter to have everything in the same repo.

The way it is organized is not tech oriented but function oriented (network, geographical data, single line diagram) which seems to me a good idea.

Also we have to be aware that for DL profile is really hard to support (GL on the other hand is quite straightforward), and we need to have a deep understanding of everything regarding single line diagram mode/layout to be able to maintain it.
So I think it is a good idea to let it in single line diagram repo.


Geoffroy



De : powsybl-tsc@... <powsybl-tsc@...> de la part de BAGUE Mathieu via Lists.Lfenergy.Org <mathieu.bague=rte-france.com@...>
Envoyé : mercredi 8 janvier 2020 10:13
À : powsybl-tsc@...
Objet : Re: [powsybl-tsc] Creation of new repositories
 

Hi,

Just a question about CGMES GL: are we sure we want to put the code of each profile (GL, DL, DY...) in different repositories? Or should we create a more generic CGMES repository (or put everything in powsybl-core?)?
We will probably have profile used by two or more different features, then the code have no good reason to be in one or in the other repository... Maybe we can just keep this in mind, and if the situation occurs, take a decision.

Best,

Mathieu



"Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message."

Re: Creation of new repositories #poll

BAGUE Mathieu
 

Hi,

Just a question about CGMES GL: are we sure we want to put the code of each profile (GL, DL, DY...) in different repositories? Or should we create a more generic CGMES repository (or put everything in powsybl-core?)?
We will probably have profile used by two or more different features, then the code have no good reason to be in one or in the other repository... Maybe we can just keep this in mind, and if the situation occurs, take a decision.

Best,

Mathieu

Creation of new repositories #poll

JAMGOTCHIAN Geoffroy
 

Hi,

I need to create the following repositories:
 - powsybl-cgmes-gl: web service to support CGMES-GL profile features
 - powsybl-network-modification-server: web service to modify a persistent network.
 - powsybl-loadflow-server: web service to run a loaflow on a persistent network
 - powsybl-study-app: study application (front-end)
 - powsybl-parent: common Maven configuration
 - powsybl-deployment: deployment configuration for k8s, docker compose, etc

You can find additional infos about the microservices architecture in the doc: http://www.powsybl.org/docs/technical-documentation.html
Could you please validate the creation of these repos?

Best,
Geoffroy

Results

See Who Responded

Re: New repositories in powsybl organization #poll

JAMGOTCHIAN Geoffroy
 

I created a PR in the documentation, to add a technical documentation section, a micro-services architecture  diagram (and repo mapping) and a short description of each of the micro-service.

https://github.com/powsybl/powsybl.github.io/pull/105

Could you please review this PR?


Geoffroy



De : powsybl-tsc@... <powsybl-tsc@...> de la part de BAGUE Mathieu via Lists.Lfenergy.Org <mathieu.bague=rte-france.com@...>
Envoyé : vendredi 13 décembre 2019 16:15
À : powsybl-tsc@...
Objet : Re: [powsybl-tsc] New repositories in powsybl organization
 
I think we can also create a page on the website to describe, for each repository, which features it offers. With the multiplication of the repositories, we need to have somewhere a clear picture of what modules exist, and maybe the dependency between the modules. I will try to create this page.
@Geoffroy: could you complete this new page to describe/fix the description of the new repositories?


"Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message."

Re: New repositories in powsybl organization #poll

BAGUE Mathieu
 

I think we can also create a page on the website to describe, for each repository, which features it offers. With the multiplication of the repositories, we need to have somewhere a clear picture of what modules exist, and maybe the dependency between the modules. I will try to create this page.
@Geoffroy: could you complete this new page to describe/fix the description of the new repositories?

Re: New repositories in powsybl organization #poll

RALAMBOTIANA Miora
 

This is mainly to prevent TSC members (people responsible of the technical direction of powsybl) ignoring what the point is of some repositories - a situation that can happen when repositories are created during  night with no warning. Since we are only 8 members, if we agree that we need the majority to have consent, it means 4 votes which is not so much... If in the future we are more and/or it takes too much time to validate a change, we can rethink that, for now I don't think the constraint is very significant. It really doesn't need to be formal, it's just to keep TSC members informed with a minimum delay.
Updating MAINTAINERS file and sending an information email is really just to keep transparency with powsybl's contributors and users.

Re: New repositories in powsybl organization #poll

JAMGOTCHIAN Geoffroy
 

And also we should vote for any maven module, class, package and variable naming, right?

New repositories in powsybl organization #poll

RALAMBOTIANA Miora
 

Hi TSC members,

This is a reminder that to ensure transparency for everyone, anyone creating a new repository in the powsybl organization should:
  • submit a poll here (on powsybl-tsc) before creating it to make certain everyone in the TSC is aware and consents to the creation of the repository
  • update the MAINTAINERS file in the .github repository
  • send a message on powsybl-announce indicating the creation of the repository, its name and a small description of which purpose it serves

If you agree with this steps and to apply them in this situation, please vote Yes to this poll. If you don't, vote No and develop your point of view as answer.

Thank you and have a good day,
Miora Ralambotiana

Results

See Who Responded

Re: IIDM Versionning - questions

LECLERC Sylvain
 

Hi all,

 

1)      Unfortunately I think the use case is important.

If we don’t have this feature, if one application provides IIDM data to other applications and if that first application wants to use new features of powsybl (and hence a new IIDM format), it will have to wait for all client applications to have migrated to that version of powsybl and deployed a new version.

This may have strong impacts on deployment schedules in our IT systems, and does not seem acceptable.

 

2)      About the proposal, I am OK with most of it, but I would propose to relax the requirements on new attributes:

if a new attribute is not required by the version 1, I think in most cases it should not throw when serializing to that version, even if the attribute is required in version 2.

Maybe this should be decided on a case-by-case basis : for some new attributes, the network will still make sense without them, maybe with some adaptation (like transferring it to an older attributes), while for others it will not.

 

Best regards,

Sylvain

 

 

De : powsybl-tsc@... [mailto:powsybl-tsc@...] De la part de MURGEY Sebastien via Lists.Lfenergy.Org
Envoyé : mercredi 20 novembre 2019 09:11
À : powsybl-tsc@...
Objet : Re: [powsybl-tsc] IIDM Versionning - questions

 

I think there are organisational ways to solve this type of issues. However, I understand the use case shared.
It also largely depends on the rythm of breaking changes creation in IIDM. If every two months we have to align ourselves on our releases because of IIDM XML export breaking changes, this issue will be far more important than if it is only once a year...



"Ce message est destiné exclusivement aux personnes ou entités auxquelles il est adressé et peut contenir des informations privilégiées ou confidentielles. Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to which it is addressed and may contain information that is privileged or confidential. If you have received this communication by error, please notify us immediately by electronic mail, do not disclose it and delete the original message."

Re: Open discussion about powsybl-hpc, powsybl-afs and powsybl-gse

BAGUE Mathieu
 

Hi,

A summary, just to be sure I understand well the proposal:

powsybl-hpc
  • Review: Geoffroy (MPI), Sylvain (Slurm)
  • Release: Sylvain
powsybl-afs
  • Review: Paul, Geoffroy
  • Release: Paul (release notes), Mathieu/Miora (upload)
powsybl-gse
  • Review: Paul, Geoffroy
  • Release: Paul (release notes), Mathieu/Miora (upload)

About powsybl-afs and powsybl-gse repositories, the uploaders will be changed when a (new) commiter will uses these repositories.

Best,
Mathieu