Repository navigation
Fix the supply function in quantities.py to impose minimum constraint #335
Description
I've just found why the discrepancy.
- The sector output, taking the values right out of the market, gives the right values as market information is calculated based on the constrains (so figure on the right is correct).
- The MCA information, surprisingly and I don't know why, is obtained by recalculating everything. In this line, it limits the supply so it is not higher than the maximum production, but it does not impose any minimum constrain but to fulfil the demand, and therefore the minimum service constrained is not honoured.
In summary, the calculation for the MCAMetric_Supply.csv is wrong - and I would presume that any other calculation that uses this supply function will also be wrong, as no minimum constrains are imposed but to fulfill the demand.
Originally posted by @dalonsoa in #321 (comment)
Activity
tsmbland commentedon Jun 12, 2024
@dalonsoa Are you working on this, or would you like me to look into it?
ahawkes commentedon Jun 12, 2024
dalonsoa commentedon Jun 12, 2024
@tsmbland , nope, so all yours!
dalonsoa commentedon Jun 21, 2024
So, I've been looking into this and, after digging in the exciting world of decorators and registries, it turns out this function is used whenever
dispatch_production = 'share'is chosen for a sector, which is most of the times. So:So the fix passes through updating the function such that we also calculate a
minimum_productionand impose it here.ahawkes commentedon Jun 21, 2024
dalonsoa commentedon Jun 21, 2024
The maximum production (which includes the utilisation factor) can also prevent this from happening, so also using the minimum service constraint will not lead to a new situation that is not potentially happening already.
Ok, as it is often the case, this is an undocumented/wrongly documented feature of MUSE. If you go to the input file documentation (to this section) it explains what the
investment_productionand thedispatch_productionare. But the valid options for either case (which are the same) are not correct. These options can be found in the code itself (and the API documentation), everything with theregister_productiondecorator. The current options are:maximum,share,matchandcosted. I'm not sure if any of them do what you want.ahawkes commentedon Jun 21, 2024
Wow. Don't all of the 4 options potentially (likely!) contradict the dispatch as computed in the call to highs that we've discussed previously? Why are they all calculated again here? Am I missing something?
dalonsoa commentedon Jun 24, 2024
I've created a PR (#368) to close this issue and, after seeing what files were modified, I think I know why there're two routes for calculating stuff (to be checked): The individual dispatch functions are only really used by the
ad-hocsolver, not thescipysolver, which takes the output of the solver as the dispatch, as it should since it contains all the constrains. Thead-hocsolver needs to calculate everything manually, and hence this functions.This is not really documented, as far as I can tell, which leads to incorrect use of the input parameters, normally irrelevant as they will not affect the result or it will result in contradictory outputs. The
MCAMetric-related outputs used the quantities calculated with thead-hocsolver, which are not necessarily the same than thescipysolver.ahawkes commentedon Jun 24, 2024
But have we solved the fundamental issue? It's not OK to have contradictory outputs, right? I do not understand why this "ad-hoc" solver exists. Why do we have this output reported in two different places?
dalonsoa commentedon Jun 24, 2024
@ahawkes , the
adhocsolver has always existed, coming from the time of the original MUSE but using xarray and the more modern architecture setup by Mayeul, and indeed it is still the default, although none of the models or examples use it. There has never been a suggestion or discussion to drop it, so there it is.The
fundamental issueis, mainly, one of documentation.ahawkes commentedon Jun 24, 2024
OK, but is it simple enough to change the default to spicy? And make sure that this conflicting result is not provided to the user when using spicy? Because it's understandably very confusing.
I think probably worth dropping the ad-hoc as it does not appear to respect input data, but we should ask @sgiarols of any known implications. Any thoughts Sara?
tsmbland commentedon Oct 28, 2024
Closed by #368