MGA updates & employment outputs

[atpham88]

Summary

This PR adds some updates to MGA, cplex settings for national MGA runs, and employment outputs using employment factors from JEDI/WIRED and literature.

Technical details

Implementation notes

• Employment factors input files are added to inputs/employment folder.
• b_inputs.gms: Read in employment factors input (from JEDI/WIRED, Mayfield et al. (2023), Rutovitz et al, (2024), or Ram et al. (2020)).
  • JEDI/WIRED already specifies employment factors for CCS upgrades.
  • For the upgrade techs and CCS upgrades from non-JEDI/WIRED sources, employment factors are adjusted by upgrade ratio calculated as the ratio of the difference in capital costs between the initial techs and the upgraded tech divided by the capital costs of the initial techs.
• d_mga.gms: Add option to run MGA max/min for all capacity, generation, and employment (sum of construction, FOM, and VOM jobs-years for power plants and transmission lines).
• e_report.gms: Add employment outputs.
• Two additional cplex setting files are added for MGA runs, cplex.op3 and cplex.op4. Default setting is cplex.op3. Users can switch to cplex.op4 if runs still hang with cplex.op3 settings:
  • cplex.op3 and cplex.op4 are specifically for MGA runs which have difficulties with cplex.opt and cplex.op2. They differ from cplex.opt and cplex.op2 in that they set predual = -1, which does not send dual to optimizer to reduce time; sets barcrossalg = 1, which only performs primal crossover; and sets baralg = 3 (cplex.op3).
• Transmission FOM employment is not calculated based on JEDI/WIRED transmission FOM employment factors but is scaled from transmission construction employment using trans_fom_frac.

Switches added/removed/changed

• GSw_EmploymentFactor: Employment factor by technologies, options including jedi, and recent literature including mayfield, rutovitz, and ram. Default is jedi.
• GSw_gopt_mga: cplex opt file for MGA run. Default is 3 (cplex.op3).
• GSw_MGA_Objective: Add generation and employment options.
• GSw_MGA_SubObjective: Add gentech option to maximize/minimize all generating capacities.

Issues resolved

Known incompatibilities

Relevant sources or documentation

Charge code for review

GDOP.12495.25.01.01

Validation, testing, and comparison report(s)

There's no changes in the USA default case

MGA runs which max/min employment (Pacific and Western Interconnection):

Checklist for author

Details to double-check

• Charge code provided for review
• Included comparison reports for appropriate test cases
• Documentation updated if necessary
• If input data added/modified:
  • Dollar year recorded and converted to 2004$ for GAMS
  • Timeseries are in Central Time
  • Units are specified
  • Preprocessing steps have been documented and committed to ReEDS_Input_Processing
  • New large data files handled with .h5 instead of .csv
  • If spatially resolved inputs are modified, the following visualizations for each file are included in the PR description (time-averaged if the inputs are time-resolved):
    • Map of absolute values before
    • Map of absolute values after
    • Map of differences: (after - before) or (after / before)
  • If entries are added/removed/changed in the EIA-NEMS unit database:
    • Changes have been committed to ReEDS_Input_Processing
    • hourlize/resource.py was rerun to regenerate the existing/prescribed VRE capacity data
• Code formatting standardized
• Reusable functions used where possible instead of copy/pasted code

General information to guide review

• Zero impact on results of default case
• No large data file(s) added/modified
• No substantive impact on runtime for full-US reference case
• No substantive impact on folder size for full-US reference case
• No change to process flow (runbatch.py, d_solve_iterate.py)
• No change to code organization
• No change to package requirements (environment.yml or Project.toml)

Did you use LLM tools (chatbot or copilot) in the preparation of this PR? If so, describe how

No

Tag points of contact here if you would like additional review of the relevant parts of the model

[patrickbrown4]

Thanks! Sorry about all the minor formatting stuff; just trying to avoid conflicts since a few other open PRs touch these same files. Happy to discuss the transmission FOM stuff if helpful.

[bsergi]

One question on the transmission jobs reporting but otherwise looks pretty good to me. Once you address that one it's good from my end so approving.

Also, I think the PR text about the assumption of 50% employment factors for CCS is out of date--if that's correct can you update it?

[bsergi]

