Fix Monte Carlo random sampling for VRE siting availability

[patrickbrown4]

Summary

This PR partially addresses #41 by fixing the Monte Carlo sampling functionality for VRE siting availability.

Latin hypercube sampling for VRE siting availability is still broken; we can decide whether to fix that here or in a followup PR.

Technical details

Implementation notes

• The original sampling approach for siting was designed around the old region/class profiles; now that we use site-level profiles, that approach would be much more time- and memory-intensive.
• We used to reweight the profiles based on the capacity in the sampled supply curve. Profiles do vary at the site level (see Fix Monte Carlo sampling for demand and VRE availability #41 for some background discussion and plots), but not very much.
• So now we read a set of site-level profiles for the most permissive siting scenario included in the specified Monte Carlo distribution. For example, if the distribution includes both limited and reference access, the reference-access site profiles will be used; if it includes reference and open, the open-access profiles will be used.
  • There are sites in limited that are not in reference/open, and sites in reference that are not in open. So for Monte Carlo sampling, we ignore site mismatches between the profiles and the supply curves (printing messages to the user)

Additional changes

• writecapdat.py: I was having trouble following the structure while debugging, so reorganized to put the globals at the top and renamed a few variables (sorry)
  • The substantive changes ended up just being to assign_class(); I was getting float classes (instead of integers) without this change, which were messing up downstream processing.
• mcs_sampler.py: We no longer need the exogenous or prescribed capacity processing, so those parts are removed along with the recf profile processing.
• mcs_distributions_default.yaml:
  • Updated AEO switches from 2025 to 2026
  • Tweaked a few scenario definitions to match what was used in the conference paper (we could still do more here to unify the naming and clarify the structure and options)

Issues resolved

#41 (partially)

Known incompatibilities

• I'm still getting an error for the MonteCarlo_LHS (latin hypercube) case when siting is included; I'm not sure why it's behaving differently from MonteCarlo_Random. I think the fix to random sampling is valuable enough to get in on its own, but if the LHS case ends up being a quick/easy fix, we can include it here too.

TODO before merge

• Double check that the supply-curve sampling results make sense. Are all the site capacities somewhere between the capacities in the scenarios that define the distribution?
• Debug full-USA MC run (error in missing_class_resource.csv)
  • Consider doing Allow users to specify number of tech classes #59 first

Validation, testing, and comparison report(s)

The MonteCarlo_Random case now works with VRE siting included in the distribution.

I'll include a full-US comparison once it finishes.

Checklist for author

Details to double-check

• Charge code provided to reviewers
• Included comparison reports for appropriate test cases
• 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 (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