add quantile maps

[perrette]

Quoting @NiklasSchwind here

We should add quantile maps to the package (maybe just the old CIE methodology is enough (=quantile taken from the year at which the median warming level in the scenario and year is first reached in each simulation) or by calculating a grid point-wise weighted quantile, not sure if this works without overloading the RAM though)

[NiklasSchwind]

To go into further detail on the two methodologies proposed:

Old CIE methodology for the maps "quantile taken from the year at which the median warming level in the scenario and year is first reached in each simulation"

This is used to calculate the maps in the current CIE. The map show the median value of the indicator per gridpoint in a scenario and year and they are produced by ... (1) simply calculating the median warming level for the emulated scenario and year from MAGICC output (2) pooling all maps from all input ISIMIP simulations at the time the warming level in the simulation is the same as the median warming level calculated in (1) (3) calculate the median of the pooled maps

This could be generalized to all percentiles by calculating the general percentile of the warming level in the scenario and year from the MAGICC distribution in (1) (instead of taking the median per default) and then calculating the percentile of the pooled maps in (3) (instead of taking the median per default)

Advantages: Can be easily preprocessed for the CIE (e.g. by providing median and 95th percentile maps for all available warming levels and loading the map for the correct warming level whenever someone looks at a map) Disadvantage: Not consistent with the rimeX emulator for time series, doesn't use all available information, not really a mathematically correct grid point quantile given our simulation democracy and GMT dependency assumptions

Methodology consistent with the rimeX emulator for time series "calculating a grid point-wise weighted quantile"

In this method, we would calculate the quantile for each grid point the same way as for the aggregated time series (a gridpoint-wise weighted quantile weighted by the probability of their warming level in the scenario and time).

Advantages: Consistent with the rimeX emulator for time series, uses all available information, mathematically correct grid point quantile Disadvantage: Can not be easily preprocessed for the CIE (At least I can't think of a way) and would take a long time to calculate -> Can probably not be calculated on the fly and we would need to redo preprocessing for all indicators at each scenario update (which would be painful)

[perrette]

How useful are these quantile maps? (in my mind they are not very useful...). I guess we could provide an approximation anyway. That's what I'd do for a reasonably accurate calculation:

• The information can be stored as impact(quantile, warming, lat, lon), where quantile and warming would only be a few points (like min, 0.05, 0.1, 0.17, 0.25, 0.5, 0.75, 0.83, 0.95, max and 1, 1.5, 2, 2.5, 3, 4, say -- I don't remember what Mia used but they use few warming levels).
• On the "driver" side, split up the warming side range into a number of quantile intervals (like 10 or 100).
• Randomly match each of the temperature quantile with one impact quantile (and interpolate the impact according to the sampled temperature) -> this gives you 10 or 100 (temperature, impact) sample pairs, in the form of a (sample, lat, lon) matrix.

Now if we use a relatively coarse grid so that we stay under 1e6 points overall, that could be reasonably fast. Though whether that would be fast enough for a server calculation, I don't know -- can you specify some kind of requirement in terms of memory usage and execution time ?

A rougher approximation would be to compute the percentile due solely to the temperature forcing (using the median map), and another due solely to the model uncertainty (using a quantile maps like you describe above), and combine them by summing the squares of deviations from the median. So this requries computing the median map as well obviously. Three maps and the result = approx(q) = ((approx_temp(q) - median)**2 + (approx_model(q) - median)**2)**.5. That would be much faster and probably more than sufficient to display on a screen...