Add battery O&M and self-discharge #354
Conversation
| model_degradation::Bool = false | ||
| degradation::Dict = Dict() | ||
| minimum_avg_soc_fraction::Float64 = 0.0 | ||
| daily_self_discharge_fraction::Float64 = 0.0 |
There was a problem hiding this comment.
@lixiangk1 could you add a little explanatory text here for this input?
There was a problem hiding this comment.
Hey! Did you mean add notes in the code to better define this term or just explain it in the pull request?
The input is a loss term for battery self-discharge, entered as a daily fraction for how much of the stored kWh is leaked from the battery (e.g., 3% of the the kWh stored in the battery is self-discharged per day). This is then modeled as a per timestep loss term where eg. 0.03/24/timesteps_per_hour * dvStoredEnergy is subtracted from dvStoredEnergy at every timestep.
There was a problem hiding this comment.
I mean adding a comment "# explanation" in the code here so that it appears in the REopt.jl documentation (https://nrel.github.io/REopt.jl/dev/reopt/inputs/#ElectricStorage). We haven't really done this for ElectricStorage inputs but for all of the other techs we've been including some help text around the inputs. If you could do the same for the O&M costs that would be great! Maybe with a note about not double-counting replacement and O&M costs.
|
@lixiangk1 Three quick comments from an initial review!
|
|
@adfarth Thanks for your review! Do the latest changes address your comments? As for the tests, it seems that the Windows/MacOS ones are passing but the Ubuntu ones timeout - do you know why that might be happening? Is it something specific to this branch? |
Recapping our convo here!
|
|
@lixiangk1 any plans to finish this? I could probably support with a charge code in Q1. |
|
@lixiangk1 just a note that we'll have to add the battery O&M to the proforma.jl functions to calculate e.g. simply payback and IRR. |
|
@adfarth did you re-review this after @lixiangk1 's responses/updates after your initial review? |
I haven't re-reviewed since the April 5, 2024 comment |
| - m[Symbol("dvDischargeFromStorage"*_n)][b,ts] / p.s.storage.attr[b].discharge_efficiency | ||
| ) | ||
| - (p.s.storage.attr[b].soc_based_per_ts_self_discharge_fraction * m[Symbol("dvStoredEnergy"*_n)][b, ts]) | ||
| - (p.s.storage.attr[b].capacity_based_per_ts_self_discharge_fraction * m[Symbol("dvStorageEnergy"*_n)][b]) |
There was a problem hiding this comment.
@lixiangk1 based on our convo last week - this "per_ts" method was also going to be adopted for H2, right? (instead of "daily leakage"). I agree with that.
There was a problem hiding this comment.
Yup, will be updating all the daily values to per ts. What do you think about having both an soc and capacity based leakage term for electric storage, thermal storage and h2?
There was a problem hiding this comment.
Seems good to have both options, if it's not that much more development. I would imagine SOC-based could slow things down more.
4 participants
Uh oh!
There was an error while loading. Please reload this page.