1. Powsybl-Tsc
  2. Topics

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

VEDELAGO 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

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

MURGEY Sebastien
 

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

BAGUE Mathieu
 

Hi Sebastien, all,

When Miora and I thought to the backward compatibility, we considered an architecture with 3 systems that exchange networks, but with a cyclic dependency. How do you update IIDM API (or XML converter implementation) in that case? You have to be able to update each component independently but with a strong bond to the IIDM format, you cannot and it will be necessary to update all components in the same time. I think the problem also occurs if the networks are stored in a shared database.

Best,
Mathieu

MURGEY Sebastien
 

Hi all,

On my side, I do not think the benefits of being able to do that kind of backward conversion are worth the complexity of the associated development. I do not have any critical use case for this feature.

In case we decide to do that development, I agree with the proposition.

Sébastien

VEDELAGO Miora
 

Hi all,


As you may know, we are currently working on the versionning of XIIDM.


In this context, the main question we have is: do we need to handle the serialization of different versions? At first, we wanted to be able to read/validate older versions but only write in the latest (i.e. current) version. However, this will bring a lot of restrictions in processing XIIDM files. Should we allow to serialize in older versions?


If the answer is yes, here are our proposition:

  • Handling of XIIDM breaking changes
During export, the responsability to check compatibility between the version the user wants to write in and the network itself (i.e. to check if every component of the network can be serialized in the given version) is on the serializers of the network components.
    • New equipments:
If a new equipment is added in version N, the user will only be able to serialize it in version N and newer (N+1, N+2...). If they try to serialize a network containing this equipment in older versions, an exception will be thrown by the equipment's serializer.
    • New attributes
      • optional:
If a new optional attribute is added to an equipment in version N, this equipment will be serializable in older versions (N-1, N-2...) if and only if this attribute has its default value. If its value is not the default value, an exception will be thrown by the equipment's serializer if serialization in older versions is attempted.
      • required:
If a new required attribute is added to an equipment in version N, an exception will be thrown by the equipment's serializer if serialization in older versions is attempted.

  • Handling of extensions versionning:
Some extensions are dependent on XIIDM (e.g. CurrentLimitsPerSeason depends on CurrentLimits modelisation in XIIDM). Hence, extensions should be versionned as well.

Some specific examples:
  • Changing of attributes name for steps: the attributes names will depend on the version the file is imported/exported
  • Addition of new attributes for shunt regulation
    • During import of 1.0 XIIDM files containing shunts, shunts will be considered as not regulating
    • During export as an 1.0 XIIDM file of a network, if the network only contains not-regulating shunts, it will be exported with the old modeling, else (if the network contains regulating shunts), it will throw an exception
  • New modeling to discriminate linear and non-linear shunts
    • During import of 1.0 XIIDM files containing shunts, shunts will be considered as linear
    • During export as an 1.0 XIIDM file of a network, if the network only contains linear shunts, it will be exported with the old modeling, else (if the network contains non linear shunts), it will throw an exception
  • Modeling changes for current limits: it will be considered as an extension
    • During import of 1.0 XIIDM file containing current limits, we will read them and import them as the new extension of the network
    • During export as an 1.0 XIIDM file, current limits will be serialized as they were in XIIDM 1.0 and/or (?) as an CurrentLimits extensions compatible with XIIDM 1.0 (todo)
  • Introduction of apparent power limits
    • If we model them as extensions, there will be no major compatibility issues
    • Else, it will mean creating a new field which cannot be serialized as XIIDM 1.0 and will throw an exception if it is attempted
Is it clear for you? Do you think writing in older versions should be an implemented feature? If you do, do you agree with our propositions? Have you something to add to them? If you don't, how should we handle old versions files in your opinion? Don't hesitate to describe specific use cases to press your point.


Miora RALAMBOTIANA
CHARGE DE PROJETS MAINTENANCE EXPLOITATION SI
PES - Direction Système d'information et Télécom - Département Développement Logiciel - Système électrique
miora.ralambotiana@...
rte-france.com 


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

1 - 7 of 7