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

[IrenaDk]

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.

[mgovers]

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?

[IrenaDk]

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

[mgovers]

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?

[nitbharambe]

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.

[mgovers]

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?

[petersalemink95]

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.

[IrenaDk]

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.

[mgovers]

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?

[petersalemink95]

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.

[petersalemink95]

@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

[IrenaDk]

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.

[figueroa1395]

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

[petersalemink95]

@figueroa1395 yes, good idea; go ahead :)

[figueroa1395]

Closing this issue to to migration to the relevant repo: https://github.com/PowerGridModel/power-grid-model-ds/issues/18 @IrenaDk