MTD documentation and interpreting results for matched objects

[mpm-meto]

I notice that Table 19.3 in the MET documentation has the units (in brackets) for the output quantities, which is really essential.

The equivalent Table 21.4 does not. It is crucial for the interpretation of the space_centroid_delta, time_centroid_delta and speed_delta that the units are made clearer. Also the fact that the time delta in particular can have a sign. Most of the time it is clear that if the forecast is fast and the difference is computed as F-O then the speed delta will be positive... but these aspects could be made clearer. Is the space centroid delta still in grid squares? Or is it great circle difference (in km?) And what units is the time delta? For example if the time delta is quoted as 0.13 and the time delta between time slices is 12h does that mean it's 0.13 * 12 = ~1.5h? Could someone confirm that this is correct?

As an aside if the grid_res in the MET config is used anywhere, it is not a variable in the METplus wrapper config, so it is conceivable that one can end up using the wrong conversion when using the METplus wrapper with the default MET config (which specifies the grid_res as 4 km).

[CPKalb]

Hi:

The attributes for MTD are in the same units as they are for MODE. The grid_res is available in the METplus wrapper config. It is called MODE_GRID_RES.

Thanks,
Christina

[mpm-meto]

Thanks for this. The MET wrapped config did not have this variable set so apologies for picking that one up.
As for the units, I am still a bit bamboozled by how to interpret the time centroid delta example I gave above. It feels like it should be in fractions of the time resolution as defined in the LEAD_SEQ increments? Am I right?
If nothing else the documentation may be strengthened by adding an example or two instead of just the tables which define the output file columns? Happy to help with that.

[CPKalb]

The time_centroid_delta is specifically calculated as the difference between the CENTROID_T values. The CENTROID_T is the time index associated with the object centroid, which is the geometric center of the 3d object. Specifically, the calculation is the obs CENTROID_T - fcst CENTROID_T. It's based off time indexing, which starts at 0, and each time step of the input data is given an index. For an object that is present in the first time step and persists for 4 time steps, the indices are 0, 1, 2, 3. If we take 1.5 as a forecast CENTROID_T and then an observation CENTROID_T of 2, then the time_centroid_delta would be 0.5. This means the time of the geometric center of the 3d object for the forecast was a half of a time step ahead of that for the observation. If our time step was 3 hours, then this would mean that the time of the geometric center was 1.5 h ahead in the forecast.

However, interpreting this attribute is not straightforward for a number of reasons. The 3d centroid location has dependency on the object shape and area, which typically changes over the time steps. So, the time centroid is not necessarily the center of the time steps that the object persisted across, but may be earlier or later depending on object shape, size, velocity, etc. Objects don't necessarily persist for the same amount of time steps and they may appear in the middle of a run (for example, an object could start at time step 10, which would give a larger CENTROID_T than an object that starts at the first time step even if they persist for the same amount of time). Finally, we don't really know what happened in between time steps, so it's hard to know if time_centroid_delta values less than 1 are useful.

If you are looking to characterize time differences, START_TIME_DELTA, END_TIME_DELTA, and DURATION_DIFF may provide information that is easier to interpret. All of these are given in time indices so would need to be converted to a time step (multiplying by the time step).

It seems like we may be able to make the MTD documentation stronger. I can bring this up at our meeting next week after the holiday as we have a number of scientists and engineers out this week.

Christina

[CPKalb]

We have created an issue to update the MTD documentation so that tables 21.3 and 21.4 have units.

Christina

[CPKalb]

I am checking in on this. Do you have additional questions regarding units or usage of MTD?

Thanks,
Christina