Make the interconnection queue constraint user-adjustable

[patrickbrown4]

Summary

This PR adds a switch, GSw_QueueConstraintYears, indicating how many years for which to apply the interconnection queue capacity limit. My proposed default setting, applied here, is 3 years, but happy to discuss.

That's motivated by a few observations from the 2026 queue data from LBNL:

• Slide 43: 25% of projects reach an interconnection agreement in 20 months. The median is a lot higher (45 months), but the queue is so big that 25% is still a lot.
• Slide 44: The trends vary regionally. The medians in the west, southeast, and ERCOT are all under 2 years.
• Duration from interconnection request to COD is longer (slides 51-53), but there's still a decent fraction of projects that reach operations in under 3 years starting from the date of interconnection request.

It's also motivated by a few potentially unintended consequences of the pretty firm ($10,000/kW) queue constraint:

• With the queue constraint active, the model builds endogenous H2-CT, H2-CC, and offshore wind in 2030 (which would be surprising on a cost-only basis); they go away if the queue constraint is not applied in 2030
• Paul observed some areas building relatively long-duration batteries (10+ hours) in early years while the queue constraint is active (because the constraint only applies to power capacity), which doesn't really match near-term trends
• Trying to make sense of near-term results is complicated when trends like these are driven solely by the queue constraint

Technical details

Implementation notes

• The queue constraint data is modified upfront in copy_files.py to avoid adding new GAMS code

Additional changes

• Moved the queue input parameters to inputs.h5
• Renamed cap_limit to queue_limit to make it easier to find
• Added a reedsplots.map_queue() function

Switches added/removed/changed

• GSw_QueueConstraintYears (default 3): How many years (starting from and including this_year) to apply the interconnection queue capacity constraint for (0 turns off the constraint)
  • So with this_year = 2025, a setting of 1 applies the queue in 2025, a setting of 3 applies it in 2025–2027, etc. (With this_year = 2026 as in Update years to endogenous, this year, and minor unit upgrade in NEMS #221 it will be 2026 and 2026–2028.)

Relevant sources or documentation

• 2026 queue data from LBNL

Validation, testing, and comparison report(s)

Here's a compare report for the USA_defaults case: results-v20260915_mainK0_USA_defaults,v20260915_queueK0_USA_defaults.pptx. With the queue constraint lifted in 2030, we see the changes noted above (endogenous H2 and offshore wind go away), in addition to a shift from PV and storage to land-based wind and gas-CC.

Here's an additional comparison with 3-year steps: results-y3_Q5,y3_Q2,y3_Q0.pptx

Here's the queue capacity with 3-year steps:

20260921

Confirmed changes relative to main with GSw_QueueConstraintYears = 5 are within the noise: results-v20260918_mainK0_USA_defaults,v20260918_queueK1_USA_Q5.pptx

Checklist for author

Details to double-check

• Charge code provided to reviewers
• Included comparison reports for appropriate test cases
• Documentation updated if necessary
• Code formatting standardized

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 (runreeds.py, reeds/core/solve/solve.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

[wesleyjcole]

Until we change this_year to 2026, the 3-year timestep solution is pretty unreasonable in 2029 without the queue constraint due to wind+tax credit overlapping with no queue constraint. An is already doing that in #221, so I think we'll be good to go.

[wesleyjcole]

Is this needed? Won't queue_limit be empty if the switch is set to zero?

[patrickbrown4]

I just wanted to make extra sure it gets turned off when set to zero, as otherwise it's implicitly based on the interaction of this_year and the data columns included in inputs/capacity_exogenous/interconnection_queues.csv. Otherwise if someone were to add extra historical years of data, or set this_year to something in the future, the constraint would still show up even if the switch is set to zero. I'm not sure if those are realistic possibilities, but I'd feel infinitesimally better not having to worry about it.