Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Results are different when specifying utilization factor at the timeslice level #512

Closed
tsmbland opened this issue Oct 7, 2024 · 2 comments · Fixed by #518
Closed

Results are different when specifying utilization factor at the timeslice level #512

tsmbland opened this issue Oct 7, 2024 · 2 comments · Fixed by #518
Labels
bug Something isn't working

Comments

@tsmbland
Copy link
Collaborator

tsmbland commented Oct 7, 2024

Looking at the Qatar model, I've found that the results are very different when you specify utilization factor at the timeslice level with a TechnodataTimeslices.csv file, even if all the values are the same, compared to just specifying a single value in the Technodata.csv file to apply to all timeslices. In the former case the results don't make any sense at all (supply values exceeding capacity).

Digging a bit through the code in debug mode, the main difference I've found is that the technologies xarray (which is used in many, many places throughout the code) has an additional timeslice dimension, but I currently have no idea why this is causing the discrepancy in the results

UPDATE

I can recreate this with a much simpler model. This is the default model with a single UF value specified in the Technodata.csv file, compared to timeslice-level values specified in the TechnodataTimeslices.csv file. In all cases UF=1 in all timeslices, so there shouldn't be any difference between the two scenarios, however this isn't the case:

StandardUF
TimesliceUF

In the standard case the results make sense. Capacity is higher than overall supply across the year, but this is reasonable because capacity needs to match supply in the peak timeslice. In the second case however, supply actually exceeds capacity across all years (at least for wind turbines), which doesn't make any sense

UPDATE 2

This is specifically to do with the convert_timeslice operation in the max_production constraint (or at least partially to do with that).

@tsmbland tsmbland added the bug Something isn't working label Oct 7, 2024
@github-project-automation github-project-automation bot moved this to 📋 Backlog in MUSE Oct 7, 2024
@tsmbland
Copy link
Collaborator Author

tsmbland commented Oct 9, 2024

Wow, this is way worse than I thought.

According to the QuantityType class there are two ways of transforming a quantity over the timeslice dimension:

  • Intensive: In this case a quantity should be split over the timeslice dimension according to the length of each timeslice. For example if you have a quantity representing the running costs of a technology over a year, you'd find the running cost in each timeslice by multiplying the total cost over the year by the fraction of the year that the timeslice occupies.
  • Extensive: In this case a quantity should be broadcast over the timeslice dimension, so all the values in each timeslice are the same. For example if you have the price of a commodity in a year, you'd apply this same price to each timeslice.

The convert_timeslice function takes a dataset of quantities along with timeslice data, and applies the appropriate transformation according to the specified QuantityType

However... I think it's doing this the wrong way around (i.e. splitting the data when extensive is specified, and broadcasting the data when intensive is specified). The tests would appear to back this up. Thus, there are many cases in the code where the wrong transformation is being applied, and I think this is what's causing the problem here (along with potentially many other problems)

Fixing this bug properly is going to require:

  1. Fixing the convert_timeslice function so it's doing the correct thing
  2. Going through the code to make sure that every call of convert_timeslice is using the correct quantity type.
  3. Most likely this will break a lot of things and could take a fair bit of additional work to get everything running again

@tsmbland
Copy link
Collaborator Author

Closed by #518

@github-project-automation github-project-automation bot moved this from 📋 Backlog to ✅ Done in MUSE Oct 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant