Make ramp rate input flexible to other grids

[lanesmith]

🪲

• I have checked that this issue has not already been reported.

Bug summary

Currently, generator ramp rates provided in a grid's plant.csv file are overridden in REISE.jl's prepare.jl file, regardless of grid type, to equal a value according to a generator's capacity and fuel type (see here for the referenced code). This was originally implemented as a means to improve the ramp rate specifications for the generators in the TAMU U.S.A. grid. However, since we are trying to make the ecosystem more flexible to other grid types, we should make this TAMU-grid-specific adjustment only apply to the TAMU U.S.A. grid. Additionally, this adjustment probably is better suited for inclusion in PowerSimData than it is in REISE.jl.

[yixingxu]

• Agree with @lanesmith and @BainanXia . Ramp rate overwrite should be moved out of REISE.jl and included in PowerSimData . It should be only used for TAMU U.S.A grid.
• A ramp rate analysis of the most recent TAMU USA grid could inform us whether these data are reasonable. If they are, the ramp rate overwrite logic should not be applied to future TAMU USA grid scenario studies. The ramp rate overwrite logic is still needed to replicate previous scenarios.
• When the capacities of generators are scaled up or down, their ramp rate (in MW unit) should also be scaled up or down. This is a new logic needed, once the ramp rate overwrite logic is removed.

[lanesmith]

• When the capacities of generators are scaled up or down, their ramp rate (in MW unit) should also be scaled up or down. This is a new logic needed, once the ramp rate overwrite logic is removed.

I think this point is especially important. Thank you for bringing it up!

I would also like to mention that we will need to make sure that infinite ramp rates are indicated appropriately. Currently, generators with infinite ramp rates (e.g., wind, solar) have an input of 0 in plant.csv. This was remedied by the process mentioned above in prepare.jl, as all ramp rates were initially set to Inf and all generators with noninfinite ramp rates were subsequently updated. Do folks have a preference on how we would handle this? Initially, I'm thinking that we would keep the input of 0 in plant.csv and then just update that value to Inf in REISE.jl for all generators with provided ramp rates of 0. Since Inf is recognized as infinity in Julia but not Python, I'm not sure what that translation would look like going from .csv -> PowerSimData (in Python) -> .pkl file (for the forthcoming changes to pass Grid objects) -> REISE.jl (in Julia) if this were handled on the PowerSimData side or provided as an input in the plant.csv file.

[rouille]

I think we should define a set of default values in the powersimdata.network.constants.resource module as we have for pmin_as_share_of_pmax. These default values could be modified by the user via a user facing function in the create state and the grid will be modified accordingly (Pmin, Pmax, ramp30) in the powersimdata.input.transform_grid module when we create the scenario. This way the information will be directly propagated in REISE.jl

[BainanXia]

I think we should define a set of default values in the powersimdata.network.constants.resource module as we have for pmin_as_share_of_pmax. These default values could be modified by the user via a user facing function in the create state and the grid will be modified accordingly (Pmin, Pmax, ramp30) in the powersimdata.input.transform_grid module when we create the scenario. This way the information will be directly propagated in REISE.jl

Based on the discussion with @yixingxu and @lanesmith , I think the current logic in REISE.jl is not something we would like to make it "default". Instead, I was thinking to migrate the current logic into a module, say ramp_rates.py in powersimdata.design.generation to provide an optional ramp rates calculation which can be used by the user when adding new plants or scaling existing plants during scenario creation. One of the reasons of making it optional is the same concern raised in the previous issue, i.e. the default behavior of a grid model should be the same as the dataset we published to avoid confusions. This relates to the second point in the to-do list we summarized below:

1. Remove the ramp rate override logic in REISE.jl (not sure whether we should also do it for REISE )
2. Implement such logic as a backup option in PowerSimData (also for existing scenario reference purpose)
3. Figure out new logic of ramp rate changes during plant addition and capacity scalings in change_table (this is something new that we need to deal with after removing the logic from engine, which needs some research, before the exploration on this track, we can use the calculations produced by 2 in such situations)
4. Grab the original data from TAMU synthetic network and check whether the updated data is more realistic comparing with our current logic. If so, we should update our plant.csv for usa_tamu accordingly.

Update from @lanesmith on 4: looking through TAMU's most up-to-date generator data, it appears that they do not provide any ramp rate data, which seems to track with Daniel's original concern.

Then I think we will need to update the ramp rates in future release of usa_tamu model based on our exploration in 3.

[rouille]

Some questions:

1. In addition to removing the hard-coded ramp rate in REISE.jl, we also need to remove the hard-coded Pmin there, which are defined as a fraction of Pmax. I believe the updates of Pmin would need to happen before the eventual scaling up and dowm of Pmax. I would say the update of the ramp rate will happen at the very end
2. Backup ramp rates are grid model dependent and by generator type. My opinion is that since all our scenarios have been run with hard coded value currently in REISE.jl, it should be the default. Otherwise nobody will be able to reproduce our scenarios/studies.

I agree with 3.

[BainanXia]

Some questions:

1. In addition to removing the hard-coded ramp rate in REISE.jl, we also need to remove the hard-coded Pmin there, which are defined as a fraction of Pmax. I believe the updates of Pmin would need to happen before the eventual scaling up and dowm of Pmax. I would say the update of the ramp rate will happen at the very end
2. Backup ramp rates are grid model dependent and by generator type. My opinion is that since all our scenarios have been run with hard coded value currently in REISE.jl, it should be the default. Otherwise nobody will be able to reproduce our scenarios/studies.

I agree with 3.

1. Agree, but the updates of Pmin would need to happen after the scalings of Pmax, given it could be a fraction of the eventual Pmax, right?
2. I thought about it and found we had overwritten the ramp rates in plant.csv by the same logic here. Hence, in order the reproduce the results, (I think) we just need to apply the same logic for plant additions/scalings as I suggested above.

[lanesmith]

2. I thought about it and found we had overwritten the ramp rates in plant.csv by the same logic here. Hence, in order the reproduce the results, (I think) we just need to apply the same logic for plant additions/scalings as I suggested above.

I agree that updating the 30-minute ramp rates in plant.csv should serve as a sufficient enough default to allow users to replicate past studies. I will need to double-check, but we might need to make sure that the 30-minute ramp rates in plant.csv actually are the same as the outputs to the hard-coded logic in prepare.jl. I think I remember them being slightly different.

EDIT: See my comment below.

[rouille]

2. I thought about it and found we had overwritten the ramp rates in plant.csv by the same logic here. Hence, in order the reproduce the results, (I think) we just need to apply the same logic for plant additions/scalings as I suggested above.

I agree that updating the 30-minute ramp rates in plant.csv should serve as a sufficient enough default to allow users to replicate past studies. I will need to double-check, but we might need to make sure that the 30-minute ramp rates in plant.csv actually are the same as the outputs to the hard-coded logic in prepare.jl. I think I remember them being slightly different.

Does this mean we need to create a new data release in Zenodo?

[lanesmith]

Does this mean we need to create a new data release in Zenodo?

I just compared the 30-minute ramp rate values that we get from the prepare.jl process (using plants.csv as the input for Pmax and type values) and those from plant.csv. The values are closer than I remember them being when I first looked; I must have been using an older case.mat file to provide the Pmax and type values. That being said, the values aren't equivalent, as the values in plant.csv are rounded (in what appears to be a fairly non-uniform way). We still generally see absolute percent differences of less than one percent, though if we want to have values that can replicate our current process, we should probably include the exact 30-minute ramp rate values in plant.csv.