EnergySystemsModellingLab / MUSE_OS

Welcome to the MUSE-OS repository
https://muse-os.readthedocs.io/en/latest/
GNU General Public License v3.0
22 stars 8 forks source link

[BUG] Supply is much larger than annual preset demand #338

Closed sharwaridixit closed 1 week ago

sharwaridixit commented 2 weeks ago

Describe the bug

I have set up a model which describes the transport sector including subsectors for road vehicles, aviation and rail. After running the model, I found in the MCASupply results file that the sum of the supply for the end-use demand commodities for each simulation year, except the base year, seems to be much higher than the specified demand for that year. For example, in 2020 the supply for TC is 1321.6876 bvkm whereas the TC demand for 2020 is 440.5624 bvkm; this supply result is also 3 times larger than the demand. This is also the case for the other commodities as well. I am not sure as to why this is happening and why the difference is a factor of 3 ( I cannot seem to identify any input value in the model that would lead to this).

Screenshots

The first image shows the supply results and the image below it shows the demand file.

Screenshot 2024-06-14 at 15 16 17 Screenshot 2024-06-14 at 15 26 09

To Reproduce

I have attached the zip file containing my model: Transporttrialmodel.zip

Expected behavior

I expected the supply to be equal to the demand specified in the preset file.

Context

Please, complete the following to better understand the system you are using to run MUSE.

tsmbland commented 1 week ago

Hi @sharwaridixit, I'm trying to run your model, but it's failing for me with an error (ValueError: zero-size array to reduction operation fmax which has no identity). I'm using python 3.9 and MUSE 1.1.0. Could you please let me know which versions of numpy and xarray you're using?

sharwaridixit commented 1 week ago

Hi @tsmbland, I am using version 2022.3.0 for xarray and version 1.23.0 for numpy.

tsmbland commented 1 week ago

Thanks @sharwaridixit. I'm still having a hard time running your model. Could you please double check that the model you attached above runs to completion on your machine? If so, could you share the full list of packages in your environment (pip freeze > requirements.txt)?

sharwaridixit commented 1 week ago

Hi @tsmbland, it seems to be running without errors on my end. Here is the full list of packages: requirements.txt Thank you.

tsmbland commented 1 week ago

Thanks! Got there in the end. It seems your model is particularly sensitive to the version of MUSE - it fails with the latest release (1.1.0), and the latest version of the develop branch (for different reasons), but works with the version you're using which is somewhere in between. I'll have to investigate more to see what the problem is, and hopefully we can get this fixed for the next release.

Anyway, now that I can run your model I'll have a look into the issue you're describing here and get back to you :)

tsmbland commented 1 week ago

Ok, I've looked into this and I think it's a problem with the input files.

In settings.toml, you're specifying that the demand for each of the three sectors corresponds to the preset/Demand.csv file. Therefore (as far as MUSE thinks) the total demand across all sectors is three times higher than what's specified in that file, and that's what it's trying to match with supply.

If you're able to, it would make more sense to separate the demand for each of the three sectors into three separate files, and adjust demand_path for each of the sectors accordingly.

Does that make sense?

tsmbland commented 1 week ago

Alternatively, you could use a single preset sector to define demand for all sectors. So you'd remove the sectors.rail_presets, sectors.aviation_presets and sectors.road_vehicles_presets sections from settings.toml, and just have something like this:

[sectors.presets]
type = 'presets'
priority = 0
demand_path= "{path}/technodata/preset/Demand.csv"

That's probably easier

sharwaridixit commented 1 week ago

Hi @tsmbland, thanks a lot for looking into this, makes sense now! I applied the suggested change and the results look more sensible.

tsmbland commented 1 week ago

Great! Closing this issue and opened #364 to try and get this working with the latest MUSE version