dtcenter / MET

Model Evaluation Tools
https://dtcenter.org/community-code/model-evaluation-tools-met
Apache License 2.0
78 stars 24 forks source link

Simplify logic when processing point observations named APCP. #1169

Open JohnHalleyGotway opened 5 years ago

JohnHalleyGotway commented 5 years ago

This issue arose when Tracy Hertneky was running met-8.1 on Conrad to verify against 24-hour precip point observations. Here's an example of the ascii point observations:

ADPSFC 5064510 20180603_000000 50.90 4.53 NA APCP 24 0 NA 0.0 ADPSFC 5064780 20180603_000000 50.65 5.45 NA APCP 24 0 NA 2.0

She configured point-stat, like this: message_type = [ "ADPSFC" ]; obs = { field = [ { name = "APCP"; level = [ "A24" ]; } ]; }

But all of the obs are rejected by Point-Stat because of the wrong "obstype". By convention, Point-Stat stores point observation config options using the VarInfoGrib class. But that class has special logic for the string "APCP". Whenever APCP is requested, the resulting name is stored as "APCP##" where ## is the requested accumulation interval. So Point-Stat is looking for obs named "APCP_24" but they're all named "APCP".

A second problem, when you rename the point observations as APCP_24, you still don't get any matches because of the accumulation interval. The requested level is "24" but the level for the observation values is 86,400 (the number of seconds). So we're not converting between time strings and integer seconds in all the right spots.

This task is to address the problem. Rather than messing with the existing GRIB1 naming conventions logic, consider writing a new VarInfoPointObs class which is a very stripped down version of VarInfoGrib that doesn't do any special APCP renaming.

Sample data for testing can be found on dakota in: /d3/projects/MET/MET_Help/hertneky_data_20190718

JohnHalleyGotway commented 1 year ago

This same issue arose when @robdarvell was testing SEEPS for MET-11.0.0-beta5. See data in seneca:/d1/projects/METplus/discussions/darvell_20221205.