Climo Data Unit Conversion Problem

[craigr3]

When verifying model forecasts of temperature in point_stat using the NCEP climo file for reference, I am having a problem converting the climo_data units. The model data is in Kelvin so I convert it to Celsius during verification. The climo data is also in Kelvin and so I also try to convert it to Celsius. I am using the built in conversion K_to_C(x). The model data and observation data converts fine but the climo data does the following. If I have a Kelvin temperature of 264.15, after the conversion I get -282.15. It seems to have convert the number twice (264.15 - 273.15 - 273.15). You should still have the NCEP climo file from discussion #1879

[j-opatz]

Hello,

And thank you for your question.

I was able to set up a test in Grid-Stat using MET 11.0.0 and replicate the issue you found.

After utilizing the convert(x) = K_to_C(x) utility independently for the forecast and climatology mean dictionaries, as well as both dictionaries, climo_mean seems to have a coding issue where the field is converting 2x the requested conversion. This is not unique to the K_to_C(x) command, either: requesting convert(x) = 2x returns 4x the values.

As mentioned, this is not dependent on if the convert utility is used in the forecast field.

@JohnHalleyGotway, can you take a look into the code that's responsible for conversion, specifically when it's used in the climo_mean dictionary?

[j-opatz]

I wanted to follow up that an issue has been created to address this: https://github.com/dtcenter/METplus/issues/2035

In that bugfix, you'll see that @JohnHalleyGotway was able to find a short-term fix for this. By placing the convert function inside the field array, the appropriate conversion is made. This would look something like:

////////////////////////////////////////////////////////////////////////////////

//
// Climatology data
//
climo_mean = {
   file_name = ["pgba_mean.19590115"];
   field     = [{name ="TMP"; level="Z2"; convert(x) = K_to_C(x);}];
   regrid = {
      method     = NEAREST;
      width      = 1;
      vld_thresh = 0.5;
      shape      = SQUARE;
   }

Understandably, this behavior should also occur when the convert function is placed in the climo_mean dictionary outside of the field array. We'll work on making this available in the next MET bugfix.

[craigr3]

I tried the workaround and it worked - I now am getting climo data for non 6hour forecasts and the units are converting correctly
That brings up a follow on question: I am verifying the model and providing climo data and the climo numbers look good- why do I still have NAs for RMSE confidence intervals? My config file settings for point_stat are:
ci_alpha = [0.05 ];
boot = {
interval = PCTILE;
rep_prop = 1.0;
n_rep = 0;
rng = "mt19937";
seed = "";
}
Do I have to switch to boot_strap mode to get output?

[j-opatz]

I'm glad the workaround is helping work proceed on your end. I see that you have an additional question regarding confidence intervals.

In your boot dictionary, you'll see that your n_rep variable is set to 0. If we take a look at the MET user's guide entry for n_rep, we see that:

This variable should be set large enough so that when confidence intervals are computed multiple times for the same set of data, the intervals do not change much. Setting this variable to zero disables the computation of bootstrap confidence intervals, which may be necessary to run MET in realtime or near-realtime over large domains since bootstrapping is computationally expensive.

So if you want to get confidence intervals, you'll need to increase this value. Just remember that the value selected is the number of times the confidence intervals will be rerun over the subsamples, so plan a size that doesn't have your computation taking longer than you desire.

[j-opatz]

Hello,

I wanted to reach out again and mention that this issue has been resolved. It should be available in the latest bugfix. Take a look here for the specifics: https://github.com/dtcenter/METplus/issues/2035

I'm going to close this Discussion as solved. If you have any additional issues, don't hesitate to open a new Discussions topic.