Why only reference JEDI instead of all three option?

[atpham88]

I added references for the papers now.

[atpham88]

Corrected PR text for upgraded techs as well

[bsergi]

Are the other references added here part of the employment factors or were they just swept up in an update? It might be cleaner to revert any additions that aren't new citations related to this PR but it doesn't matter too much.

[bsergi]

I just realized these come in with the README in the employment folder so you can ignore this comment.

[patrickbrown4]

FWIW I always just take the results of the direct Zotero dump, even if there are new records unrelated to the PR. My impression is that the large majority of records aren't actually cited in the docs. We could implement a two-step process where we add a script to downselect to the actually cited references, but that should be its own PR.

[bsergi]

Since the AC portion is only defined for r < rr I think this would result in no jobs from AC being assigned to the rr regions. Maybe that's the intention here, but if not you might need something like sum{rr, (employment_transmission_interface(jtype,r,rr,t) + employment_transmission_interface(jtype,rr,r,t) ) / 2 }. I'm not sure the DC lines would still be correct with that approach though; another option might be to repeat the AC transmission calculation for TRAN_CAPEX_BINS.l(rr,r) and then include the same division by 2 term as the DC approach.

[patrickbrown4]

Ah good call, thanks a lot for the catch. These are so easy (for me at least) to mess up. So I think the transmission construction parameter above would be changed to:

employment_transmission_interface("construction",r,rr,t) =
    employment_factor_inter_transmission("construction")
    * trans_cost_cap_fin_mult(t)
    * (
* AC: TRAN_CAPEX_BINS is only defined for r < rr, so add the reverse direction
        sum{tscbin$[routes_inv(r,rr,"AC",t)$tsc_binwidth(r,rr,tscbin)],
            TRAN_CAPEX_BINS.l(r,rr,tscbin,t) - sum{tt$tprev(t,tt), TRAN_CAPEX_BINS.l(r,rr,tscbin,tt)}
        }
        + sum{tscbin$[routes_inv(rr,r,"AC",t)$tsc_binwidth(rr,r,tscbin)],
            TRAN_CAPEX_BINS.l(rr,r,tscbin,t) - sum{tt$tprev(t,tt), TRAN_CAPEX_BINS.l(rr,r,tscbin,tt)}
        }
* DC: INVTRAN is already defined in both directions
        + sum{trtype$[routes_inv(r,rr,trtype,t)$(not aclike(trtype))],
            transmission_cost_nonac(r,rr,trtype) * INVTRAN.l(r,rr,trtype,t)
        }
* Since we now have both AC and DC in both directions, divide everything by 2
    ) / 2
;

[bsergi]

that looks good to me. I like that approach since it makes everything consistent downstream from that point too.

[patrickbrown4]

Looks good to me after these last few changes. Thanks (and sorry for all the back and forth on the transmission calculations)!

[patrickbrown4]

Ah good call, thanks a lot for the catch. These are so easy (for me at least) to mess up. So I think the transmission construction parameter above would be changed to:

employment_transmission_interface("construction",r,rr,t) =
    employment_factor_inter_transmission("construction")
    * trans_cost_cap_fin_mult(t)
    * (
* AC: TRAN_CAPEX_BINS is only defined for r < rr, so add the reverse direction
        sum{tscbin$[routes_inv(r,rr,"AC",t)$tsc_binwidth(r,rr,tscbin)],
            TRAN_CAPEX_BINS.l(r,rr,tscbin,t) - sum{tt$tprev(t,tt), TRAN_CAPEX_BINS.l(r,rr,tscbin,tt)}
        }
        + sum{tscbin$[routes_inv(rr,r,"AC",t)$tsc_binwidth(rr,r,tscbin)],
            TRAN_CAPEX_BINS.l(rr,r,tscbin,t) - sum{tt$tprev(t,tt), TRAN_CAPEX_BINS.l(rr,r,tscbin,tt)}
        }
* DC: INVTRAN is already defined in both directions
        + sum{trtype$[routes_inv(r,rr,trtype,t)$(not aclike(trtype))],
            transmission_cost_nonac(r,rr,trtype) * INVTRAN.l(r,rr,trtype,t)
        }
* Since we now have both AC and DC in both directions, divide everything by 2
    ) / 2
;