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

How important to aggregate prime movers in upstream generation? #280

Open
dt-woods opened this issue Jan 22, 2025 · 2 comments
Open

How important to aggregate prime movers in upstream generation? #280

dt-woods opened this issue Jan 22, 2025 · 2 comments
Labels

Comments

@dt-woods
Copy link
Collaborator

The EIA Form 923 generation data, returned from here:

def eia923_download_extract(year, group_cols=None):

is used for scaling upstream LCI to their corresponding annual quantities, namely in the following modules:

  • natural_gas_upstream.py
  • geothermal.py
  • solar_upstream.py
  • solar_thermal_upstream.py
  • wind_upstream.py
  • nuclear_upstream.py

Within a handful of these modules, the generation data is aggregated to account for "multiple rows for the same facility and fuel based on different prime movers"), namely:

  • natural_gas_upstream.py
  • nuclear_upstream.py
  • geothermal.py

As demonstrated here:

geo_generation_data = (

Notably, this isn't carried out for solar PV, solar thermal or wind farms.

  • Solar PV/thermal have at least one instance of a dual prime mover (e.g., facility 59817 in 2022 with prime movers other, 'OT', and photovoltaic, 'PV').
  • Wind generation has two prime movers (onshore and offshore), but I haven't seen both recorded for a single facility

My question is how important is the summation of generation across prime movers within these fuel-specific datasets?

Is this the kind of thing that gets captured in the aggregation methods found in generation.py (e.g., calculate_electricity_by_source)?

I would like to harmonize the methods for this across the upstream modules (see #279).

@m-jamieson
Copy link
Collaborator

For natural gas, this is important due to the contributions of different prime movers for combined cycle facilities: prime mover types CT (combustion turbines) and CA (steam turbines). There can often be "duct-burners" used in the steam portion to add additional heat/electricity generation. If that additional natural gas isn't captured, we can end up with some unrealistically high combined-cycle plant efficiencies.

Nuclear units have separate Nuclear Unit Ids that are assigned to the same Plant ID, so those should be aggregated. The prime movers for nuclear are all steam turbines (ST).

Given the lack of "fuel" upstream inputs in geothermal, I'm not exactly sure what there is to aggregate there other than generation amounts. There are two possible prime mover types - ST (steam turbines) and BT (binary cycle turbines).

I'd think if you find similar instances for other types of facilities, they're worth capturing, but like with geothermal, I'm not sure what we would capture as "fuel inputs" - I guess the quantities tagged as "Heat" in the final unit processes.

RE: other aggregation methods, If they were kept as separate rows and not aggregated when reading in the EIA923 data, I suspect that calculate_electricity_by_source would capture these (or the aggregate facility flows).

@dt-woods
Copy link
Collaborator Author

Okay. I think what was being aggregated is just the electricity, "Net Generation (Megawatthours)", as each prime mover contributes some amount to the facility's total net generation. I'm guessing that the LCI data are not prime-mover specific so it is okay to lose this specification (albeit solar PV and solar thermal appear to be completely overlapped by prime mover).

For the time being, I think we'll keep the aggregation across prime movers in geothermal.py, as I'm not 100% certain that the generation.py aggregation methods are designed for handling the prime-mover-caused duplicate rows.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants