[FEATURE] *Direct Handling of Electrical Parameters in JSON Interface*

[sudo-ac]

Description

This feature introduces the capability to directly handle electrical parameters (r, x, g, b) within the JSON interface of the Power Grid Model (PGM). This enhancement aims to eliminate the need for conversion between transformer parameters and electrical parameters, thereby improving accuracy and simplifying the data handling process.

Detailed Description

1. Current Process:

   • In CGMES data, only electrical parameters (r, x, g, b) are provided.
   • A CGMES-PGM converter has been created to transform these electrical parameters into transformer parameters.
   • The Power Grid Model then converts these transformer parameters back into electrical parameters for calculations.

2. Proposed Change:

   • Enable the JSON interface of the Power Grid Model to accept electrical parameters (r, x, g, b) directly.
   • Modify the internal data handling and processing functions to work with these electrical parameters without requiring intermediate conversion to transformer parameters.

3. Benefits:

   • Increases the accuracy of the data by avoiding multiple conversions.
   • Simplifies the data exchange process between CGMES and PGM.
   • Reduces computational overhead and potential sources of errors.

[mgovers]

Hi @sudo-ac , what would you propose the JSON interface would look like? Can you provide an example?

[sudo-ac]

Hi, Hi @mgovers, maybe like this (as an example):

"transformer": [ {"id": 21, "from_node": 1, "to_node": 3, "from_status": 1, "to_status": 1, "u1": 115000, "u2": 10500, "sn": 31500000, "winding_from": 1, "winding_to": 1, "clock": 0, "tap_side": 1, "tap_pos": 1, "tap_min": 1, "tap_max": 1, "tap_nom": 1, "tap_size": 0, "b": 0, "r": 2.099206, "x": 50.3372}, ], "three_winding_transformer": [ {"id": 25, "node_1": 10, "node_2": 6, "node_3": 9, "status_1": 1, "status_2": 1, "status_3": 1, "u1": 400000, "u2": 120000, "u3": 30000, "sn_1": 350000000, "sn_2": 350000000, "sn_3": 50000000, "winding_1": 1, "winding_2": 1, "winding_3": 1, "clock_12": 0, "clock_13": 0, "tap_side": 0, "tap_pos": 17, "tap_min": 1, "tap_max": 33, "tap_nom": 17, "tap_size": 4000, "b1": 0, "r1": 0.5942857143, "x1": 96.0051006, "b2": 0, "r2": 0.05348571429, "x2": -0.001121283618, "b3": 0, "r3": 0.0254571438, "x3": 1.259741 }, ],

[sudo-ac]

The electrical parameters in these examples refer to the high voltage side

[mgovers]

My expectation is that it will not be straightforward to add this without introducing a significant memory overhead unless we have the columnnar data format mentioned in #548 , but we will discuss this in the near future. c.c. @petersalemink95

[petersalemink95]

After discussing with the maintainers we concluded the following.

Instead of extending the transformer/3w_transformer we would want to make a new component: generic_branch (naming is pending), which would model branches as a Pi model, i.e. the user can specify:

• k: transformer ratio
• theta: angle shift
• Z_series (r/x)
• Y_shunt (g/b)

@sudo-ac would this work for you?

[petersalemink95]

After discussing with the maintainers we concluded the following.

Instead of extending the transformer/3w_transformer we would want to make a new component: generic_branch (naming is pending), which would model branches as a Pi model, i.e. the user can specify:

• k: transformer ratio
• theta: angle shift
• Z_series (r/x)
• Y_shunt (g/b)

@sudo-ac would this work for you?

Maybe trivial, but k should be a float. As requested by @bartgips in #540

[Jerry-Jinfeng-Guo]

@petersalemink95 I have some doubt about the transformer ratio. Do you mean to:

• A. have a continuous range for the ratio k, instead of a discrete one ...
• B. have a finite many floating ratios, instead of integer ones ... ... as is currently modeled in the tap changer optimizer implementation?

[sudo-ac]

Apologies for my late response. I find the proposal to add a general Pi model for the transformer to be good. I would suggest using the model from Matpower. See https://matpower.org/docs/MATPOWER-manual-8.0.pdf page 27ff. Yes, the ratio should be a float and the shift_angle should be a float as input values. However, Y_shunt and Z_series need to be passed as complex values, so I would prefer the values

• R_series (Ohm),
• X_series (Ohm),
• B_shunt (Siemens)
• (possibly also G_shunt in Siemens)

[Jerry-Jinfeng-Guo]

@sudo-ac Noted. Thanks for answering. In the current form of PGM tap changer modeling, we are basically doing enumeration to find the optimal tap, although it's less suboptimal than that in reality. If I understand your answer correcly, you are suggesting a continuous range for the ratio. If PGM were to solve for a real root (floating point) as requested here, we might need to revisit the core of our tap changer design and work out the mathematics. Eventually it will be a totally different way of optimization than what we are currently doing. Think for example a linear programming or even NR process for tap position.f

