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

Replace Variable Renewable Electricity Backup with Profitability-Adjusted LCOE (PLCOE) #436

Open
wants to merge 19 commits into
base: master
Choose a base branch
from

Conversation

mmowers
Copy link

@mmowers mmowers commented Jun 11, 2024

This Core Model Proposal (CMP) updates the cost adjustment applied to variable renewable electricity (VRE) generation (wind and solar, labeled “intermittent” technologies in GCAM) based on technology value parameterizations derived from the Regional Electricity Deployment System (ReEDS) model. In addition, share-weights of wind and solar electricity are set to converge to one by 2030 (rather than 2100).

mmowers and others added 16 commits December 11, 2022 17:12
…this commit; data changes to follow in a separate commit. Model runs and solves normally, but results have not been explored / vetted.
…this commit (code changes were in a previous commit). Model runs and solves normally, but results have not been explored / vetted.
…l XMLs; GCAM runs and sovles cleanly; results have not yet been vetted.
@mmowers mmowers marked this pull request as ready for review June 11, 2024 22:02
Copy link

@mwisepnnl mwisepnnl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Marshall is going through the C++ changes

DEFINE_DATA_WITH_PARENT(
IBackupCalculator,

//! TODO: leave an explanatory comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you need to add some explanation still?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes :) I'll push this up momentarily.

const double aAverageGridCapacityFactor,
const int aPeriod) const
{
// This is a placeholder function so we can use the IBackupCalculator class

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay, so my rust is showing. Is it because it is pure virtual and needs to be defined? could it instead be removed from the ibackup_calculator, or do you think it might be useful for something else so should be left in?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i guess we need to see how to deal with Page's comments on maintaining the old ways as an option perhaps

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we want to support multiple ways of representing intermittency; pretty much every time we have ever tried to maintain multiple ways of doing something, the “non-default” option only gets maintained for a few months. We don't want to require ourselves to include multiple representations of intermittency in our standardized testing suite.
The issue that I have raised with this proposal is that right now, in high renewable scenarios, we see lots of single-cycle combustion turbines, whether powered by hydrogen or natural gas. Almost all of this capacity is in the backup electricity sectors. Perhaps coincidentally, the total capacity and total electricity output of these combustion turbines is reasonably consistent with ReEDS; high renewable scenarios in the USA tend to see between 500 and 1,000 gigawatts of combustion turbine capacity. In my opinion that technology should not be turned off in this revised approach; there should still be some demand for the services provided by combustion turbines, and their costs should be passed forward to electricity consumers.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @pkyle, thanks for your review comments.

One thing to note is that the new PLCOE method does allow us to calculate a total integration cost per region / technology / model period by taking the difference of PLCOE and LCOE. This integration cost reflects a variety of technologies that provide system flexibility and support VRE integration (e.g., storage, transmission, and firm capacity resources), and could be used to post-calculate implied combustion turbine capacity or some mix of combustion turbines, storage, and transmission. It’s not obvious that single-cycle combustion turbines are the primary system integration option supporting VRE. Per the table below for the ReEDS 2023 Standard Scenarios Mid Case, the growth in battery capacity from 2010 through 2050 is twice that of CT capacity. Doing a robust competition between Storage, CT, and other integration options is beyond the scope of this CMP, but we have done some preliminary thinking on a hybrid approach that combines PLCOE-based competition with dynamic calculation of storage/firm capacity. This is a good opportunity for future model development.

  2010 2020 2030 2040 2050
Wind Capacity (GW) 40 118 441 641 762
PV Capacity (GW) 1 72 352 753 1095
VRE Capacity (GW) 41 190 793 1393 1857
Battery Capacity (GW) 0 0 50 197 369
Gas-CT Capacity (GW) 117 128 123 173 300
H2-CT Capacity (GW) 0 0 0 11 11
CT Capacity (GW) 117 128 123 183 311
Battery-VRE Capacity Ratio 0.00 0.00 0.06 0.14 0.20
CT-VRE Capacity Ratio 2.87 0.67 0.16 0.13 0.17

Table from ReEDS 2023 Standard Scenarios Mid Case

RE: supporting multiple ways of representing intermittency, @mbins talked to @pralitp and worked out an approach for maintaining the previous approach in code that should be reasonably robust. You’re right that the “non-default” option will be more susceptible to lapses in maintenance. While we feel that the PLCOE approach proposed in this CMP does a better job of representing VRE competitiveness (and is more transparently parameterized), we acknowledge that removing the ability to estimate firm backup capacity (and associated energy use / emissions) does remove a capability that’s valuable for some projects. Thus, we agree with @mwisepnnl's suggestion to maintain the ability to use the current approach for the subset of projects for which estimating firm backup capacity is important.

-@mmowers and @mbins

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the context, and comparison with the published ReEDS run. As I noted in my initial comment, what is most important here is how this proposal impacts the system level demands for natural gas and hydrogen. Levels of deployment of hydrogen combustion turbines in ReEDS are sensitive to the scenario chosen, through the ratio of total combustion turbine capacity to renewable energy capacity is presumably more stable. And from GCAM’s perspective, the battery option would be a system cost and electricity loss that is passed on to end use consumers of electricity, similar to T&D in general.
I suppose for my own purposes, if I can continue to use the backup electricity representation that we have right now for the next year or two, while we coalesce on a strategy for how to represent short term capacity and generation, which would value combustion turbines appropriately, that does suffice. But longer term I would not want to see the demand for hydrogen combustion turbines go to 0 simply because of a different modeling convention that we adopted. Right now this is one of the major demands for hydrogen we see in GCAM, system wide in net-zero scenarios, and the deployment levels are consistent with the current literature.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay, so my rust is showing. Is it because it is pure virtual and needs to be defined? could it instead be removed from the ibackup_calculator, or do you think it might be useful for something else so should be left in?

Marshall - I think you are correct. We may have been able to remove the getMarginalBackupCapacity and getAverageBackupCapacity from the IBackupCalculator class (from which the ValueFactorCalculator class is derived). But now that we've reintroduced the CapacityLimitBackupCalculator class, which uses those methods, I think we need to leave them in the IBackupCalculator class and thus leave empty implementations of those methods in the ValueFactorCalculator class.

DEFINE_VARIABLE( SIMPLE | NOT_PARSABLE, "average-grid-capacity-factor", mAveGridCapacityFactor, Value ),

//! State value necessary to track tech output ration
//! State value necessary to track tech output ratio

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

awesome. i think that was my typo from 20 years ago!

@@ -57,23 +58,8 @@ class IInfo;
* resource.
* \details An intermittent subsector represents the production of a good, such

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i probably caused this, but i am now confused as to whether it is teh subsector or technology that is intermittent and why?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That comment was committed in October 2008 (!), and was itself copied from an even older commit in a different repository that I don't think we have archived. In any case, what is described in the comment is not true of the structure; in the core model there are intermittent technologies, not intermittent subsectors, and the technologies have multiple (non-substitutable) inputs: the variable resource (e.g. wind) and the backup electricity.
This structure allows us to have multiple technologies which may or may not be intermittent (e.g. wind and wind_storage) competing within the same sub sector (wind).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've updated the comment to reflect the current structure.

mbins added 2 commits October 9, 2024 17:19
…VRE integration. Includes C++ code changes and gcamdata changes (using a switch in constants.R).
@@ -141,8 +141,6 @@
#include "sectors/include/afinal_demand.h"
#include "sectors/include/ag_supply_sector.h"
#include "sectors/include/ag_supply_subsector.h"
#include "sectors/include/capacity_limit_backup_calculator.h"
#include "sectors/include/CSP_backup_calculator.h"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need these for backwards compatibility here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The model compiled, ran cleanly, and produced expected results without these lines. But I think you're right that they should be included; I'll reintroduce them in a commit momentarily.



/*!
* \file interm_subsector.cpp

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might as well fix this comment here since we are bringing it back for no

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good suggestion! Fix coming in the next commit.

@mwisepnnl
Copy link

i'll approve the pull request

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

Successfully merging this pull request may close these issues.

4 participants