search

OSeMOSYS / OSeMOSYS_GNU_MathProg

The GNU MathProg implementation of OSeMOSYS
Apache License 2.0
9 stars 14 forks source link

Resolve issues with the REGION index, so that multi-region models with trade can be developed #85

Open willu47 opened 1 year ago

willu47 commented 1 year ago

At present, no models use the REGION index for its intended purpose of creating multi-region models. Instead, regions are implemented through naming conventions.

I have heard various reasons for not using regions:

Are there any other reasons for not using the REGION index? Can these issues be overcome so that we can start using the REGION index?

HauHe commented 1 year ago

Hi, thanks for opening this issue and discussion @willu47. With Capacity you already cover the main issue, but to my understanding trade lacks any kind or parameter options that we have with technologies. Hence, using the trade options requires to create more technologies if one wants to parameterise the trade.

willu47 commented 1 year ago

@HauHe - the current implementation of the TradeRoute parameter seems to set up links between FUELs of the same name in different regions. Could this allow import/export technologies to be defined using special import/export fuels in different regions?

HauHe commented 1 year ago

Yes, I that should work. But I think one then would have two times more technologies per link than one would have without using the sets REGION. With two modes of operation one would have one technology per region per link. With one mode of operation two technologies per region per link. When I thought about if I should switch to using the set REGION that was what kept from doing so. But perhaps there are advantages of using the regions, that I just didn't see, and I guess with the latest improvements to avoid lines of zeros a few more technologies might make such a big difference in computation anymore.

TomAlfstad commented 9 months ago

I think it would be good to pursue this issue. The concerns/lack of use with the trade implementation seem to be related to limitations/problems with how it is implemented rather than an inherent problem with using regions. Duplication/performance issues should be manageable with preprocessing of data files and it would lead to a more intuitive use of regions and trade in Osemosys models.