Error solving s4x1 --year 2024 : infeasible or unbounded problem

[TMBrindle]

I have successfully had the mode solve for s4x1 2030 but get errors when I try to run for 2024.

core error seems to be an issue with the input files - the error text highlghts p1_batteries_1 but this is just the first entry in the gen_info.csv input file and I can't see that there are any issues with the input file - it is very similar to the 2030 input file which solved...

Curious if other have encountered this error?

ValueError: No value for uninitialized NumericValue object SuspendGen[p1_batteries_1,2016.0,2024]

Barrier solved model in 0 iterations and 0.21 seconds (0.38 work units)
Model is infeasible or unbounded
WARNING: Loading a SolverResults object with a warning status into
model.name="unknown";
    - termination condition: infeasibleOrUnbounded
    - message from solver: Problem proven to be infeasible or unbounded.
---------------------------- end of solver output ----------------------------

Solver finished. Total time spent in solver: 34.80 s.
ERROR: evaluating object as numeric value:
SuspendGen[p1_batteries_1,2016.0,2024]
        (object: <class 'pyomo.core.base.var.VarData'>)
    No value for uninitialized NumericValue object
    SuspendGen[p1_batteries_1,2016.0,2024]

================================================================================

Solver terminated without a solution:
  Solver Status: warning
  Termination Condition: infeasibleOrUnbounded
Check the solver log above for more details.

================================================================================
Terminating early due to error:
    RuntimeError: Solver failed to produce a solution.
--------------------------------------------------------------------------------
The error occurred at
    > __main__.<module>:9
    > switch_model.main.main:42
    > switch_model.solve.main:236
    > switch_model.solve.solve:1262
Run with --full-traceback to see more details or --debug to debug interactively.
================================================================================

[mfripp]

The standard model is currently infeasible for 2024 for a few reasons (some of these may be due to changes in my version that I'll post soon):

Zone p46 in western Wisconsin can't meet its load requirements in at least one hour when when spinning reserves, line losses and forced outages are in place. You may not have this problem until you get the newer data with forced outages. I don't have a great solution for this, since in principle it means that zone did not have a secure power supply in 2024 (or something is wrong with our generator or transmission inventory). For now, you can work around it by adding --include-module switch_model.balancing.unserved_load when running 2024 cases (then keep an eye on UnservedLoad.csv in the outputs)

Several capacity obligations can't be met in the 2024 model, either because we have the wrong data on existing plants or on the rules in place, or because they were actually violated in 2024.

• minimum capacity for offshore wind in NY and RI
• RPS obligation in NY

These can be prevented by specifying --exclude-modules study_modules.min_capacity_constraint study_modules.rps_regional on the command line. It doesn't really make sense to enforce a capacity obligation in 2024, since the model is not allowed to add capacity then (it's an already-built system).

In my newer datasets (soon to be released), there are limits on growth of wind, solar and gas turbines based on our research and assumptions about current market conditions. These are a little brittle, since PowerGenome only allows specifying a limit on total capacity of each type, not capacity added. So the upstream code (make_emission_policies.py) has to calculate how much existing capacity of each type will make it through to the model for each year, then set the limit to [existing] + [allowed growth]. The calculation of existing capacity isn't quite right yet, so these caps don't work exactly right. In particular, I think it's estimating existing capacity a little low in 2024, then setting the cap below the amount that makes it through to Switch, so the growth cap ends up making the model infeasible. I'll keep working on this, but for now, the solution is to specify --exclude-module study_modules.max_capacity_constraint on the command line for 2024 models. This is probably reasonable anyway, since there's no leeway to adjust capacity in 2024 anyway.

So in total, my advice when running 2024 models is to add these flags to the command line (or adjust via modules.txt):

--include-module switch_model.balancing.unserved_load --exclude-modules study_modules.min_capacity_constraint study_modules.max_capacity_constraint study_modules.rps_regional

Also, as an FYI, I found the specific problems by using --include-module study_modules.diagnose_infeasibility on the switch solve command line. First I added it on its own, which then reported a bunch of constraints that it wanted to relax, some of which seem too fundamental to relax. So then I added an additional flag --no-relax Distributed_Energy_Balance BuildGen_bounds Enforce_Commit_Upper_Limit. Then I solved again, added some more constraints to the --no-relax list, and repeated until I had a small list of constraint violations that made sense. On the last run, I ran with --include-module study_modules.diagnose_infeasibility --no-relax Distributed_Energy_Balance BuildGen_bounds Enforce_Commit_Upper_Limit Enforce_Dispatch_Upper_Limit Enforce_Hydro_Generation CommitGenSpinningReservesUp_Limit Force_Off_Unavailable_Gens Enforce_Hydro_Extraction Enforce_Wnode_Balance and got back a message that the following constraints were violated, which gave me the info I needed to write the notes above:

