Super-region, region set, multiple region declaration

[VictorG]

Dear forum members,

I am working on a model with multiple regions and I would like to manage their input data using groups of regions. Currently I declare all my processes and commodities in VT for the superregion declared in the syssetings and I further declare for each region the corresponding data.

I would like to manage the declaration and update of this parameters for a GroupRegion when multiple regions share the same data. A way to see it would be to have a set of region like we have for process and commodities.

Here is an example for Europe of Super-region > Group-region > Region:

SuperRegion | GroupRegion | Region
EUR        | CWE        | AT
EUR        | CWE        | BE
EUR        | CWE        | CH
EUR        | CWE        | DE
EUR        | CWE        | FR
EUR        | CWE        | LU
EUR        | CWE        | NL
EUR        | NWN        | DK
EUR        | NWN        | FI
EUR        | NWN        | IS
EUR        | NWN        | NO
EUR        | NWN        | SE


I would be interested to know how you handled this kind of situation in your models ?


Victor

[AKanudia]

How many super-regions do you have?

[VictorG]

one super-region and around 30 regions. I would like to classify the regions in two groups

[AKanudia]

why don't you use those groups as super-regions?

[VictorG]

because I do not want to double the number of VT. Let say I have a process that is common to both super-region, I will have to declare it twice even though it is the same. Am I right ?

[AKanudia]

I can think of three categories

1. Topology: common across all regions
2. Like Efficiencies and costs: common across your region groups?
3. Like Existing stock: region-specific

Doubling the number of VT files can be tolerable depending on how many attributes you have in these categories.

You could also use something like ~TFM_INS-TS: Region=(comma-separated list of regions) or ~TFM_INS-AT: Region=(comma-separated list of regions) in BY_Trans (or scenario files) for this.

[VictorG]

Alright, I started with a model that had VT for the ~30 regions which was difficult to maintain, now I use a similar structure that Evangelos Panos presented in: ETSAP Webinar 2: How to Build a TIMES model from scratch.

I try to write things only once to ease the update of the model. You are right doubling the number VT is fine for a limited number of super-regions but if I want to disaggregate some regions of the 30 I will come back to my first problem. Anyway, 2 super-regions is good for my current situation and I will try this.

I am not familiar with the tags you mentionned, I will have a look on these.

Thank you for your help

[Antti-L]

I have seen that one can also use a list of regions in the Tag, at least in TFM_DINS-TS, like this:

  ~TFM_DINS-TS: Region=BG,CY,CZ,EE,HR,HU,LT,LV,PL,RO,SI,SK,AL,BA,KS,ME,MK,RS

I wonder if that works also in TFM_INS (such that in TFM_INS the values are specified in AllRegions)?
[Edit:] Ahh... Amit already mentioned this. So, I gather it works with TFM_DINS-TS, TFM_INS-TS and TFM_DINS-AT, but does it work also with TFM_INS, TFM_UPD and TFM_MIG?

[VictorG]

Alright, I was thinking of reducing this kind of writing from:

~TFM_DINS-TS: Region=BG,CY,CZ,EE,HR,HU,LT,LV,PL,RO,SI,SK,AL,BA,KS,ME,MK,RS

to: ~TFM_DINS-TS: Region=CEE

if I have previously declared my region group CEE as BG,CY,CZ,EE,HR,HU,LT,LV,PL,RO,SI,SK,AL,BA,KS,ME,MK,RS

I use this kind of region mapping a lot for my results aggregations and I think it would be handy to have something similar for the building of a model

[Antti-L]

You could accomplish that in Excel, defining a Name for the region list and then using that Name in the Tag cell.

[AKanudia]

You are basically suggesting a region set. It is available for reporting (under Reports), but not on the input side.

I have felt the need sometimes, but not often enough to make it into a feature. I have used comma-separated regions in a region col or in the table tag when the need arose.

Will think about it.

[AKanudia]

Alright, I started with a model that had VT for the ~30 regions which was difficult to maintain, now I use a similar structure that Evangelos Panos presented in:  ETSAP Webinar 2: How to Build a TIMES model from scratch.

I try to write things only once to ease the update of the model. You are right doubling the number VT is fine for a limited number of super-regions but if I want to disaggregate some regions of the 30 I will come back to my first problem. Anyway, 2 super-regions is good for my current situation and I will try this.

I am not familiar with the tags you mentioned, I will have a look on these.

Thank you for your help

In case you have ever wondered why there were 30 sets of VTs to begin with - because different modelers were responsible for different regions in the project where this model was born. The original version of TIAM had each region in its own super-region for the same reason. TIAM had started with the SAGE model at EIA, where the VT files were maintained by Regional experts.

https://www.eia.gov/analysis/pdfpages/m0...2index.php

[VictorG]

You could accomplish that in Excel, defining a Name for the region list and then using that Name in the Tag cell.

I do not understand what you mean, can you give a small example please ? With this method can I define a Name for the region list at one place in an excel file (eg syssettings) and use this definition anaywhere in the model ?

[VictorG]

You are basically suggesting a region set. It is available for reporting (under Reports), but not on the input side.

I have felt the need sometimes, but not often enough to make it into a feature. I have used comma-separated regions in a region col or in the table tag when the need arose.

Will think about it.

Yes a region set is something that would fit my need. Copy and paste comma-separated regions may work for a limited number of regions but it is a bit risky when you work with larger groups of regions like NUTS1&2 for EU.

Let me know if you decide to implement it in veda