Add extra models from the remind group using additional files #208
Conversation
| @@ -0,0 +1,57 @@ | |||
| model: REMIND-Buildings 3.0.0 | |||
There was a problem hiding this comment.
| model: REMIND-Buildings 3.0.0 | |
| model: | |
| - REMIND-Buildings 3.0.0 | |
| - REMIND-Industry 3.0.0 |
There was a problem hiding this comment.
I understand your suggestion, but we need to differentiate these model runs from pure REMIND 3.0.0 run results that should be added soon to the db. So I would keep instead the different names and the PR in its original form.
There was a problem hiding this comment.
But does REMIND 3.0.0 have a different region resolution? If yes, I'd use the same region resolution.
There was a problem hiding this comment.
REMIND 3.0.0 has the same regional resolution.
At the same time I would like to keep in the db the results from REMIND 2.1, REMIND 3.0.0, REMIND-Buildings 3.0.0 and REMIND-Industry 3.0.0 differentiated so we can compare their results against each other.
There was a problem hiding this comment.
I just didn't included yet the REMIND 3.0.0 model to the db as its results are still not available, and if in the meantime you have the opportunity to implement the feature to use a single region mapping file, I would prefer instead to refactor these files to simplify this when I do the REMIND 3.0.0 results upload.
There was a problem hiding this comment.
I would keep the region-mapping specific for the MAJOR.MINOR model version because the regional resolution may change in the future - and CAZ may be a different region in REMIND 4.0 compared to REMIND 2.1 and 3.0…
It’s all about finding a good compromise between having too many categories vs not enough categories.
There was a problem hiding this comment.
This was deliberated internally already and we have planed to keep compatibility in between the past and future region acronomys used in REMIND. So this shouldn't be an issue in our case.
There was a problem hiding this comment.
I find it very hard to believe that there will not be any changes in the regional resolution of the REMIND model over the next years. Please keep the region-mapping such that the region-hierarchy includes the MAJOR.MINOR model version.
There was a problem hiding this comment.
There will be changes in the regional resolution of REMIND, but they will always be incremental.
Including the version number in the region definition is just misleading in this case, as when we reach REMIND 4 with more regions, instead of only adding the extra regions to the region definition, I will have to edit the version number unnecessarily in more than one file.
If this is a mandatory format from the iiasa db I will change it, although I don't see the point of including the version number in something that will be version independent.
There was a problem hiding this comment.
There are a few issues in your response, but the discussion goes beyond this PR. Please follow my advice on versioning of the region-resolution.
| @@ -0,0 +1,57 @@ | |||
| model: REMIND-Buildings 3.0.0 | |||
| native_regions: | |||
| - CAZ: REMIND-Buildings 3.0.0|CAZ | |||
There was a problem hiding this comment.
| - CAZ: REMIND-Buildings 3.0.0|CAZ | |
| - CAZ: REMIND 3.0|CAZ |
| - REMIND-Buildings 3.0.0: | ||
| - REMIND-Buildings 3.0.0|CAZ |
There was a problem hiding this comment.
| - REMIND-Buildings 3.0.0: | |
| - REMIND-Buildings 3.0.0|CAZ | |
| - REMIND 3.0: | |
| - REMIND 3.0|CAZ |
| @@ -0,0 +1,62 @@ | |||
| model: | |||
| - REMIND 2.1 | |||
There was a problem hiding this comment.
Not sure why you want to use REMIND 3.0-regions for REMIND 2.1? Better to just leave that as it was...
There was a problem hiding this comment.
As I said before, REMIND region definitions are agnostic in relation to the model version.
The REMIND region acronyms are unique and they will be always possible to be reported in any current or future version of REMIND.
I changed my PR to replace the 3.0 version by the 2.1 as requested if you prefer to keep that way, although I still can't see any reason that would justify to include any version number to it.
|
closing in favor of #210 |
as suggested in: #207