Present precip and snowfall in cumulative units

[rod-glover]

This applies to precip and precip as snowfall, and may apply to other variables in future.

At present, this is also relevant only to maps (climate layers), because that is the only place that absolute values of precip are presented; all others are relative (% change). However, it could apply in other areas if we present absolute values, e.g., in graphs or even in summary as a notion of what the baseline values are for judging whether they are low ... a possible enhancement to come.

From a conversation with Trevor:

• ​Precip base data is in units of "kg m-1 d-1", which is a flux (amount per time) unit. Base data is daily (so, parenthetically, it is an average value over the day).
• We then compute temporal averages of flux over various periods. Units are still "kg m-2 d-1", but averaged over a longer period (month, season, year).
• Desired to present to users in cumulative units, i.e., integral of flux over time. For example, the total precip in winter.
• Fortunately, since the fluxes we have are average flux over a given period, to integrate them over time is just to multiply by the length of time period. For example, average flux in winter times 91.25 days per winter = total precip in winter.

Trevor replies:

Yes, that is correct. When converting from GCM to human units we want to go from kg/m/day to mm/period where period = month, season, or year (but still averaged over the 30 year period)

Also, although technically some models have 90 days (or something even different than that) because you’re going from daily fluxes you want to just multiply by the number of days in the month or season in reality without worrying about how many days the model actually has in its calendar. Also to be real fussy, you might want to multiply by 91.25 days in winter because of leap years – I don’t have a strong opinion but might be useful to be consistent with what we do in the regional assessments – Steve can you comment on that?

Stephen replies:

In the assessments the averages are computed according to each model's calendar, so it will be different for Hadley (360-day) than the Gregorian or 365-day models, and leap years are accounted for.

Lee replies (paraphrased):

cdo accounts for that, and the datasets that P2A works with are the output of cdo processing. So there is no concern within P2A about that.

At present, as a stopgap, we present all precip values in average mm/mon, which is sensible for all timescales.

What we want to do is to present precip values in cumulative mm per period. This will be relatively simple unless we have to make some kind of allowance for differing calendars. But as the datasets in P2A are aggregated (e.g., averaged) across models, which removes the per-model consideration.

[rod-glover]

The (or a) full solution is to allow a variable's units to be configured per season. Given that, we can configure cumulative variables like pr and prsn as mm/year for annual "season" and mm/season for seasons spring, summer, fall, winter. (We need better terminology.) The conversion factors for these two different units differ (365.25 for mm/year, 91.xxx for mm/season), and they can both specify that their presentation label is just "mm" (with the implication that they are for the period presented). This solution is flexible and can accommodate a large number of variations on this scenario.

This solution also easily allows for configuring other season-related items such as data range in the maps (determining the colour scale). This goes part way to addressing #175 .