[sudo-ac]

As an input parameter, the tap can be defined as an integer value or enumeration. The background of the issue was the data import from CIM/CGMES files. In these files, the equivalent circuit elements for power transformers are directly defined (see here). To process CIM/CGMES data with PGM without further conversions, an adjustment of the interface would be required. A PI-branch, as proposed, would be conceivable for this. In your calculation algorithm, you will ultimately work with a complex transformation ratio, which is initially irrelevant for the interface. An adjustment of the algorithm for automatic tap calculation will not be affected by this. According to my understanding, the solutions for tap calculation always involve the additional voltage that results from the specified or unknown transformer tap and is a complex number (magnitude + angle). Once the additional voltage is determined by the solver, the tap must be calculated from it. Typically, the determined tap is a floating-point number that must be suitably rounded to an integer. But as mentioned, this requirement should not impact the internal calculations of the program.

[Jerry-Jinfeng-Guo]

@sudo-ac Thank you for the clarification. I think there is some mis-understanding from both sides:

According to my understanding, the solutions for tap calculation always involve the additional voltage that results from the specified or unknown transformer tap and is a complex number (magnitude + angle). Once the additional voltage is determined by the solver, the tap must be calculated from it.

The additional voltage is a result of changing to a different tap, not the other way around.

Typically, the determined tap is a floating-point number that must be suitably rounded to an integer.

The finite tap, which is now an integer, determines the floating point ratio, not the other way around.

But as mentioned, this requirement should not impact the internal calculations of the program.

If I now understand you correctly, you would want to have floating point ratios next to the integer based tap positions. The floating point ratios are finite and not continuous. Based on these two, the internal would not be affected indeed.

[petersalemink95]

Apologies for my late response. I find the proposal to add a general Pi model for the transformer to be good. I would suggest using the model from Matpower. See https://matpower.org/docs/MATPOWER-manual-8.0.pdf page 27ff. Yes, the ratio should be a float and the shift_angle should be a float as input values. However, Y_shunt and Z_series need to be passed as complex values, so I would prefer the values

• R_series (Ohm),
• X_series (Ohm),
• B_shunt (Siemens)
• (possibly also G_shunt in Siemens)

That was exactly what I had had in mind. I wrote is as Z_series (r/x), meaning the user would specify R and X, as you mention. My notation wasn't that clear, but good that we're on the same page!

[petersalemink95]

@sudo-ac I think @Jerry-Jinfeng-Guo means that the proposed generic_branch component would not fit the current automatic tap changer algorithm, due to having a floating ratio k. Would this be an issue for you?

On the long term planning we want to implement the transformer ratio as an unknown in the Newton-Raphson calculations, which will result in floating transformer ratio's. Most of the mathematics are already worked out, but the actual implementation requires some more discussions and is not yet prioritized/planned.

[sudo-ac]

Thank you very much for the lively discussion. As mentioned, the algorithm or the method for the transformer tap calculation is a problem separate from this use case. For me, it would be important to work directly with the electrical parameters instead of the short-circuit and no-load test parameters. For the transformer taps, the existing format can be used (i.e., maximum tap, minimum tap, current tap, voltage change per tap, etc.).

[petersalemink95]

In order to add a new component to Power Grid Model the following steps need to be taken:

• [ ] Check if the available input/update/output data suffices (check power-grid-model/power_grid_model_c/power_grid_model/include/power_grid_model/auxiliary/ input.hpp / update.hpp / output.hpp or in the documentation directly)
• [ ] If not, add the new data format to code_generation/data/attribute_classes/ input.json / update.json / output.json + run code_generation/code_gen.py
• [ ] Create a new component in a new power-grid-model/power_grid_model_c/power_grid_model/include/power_grid_model/component/[component].hpp file that at least inherits from Base, but in this case GenericBranch should inherit from Branch
• [ ] If necessary: add new enums or exceptions
• [ ] Create the necessary unit tests in power-grid-model/tests/cpp_unit_tests/test_[component].cpp
• [ ] Add the test_[component].cpp to power-grid-model/tests/cpp_unit_tests/CMakeLists.txt
• [ ] Add component to power_grid_model_c/power_grid_model/include/power_grid_model/all_components.hpp
• [ ] Not necessary for this component (If necessary update main_core/topology.hpp / input.hpp / output.hpp / update.hpp)
• [ ] Add component to code_generation/data/dataset_class_maps/dataset_definitions.json + re-run code_generation/code_gen.py
• [ ] Add validation test cases to tests/data
• [ ] Update input/update data validator for the new component: src/power_grid_model/validation/validation.py + add corresponding tests

Note: the order is recommended, but not necessary