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 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, Mayfield et al. (2023), Rutovitz et al, (2024), or Ram et al. (2020)).
• • JEDI already specifies employment factors for CCS upgrades.
• • For the upgrade techs and CCS upgrades from non-JEDI sources, employment factors are assumed to be half of those of new 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).

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 capacity.

Issues resolved

Known incompatibilities

Relevant sources or documentation

Charge code for review

GDOP.12495.25.01.01

Validation, testing, and comparison report(s)

Comparison reports pending.

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

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.

[patrickbrown4]

Can you add an inputs/employment/README.md file describing the sources (with links) and explicit units for each of the files in this folder?

[patrickbrown4]

We should also add a section on the employment calculations to the docs.

[patrickbrown4]

Sorry I missed this earlier but it seems like there should be a / 2 here

Suggested change

	* employment_factor_inter_transmission("fom") }
	* CAPTRAN_ENERGY is defined in both directions so needs to be divided by 2
	* employment_factor_inter_transmission("fom") / 2 }

[patrickbrown4]

Actually it looks like we're high by a factor of 2 in the objective function too (so it makes sense why it's not included here):

ReEDS/c_supplyobjective.gms

Line 180 in 13224b8

transmission_line_fom(r,rr,trtype) * CAPTRAN_ENERGY(r,rr,trtype,t) }

Let's do the fix for that in a separate PR though

[patrickbrown4]

Thinking about it more, I'm not sure I understand how a transmission employment factor in terms of [job-years/MW] would work, so maybe best to discuss. The alternative would be to keep it in [job-years/$] and use equations similar to the transmission FOM calculation (with interface-dependent costs) in the objective function:

ReEDS/c_supplyobjective.gms

Lines 178 to 188 in 13224b8

	* transmission lines
	+ sum{(r,rr,trtype)$routes(r,rr,trtype,t),
	transmission_line_fom(r,rr,trtype) * CAPTRAN_ENERGY(r,rr,trtype,t) }
	* LCC and B2B AC/DC converter stations
	+ sum{(r,rr,trtype)$[lcclike(trtype)$routes(r,rr,trtype,t)],
	cost_acdc_lcc * 2 * trans_fom_frac * CAPTRAN_ENERGY(r,rr,trtype,t) }
	* VSC AC/DC converter stations
	+ sum{r,
	cost_acdc_vsc * trans_fom_frac * CAP_CONVERTER(r,t) }

[atpham88]

I updated this term using trans_fom_frac and created an issue for CAPTRAN_ENERGY terms in objective function #127 so we remember to fix it in a separate PR.

[patrickbrown4]

Sorry, I think we discused this but am forgetting the details. How does it work to have job-years/MW for transmission FOM? I would think that 1000 MW on a 100-mile path would have more O&M requirements than 1000 MW on a 1-mile path, but if the units are [job-years/MW], they'd come out the same.

Also can you specify the units used for each jtype as noted above?