Mask_poly on GridStat Data

[craigrj]

I am running stat_analysis on gridstat data. My command line is below:
/h/MET/bin/stat_analysis -lookin /h/data/global/WXQC/data/met/gdstat/mdlob_pairs/galwem/TC -out_stat /h/data/global/WXQC/data/met/summary/stat_anal_galwem_TC_GT80_20210701_20210731.txt -tmp_dir /h/data/global/WXQC/data/met/tmp -job aggregate_stat -line_type MPR -out_line_type CTS -out_fcst_thresh ">80" -fcst_var "TCDC" -fcst_lev L0 -out_obs_thresh ">80" -obs_var Cloud_Pct - fcst_valid_beg 20210701_000000 -fcst_valid_end 20210731_180000 -by fcst_lead -by obs_thresh -obs_lev SFC -by model -mask_poly /h/data/global/WXQC/data/met/poly/greenland.nc -by fcst_valid_ hour -config /h/data/global/WXQC/data/met/config/met_config/STATAnalysisConfig_bootstrap_aggstat -v 4.0

The question I have is what should be my -line_type in this situation. When I use -mask_poly, I need the model ob pairs to generate the statistic for a particular region. In point stat I would use the MPR line type for this but not sure what the setting should be for using gridded pairs.nc data from grid stat. I notice when I run the job MET is reading through the .stat files but in this case the model ob pairs are in the pairs.nc file. How is that supposed to work?

[j-opatz]

Hi Craig, and thank you for your question.

As you noted, the stat_analysis tool was initially designed to use the .stat files in a user's "-lookin" flag path.

As of MET version 9.0.0, though, users have an option to use a Python script to read in the MPR line type by setting the "lookin" flag to "python". Take a look at the MET User's Guide here, where there is a brief discussion on the topic.

I'll also provide a link to our METplus User's Guide MET tool wrapper for stat_analysis that specifically uses a Python script to read in the matched pair data. On that page you'll find a link to an example Python script, read_ascii_mpr.py, that may be of use to your situation.

Let us know if you have any further difficulties or questions.

[JohnHalleyGotway]

Bob,

Yes, just to emphasize the point that @j-opatz is making, the Stat-Analysis tool does not read the NetCDF matched pairs file created by Grid-Stat. Instead, it only reads the .stat ASCII flies created by Grid-Stat (as well as Point-Stat, Ensemble-Stat, and Wavelet-Stat).

@j-opatz is right that you could serve up paired data from those files to Stat-Analysis using python embedding. That's fine for investigation but likely isn't a good longterm solution for routine processing. You could always read those NetCDF matched pairs files from Grid-Stat back into Grid-Stat for further processing, if that's useful. Or you could pass them as input to the Series-Analysis tool to compute stats separately for each grid point through time.

Please feel free to describe the type of processing you're trying to do, and we could give it some more thought.

[craigrj]

We verified global model data with grid stat. I now need to get performance statistics for a subregion of the global domain using stat_analysis. In stat_analysis on point_stat model/ob pairs data, I would use a mask to limit the statistic calculations to a particular region. I need to do the same thing with grid_stat model ob pairs – generate stats for a sub region. How would I accomplish that?

[JohnHalleyGotway]

Bob, thanks for explaining what your goals are. You computed verification stats for the global domain, but are now interested in one or more smaller, regional sub-domains. I assume you've configured Grid-Stat to write the NetCDF matched pairs output file for your runs, since you're asking about them.

I would recommend writing a script to rerun Grid-Stat, using those NetCDF matched pairs files as input. So run Grid-Stat once for each NetCDF matched pairs file... and since the fcst and obs data lives in the same file, you'd pass it in for both the fcst_file and obs_file command line options. In the Grid-Stat config file, specify the fcst and obs variable names that you'd like to reprocess, and you can define one or more masking regions over which to compute stats.

Once you've computed stats for each sub-domain are written them to a .stat file, you can use the Stat-Analysis tool (or METviewer eventually) to aggregate results through time.

In the future, I suspect it'd be more convenient to just include the smaller regional subdomains in the list of the masking regions to be included in your initial global runs.