Fix for models with no existing capacity

[tsmbland]

Description

Please include a summary of the change and which issue is fixed (if any). Please also include relevant motivation and context. List any dependencies that are required for this change.

Fixes #286

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.

• [ ] 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

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

Further checks

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

[tsmbland]

@dalonsoa I've been struggling a bit with this, so maybe you can help (see #286). In the create_newcapa_agent function it looks like the 'newcapa' agents are being limited to technologies that already exist, which doesn't seem right to me (unless I'm missunderstanding something). I've changed this, and changed the clean_assets function to allow empty assets, and this allows Sharwari's model to run. I'm not sure if the results make sense, but all the regression tests are now failing (not surprising since I've changed the model), so this probably isn't appropriate. What do you make of this?

I've made another PR (#298) which doesn't change the model and just changes the way that empty xarrays are dealt with to suppress the error. This also allows Sharwari's model to run, but in this case you have no capacity throughout the whole simulation as agents can't invest in technologies that don't already exist, which doesn't seem right either.

Any ideas? Am I barking up the wrong tree?

[dalonsoa]

I think we have hit an edge case here - combined with a problem with the inputs.

First the second point. The simulation include retrofit agents which, by definition, only manage technologies with existing capacity. As there is no initial capacity, there's no point in having retrofit agents. This is fixed by doing the following:

• removing that line from the Agents.csv file
• setting the last column of the Technodata.csv file to Agent1 (the only one we have).
• the section sectors.road_vehicles.interactions will need to be removed, as there are no new and retro agents to interact.
• the demand_share parameter in the toml file, section [sectors.road_vehicles.subsectors.retro_and_new] needs to be defined as demand_share = "standard_demand" (it defaults to new_and_retro if the parameter is not present, which requires retro agents). For some reason, though not surprisingly, this is totally undocumented!

These changes will let new capacity agents manage any existing capacity.

But this is not really the problem, just moves it to the new capacity agent. I don't think MUSE has ever been run in a situation where there's absolutely no initial capacity of any kind in any technology. It is assumed, and have checks for that, that here's always a non-null starting point.

To fix this, the only change needed in the code is in the calculation of the share of initial capacity between agents, ensuring that the returned array is not an empty one when there's no capacity:

https://github.com/EnergySystemsModellingLab/MUSE_OS/blob/b6f17a4c171723b0fe682baeebcf6726d2686698/src/muse/agents/factories.py#L360

should change to:

  if not any(techs):
      return (capacity * shares).copy()
  return (capacity * shares).sel(asset=techs.values).copy()

With the changes above, @sharwaridixit simulation runs beginning to end with non-null capacity being installed in all years. If they make sense or not that's a different story.

[tsmbland]

@sharwaridixit Does this make sense? I've made Diego's suggested changes to the source code in #299. To try this out you will need to do a source-code installation, and checkout the no_capacity3 branch (git checkout no_capacity3), and also modify your model as outlined above. Let me know if this works and if the results make any sense.

[sharwaridixit]

Thank you @dalonsoa @tsmbland for looking into the issue! I applied the suggested changes to my model and ran it under the no_capacity3 branch. I don't seem to be running into any errors now and I checked the MCACapacity results which now seem to show capacity being built for the technology. The capacity for each year seems to match the demand outline in preset (I have attached an image of the results):

However, I am a little unsure about why there are multiple entries of the capacity for the same year and am trying to look into this further; I was wondering if you had any idea about this?

[tsmbland]

However, I am a little unsure about why there are multiple entries of the capacity for the same year and am trying to look into this further; I was wondering if you had any idea about this?

As far as I'm aware this is normal for new versions of the code. I think at some point a change was made to have multiple rows in the output representing different assets. If you were using an older version of the code before then you may not have seen this, but if you sum all the rows for each year then this should be equivalent to how it was before. @dalonsoa do you know any more about this?

[dalonsoa]

@tsmbland is correct. Each row represent a different asset, and it was changed fairly recently, but I'm not sure why it was done this way. I guess that they might differ in the installation year.