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

Adding REMIND-MAgPIE 3.4-4.8 according to current model version #135

Merged

Conversation

laurinks
Copy link
Contributor

We would like to register the latest REMIND-MAgPIE version. After merging the PR, I would also need the corresponding permission to upload.

Thank you!

Copy link
Contributor

@orichters orichters left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good from my side

@danielhuppmann
Copy link
Member

Looks ok in principle, but would it be ok to follow the convention from https://github.com/IAMconsortium/common-definitions/blob/main/mappings/REMIND_3.1.yml where the region names only use the REMIND-version number (ie., "REMIND 3.4|...", and the model "REMIND-MAgPIE 3.4-4.8" maps to those regions? This way, we can avoid having multiple definitions/mappings files that are identical.

[Note that the full model version would still always be displayed in the model column in the IAMC format].

@orichters
Copy link
Contributor

I would prefer to split up REMIND-MAgPIE and REMIND standalone, as these are really different models, although the default regional split is the same. I see no reason to drop MAgPIE in the region names when the model is used, and the MAgPIE colleagues may even have a stronger opinion on that than I do 🙂

Instead, I wonder whether we can drop all the "3.4" and "3.1" from the REMIND and REMIND-MAgPIE region names, as our development direction is rather to split up existing regions and give them new names, not redefining old ones.

@flohump
Copy link
Contributor

flohump commented Sep 16, 2024

I would prefer to split up REMIND-MAgPIE and REMIND standalone, as these are really different models, although the default regional split is the same. I see no reason to drop MAgPIE in the region names when the model is used, and the MAgPIE colleagues may even have a stronger opinion on that than I do 🙂

Instead, I wonder whether we can drop all the "3.4" and "3.1" from the REMIND and REMIND-MAgPIE region names, as our development direction is rather to split up existing regions and give them new names, not redefining old ones.

I agree with @orichters. If the coupled REMIND-MAgPIE system is used, the full name "REMIND-MAgPIE" should be used in all instances.

@laurinks
Copy link
Contributor Author

@orichters, @flohump : This would be the version with separate REMIND and REMIND-MAgPIE registration and without version names in the model regions. However, the names of the current versions are listed as model names to enable submission with the specific model version. Is this what you had in mind?

@danielhuppmann
Copy link
Member

Ok to keep the full REMIND-MAgPIE model name in the region prefix, but please also keep the model version numbers in the prefix.

Also, please use one specific regional Reduktion for each model version - we had plenty of headache when REMIND 2.1 was used with both the 12- and 21-region-versions in one project.

@orichters
Copy link
Contributor

REMIND-MAgPIE currently only supports a 12 region version. Therefore, I suggest undoing everything done to the REMIND 3.1 standalone file and just add REMIND-MAgPIE 3.4-4.8 for the 12 region version.

Please discuss possible issues about REMIND 21-region version and its splitting up with @Renato-Rodrigues or other people submitting REMIND 21-region results.

@danielhuppmann
Copy link
Member

REMIND-MAgPIE currently only supports a 12 region version. Therefore, I suggest undoing everything done to the REMIND 3.1 standalone file and just add REMIND-MAgPIE 3.4-4.8 for the 12 region version.

Sound good - and I suggest to bump the version number to REMIND-MAgPIE 3.5-4.9 (or higher) when implementing higher regional resolution.

@laurinks
Copy link
Contributor Author

Alright, I reset to the status as of Friday. As @orichters said, we will only contribute REMIND-MAgPIE scenarios with the 12 regions. I leave it to colleagues submitting REMIND standalone runs to update the REMIND model registration accordingly when needed.

@danielhuppmann
Copy link
Member

Permissions granted for REMIND modelers to submit scenarios for “REMIND-MAgPIE 3.4-4.8” to the SSP-submission instance.

@danielhuppmann danielhuppmann merged commit a00727c into IAMconsortium:main Sep 16, 2024
6 checks passed
@laurinks
Copy link
Contributor Author

Thank you, @danielhuppmann ! Permission has been granted. Currently the submission template still uses REMIND 3.1 leading to the rejection of the updated model name when processing the upload file in the scenario explorer. No problem if it is more efficient for you to wait for other updates of the Excel file. Please let me know once it is updated and I will process the submission.

@danielhuppmann
Copy link
Member

@phackstock, can you please take a look why the SSP-submission template wasn’t updated upon merging this PR?

@phackstock
Copy link
Contributor

@danielhuppmann, it wasn't updated because I pinned it as a precautionary measure. I can remove the pin but then we're playing with fire when it comes to potential variable or unit changes in the future.

@phackstock
Copy link
Contributor

Updated it (while keeping the pin) to the latest version now.

@laurinks
Copy link
Contributor Author

@phackstock : Great, thanks a lot! Now, the REMIND-MAgPIE 3.4-4.8 scenarios are in the Scenario Explorer. As they are identical with the earlier REMIND 3.1 upload on Friday (except for the name), I was wondering if there is an easy way to delete the REMIND 3.1 scenarios. I tried this by deleting the corresponding upload file but this does not seem to be sufficient.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants