-
Notifications
You must be signed in to change notification settings - Fork 94
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
Potential misinterpretation of (internal) cost calculation related to OM cost term #645
Comments
Thanks @sstroemer. The bug looks to have been introduced in v0.7. It is as you suggest in v0.6.10. RenamingI don't like Global expressionsIt's about more/less expressions, but also the value to the user of those expressions. The current split of investment costs is really just to stop |
Sorry, that wasn't meant as a "hard suggestion" to adopt these namings, just the assumption that it might be reasonable since stuff like
I assume both are of interest: Before gives me the total costs that my system spends, after gives me access to calculate proper annual shares of different cost types.
|
Great. Let's go with that, then.
Both might be of interest, but it does increase model size in memory (expression objects just take up memory) and increases build time. It probably isn't a considerable increase as investment costs don't have a timeseries dimension, but something we should explore. I wouldn't have them as auxiliary variables, for sure (that's why all our costs are "expressions", leveraging what Pyomo etc. support out-of-the-box). |
My bad, I did not check it for
Just my personal opinion: As you indicated, due to these not being temporal, the memory and time-to-build cost is almost none compared to the rest of the model. Especially since they are not even "large expressions" (as in, they group investment variables, leading to a low amount of variable-coefficient pairs in the underlying data structure). But again, this is just quality-of-life and nothing important. |
What happened?
Description
Currently, the internal annualisation of costs is done in
cost_investment
. The way it's done may be different to what some users may expect, based on the naming conventions, and may lead to confusion or misinterpretation of input data (and therefore wrong results).The main motivation is the following observation of the calculation of
cost_investment
, which roughly looks like:Here$\delta$ is some sort of depreciation/annualisation factor ($\alpha$ just allows to generalize that for periods different to a single year) which weights the total capital expenditure (correct), but also the parts of the fixed operation and maintenance costs ($FOM$ ). The latter may not necessarily be expected by users, because these are often given as either $FOM_{absolute}$ , correct) or $FOM_{\%}$ - potentially misleading).
EUR/MW/a
(represented bycost_om_annual
, here%/a
(represented bycost_om_annual_investment_fraction
, hereFor both cases, it is a recurring fixed annual payment, which means it's already "per year" and does not have to be annualised. In the end, this leads to considerably reduced costs if using the "FOM are 2-5% depending on technology" approach (e.g., directly using Danish Energy Agency data would be fine, using the processed PyPSA technology-data would lead to wrong results, since they convert everything to %).
If that is actually a problem (and not intended), the easiest fix could be reworking to:
Everything below just contains additional thoughts, that could be relevant when doing the (breaking) change.
Thoughts
I'd like to point out / propose the following changes:
Renaming
cost_var
could be renamed tocost_operation_var
(or something similar) - these are commonly referred to as VOM, variable operation and maintenance costs, which could be reflected by usingcost_vom
.cost_operation_fix
for fixed costs of operation. Similar to the above, these are commonly referred to as FOM, fixed operation and maintenance costs, which could be reflected by usingcost_fom
.cost_investment
tocost_investment_total
, to better communicate that this is a (total) sum expression.cost_investment_total_annualised
, indicating that this accounts for annualisation.Changing calculations
Initial suggestion
cost_vom
is given by the calculation ofcost_var
as it is.cost_investment_total
is given as "the inner sum of investment costs" of the currentcost_investment
, roughlysum(cost_investment_flow_cap, over=carriers) + cost_investment_storage_cap + cost_investment_source_cap + cost_investment_area_use + cost_investment_purchase
.cost_fom = annualisation_weight * (sum(cost_om_annual * flow_cap, over=carriers) + cost_investment_total * cost_om_annual_investment_fraction)
.cost_investment_total_annualised = annualisation_weight * depreciation_rate * cost_investment_total
.cost = cost_vom + cost_fom + cost_investment_total_annualised
.Drawbacks:
annualisation_weight
is now needed in two separate locations.An alternative way
This looks like a bigger change, which is why I did not want to propose this as the main way to go, but it may be worth considering (steps 1 and 2 are identical):
cost_vom
is given by the calculation ofcost_var
as it is.cost_investment_total
is given as "the inner sum of investment costs" of the currentcost_investment
, roughlysum(cost_investment_flow_cap, over=carriers) + cost_investment_storage_cap + cost_investment_source_cap + cost_investment_area_use + cost_investment_purchase
.cost_fom = sum(cost_om_annual * flow_cap, over=carriers) + cost_investment_total * cost_om_annual_investment_fraction
.cost = cost_vom + annualisation_weight * (depreciation_rate * cost_investment_total + cost_fom)
.This introduces less global expressions, and
annualisation_weight
is only needed in one location.Which operating systems have you used?
Version
latest (4fc6b84)
Relevant log output
No response
The text was updated successfully, but these errors were encountered: