codecov[bot]
commented
5 months ago Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 76.7%. Comparing base (
38aa6e9) to head (48ccf0b). Report is 2466 commits behind head on main.
Made a number of changes to
tools.costs, mostly relating to the modeling of base year, first model year, and first technology yearTo summarize, the changes are:
base_yearto mean the year to start modeling cost changesfom_rate) to 0Additional details relevant to each change found below.
How to review
For @khaeru and/or @glatterf42 : Read the diff and note that the CI checks all pass.
PR checklist
Additional information
Fixed jumps in cost projections for technologies with later first technology year
Issue #169 described an issue with certain technologies that have a "first_technology_year" that's after the first model year (2020) behaving weirdly -- namely, the costs would jump up and then come back down to base year costs when it reaches its "first_technology_year". I've fixed this issue, so that the costs are projected just like other technologies (starting from the base year). Additionally, I've removed projections for years that are before the technology's "first_technology_year" completely. The "first_technology_year" refers to the first year a technology starts being deployed within MESSAGE. There's no other place this concept is used I think, so there's no other way to constrain it. So, I decided to filter out those years to avoid giving the model costs for years where the technology shouldn't even be in operation.
Using the same example as issue #169, here's how the investment cost projections for
bio_istig_ccslooks now:Modified the usage of
base_yearin the modulePreviously, the
base_yearwas mainly just used to decide what year WEO data to use. Now, I've changed the module to use 2021 WEO data no matter what, andbase_yearmeans the year to start projecting cost changes/reductions.base_yeardoes not have to equal the first model year (y0). Ifbase_yearis aftery0, then the technology's costs is held constant at the base year cost untily0. Note that this means there will be no cost variance across scenarios untilbase_year, but there will still be regional differentiation. I've changed the defaultbase_yearto 2025, holding the cost across scenarios constant fromy0(2020) to 2025 (so forcing no scenario variance from 2020 to 2025).Example of this in action:
Updated cost assumptions for certain CCS technologies
@OFR-IIASA, @gidden, and others have noted that there are some cases with a CCS technology's costs would dip lower than its non-CCS variant. The reason for that is that based on the inputs into the cost module, since these are two different technologies, there is nothing stopping their assumptions from causing them to have completely different pathways. Using
syn_liqandsyn_liq_ccsas examples: for the regional differentation,syn_liqwas being mapped to IGCC in the WEO, whilesyn_liq_ccswas mapped to IGCC with CCS. If WEO has different regional differentations for their two technologies (which they do), then that affects how our costs forsyn_liqandsyn_liq_ccs. Additionally,syn_liqandsyn_liq_ccswere following different cost reduction pathways and narratives. The combinations of these issues caused the costs ofsyn_liq_ccsin some regions to dip lower thansyn_liq, which doesn't make sense.The list of problematic technologies found in the cost module where this phenomenon occurs are:
For the listed technologies above, I made the following changes to their data inputs:
Here is what
syn_liq_ccscosts look like after the changes:Longer term we are having discussions on if we want to move to component-based modeling of CCS components and adding that cost onto the original technology.
Changed the default fixed O&M reduction rate (
fom_rate) to 0@macflo8 took a look at
solar_pv_pplcosts over time and noted that fixed O&M costs were increasing too rapidly, causing solar to be deployed at very slow rates. This is due to the defaultfom_ratein the module being 0.025, which is applied universally to all technologies. For now I've just changed this to zero, which means for eachyear_vtg, the costs remain the same across allyear_act. Longer term I need to look at making this configurable for specific technologies (some have lower or higher values) -- perhaps this can just be an input similar to the base year reference region costs.