How to introduce regional tech cost in to GCAM?

[missxtuna90]

I understand that GCAM uses global technology cost data. Is there a way to incorporate regional cost differences for the same technology? For example, in the electricity sector, the cost of solar technology appears to be uniform across all regions. Is there a way to differentiate this by region? Any suggestions or proxy methods to achieve this would be greatly appreciated. Thanks!

[pkyle]

Note that each region is assigned region-specific capacity factors for wind and solar technologies, which return region-specific levelized costs of capital. This is under: region / supplysector / subsector / stub-technology / period Wind and rooftop PV resources also have an upward-sloping supply curve which contributes to inter-regional variability in costs of power generation. Capital costs are not region specific, for any technologies in most sectors, though the model certainly allows it, as a parameter set within the stub-technology of any region will over-ride the default set in the global-technology-database. E.g. you could over-ride the global technology default for PV in 2025 in the Middle East as follows:

<scenario>
    <world>
        <region name="Middle East">
            <supplysector name="electricity">
                <subsector name="solar">
                  <stub-technology name="PV">
                    <period year="2025">
                        <input-capital name="capital">
                            <capital-overnight>290</capital-overnight>
                            <fixed-charge-rate>0.13</fixed-charge-rate>
                        </input-capital>
                    </period>
                  </stub-technology>
                </subsector>
            </supplysector>
        </region>
    </world>
</scenario>

[missxtuna90]

Thanks! This is really helpful!

[missxtuna90]

Hi @pkyle ,

Two questions following this:

• I have a question regarding the technology cost data used in GCAM. The documentation states that technology costs were sourced from the 2019 Annual Technology Baseline (ATB) Cost. However, after downloading the ATB data and comparing it with the values in GCAM's technology cost XML files (e.g., solar_adv.xml), I noticed significant discrepancies. For instance, the solar_adv.xml file lists the capital overnight cost for 2020 as 60695.712 2020$/kW (inflation adjusted from 1975$/KW), which is much higher than the corresponding value in the ATB dataset. Could you clarify why these numbers differ?

• Additionally, I have a question regarding the capital overnight costs in electricity_water.xml. Unlike other technology cost files (e.g., solar.xml, wind.xml, nuclear.xml), the electricity_water.xml file does not appear to provide cost projections. How should we interpret the capital overnight cost values in this file compared to those in the other electricity technology files?

Any clarification on these discrepancies would be greatly appreciated!

Thanks!

[pkyle]

The specific assumptions are found in input/gcamdata/inst/extdata/energy/NREL_ATB_capital.csv If those differ from what you see online I don't have any explanation, but note that the specific source is noted in the comments of that file. The processing happens in input/gcamdata/R/zenergy_L113.atb_cost.R The only change from those costs to what is in the model input files is a conversion to a different dollar year. electricity_water.xml does provide cost projections, in the global-technology-database. Each technology's full set of characteristics are written for each time period to 2100. Note that the capital costs are written to the "electricity" sector, for all technologies. Thermo-electric plants have some of their characteristics in downstream pass-through sectors (e.g., elec_coal (conv pul)). But there the capital costs are just the cooling systems, which is why the capital costs are so low (e.g., $6/kW, in 1975$). Those sectors' technologies are intended to compete the different cooling system types.

[missxtuna90]

Hi @pkyle ,

Thank you for your prompt and helpful responses!

We are currently working on updating historical information in GCAM using IEA energy balance data to calibrate the model to a more recent year. I have read several discussions on this topic but wanted to double-check a few points.

If we only have IEA energy balance data (e.g., for 2022), would this be sufficient to recalibrate the model so that the energy system is updated accordingly (and, as a result, historical emissions are updated as well), while keeping all other historical calibration data unchanged?

Additionally, does the choice of calibration year matter in this process, given that GCAM runs on a five-year time step? For example, would calibrating to 2022 introduce any issues compared to calibrating to 2020 or 2025?

I appreciate your insights on this!

Thanks!

[pkyle]

We have had an effort for the last few years to update the model base year, and make the base year choice flexible, as well as depart from the five-year timestep so that we don't end up with 2020 as a model calibration year. The process has been complicated but I have not been directly involved with it. I don't know what to tell you, as a recommendation for how to do this, as updating the calibration year requires updating every single data point in all sectors. It isn't enough to update the energy data if the agricultural data still cuts off in ~2016. There are dozens of different datasets that are used for calibrating the model and they all have to be updated simultaneously for the model to be able to run with a new calibration year. If you want to use 2022 as a calibration year, then that will need to be added as a model time period, and that might involve changes in a large number of files that you only discover through repeated crashes. Some of the data inputs to gcamdata are in tables that specify all model time periods, so the processing code does not perform any interpolation to all model periods. In such instances a 2022 time period will need to be inserted, or the processing code will need to be modified to perform the interpolations. Depending on your specific project need, you could soft-calibrate the model by adjusting share weights to return observed market outcomes in key sectors and technologies, or alternatively wait until we have updated the model base year. Again I have not been involved with the process so I don't know about the timeline of when that would be in the release.

[missxtuna90]

Thanks a lot for this detailed and comprehensive explanation. Understand that calibrating a complex model like GCAM is very difficult. I think what we aim for is for energy consumption being corrected so the share weight solution is very helpful. Thanks @pkyle !

[nurf004]

Thank you for this discussion. Hi @pkyle I have one question regarding the way to over-ride the technology cost. Can we do it for elect_td_bld (rooftop_pv). I used the same method, but failed. It showed"Unknown tag: capital-overnight encountered while processing input-capital Unknown tag: fixed-charge-rate encountered while processing input-capital". Is there any different treatments for this? Thank you.

[pkyle]

Opening up electricity_water.xml here is what I see for rooftop pv in the first region, in 2021:

                        <period year="2021">
                            <capacity-factor>0.170000237372851</capacity-factor>
                            <tracking-non-energy-input name="capital">
                                <capital-coef>10</capital-coef>
                                <tracking-market>capital</tracking-market>
                                <depreciation-rate>0.0666666666666667</depreciation-rate>
                            </tracking-non-energy-input>
                            <minicam-non-energy-input name="capital">
                                <input-cost>11.8736963250617</input-cost>
                            </minicam-non-energy-input>
                        </period>

So, it appears we've pre-levelized the costs of rooftop PV, rather than using the input-capital tag which itself contains a capital-overnight tag. As long as you are using the exact structure in the XML for reading in the costs, your add-on assumptions will over-ride the ones in electricity_water.xml. But if you're using a different set of parameters altogether, then a model crash is the expected/correct outcome.

[nurf004]

Noted. Thank you @pkyle