Enforce_Min_Capacity['MinCapTag_NY_offshorewind', 2024] violated by 2.0 units
Enforce_Min_Capacity['MinCapTag_RI_offshorewind', 2024] violated by 0.6999999999999993 units
Enforce_Max_Capacity['MaxCapTag_GasTurbineSupply', 2024] violated by 8945.36999999993 units
Enforce_RPS_Share['ESR_NY_rps', 2024] violated by 9085635.963219495 units
Zone_Energy_Balance['p46', 73] violated by -55.458341229357444 units

There's quite a lot of judgment involved in using study_modules.diagnose_infeasibility. By default, it relaxes every constraint in the model, then chooses a fairly random collection of constraints to violate in order to make the model feasible. I like to use the --no-relax flag to adjust this set until it gives me a clear idea of what is going wrong in the model.

As a general principle, this usually means enforcing more fundamental technical constraints (e.g., Enforce_Commit_Upper_Limit, which says unit commitment has to be below the installed capacity for each generation project) while allowing the model to relax the more general constraints, e.g., the RPS or the zonal energy balance. That way, I can reach conclusions like "oh, we can't meet the RPS (or load balance) with the capacity that is available to install" (if the RPS or load balance is violated when I enforce the capacity, commitment and dispatch limits).

I'm not sure why all the hydro limits kept popping up in the early stages, but I gradually enforced them whac-a-mole style (added any that were violated to the --no-relax list), and eventually the model was happy to enforce them, but then couldn't meet the RPS obligation. I also usually like to include Distributed_Energy_Balance in the --no-relax list because this is the distributed counterpart to Zone_Energy_Balance. Usually if you enforce Distributed_Energy_Balance (load balance in the distribution network), it chases the infeasibility up to Zone_Energy_Balance (load balance in the transmission network), which tells you what you need to know: this system can't meet load while respecting all the other rules.

[mfripp]

I think you asked at one point about how to combine a 2024 period and later periods in the same model. This can be done, but I think there are a couple of reasons to avoid it.

Planning reserve margins (PRMs) and unserved load. We currently require the same PRM in all years. If 2024 had some slack capacity, this would be OK, but our version is currently short of capacity in 2024. You can get around the shortfall by including the unserved_load module as noted above. But then you have to decide whether to run the no-PRM case or the PRM case (currently requiring 2% extra capacity on top of spinning reserve margins, losses and forced outages). If you use the PRM, I think Switch will leave some load unserved in order to maintain 2% spare capacity at all times on top of operating needs, including spinning reserves, which isn't how the system is actually run. (Power systems enforce PRMs in the planning stage but not the operational stage.) On the other hand, if you turn off the PRM, the model will build too little capacity in later years. Neither of these are quite right. Another option would be to write a mini-module (or add code to switch/study_modules/planning_reserves_extreme_days.py) to relax the PRM during historical periods, but keep it in effect in future periods. (It would also be possible to add an argument to the add_extreme_days.py script to prevent defining PRM days for historical periods.)

(Actually, now that I think of it, the unserved_load module will probably cancel out any effect of the PRMs, since the model can just leave load unserved on extreme days, and there won't be any cost because those days are labeled as having 0 probability of occurring. It may also make it hard to get the model to meet load on peak days, since those are currently indicated as occurring once in 7 years, so leaving load unserved may look cheaper than building enough capacity for those days. That could be mitigated by setting a very high unserved load penalty.)

RPS, minimum-capacity and maximum-capacity constraints. Like the load balance, the 2024 model can't currently meet these requirements. I added a script you can use to remove these rules for historical years for individual models (adjust/remove_historical_policies.py'). But I wouldn't want to do this all the time because it blocks our ability to use 2024 for calibration, e.g., to see if it was possible to meet these policies and if not, why not. If we do adjust the model to the point where these limits can be met, then they could also be important for getting prices right, e.g., going to negative power prices if needed to meet the RPS obligation, which might not happen if the rules are removed (although there we probably have a bigger problem from the fact that we are not modeling the PTC for the renewable facilities that still have it). As an alternative, for single-period models, you can activate and deactivate these policies to get the model to solve by turning the relevant modules on and off, as noted above. For carbon constraints, I don't think you need to do anything, because all the ones currently in effect have escape prices, so they won't make the model infeasible.

So running run a model with both historical and future periods is messy and I'm inclined to avoid it. But that said, you can now do it by running these commands (or similar):

python -m pdb pg_to_switch.py pg/settings switch/in --case-id s4x1 --year 2024 --year 2030`
python adjust/remove_historical_policies.py switch/in/foresight/s4x1
cd switch
switch solve --inputs-dir in/foresight/s4x1 --outputs-dir out/foresight/s4x1 --include-module switch_model.balancing.unserved_load

[mfripp]

Oh, also, to get that to work, you need to update the model_year and model_first_planning_year settings in model_definition.yml to define a continuous strip of time, e.g.,

model_first_planning_year: [2024, 2025]
model_year: [2024, 2030]