CGMES export bugs

[annetill]

Describe the current behavior

• If reactive capability curve present, no need of minQ and maxQ.
• Missing AcLineSegment gch: maybe because there are equal to zero (we have this condition in the code).
• Missing FossilFuel and HydroPowerPlant.
• TapChangerControl missing (phase control and voltage control).
• SynchronousMachine changes operatingMode in SSH even though the injection is 0. This is not that relevant unless the machine has control enabled.

To be continued.

Describe the expected behavior

No response

Describe the steps

No response

Environment

No response

Relevant Log Output

No response

Extra Information

No response

[marqueslanauja]

minQ and maxQ are required in ExternalNetworkInjection and are optional in SynchronousMachine and EquivalentInjection. In concordance with specifications, if a reactive capability curve is present, any provided minQ / maxQ limit attributes shall be ignored. In my opinion, it is not a problem to always export minQ and maxQ.

gch is optional and it is considered zero if it is not present. In my opinion, it is ok not to export it when is zero.

I will fix the rest of the issues in separated PRs. I will start with the TapChangerControl issue.

[zamarrenolm]

About preserving FossilFuel information:

We plan to store (in a property) only the FossilFuel type (coal, oil, gas, ...), that is the only attribute visible through the EQ profile. The generic CIM definition, and other ENTSO-E profiles related to market and transparency, have other detailed attributes (cost, dispatch cost, handling cost, efficiency factor, heat content, mixture, ...). We assume we won't need to keep these attributes in IIDM in the near future.

[zamarrenolm]

About preserving HydroPowerPlant information:

We plan to store (in a property) only the storage type of hydro power plant (run of river, pumped storage, storage).

[geofjamg]

Using property is very weak, we should think about enriching the generator to have something better than just energy source with just a few values

[zamarrenolm]

Both FossilFuel and HydroPowerPlant characteristics are defined in CGMES using independent objects associated with the generating unit. We assume we do not need to preserve the identifiers of these objects, to reduce the amount of data attached to the IIDM Network. This means that, when re-exported, the relationship between synchronous machines and their extended attributes will be re-created through new identifiers.

For the use-case that we want to support, is this valid ?

[zamarrenolm]

Using property is very weak, we should think about enriching the generator to have something better than just energy source with just a few values

We defaulted to properties because this information is not required for the kind of analysis that PowSyBl is performing now, but we are not aware of the specific use-case where it is needed. Are there more details on this ? Why is relevant to keep this information through PowSyBl ?

[zamarrenolm]

Also, before deciding how to store this data in IIDM, we have to know if we need to keep track of the CGMES identifiers involved: a generating unit may have multiple fossil fuel type associations, and an hydro generating unit has its kind defined through an association to a hydro power plant object.

Maybe instead of augmenting the model for generators we should consider an extension.

[annetill]

About preserving FossilFuel information:

We plan to store (in a property) only the FossilFuel type (coal, oil, gas, ...), that is the only attribute visible through the EQ profile. The generic CIM definition, and other ENTSO-E profiles related to market and transparency, have other detailed attributes (cost, dispatch cost, handling cost, efficiency factor, heat content, mixture, ...). We assume we won't need to keep these attributes in IIDM in the near future.

Let's look at generatorStartup extension for market related information. Not in the near future... and I don't think that the "type" coal, oil and gas has to be stored in IIDM, even as property.

[annetill]

About preserving HydroPowerPlant information:

We plan to store (in a property) only the storage type of hydro power plant (run of river, pumped storage, storage).

Is it needed?

[annetill]

I agree with @geofjamg, we have to increase enum EnergySource. We need:

• Type HYDRO has 2 subtypes HydroPowerPlant and HydroPump; the information is really interested to store in IIDM because if indicates if a generator is consuming power (and it is not an error of data).
• Type ThermalGeneratingUnit has a subtype FossilFuel. I don't know if it is really an issue...

Can we put in this reflexion what is called generator enstoe category?

[zamarrenolm]

About preserving HydroPowerPlant information: We plan to store (in a property) only the storage type of hydro power plant (run of river, pumped storage, storage).

Is it needed?

It is needed if we want to preserve the original CGMES information in IIDM. It also contains "hints" about the behaviour of the plant (pumpedStorage is a valid kind of plant). Maybe we do not need to check for class HydroPump, just the type of hydro plant, depending on the checks we want to perform ...

[nemanja-st]

Hello,

In general, if we want to keep the information for round trip import-export, it can be modeled as a named property, if it's not going to be used in powsybl, or as extension of IIDM model.

Regarding Hydro discussion:

graph LR;
SynchronousMachine-->HydroGeneratingUnit-->HydroPowerPlant;
HydroPump-->SynchronousMachine;
HydroPump-->HydroPowerPlant;

• HydroPump: SynchonousMachine.kind provides information if the machine is generator, motor... HydroPump should be applicable to motor only, so this can cause a collision during import depending on which object/attribute is used to determine the type. As suggested previously, HydroPump is an object in CGMES with an ID so the information is lost if it's not kept.
  • Reasons to keep: Round trip CGMES EQ import-export in order to preserve model information.
• HydroGeneratingUnit.energyConversionCapability: additional attribute in CGMES which indicates generator or pumpAndGenerator, it can also cause a collision during import if SynchronousMachine.kind does not correspond (QoCDC currently allows one RotatingMachine per GeneratingUnit in GeneratingUnitSM rule).
  • Reasons to keep: Round trip CGMES EQ import-export in order to preserve model information.
• HydroPowerPlant.hydroPlantStorageType: specifies the type of hydro plant runOfRiver, pumpedStorage, storage.
  • Reasons to keep: Mandatory attribute, Round trip CGMES EQ import-export in order to preserve model information (HydroPowerPlant is an object with ID), CC, CSA, Adequacy, Long Term Planning, etc... calculation since type of power plant might be important.