You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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).
The text was updated successfully, but these errors were encountered:
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).
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.
The EIA Form 923 generation data, returned from here:
ElectricityLCI/electricitylci/eia923_generation.py
Line 138 in 4ba67fb
is used for scaling upstream LCI to their corresponding annual quantities, namely in the following modules:
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:
As demonstrated here:
ElectricityLCI/electricitylci/geothermal.py
Line 65 in 9015245
Notably, this isn't carried out for solar PV, solar thermal or wind farms.
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).
The text was updated successfully, but these errors were encountered: