GCAM-USA to CERF: Heat rates by technology, vintage, and state xml query

[kmongird]

GCAM-USA to CERF: Heat rates by technology, vintage, and state xml query

GCAM-USA version: 5.3 (IM3 version)

Python script: get_heat_rates.py

Data Description: Heat Rates by Technology Type

Meta-Issue: #1

[pralitp]

This looks good to me. Although, to be transparent: I did not count out the decimal places on the unit conversions to make sure we got the prefix conversions perfect.

I have you compared these to other estimates? One thing to watch out for when using BTU/kWh is "higher heating value" vs "lower heating value". Different modeling teams use different conventions -- and I always forget which one GCAM is using..

[kmongird]

This looks good to me. Although, to be transparent: I did not count out the decimal places on the unit conversions to make sure we got the prefix conversions perfect.

I have you compared these to other estimates? One thing to watch out for when using BTU/kWh is "higher heating value" vs "lower heating value". Different modeling teams use different conventions -- and I always forget which one GCAM is using..

I've compared the output to general heat rate assumptions for each technology and they are reasonably close. Can you provide a bit more info on "higher" vs "lower" heating values and how that might impact this output?

[pralitp]

It is this issue:
https://en.wikipedia.org/wiki/Heat_of_combustion#:~:text=Note%3A%20Higher%20heating%20value%20(HHV,water%20being%20in%20vapor%20form.

The reason I brought it up is that I have been bitten in the past by this. Some modeling teams (I think NEMS) use a different convention than we do, and when comparing results we would be off by a constant factor, and this is the reason.

I just want to make sure there wasn't a definition issue between GCAM's heat rates and what GO uses.

[kmongird]

It is this issue: https://en.wikipedia.org/wiki/Heat_of_combustion#:~:text=Note%3A%20Higher%20heating%20value%20(HHV,water%20being%20in%20vapor%20form.

The reason I brought it up is that I have been bitten in the past by this. Some modeling teams (I think NEMS) use a different convention than we do, and when comparing results we would be off by a constant factor, and this is the reason.

I just want to make sure there wasn't a definition issue between GCAM's heat rates and what GO uses.

Got it, thanks for the extra info. CERF would assume a higher heating value in this case and I am getting confirmation that GO is the same.

[kmongird]

@pralitp, based on a conversation with Matthew, we've switched the heat rate extraction process to pull from the exogenous efficiency file for GCAM rather than collecting from the file that's written to the database. Most of the code is the same as before, the only real additions are grabbing the file and converting from efficiency to the I-O coefficient, but if you can take a quick look to confirm it looks good I would appreciate it