-
Notifications
You must be signed in to change notification settings - Fork 1
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
Add optional aggregation with ssp population masks #36
Comments
Thanks, good point.
I think it’s nice to have that possibility in principle I think. In particular for IAM coupling this might be nice, as they also take population change into account for the mitigation side. Problem will be that we might not have gridded pop for all SSPs. Or do we now?
Cheers,
Carl
On 22. Oct 2024, at 11:18, NiklasSchwind ***@***.***> wrote:
We considered adding SSP population projections to the emulator. They exist as masks in 10-year steps for 2020 to 2100 and I already processed them into population weight masks and population number masks. You can find them here:
/mnt/PROVIDE/climate_impact_explorer/data/rime_masks/{iso}/masks/{iso}360x720lat89p75to-89p75lon-179p75to179p75{ssp}_{year}popWeight.nc4
/mnt/PROVIDE/climate_impact_explorer/data/rime_masks/{iso}/masks/{iso}360x720lat89p75to-89p75lon-179p75to179p75{ssp}{year}_populationFull.nc4
The population weight masks could be used for population-weighted averages in line with the SSP population projections and the population numbers could be used to derive actual impact indicators like "population exposed to XY" in line with SSP population projections.
Implementing this additional functionality would require optionally using the masks for aggregation in the preprocessing (I think this is already possible when adding the masks to the configurations) and then correctly applying them in the emulator function. When considering the SSP population projections the emulator function would have to emulate quantile time series in a 10-year time resolution from 2020 to 2100, using the data aggregated for the correct SSP and year at every year of the time series instead of using a constant aggregation at every year of the time series as done at the moment.
I am not sure what would be the best strategy to add this to the code without complicating it too much. Ideas would be to add it as an option to the current emulator function or to write a distinct function to handle this specific case (which would then be bad for maintainability). What do you think @perrette<https://protect.checkpoint.com/v2/r02/___https://github.com/perrette___.YzJlOmlpYXNhOmM6bzplYmY3NDcwZTNhOTZhZjAxY2QyYTlkZjE0YWE5Zjg0MTo3OmIxZWQ6YmM0ODY5MDUyOWNmMTc2NmRlMDk1NDI2Mjg5ZGZhNDYwNzNkMThiN2FkZjdjNWRjZTY2MjVhODlhODE4Mzc2ODpoOlQ6Tg> ? And would this be an interesting direction for development @cschleussner<https://protect.checkpoint.com/v2/r02/___https://github.com/cschleussner___.YzJlOmlpYXNhOmM6bzplYmY3NDcwZTNhOTZhZjAxY2QyYTlkZjE0YWE5Zjg0MTo3OjI1NmU6NmVmNjdkYTM0NjYxZjU2NTVlMDZkNDlmY2Y3MzAzNzJhNjQ2NGM3MjcwZmUyNWRkOGNkNmIxNTgzYzE5ZmUxZjpoOlQ6Tg> ?
—
Reply to this email directly, view it on GitHub<https://protect.checkpoint.com/v2/r02/___https://github.com/iiasa/rime/issues/36___.YzJlOmlpYXNhOmM6bzplYmY3NDcwZTNhOTZhZjAxY2QyYTlkZjE0YWE5Zjg0MTo3OjUyYTg6MDZkYTVjNDQ4NmE4OTgxMTA4MzQzNmI1ODJlNzQxNjRiMGMzZjQzN2UzNTI1NWI5MDllNTZjNjIwYWNhM2FkNjpoOlQ6Tg>, or unsubscribe<https://protect.checkpoint.com/v2/r02/___https://github.com/notifications/unsubscribe-auth/BKBMB6NJX4SILESJXAXSCT3Z4YJ77AVCNFSM6AAAAABQMAONFGVHI2DSMVQWIX3LMV43ASLTON2WKOZSGYYDIOBRGUZTGMQ___.YzJlOmlpYXNhOmM6bzplYmY3NDcwZTNhOTZhZjAxY2QyYTlkZjE0YWE5Zjg0MTo3OmQyMzI6MWEzMjhhOTE2Zjg5Mzg2ZGZhMTk2MzZjYzBiMTA5YzgzMmNjNDJiZTY2YzQ0OWIwYjhiOTY2MTExYmFlMWJhNDpoOlQ6Tg>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Hi Niklas, Carl. The coding part is manageable I guess. It does increase complexity but if useful then benefit outweighs costs. In fact, it is already partly implemented in the emulator itself when dealing with Wernings et al datasets (see https://github.com/iiasa/rime/tree/rimeX?tab=readme-ov-file#match-years). Storage might be more challenging though, as it means adding another dimensions (years) in a factorial manner, i.e. this leads to 10x more storage need if we keep one population grid per decade, starting in 2010 (we must be able to use any temperature with any year). What about the input datasets? I see an ISIMIP dataset that would do just that but it is "not available for download anymore". |
And of course IIASA https://iiasa.ac.at/models-tools-data/ssp |
We considered adding SSP population projections to the emulator. They exist as masks in 10-year steps for 2020 to 2100 and I already processed them into population weight masks and population number masks. You can find them here:
/mnt/PROVIDE/climate_impact_explorer/data/rime_masks/{iso}/masks/{iso}360x720lat89p75to-89p75lon-179p75to179p75{ssp}_{year}popWeight.nc4
/mnt/PROVIDE/climate_impact_explorer/data/rime_masks/{iso}/masks/{iso}360x720lat89p75to-89p75lon-179p75to179p75{ssp}{year}_populationFull.nc4
The population weight masks could be used for population-weighted averages in line with the SSP population projections and the population numbers could be used to derive actual impact indicators like "population exposed to XY" in line with SSP population projections.
Implementing this additional functionality would require optionally using the masks for aggregation in the preprocessing (I think this is already possible when adding the masks to the configurations) and then correctly applying them in the emulator function. When considering the SSP population projections the emulator function would have to emulate quantile time series in a 10-year time resolution from 2020 to 2100, using the data aggregated for the correct SSP and year at every year of the time series instead of using a constant aggregation at every year of the time series as done at the moment.
I am not sure what would be the best strategy to add this to the code without complicating it too much. Ideas would be to add it as an option to the current emulator function or to write a distinct function to handle this specific case (which would then be bad for maintainability). What do you think @perrette ? And would this be an interesting direction for development @cschleussner ?
The text was updated successfully, but these errors were encountered: