-
Notifications
You must be signed in to change notification settings - Fork 35
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
Wat ssp upd4 #268
base: main
Are you sure you want to change the base?
Wat ssp upd4 #268
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #268 +/- ##
=======================================
- Coverage 77.6% 76.7% -0.9%
=======================================
Files 211 211
Lines 16079 16102 +23
=======================================
- Hits 12481 12355 -126
- Misses 3598 3747 +149
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, thanks :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this is a for
inside a for
inside a for
? I'm surprised that this is the faster solution, it doesn't seem very efficient. Without spending more time, I'm not sure how to improve this, though, and if you say it's an improvement, then it's fine with me :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the thing is that for any item to be removed, the message_ix_models.model.build.apply_spec()
checks if elements exist and proceeds or says that there are no elements. This is very slow.
now we just exclude in advance sets from the remove list that we know are not in the scenario, so that they do not get sent to apply_spec()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is a serious problem and/or you know a solution for it, please record it in a new issue. This will raise awareness and eventually lead to a solution :)
some calibration scenarios run 2020 and 2025 free, the previous code should in theory no break, but it is safer to look at fully historical years
Move adjustment at the end of the script, for all technologies
Required: write a single sentence that describes the changes made by this PR.
Fixes for the SSP update.
we noticed nuc_lc cooling technology was not correctly parametrized. I did not notice it because in all the scenarios I tested the technology was not active, but in some scenario it is, before 2020
Oliver suggested to pre-filter the
remove.set
as currently it takes lot of time just to check if the set is thereHow to review
Not, sure changes are quite minimal and I already cherry picked them in
ssp_dev
PR checklist