Adds demand-limitting capacity constraint

[dalonsoa]

Description

Adds a new (default) constraint that limits the combined capacity being installed to just matching the demand, no more. While such a condition should be reached automatically in general by minimising the costs, it should not harm to impose it via an upper limit constraint as there might be several local minima and have the solver falling in one of them.

The constraint is setup such that utilisation factors are taken into account, so if there is only a technology with an utilisation factor of 0.1 in a timeslice, then the installed capacity can be up to 10 times the peak demand, such that the production can indeed satisfy the demand.

Only tutorial docs\tutorial-code\2-add-agent\2-multiple-objective has been affected by this new constraint. As seen in the modified output files, the result is a drastic redistribution of the investment by each agent, now both looking very similar, with a reduction of the combined total capacity. I'm not entirely sure if this is reasonable or not. I guess that if we are now constraining the installed capacity, the influence on the different decision objectives is less relevant, as the search space is much smaller... @ahawkes , what do you think?

I've removed the specific list of constraints for the residential sector in the TOML file for this tutorial so it uses the default settings, like the other sectors.

Fixes #323

Type of change

Please add a line in the relevant section of CHANGELOG.md to document the change (include PR #) - note reverse order of PR #s.

• [x] New feature (non-breaking change which adds functionality)
• [ ] Optimization (non-breaking, back-end change that speeds up the code)
• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] Breaking change (whatever its nature)

Key checklist

• [x] All tests pass: $ python -m pytest
• [x] The documentation builds and looks OK: $ python -m sphinx -b html docs docs/build

Further checks

• [x] Code is commented, particularly in hard-to-understand areas
• [x] Tests added that prove fix is effective or that feature works

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 71.29%. Comparing base (d331f46) to head (5aeea97).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## develop #355 +/- ## =========================================== + Coverage 71.24% 71.29% +0.04% =========================================== Files 44 44 Lines 5870 5880 +10 Branches 1158 1159 +1 =========================================== + Hits 4182 4192 +10 Misses 1366 1366 Partials 322 322 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[tsmbland]

I haven't looked at the code yet, but the results look much more reasonable now. Agent 2 was massively overinvesting before because it uses EAC which is negative, so could 'minimise costs' by overinvesting. This is no longer an option. I guess EAC and LCOE are similar enough in how they rank the technologies that Agent 1 and 2 look very similar when this constraint is imposed. In this case it probably makes more sense to use a different objective for the tutorial so there's more of a difference between the two agents, but that's a future job for me.

[tsmbland]

I think this mostly makes sense but I'm still confused about a few things. For example, what happens if you have two timeslices, one with demand=1 and UF=1, and the other with demand=0.1 and UF=0.1. It looks like capacity would then be allowed to reach the point where it can meet demand=1 with a UF of 0.1 (which is much more than it actually needs)? Is that right?

[dalonsoa]

That's a very good point. In that case, the capacity constraint will be much higher than needed. I'll review the code to account for that circumstance.