Precise exclusion of stations outside of mask #1215
-
A follow-on from #1208, but resulting from the same jobs. I have created a Northern Hemisphere mask ge20N -> le90N using the gen_vx_mask routine and the type -lat option on one of our Unified model netcdf files. I am now running that through my PointStat job using an observation file which contains Global observations. What I am hoping to extract are just those location which are from 20.0N and North of that (no rounded lats). There is one location which is getting through this net, which has a lat of 19.983. Is there any way of making sure that this (or others which may be there, just not in this example) are not getting included in the stats/output. It might be getting included as the lat boundaries in the file are '19.92188, 20.01562,' so it is falling between those two. If I alter the mask set up to do 20.016 then this location doesn't get included in the output, but I then lose another 3 which I want to include. I have also create a NH mask (same setup) using a file with slightly larger spacing between lats, but that then includes a few more 19.??? values in the output. Any thoughts/guidance welcome. Rob |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
@robdarvell yes, great question. There is a clear explanation for this behavior. You'll see that it describes 4 types of mask definitions: grid, poly, sid, and llpnt. The Point-Stat tool supports all 4 of these, while Grid-Stat only supports the first 2. Here's the important point...
You ran Gen-Vx-Mask to define a masking region from 20-90 degrees north latitude. You're telling MET to verify all grid points whose latitudes fall in that range. And I assume you've chosen nearest neighbor interpolation. With nearest neighbor interpolation, the point obs with latitude 19.92188 is matched to a grid point with a latitude of 20 degrees, and that grid point is include in your defined mask. If you had selected bilinear interpolation, I don't think it would have been included because 2 of the 4 forecast grid points would fall outside that masking region. In short, the mask is applied to forecast grid points, not the verifying point observations. So that explains the behavior you're seeing. This is not the first time this has come up. And if fact, this is the reason we added the llpnt mask option. This defines thresholds directly on the lat/lon values of the point observations themselves. Using the following should produce the exact behavior you want:
The obs with latitude 19.92188 does not meet the "lat_thresh" defined above, and will therefore be excluded. Note that using an "NA" threshold ALWAYS evaluates to true. Since we only care about the latitudes, I set lon_thresh to always evaluate to true. While this option makes it easy to threshold the observation lat/lon's themselves, you can see that it only works well for simple rectangular regions. Although, remember that MET does support complex thresholds. For example, you could only use points near the poles using: Use vertical bars (||) for OR and use double ampersands (&&) for AND, as described in the Configuration File Overview. Hope that helps clarify. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the comprehensive reply @johnhg . Understand now that MET uses a different framework for this aspect of the process compared to how VER runs it, and I will look further when I am back from leave. |
Beta Was this translation helpful? Give feedback.
@robdarvell yes, great question. There is a clear explanation for this behavior.
Please take a close look at the masking options in this section of the MET User's Guide.
You'll see that it describes 4 types of mask definitions: grid, poly, sid, and llpnt. The Point-Stat tool supports all 4 of these, while Grid-Stat only supports the first 2. Here's the important point...
You ran Gen-Vx-Mask to define a masking region from 20-90 degrees north latitude. You're telling MET to verify all gr…