Open NiklasSchwind opened 1 month ago
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/rimemasks/{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 @perrettehttps://protect.checkpoint.com/v2/r02/___https://github.com/perrette___.YzJlOmlpYXNhOmM6bzplYmY3NDcwZTNhOTZhZjAxY2QyYTlkZjE0YWE5Zjg0MTo3OmIxZWQ6YmM0ODY5MDUyOWNmMTc2NmRlMDk1NDI2Mjg5ZGZhNDYwNzNkMThiN2FkZjdjNWRjZTY2MjVhODlhODE4Mzc2ODpoOlQ6Tg ? And would this be an interesting direction for development @cschleussnerhttps://protect.checkpoint.com/v2/r02/___https://github.com/cschleussner___.YzJlOmlpYXNhOmM6bzplYmY3NDcwZTNhOTZhZjAxY2QyYTlkZjE0YWE5Zjg0MTo3OjI1NmU6NmVmNjdkYTM0NjYxZjU2NTVlMDZkNDlmY2Y3MzAzNzJhNjQ2NGM3MjcwZmUyNWRkOGNkNmIxNTgzYzE5ZmUxZjpoOlQ6Tg ?
— Reply to this email directly, view it on GitHubhttps://protect.checkpoint.com/v2/r02/___https://github.com/iiasa/rime/issues/36___.YzJlOmlpYXNhOmM6bzplYmY3NDcwZTNhOTZhZjAxY2QyYTlkZjE0YWE5Zjg0MTo3OjUyYTg6MDZkYTVjNDQ4NmE4OTgxMTA4MzQzNmI1ODJlNzQxNjRiMGMzZjQzN2UzNTI1NWI5MDllNTZjNjIwYWNhM2FkNjpoOlQ6Tg, or unsubscribehttps://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 Seems an update to the SSPs is being completed (due in 2024), and links are provided to "legacy" SSP scenarios. However, I doubt the new scenarios are in a gridded format. From the few lines I could read on the outdated ISIMIP webpage linked above, and the UCAR dataset, it seems the scenarios are made for each country, and then making the grid is some kind of postprocessing step done by different groups or people. Anyway, it seems a choice between using the legacy SSP scenarios with existing gridded option (not sure which is best), or wait for some future release (that could take long).
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 ?