Fix supply function

[tsmbland]

To be reviewed after #647

The main changes in the PR are a rewrite of the supply and emission functions, along with some changes to broadcast_techs

supply

• I've tried to keep this function true to how it was originally written, so most results are unaffected (except multi-region models, see next point), however I've tidied it up to make it more readable
• There was a bug when using multi-region models. demand has a "region" dimension, so the line expanded_demand = (demand * maxprod / maxprod.sum(demsum)).fillna(0) created an array with separate "asset" and "region" dimensions, which essentially duplicated each asset over every region (this is why regression tests are failing in Xarray patch: Check array dimensions #647). This led to the problem described in [BUG] Unexpected behaviour in multi-region models #475, and also inflated commodity prices in multi-region models (see Prevent arrays from having separate "asset" and "region" dimensions #619). I've fixed this by calling broadcast_techs on the demand data so that each asset only sees the demand for its respective region
• Added some tests for single and multi-region models
• Trade models get treated a bit differently. I've done my best attempt at coding what I think should happen in trade models, however trade models have never worked to begin with, it's unclear how they are supposed to work, and it's not worth my time right now to dig too deep into this. So I've added a note that it may be incorrect, possibly to return to in the future.

emission

• Emissions should be scaled according to production amplitude (as calculated by production_amplitude), rather than the sum of end-use quantities as was being done before. This is especially relevant for technologies with multiple end-use commodities, or output ratios not equal to 1.
• Added a test

broadcast_techs

• Since this function is no longer used exclusively on technology data, I've added a note about this in the docstring.
• I've added some detail to the docstring about the installed_as_year parameter, as this is actually very important and care needs to be taken depending on the type of data that the function is called on.
• I've also removed the interpolation feature, as this shouldn't be necessary if the technology data covers the appropriate years found in the assets template. (In general I think interpolation is overused, and should rarely be required as there's a well defined time framework which all datasets should follow).
• Also removed filtering with kwargs as this wasn't being used anywhere
• Rewritten the test

Results

• Fixes the issue in [BUG] Unexpected behaviour in multi-region models #475. Results now look much more reasonable in multi-region models:
  
• Commodity prices in multi-region models are now more in line with how they are in single region models
• For some reason the Power_Supply.csv files now have data for 2020 which was missing before - not sure why, but I'll take it

Close #475

[dalonsoa]

It looks OK. The code is cleaner and with better explanations. Having said that, I've a few questions/doubts.

[dalonsoa]

Ok, I got a bit confused here. What's the point of multi-region simulations if there's no trade between them? You could equally have individual simulations for each of the regions as they are, in practice, independent from each other, right?

For some reason, I had always implicitly assumed that if you have multiple regions, you're going to send stuff from one region to another. I never consider that that was not required.

[tsmbland]

Good point. I agree, it's pointless without trade

However, trade requires things to be set up in a particular way, with a TradeTechnodata.csv file, and it's still possible to run a multi-region model without this file, which we need to account for (at least for now).

The multi-region model in the tutorials doesn't have any trade, and is just used to demonstrate how regions with different technology parameters can differ - although obviously you could do the same with two single-region models!

[dalonsoa]

Since this function is not limited to technology datasets, it should be renamed to something different as well as well as use variable names that do not indicate the type of data. Maybe broadcast_data for the function name, and just data or dataset instead of technologies. The docstring and comments will need to be updated accordingly.

[dalonsoa]

It might be worth to add an explanation of the use case for this to be False, as well.

[dalonsoa]

As there seem to be more things to do, maybe implement the changes I suggest above as a separate PR, alongside this TODO.