search

Breakthrough-Energy / PowerSimData

Simulation framework
https://breakthrough-energy.github.io/docs/
MIT License
51 stars 40 forks source link

Port linearize_gencost and pmin modifications from REISE.jl #701

Closed jenhagg closed 1 year ago

jenhagg commented 1 year ago

Purpose

To facilitate using a grid.pkl and remove the need for mapping between a case.mat/grid.mat/etc, we move grid modifications previously done in REISE.jl to the scenario preparation process.

This PR should be merged at the same time as https://github.com/Breakthrough-Energy/REISE.jl/pull/187, after which we should update the existing grid.mat files. I believe we also need to update the ramp30 values in plant.csv as discussed in this issue https://github.com/Breakthrough-Energy/PowerSimData/issues/680 and release a new dataset on zenodo.

What the code is doing

Scale plant Pmin values and linearize cost curves the same way we were doing in REISE.jl - after we apply the change table, and just before we upload the grid.pkl to the server (or, container, or wherever). I also ported the linearize_gencost tests from julia since those will be unused/deleted.

Testing

Ran a scenario in a container and reloaded it after it finished for some cursory spot checking.

Time estimate

20 min

rouille commented 1 year ago

Is powersimdata/design/generation/ a good location for the cost_curves module? Should we move it in powersimdata/scenario/ or powersimdata/input/? What do you think @BainanXia?

BainanXia commented 1 year ago

Is powersimdata/design/generation/ a good location for the cost_curves module? Should we move it in powersimdata/scenario/ or powersimdata/input/? What do you think @BainanXia?

I agree. The original idea of design module is a place for functions that are optionally used in the scenario workflow. However, linearization is essential given the engine can't deal with quadratic cost curves (at least for now) and similarly for the ramp module in the future. Thus we can create a new module in powersimdata/scenario/. Not sure what is a good name for it, maybe configure?

lanesmith commented 1 year ago

I agree. The original idea of design module is a place for functions that are optionally used in the scenario workflow. However, linearization is essential given the engine can't deal with quadratic cost curves (at least for now) and similarly for the ramp module in the future. Thus we can create a new module in powersimdata/scenario/. Not sure what is a good name for it, maybe configure?

Is the ramp module essential? Especially once (if?) plant.csv gets updated, I'm not sure we would need the ramp-rate correction anymore.

BainanXia commented 1 year ago

I agree. The original idea of design module is a place for functions that are optionally used in the scenario workflow. However, linearization is essential given the engine can't deal with quadratic cost curves (at least for now) and similarly for the ramp module in the future. Thus we can create a new module in powersimdata/scenario/. Not sure what is a good name for it, maybe configure?

Is the ramp module essential? Especially once (if?) plant.csv gets updated, I'm not sure we would need the ramp-rate correction anymore.

We will need that when scaling existing plants as well as adding new plants without specifying ramp rates until we have a better solution.

rouille commented 1 year ago

Is powersimdata/design/generation/ a good location for the cost_curves module? Should we move it in powersimdata/scenario/ or powersimdata/input/? What do you think @BainanXia?

I agree. The original idea of design module is a place for functions that are optionally used in the scenario workflow. However, linearization is essential given the engine can't deal with quadratic cost curves (at least for now) and similarly for the ramp module in the future. Thus we can create a new module in powersimdata/scenario/. Not sure what is a good name for it, maybe configure?

It can be done in a separate PR. I am fine with having the linearize_gencost function in a new powersimdata.scenario.configure. We could have the ramp rate setting there too. Or we could have a linearize_cost_curve module and a assign_ramp_rate modules in powersimdata.input. Hat is your opinion @jenhagg?

jenhagg commented 1 year ago

Is powersimdata/design/generation/ a good location for the cost_curves module? Should we move it in powersimdata/scenario/ or powersimdata/input/? What do you think @BainanXia?

I agree. The original idea of design module is a place for functions that are optionally used in the scenario workflow. However, linearization is essential given the engine can't deal with quadratic cost curves (at least for now) and similarly for the ramp module in the future. Thus we can create a new module in powersimdata/scenario/. Not sure what is a good name for it, maybe configure?

It can be done in a separate PR. I am fine with having the linearize_gencost function in a new powersimdata.scenario.configure. We could have the ramp rate setting there too. Or we could have a linearize_cost_curve module and a assign_ramp_rate modules in powersimdata.input. Hat is your opinion @jenhagg?

Based on the current package structure, I think having those in powersimdata.input makes sense, although the distinction between input and design isn't super clear to me. I'm fine with either option; there is always the possibility of reorganizing in the future.