Add optional aggregation with ssp population masks

[NiklasSchwind]

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 ?

[cschleussner]

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: ***@***.***>