Modeling decisions for 221110 electricity physical-unit (MWh) integration

[jvendries]

This discussion is meant to decide how to introduce physical units (MWh) for the electricity generation sector (221110) on top of the monetary 221100 disaggregation already implemented (see #85 and bedrock PR #462). There is no PR for this yet as I am still iterating on the implementation, but I think it would be beneficial to kick-off this discussion before finalizing the implementation and pushing the PR.

The end state is a mixed-unit (hybrid) model: the generation commodity/industry 221110 is expressed in MWh (so its row of B is CO2/MWh), while transmission (221121), distribution (221122), and every other sector stay in dollars. As in #85, I suggest providing feedback in the order the decisions are posted and resolving them in that order, since earlier decisions constrain later ones. Currently the only decision under this discussion is Decision 1 (conversion approach), but I may add others as I continue with the implmentation. Feel free to add other decisions as well.

Summary table

#	Decision	One-line takeaway
1	Conversion approach	Two candidates: "rederive V/U" (scale in $, then convert) vs "apply mixed units directly" (define hybrid coefficients in A-space). Currently using rederive V/U approach.
2	Price-conversion mapping across consumers	Currently using Electric Power Annual's table 2.4 for weighing MWh consumption based on electricity price by end-use sectors.
3	Use MWh values before or after accounting for grid losses	Currently using eGrid MWh values before accounting for grid losses for physical unit conversion but this might underestimate emissions from individual users even if emissions accounting balance is maintained.
4	Treatment of imported electricity in the 221110 physical-unit conversion	Currently using eGrid MWh for domestic production, and the same prices as in decision 2 for import electricity, leading to Adom + Aimp 221110 row to sum to slightly more than eGRID

[jvendries]

1. Conversion approach — "rederive V/U" vs "apply mixed units directly" (central decision)

Proposed code touchpoints: derive_cornerstone_Aq_scaled() and _derive_cornerstone_Aq_from_disaggregated() in bedrock/transform/eeio/derived_cornerstone.py; derive_cornerstone_B_via_vnorm() (same file); year-scaling in bedrock/transform/eeio/cornerstone_year_scaling.py; MWh from us_total_net_generation_mwh() in bedrock/extract/disaggregation/egrid_generation.py.

We need a mixed-unit A and q (everything in $ except 221110 in MWh) and a B with 221110 in CO2/MWh. Two candidate procedures reach the same end state but differ in how the physical conversion is computed and where it sits relative to the existing monetary scaling/inflation pipeline.

• "rederive V/U": run the full monetary scaling/inflation pipeline to obtain model-year $ A and q; reconstruct the V/U/Y/VA flow tables in model-year $; replace the 221110 row and Make intersection $ values with MWh (proportional to $ , via a defined price in $/MWh); set q_221110/x_221110 to MWh; then re-derive the mixed-unit A from the converted tables.
• "apply mixed units directly": define the hybrid A coefficients directly — set the 221110 row physical (MWh per unit of consumer output) and q_221110/x_221110 to MWh, normalizing the 221110 column by physical output — and apportion the eGRID MWh onto the coefficients without round-tripping through reconstructed flow tables.

Modeling implications: "rederive V/U" reuses the validated monetary scaling/inflation machinery unchanged (physical conversion is an isolated final step) and keeps year-scaling entirely in $ space, but it requires reconstructing flow tables from A/q (the inversion is not guaranteed to round-trip exactly) and performs two A derivations. "apply mixed units directly" operates on A/q directly, but it touches the core A normalization (compute_Unorm_matrix/compute_Vnorm_matrix) and must add an explicit rule to keep the physical row/column out of the monetary scaling/inflation path.

I am currently leaning toward "rederive V/U" for the first implementation because it confines the change to a final conversion step and avoids any possible scaling of the physical row by construction. Additinally, it is unclear to me at this time how to implement the "apply mixed units directly" method yet (and have not found any analogue in the IO literature).

[bl-young]

replace the 221110 row and Make intersection $ values with MWh (proportional to $ , via a defined price in $/MWh)

Which could vary, right, based on specific customer (commercial, residential, industrial)? - though are those prices for all electricity not just generation...?

[jvendries]

Yes, they could vary based on those customer classes, and that is the intended implementation. But as you mention, the prices we have available are for all electricity and not just generation.

[jvendries]

After further analysis I think we can go with the "apply mixed units directly" path to avoid having to add code to explicitly re-derive U/V/VA/Y after scaling, as both options arrive at the same result. I'm attaching this comparison of both options using a simplified toy example. I think all the math and resulting tables are accurate; please review and let me know if there are any errors.
d_86_analysis_report.md

[jvendries]

2. Use table row and final demand — price-conversion mapping across consumers

Punted from Decision 5 in #85 to this phase of the implemenation.

Main question: Is the current implementation adequate or do we want to revise it?

Current implementation: The current plan is to use Electric Power Annual Table 2.4, Average Price of Electricity to Ultimate Customers by End-Use Sectors 2014 through 2024 (Cents per kilowatthour), to map Industry Codes to one of the end-use sectors, and weight the splits according to each end use sector using the model's target year price (e.g., 2024). The end result is that per dollar of consumption, BEA industries mapped to Table 2.4's "Industry" end use sector would approximately double the amount of MWhs than the BEA's Household Final Demand column which is mapped to the "Residential" end use sector. Per dollar MWh consumption for industries/FD columns mapped to "Commercial" and "Transportation" end use categories would fall somewhere in between. The total MWh consumption for the 221110 row would still be constrained by total MWh avaialble for the target year as obtained from eGrid's data.

Implications:

1. The prices used here reflect the bundled G/T/D electricity price paid by each end-use sector. By basing the weights on these prices, we are assuming that the generation price alone varies by end-use sector as the bundled G/T/D electricity price.

Total Electric Industry

Year	Residential	Commercial	Industrial	Transportation	Total
2014	12.52	10.74	7.10	10.45	10.44
2015	12.65	10.64	6.91	10.09	10.41
2016	12.55	10.43	6.76	9.63	10.27
2017	12.89	10.66	6.88	9.68	10.48
2018	12.87	10.67	6.92	9.70	10.53
2019	13.01	10.68	6.81	9.66	10.54
2020	13.15	10.59	6.67	9.90	10.59
2021	13.66	11.22	7.18	10.20	11.10
2022	15.04	12.41	8.32	11.59	12.36
2023	16.00	12.59	8.04	12.77	12.68
2024	16.48	12.75	8.13	12.75	12.94

2. Redistribution in the L multipliers.

$M = BL$ now attributes more upstream generation MWh/emissions per dollar to industrial-mapped consumers (lowest price → largest row emission factor) and less to residential-mapped consumers (highest price → smallest row emission factor). The trick is that this lives entirely in the total (Leontief) multipliers, not in the direct D emissions. Is this something we are comfortable with?

3. Divergence ins system price average ($q/eGrid q) vs. consumption-weighted price implied by Use + FD row/generation values.

The price conversion for q (total $ 221110 value / total eGrid MWh value) is is derived from the make-side monetary q_V output during construction. For the monetary disaggregation, there might be a small monetary difference when building q_U from the disaggregated 221110 U+Y columns, but it is small (less than 1%). However, the physical unit conversion contrains both q_V and q_U to the eGrid MWh value, silently absorbing any residual dollar imbalance into the implied prices. I think this a defensible choice for the physical row, but we should document it, because the implied system-average price from Make won't match the implied system average price from Use.

Related discussion: #70

[jvendries]

3. Explicit treatment or description of grid losses

Main question: Should the physical MWh values included in the Make/Use/A tables reflect the generation values before grid losses (i.e., generated at the plant level) or after losses (i.e., the MWh values that end users ultimately consume)?

Current approach: The conversion to physical units in centered around the generation sector (221110), while the transmission and distribution sectors (221121 and 221122) remain in monetary units. What this means is that grid losses are not explicitly accounted for in physical units; that is, the values reflected in the monetary-to-physical conversion for 221110 reflect the generation values from eGrid, rather than the final MWh values delivered to end users.

Implications:

1. Since the before grid losses MWh value is higher than the after losses MWh value, the emission factors calculated using the former would be lower on a per MWh basis than the latter. For national level inventory calculations or similar, this should not affect emissions accounting, as the EF would be based on the total MWh generation value and the total emissions generation value. However, at individual user level, careful consideration of their individual electricity consumption value would likely have to taken to determine whether the physical consumption value they report reflects losses or not.

[jvendries]

4. Treatment of imported electricity in the 221110 physical-unit conversion

Surfaced while implementing the class-specific conversion (Decision 2): eGRID measures domestic net generation only, but the 221110 row of the Use table also carries imported electricity (the Aimp row, ultimately Canada/Mexico trade — cf. EIA Electric Power Annual Table 2.14). This decision is about how that imported portion is converted to MWh and how it interacts with the eGRID-total constraint.

Main question: Under class-specific MWh conversion, how should the imported-electricity portion of the 221110 row be (a) converted to MWh, and (b) treated in the eGRID-total normalization, given that the eGRID anchor counts domestic generation only?

Current plan (proposed default):

• The domestic generation output is anchored exactly: q_221110(MWh) = eGRID_MWh, via a single scalar c_col = eGRID_MWh / q$_221110.
• The 221110 sales row is class-tilted per consuming column j with c_j = λ / p_j (Table 2.4 end-use price, Decision 2), where λ is chosen so the converted domestic row (domestic Use + final demand) sums to eGRID_MWh.
• Imports come in on the use side (Aimp), not in domestic q. Proposed default: convert the imported portion of each column with the same consumer class factor c_j (a consumer faces its retail class price regardless of whether the electricity was domestically generated or imported), and compute λ over the domestic row only — so it matches the c_col output anchor (both equal eGRID).

Options:

	Normalization scope (λ)	Import-row conversion factor
A (proposed default)	Domestic row only (= eGRID, matches c_col)	Same consumer class factor c_j
B	Total use (domestic + imports) constrained to eGRID	Same consumer class factor c_j
C	Domestic row only	Distinct import supply price c_imp from EIA Table 2.14 MWh trade data

Implications:

• Under A, the full Adom + Aimp 221110 row sums to slightly more than eGRID — by exactly the converted import MWh. This is physically correct (imports are additional supply on top of domestic generation, ~1% of net generation in the US), and q_221110(MWh) still equals eGRID by construction. The cost is a small, documented gap between the converted row total and the converted output q — i.e., the mixed model's 221110 supply = domestic generation + imports, as it should be. This is in the same spirit as the Make-vs-Use implied-price gap already noted under Decision 2.
• B forces the combined row (incl. imports) onto eGRID, which would shrink domestic intensities to "make room" for imports and effectively re-label imported MWh as domestic generation — not desirable for a generation-anchored model.
• C prices imported electricity on its own supply-side $/MWh rather than the consumer's retail class price. It's defensible but (i) adds a separate supply-side axis orthogonal to the consumer-class tilt, (ii) the Table 2.14 import total is intermediate + final-demand-bound (not just intermediate-use), so anchoring to it over-states the factor, and (iii) it breaks the "every consumer of 221110 faces its own class price" simplification. I'm treating C as deferred / out of scope for the first implementation.

Leaning: Option A — normalize λ on the domestic row (so both q and the domestic row equal eGRID), convert imported electricity at the same consumer class factor c_j, and document that the converted Adom + Aimp 221110 row exceeds eGRID by the (small) imported-MWh quantity, reported separately. Revisit a distinct import supply price only if imports turn out to be material for any 221110 EF.

Related: Decision 2 above; #85 decision 5; bedrock PR #462; EIA Electric Power Annual Table 2.14 (electricity trade, MWh).