[FEATURE] Add P and Q min and max to LoadGenerator

[figueroa1395]

This issue with its discussion was migrated from PowerGridModel/power-grid-model#639.

Original issue description:

The LoadGenerator types: sym_load, sym_gen, asym_load, and asym_gen, have as input p_specified and q_specified which are RealValueInput, so they can take both positive and negative values.

My proposal is to add attributes 'p_min', 'p_max', 'q_min', 'q_max' to the LoadGenerators, that can be used to indicate what are the minimum and maximum values that can be taken.

For example, now a sym_load only has p_specified, which is its nominal(maximum)power. But a sym_load can take a negative value as well as a result of a calculation in p. However, since no lower/minimum is specified, it cannot be compared or checked after PGM runs a calculation to see if the result p is within the expected bounds.

As default the following is proposed:
sym_load: p_min = 0, p_max= p_specified, equivalent for q and reference direction load.
sym_gen: p_min = 0, p_max= p_specified, equivalent for q and reference direction generation.

Comment 1:

Hi Irena, what would the desired behavior of the Power Grid Model be if the system goes out of the boundaries set by p_min and p_max?

• Should an error be thrown?
• Should there be an output attribute that specifies whether it went out of range?
• Should the values be enforced within the specified range?

Comment 2:

• I would say that a warning rather than an error should be thrown if the values is out of the boundaries. For example, when a state estimation result is out of the boundaries, or when an input/update for p is out of the boundaries.
• I don't think it is necessary as the users themselves can compare that.
• I don't think so. It is possible, but it may be too restrictive. Hence a simple warning when going out of the boundaries is sufficient.

Comment 3:

Our PGM core currently does not support raising warnings. In what way would you prefer to see the diagnostics?

• would you prefer that this is handled on the python side?
• would you prefer we expose warning-like diagnostics? if so, in which way would you prefer that?

Comment 4:

This would be a request for an input validation utility. A diagnostic function like you mention @mgovers .
Similar to valid_input_data. But more restrictive on the inputs.
We can also think of an output diagnostic utility in future.

Comment 5:

This would be a request for an input validation utility. A diagnostic function like you mention @mgovers . Similar to valid_input_data. But more restrictive on the inputs. We can also think of an output diagnostic utility in future.

this is about output diagnostics, right?

Comment 6:

Hi Irena, p_specified is only used in power flow calculations and is completely ignored (and not required to provide) for state estimation. In general, PGM is set up as a calculation engine and the business logic, e.g. checking whether values stay within bounds, lies at the end users.

Since you also mention "I don't think it is necessary as the users themselves can compare that [if it's out of range]" I'm not sure if I see the use case of providing a min and max value in PGM. In that case it would only be so the data is present, but it's not used within PGM itself. Please let me know if I'm looking at this from the wrong perspective.

Comment 7:

This can be used for input validation, as Nitish and Martijn commented. If there are no plans to do output diagnostics in the future, then the benefit of having the min and max value in PGM would be, as you said, so that the data is present. The, it would be easier for the users to debug, especially if a warning for out-of-bounds is thrown. So you are looking at it from the correct perspective.

Comment 8:

is this similar to how we currently also have i_n for lines, which can be used to have a normalized view on the output current, which makes diagnostics easier for the user?

Comment 9:

is this similar to how we currently also have i_n for lines, which can be used to have a normalized view on the output current, which makes diagnostics easier for the user?

No, i_n gives the nominal current of the line, similarly as s_n gives the nominal power of the transformer. This is used to determine the loading. Limits are company specific and thus referred to as "business logic", e.g. some companies might think lines can always be loaded 110%, where others might not want to exceed the nominal values at all.

Comment 10:

@IrenaDk after discussion with the team we concluded that this would not fit within PGM itself. However, it would fit within the "data science toolkit" which is on the way of being open sourced. This repo will be more suitable to extend component attributes and include business logic.

We will migrate this issue once the new repo is available.
p.s. see: https://github.com/orgs/PowerGridModel/discussions/14

Comment 11:

Thanks a lot for the update Peter. I get the reasoning behind the decision. I understand and agree that it may be better to have it included in the data-science-toolkit. Thank you taking the responsibility to migrate the issue.

Comment 12:

@petersalemink95 Since pgm-ds is already an open source project, should we migrate this issue there and close it here?

Comment 13:

@figueroa1395 yes, good idea; go ahead :)

[vincentkoppen]

Thanks for referencing this issue here.
@jaapschoutenalliander en @Thijss curious what your thoughts are.

I'm not sure if I fully understand the feature request, so please let me know if I misunderstood.
This request seems to be for state estimation specifically.

So to implement it, this would come down to:

• Add support for calculate_state_estimation in PowerGridModelInterface similar way as calculate_power_flow
  I think this is a logical addition to the interface.
  • Results (such as your p) become available in your sym_load / sym_gen arrays if you want to, similar to: https://power-grid-model-ds.readthedocs.io/en/stable/quick_start.html#performing-loadflow-calculations
• Now the user can write the check on the array themself if they want to:

import numpy as np
from numpy.typing import NDArray

from power_grid_model_ds.arrays import SymLoadArray


class ExtendedSymLoadArray(SymLoadArray):
    p: NDArray[np.float64]
    q: NDArray[np.float64]
    p_min: NDArray[np.float64]
    p_max: NDArray[np.float64]
    q_min: NDArray[np.float64]
    q_max: NDArray[np.float64]

    _defaults = {
        "p_min": 0.0,
        "p_max": 100.0,
        "q_min": 0.0,
        "q_max": 100.0,
    }

    @property
    def within_boundaries(self):
        return (self.p_min <= self.p) & (self.p <= self.p_max) & (self.q_min <= self.q) & (self.q <= self.q_max)


array = ExtendedSymLoadArray.empty(2)
array.p = [10.0, 200.0]
array.q = [0.0, 0.0]

print(array)
print(f"Within boundaries: {array.within_boundaries}")

      id     |     node    | status | type | p_specified | q_specified |   p   |  q  | p_min | p_max | q_min | q_max 
 -2147483648 | -2147483648 |  -128  | -128 |     nan     |     nan     |  10.0 | 0.0 |  0.0  | 100.0 |  0.0  | 100.0 
 -2147483648 | -2147483648 |  -128  | -128 |     nan     |     nan     | 200.0 | 0.0 |  0.0  | 100.0 |  0.0  | 100.0 
Within boundaries: [ True False]

[Thijss]

I also think this is an excellent use case for an extension of the SymloadArray in your project.

Since this is a bit of a messy issue due to the migration, I've created a separate feature request to support calculate_state_estimation in #20