You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
For most modelers, data from timeseries will come in natural units, and it's common than different weather years have different maximum values. Since PSI requires the timeseries data to be normalized by the scaling factor, it requires the user to update his static field of the generator with the maximum value of that timeseries (in natural units), since there is an upper bound on the variable associated with that number, so no normalized timeseries value greater than 1.0 will be in effect.
This is a two-fold problem. First, it requires manipulation to normalize natural units. Second, it requires to be sure that no number is larger than 1.0 after normalization.
Describe the solution you'd like
A solution for most modelers would be to allow the users to use natural units in their time series, without scaling factor, and create the constraints based on the natural unit number (and probably normalize internally by the system base), ignoring any hard upper bound on the variable.
Describe alternatives you've considered
Currently, the approach is to have a script that re-updates the rating field of RenewableDispatch of every unit based on the specific time series that want to be used. This also includes normalizing the data that comes in natural units.
Additional context
Natural units data is the most common approach for modelers. Currently, in PowerSimulations, we are not super clear that the timeseries data need to be normalized. If we add data in natural units without scaling_factor_multiplier it will be scaled anyways by the rating field for renewables.
Alternatively, we need a proper explanation/tutorial on the future documentation that clearly states that the time series data must be normalized by the rating number, and it does not accept normalized values larger than 1.0.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
For most modelers, data from timeseries will come in natural units, and it's common than different weather years have different maximum values. Since PSI requires the timeseries data to be normalized by the scaling factor, it requires the user to update his static field of the generator with the maximum value of that timeseries (in natural units), since there is an upper bound on the variable associated with that number, so no normalized timeseries value greater than 1.0 will be in effect.
This is a two-fold problem. First, it requires manipulation to normalize natural units. Second, it requires to be sure that no number is larger than 1.0 after normalization.
Describe the solution you'd like
A solution for most modelers would be to allow the users to use natural units in their time series, without scaling factor, and create the constraints based on the natural unit number (and probably normalize internally by the system base), ignoring any hard upper bound on the variable.
Describe alternatives you've considered
Currently, the approach is to have a script that re-updates the rating field of
RenewableDispatch
of every unit based on the specific time series that want to be used. This also includes normalizing the data that comes in natural units.Additional context
Natural units data is the most common approach for modelers. Currently, in PowerSimulations, we are not super clear that the timeseries data need to be normalized. If we add data in natural units without
scaling_factor_multiplier
it will be scaled anyways by therating
field for renewables.Alternatively, we need a proper explanation/tutorial on the future documentation that clearly states that the time series data must be normalized by the rating number, and it does not accept normalized values larger than 1.0.
The text was updated successfully, but these errors were encountered: