Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

storage unnecessarily simultaneously charging/discharging? - Small NE OneZone Multistage, 30, 60, 90% RPS for periods 1, 2 & 3 respectively, no CarbonCap #547

Closed
AlejandroGNE opened this issue Sep 9, 2023 · 10 comments
Assignees

Comments

@AlejandroGNE
Copy link

I get these odd storage operation profiles when modeling 90% RPS in the example case. I don't get why would storage want to simultaneously charge and discharge, and lose energy in the process, rather than charging just enough to cover the relevant discharges, specially considering this small example case is copperplate. Any ideas? Thanks!

image

For easy replication, you can see a summary of the changes in this commit: 9eae852

@pz-max
Copy link

pz-max commented Sep 9, 2023

@AlejandroGNE It's probably a parameterization issue. Here is a paper explaining more about this effect by me et al. 2023, "Reducing energy system model distortions from unintended storage cycling through variable costs" https://www.sciencedirect.com/science/article/pii/S2589004222020028 One quick fix to avoid this: set variable costs of all generators (also solar and wind) to a minimum of 0.1$/MWh. Won't change significantly the final investment decision but removes this weird operational behaviour. Generally I recommend: apply realistic variable costs with a minimum of 0.1$/MWh per operating asset (the value worked out good in my cases. But I know it's solver tolerance dependent and likely also solver and model dependent -- haven't checked)

@AlejandroGNE
Copy link
Author

"Dios te lo pague con muchos hijos" i.e., thank you so much in "mexican" -I will try it out!

@AlejandroGNE
Copy link
Author

Following your findings I had to iterate up to $100/MWh VOM for this very simple example model to finally get rid of unintended storage cycling. I will use these insights when I get to a more accurate model beyond these simple tests, hopefully then I can find the sweet spot for VOM values that don't really affect the model outcomes, as in this case I confirm your findings: more wind, less solar. Didn't look at other results -but can imagine. It's interesting, evaluating high VRE grids kind of forces you to consider a minimal level of accuracy because of this!

Thanks for the tip, @pz-max Max!
image

@pz-max
Copy link

pz-max commented Sep 12, 2023

@AlejandroGNE , to which components did you add the VOM? $100/MWh sounds a lot.
Do you have RES constraint defined somewhere e.g. I need to achieve 50% solar+wind dispatch on average?
If you answer YES to the second question, not only dispatch but also investments are screwed by unintended storage cycling. Will be challenging to fix this. Kittel et al. referenced in my paper address this.

@JesseJenkins
Copy link
Collaborator

@AlejandroGNE can you please check the price time series during the periods when simultaneous charging and discharging is occuring? This should only be happening when prices are <$0/MWh. At those periods, it is actually rational to consume more electricity -- that is what the negative price is telling you -- and thus storage can make money by losing energy. Think of it as basically acting as a price elastic demand. Prices can be negative due to production subsidies (e.g. for renewables) or to avoid thermal power plant cycling costs (unit commitment decisions).

@pz-max has a viable suggestion if you want to minimize this behavior to set variable costs to storage to some reasonable value. But this may also not be a totally unrealistic behavior. We do ensure that the sum of charging and discharging capacity can't exceed the actual power capacity of the storage devices as well.

@JesseJenkins
Copy link
Collaborator

Another reason why this is happening your case @AlejandroGNE is to help the solar & wind generate more MWh to meet the RPS requirement. I assume you have specified the RPS as a % of total demand here. We have built the Energy Share Requirement policy constraint to allow you to include storage losses in the RPS calculation, which would penalize this activity as well.

@pz-max
Copy link

pz-max commented Sep 12, 2023

This should only be happening when prices are <$0/MWh

We observed unintended storage cycling for prices <$0/MWh, =$0/MWh and >$0/MWh.

Case prices <$0/MWh. As Jesse mentioned, it might make sense to dissipate the electricity in the energy storage. However, it would only make sense if electricity dissipation in energy storage is more realistic than just stopping the operation of wind turbines/ PV panels.

Case prices =$0/MWh. A convex problem has at least one optimal solution, but when not uniquely defined, it can also have multiple optima. When you set the VOM of every RES and storage asset to $0/MWh, and you have times with surplus wind and solar electricity, it is indifferent to the model to curtail RES, or operate the RES and simultaneously dissipate the electricity in the storage.

Case prices >$0/MWh. I think this is what Kittel et al. observed. When you define a RES constraint e.g. min 50% solar generation on average of total load, then USC can also appear with prices >$0/MWh because it can save investment costs by dissipating energy in the storage while artificially increasing the RES share (USC increases FLH of RES and FLH of energy storage).

@AlejandroGNE
Copy link
Author

