Update math lower bound capacity setting

[brynpickering]

Fixes #643

Hopefully this does the trick @sstroemer!

Summary of changes in this pull request

• Moved capacity variable lower bound setting to own constraints.
• Added equivalent constraints for area_use and source_cap.

Reviewer checklist

• Test(s) added to cover contribution
• Documentation updated
• Changelog updated
• Coverage maintained or improved

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.97%. Comparing base (ed25596) to head (cceef56).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff            @@
##             main     #700    +/-   ##
========================================
  Coverage   95.97%   95.97%            
========================================
  Files          29       29            
  Lines        4048     4048            
  Branches      849      578   -271     
========================================
  Hits         3885     3885            
  Misses         72       72            
  Partials       91       91            

see 2 files with indirect coverage changes

[sstroemer]

So I've thought about this, and noticed the following points.

Lower vs. upper bound

• The lower bound of any cap is now either cap_min or cap_min * purchased_units
• The upper bound of any cap is both cap_max and cap_min * purchased_units

If purchased_units is binary nothing unforeseen happens, but if purchased_units is integer-valued, these now work differently (since the lb scales with number of units, the ub is limited to one unit).

area_use_min currently reads: Limits the lower bound of the area_use decision variable to this value. This feels more like the second case, but I assume the first case (binding it to the number of units) is more intuitive for a user? But the next point (storage capacities) made me unsure - maybe the second case is the intended one.

If it's the first, then the docstrings for these parameters would need to be changed accordingly, example: Limits the lower bound of the area_use decision variable to this value. Note that this scales with the number of aggregated units, modeled by purchased_units, if active.

Storage capacities

storage_capacity_units_milp still exists right? As far as I see, storages are the only tech now having a separate "per unit" and "total" parameter. Now the maximum sets

storage_cap <= storage_cap_max * purchased_units

while the per unit sets

storage_cap == purchased_units * storage_cap_per_unit

Not saying this is wrong, it just feels like potential for someone to overlook / misunderstand the interactions and meanings of the different settings.

---

Unsure what the best way is. Maybe it's unifying everything? Maybe it's not, but then more explicitly pointing out the differences?

[brynpickering]

Good catch, as usual @sstroemer!

The lower bound scaling with the number of units is expected. If you buy two units, the lowest capacity you can achieve overall is the minimum allowed purchase capacity of each of those two. When operating the units, then the minimum load rate is based on the number of units operating at that moment (<= number of purchased units). This is handled by a different constraint (flow_out_min_milp). I'll updated the description of each.

As to the per_unit vs min/max: this is based on whether to activate available_flow_cap or not. So, if you use per_unit then you say that if a unit is purchased, it is at a fixed capacity. This is expected to be used for cases where units_max >= 1. If you use min/max capacities, then it allows you to have a choice on the capacity of the purchased unit whilst still enforcing a minimum capacity that is initiated only when a non-zero quantity of that technology is invested in. This is_expected to be used only for cases where units_max == 1.

Clearly we need to document things better, and to group constraints more appropriately to make it clear which ones are linked. We could also add to the where string of available_capacity that units_max must equal 1 (i.e. a binary decision) for that decision variable to be activated.

[sstroemer]

Oh yeah, that makes a lot of sense!