Surface temperature correction configs

[robdarvell]

Might be more of a general question rather than a specific one. (can’t find (not saying there isn’t anything) a reference in the docs). I’ve put it in as a configuration discussion as I think that may best describe it.

How best to go about correcting surface temperature for differences in the station height compared to what the model thinks is the station height?

How do others do it?

Of course, you could correct either the observation values or the model values, as I know different centres may well have different ideas behind it (but for some stats it doesn’t actually make any difference).

If you run several different models, then the corrections will be different for each of them. And then not all locations report at every step, stations come on-line during a month, station details may change (if they correct things or move the site).

I can see this sort of thing sitting better within the MET codebase (with a switch, perhaps like the topo, land/sea options available) rather than an outside ‘embedding’ feature (extra step). If you do it outside, to me in part, you are basically just going to be repeating the steps within the MET code, just possibly in a different program language.

As I say, something may already be there, I just haven't found it.

Rob

[JohnHalleyGotway]

@robdarvell, great question. You're correct to assume that MET does not already include functionality to modify the forecast or observation surface forecast temperature values to correct for topography differences. However, it does something close to that.

Please read through the description of the topo_mask config options. This was added by MET#527 back in 2019 for version 8.1. It points to a gridded data file to define model topography values and is used by Point-Stat when verifying against "surface" message types, as identified using the message_type_group_map.

This functionality serves as a filter. If the model topo and surface station elevations differ too much (configurable), then that pair is excluded from the stats. Or, when interpolating forecast data to the obs location, only forecast points whose topography difference is small enough are used in that interpolation.

Somewhat similar to this is the land_mask config option to verify land forecast grid points against land obs and water forecast grid point vs water obs.

I do recall us discussing that we could have MET modify the forecast or obs values themselves to correct for the topography difference. And some other software systems in RAL do exactly that. But I'm not sure if there's a scientific consensus for how to do that. I do recall discussing with our US Air Force partners at the time, and they were satisfied with the topography filtering options rather than modifying the values themselves.

It sounds like the MetOffice would like to actually apply a temperature correction. Personally, I'd feel more comfortable correcting the forecast values than modifying the obs themselves. For example, if verifying multiple forecasts using the same set of point observations, keeping the point obs values unchanged would be desirable. And the good news is that we already have this situation well identified in the code... so presumably adding in the logic to perform the correction would be relatively straight-forward.

Presumably, we'd want to support a standard lapse rate correction. Are you aware of competing algorithms that should be supported in addition to, or instead of the lapse rate correction?

I'd also be interested to hear from others about this. @robdarvell this could be a good topic of conversation for the next METplus Advisory Group meeting. I definitely see how MET could be enhanced to provide one or more correction options. And it'd just be a matter of defining the specifics, identifying the funding source(s), and working it into a development timeline.