@AlejandroGNE , to which components did you add the VOM? $100/MWh sounds a lot. Do you have RES constraint defined somewhere e.g. I need to achieve 50% solar+wind dispatch on average? If you answer YES to the second question, not only dispatch but also investments are screwed by unintended storage cycling. Will be challenging to fix this. Kittel et al. referenced in my paper address this.

  1. to which components did you add the VOM?
    I added the VOM to solar and wind first, then also to storage
    I tested 0.01, 0.1, 1, 10 and 100 $/MWh VOM

this is the final set of parameters that produces the second plot:

Resource Var_OM_Cost_per_MWh Var_OM_Cost_per_MWh_In
natural_gas_combined_cycle 3.55 0.1
solar_pv 100 0.1
onshore_wind 100 0.1
battery 100 100
  1. do you have RES constraint defined somewhere e.g., I need to achieve 50% solar+wind dispatch on average?
    yes, the point of this run is using the very simple example case for New England with one zone and multi-stage configuration, to test a 90% RPS in the third period
    since this is a simple example case and I would be building a more accurate model, based on your paper insights I was hoping that the increased accuracy would allow me to use lower VOM -do you think this is possible?
    I will still check Kittel's paper, thanks for shining light on this

@AlejandroGNE
Copy link
Author

@AlejandroGNE can you please check the price time series during the periods when simultaneous charging and discharging is occuring? This should only be happening when prices are <$0/MWh. At those periods, it is actually rational to consume more electricity -- that is what the negative price is telling you -- and thus storage can make money by losing energy. Think of it as basically acting as a price elastic demand. Prices can be negative due to production subsidies (e.g. for renewables) or to avoid thermal power plant cycling costs (unit commitment decisions).

@pz-max has a viable suggestion if you want to minimize this behavior to set variable costs to storage to some reasonable value. But this may also not be a totally unrealistic behavior. We do ensure that the sum of charging and discharging capacity can't exceed the actual power capacity of the storage devices as well.

@AlejandroGNE Another reason why this is happening your case @AlejandroGNE is to help the solar & wind generate more MWh to meet the RPS requirement. I assume you have specified the RPS as a % of total demand here. We have built the Energy Share Requirement policy constraint to allow you to include storage losses in the RPS calculation, which would penalize this activity as well.

@JesseJenkins

  1. Indeed I used this Energy Share Requirement and enabled storage losses, so these are already accounted for in the model outcomes discussed above.

  2. huh, no prices.csv output files were generated in any of my runs. Same for NetRevenue.csv: no file. Any ideas on why?

  3. you mention production subsidies -is this easily configurable in GenX? I saw a way to require minimum capacities of certain technologies, but no way to apply direct subsidies.

  4. just to make sure I understand this unintended cycling of storage being a mathematically rational phenomenon in the model:

under negative prices

  • high VRE/inflexible thermal lead to negative prices
  • negative prices mean you get paid to consume energy
  • storage can choose to consume energy by charging and gets paid a revenue, then discharges/sells a bit less energy because of storage losses, and loses some of that revenue -but it gets a net revenue
  • and this is better than just curtailing because in that case no one gets any revenues (right?)

under RPS policy

  • there is also the added pressure to comply with RPS
  • with storage cycling you get to add some extra renewable MWh to your RPS balance that you wouldn't by just curtailing
  • and this RPS-complying pressure can make storage cycling appear even when prices are not negative, because it is cheaper to add renewable MWh this way than adding more wind/solar which are the cases cited by @pz-max above, for prices>=$0/MWh

two things come to mind:

  1. it could be that if charging and discharging cancel each other out in the constraints, that storage is "operating" at ~2x its capacity -I checked, and this doesn't happen: adding the absolute values of hourly charging and discharging never surpasses the storage capacity, just like Jesse said

  2. there is only one zone and one battery in this example case, and storage cannot physically charge and discharge at the same time, which brings us to the research by Max et al and Kittel et al where the reasonable way forward is to get rid of these storage distortions

*So, cycling storage is not a realistic way to dissipate energy nor to add renewable energy to your RPS, and you want to get rid of it. *
To this end, @pz-max I think I mistook your paper's conclusion that tuning VOM costs depends on solver accuracy as model accuracy. Still, I think giving the model more carbon-free options beyond this super simple example might take care of these issues for the most part. Thank you both so so much for engaging, I was truly lost before your contributions and it would have taken me much longer to explain these modeling issues. If any of what I said seems wrong, please, steer me in the right direction!

@AlejandroGNE
Copy link
Author

FYI, this is how capacities compare between original outcome and the parameters that get rid of storage cycling:

Capacity in last period (MW):

Resource base VOM=$100/MWh
natural_gas_combined_cycle 12,091 11,157
solar_pv 22,725 33,472
onshore_wind 26,828 34,868
battery 31,448 9,801
Total 93,092 89,299

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants