diff --git a/.readthedocs.yaml b/.readthedocs.yaml index e148a2aad0..acae87d7f0 100644 --- a/.readthedocs.yaml +++ b/.readthedocs.yaml @@ -7,7 +7,7 @@ version: 2 # Build all formats (htmlzip, pdf, epub) #formats: all -formats: [] +formats: [pdf] # Optionally set the version of Python and requirements required to build your # docs diff --git a/README.md b/README.md index 4b6e40f7ea..1c504e4d69 100644 --- a/README.md +++ b/README.md @@ -2,4 +2,4 @@ This repository contains the source code for the Model Evaluation Tools package (met), unit test code (test), and scripts used to build and test the code (scripts). -Please see the [MET website](https://dtcenter.org/community-code/model-evaluation-tools-met) for more information. Support for the METplus components is provided through the [METplus Discussions](https://github.com/dtcenter/METplus/discussions) forum. Users are welcome and encouraged to answer or address each other's questions there! For more information, please read "[Welcome to the METplus Components Discussions](https://github.com/dtcenter/METplus/discussions/939)". +Please see the [MET website](https://dtcenter.org/community-code/model-evaluation-tools-met) and the [MET User's Guide](https://met.readthedocs.io/en/latest) for more information. Support for the METplus components is provided through the [METplus Discussions](https://github.com/dtcenter/METplus/discussions) forum. Users are welcome and encouraged to answer or address each other's questions there! For more information, please read "[Welcome to the METplus Components Discussions](https://github.com/dtcenter/METplus/discussions/939)". diff --git a/met/data/map/admin_by_country/admin_Yemen_data b/met/data/map/admin_by_country/admin_Yemen_data index 3bb2d565c1..38eacd3988 100644 --- a/met/data/map/admin_by_country/admin_Yemen_data +++ b/met/data/map/admin_by_country/admin_Yemen_data @@ -126,7 +126,7 @@ 12.94042 -45.09903 12.86061 -45.05790 12.80125 -44.85958 -4 33 13.829 14.8252 -46.0336 -44.5861 'Al Bayḑā’ (Yemen)' +4 33 13.829 14.8252 -46.0336 -44.5861 'Al Bayḑā' (Yemen)' 14.53238 -45.11610 14.50399 -45.18688 14.55476 -45.31480 @@ -579,7 +579,7 @@ 17.42610 -43.61780 17.36670 -43.68330 17.33890 -43.83190 -17 40 14.7473 16.0428 -45.1087 -43.5061 'Şan‘ā’ (Yemen)' +17 40 14.7473 16.0428 -45.1087 -43.5061 'Şan‘ā' (Yemen)' 15.12214 -45.08009 14.79469 -44.90892 14.74730 -44.83651 diff --git a/met/data/map/admin_data b/met/data/map/admin_data index e1e5e18f84..db40e5e64b 100644 --- a/met/data/map/admin_data +++ b/met/data/map/admin_data @@ -82728,7 +82728,7 @@ 30.32615 -48.28101 30.20689 -48.39930 30.20050 -48.40535 -1193 33 13.829 14.8252 -46.0336 -44.5861 'Al Bayḑā’ (Yemen)' +1193 33 13.829 14.8252 -46.0336 -44.5861 'Al Bayḑā' (Yemen)' 14.53238 -45.11610 14.50399 -45.18688 14.55476 -45.31480 @@ -85990,7 +85990,7 @@ 35.17110 -43.41893 35.14398 -43.44602 35.05437 -43.54642 -1267 40 14.7473 16.0428 -45.1087 -43.5061 'Şan‘ā’ (Yemen)' +1267 40 14.7473 16.0428 -45.1087 -43.5061 'Şan‘ā' (Yemen)' 15.12214 -45.08009 14.79469 -44.90892 14.74730 -44.83651 diff --git a/met/data/table_files/met_header_columns_V10.1.txt b/met/data/table_files/met_header_columns_V10.1.txt index 6c64d89a5f..d538d74c92 100644 --- a/met/data/table_files/met_header_columns_V10.1.txt +++ b/met/data/table_files/met_header_columns_V10.1.txt @@ -1,4 +1,4 @@ -V10.1 : STAT : CNT : VERSION MODEL DESC FCST_LEAD FCST_VALID_BEG FCST_VALID_END OBS_LEAD OBS_VALID_BEG OBS_VALID_END FCST_VAR FCST_UNITS FCST_LEV OBS_VAR OBS_UNITS OBS_LEV OBTYPE VX_MASK INTERP_MTHD INTERP_PNTS FCST_THRESH OBS_THRESH COV_THRESH ALPHA LINE_TYPE TOTAL FBAR FBAR_NCL FBAR_NCU FBAR_BCL FBAR_BCU FSTDEV FSTDEV_NCL FSTDEV_NCU FSTDEV_BCL FSTDEV_BCU OBAR OBAR_NCL OBAR_NCU OBAR_BCL OBAR_BCU OSTDEV OSTDEV_NCL OSTDEV_NCU OSTDEV_BCL OSTDEV_BCU PR_CORR PR_CORR_NCL PR_CORR_NCU PR_CORR_BCL PR_CORR_BCU SP_CORR KT_CORR RANKS FRANK_TIES ORANK_TIES ME ME_NCL ME_NCU ME_BCL ME_BCU ESTDEV ESTDEV_NCL ESTDEV_NCU ESTDEV_BCL ESTDEV_BCU MBIAS MBIAS_BCL MBIAS_BCU MAE MAE_BCL MAE_BCU MSE MSE_BCL MSE_BCU BCMSE BCMSE_BCL BCMSE_BCU RMSE RMSE_BCL RMSE_BCU E10 E10_BCL E10_BCU E25 E25_BCL E25_BCU E50 E50_BCL E50_BCU E75 E75_BCL E75_BCU E90 E90_BCL E90_BCU EIQR EIQR_BCL EIQR_BCU MAD MAD_BCL MAD_BCU ANOM_CORR ANOM_CORR_NCL ANOM_CORR_NCU ANOM_CORR_BCL ANOM_CORR_BCU ME2 ME2_BCL ME2_BCU MSESS MSESS_BCL MSESS_BCU RMSFA RMSFA_BCL RMSFA_BCU RMSOA RMSOA_BCL RMSOA_BCU ANOM_CORR_UNCNTR ANOM_CORR_UNCNTR_BCL ANOM_CORR_UNCNTR_BCU +V10.1 : STAT : CNT : VERSION MODEL DESC FCST_LEAD FCST_VALID_BEG FCST_VALID_END OBS_LEAD OBS_VALID_BEG OBS_VALID_END FCST_VAR FCST_UNITS FCST_LEV OBS_VAR OBS_UNITS OBS_LEV OBTYPE VX_MASK INTERP_MTHD INTERP_PNTS FCST_THRESH OBS_THRESH COV_THRESH ALPHA LINE_TYPE TOTAL FBAR FBAR_NCL FBAR_NCU FBAR_BCL FBAR_BCU FSTDEV FSTDEV_NCL FSTDEV_NCU FSTDEV_BCL FSTDEV_BCU OBAR OBAR_NCL OBAR_NCU OBAR_BCL OBAR_BCU OSTDEV OSTDEV_NCL OSTDEV_NCU OSTDEV_BCL OSTDEV_BCU PR_CORR PR_CORR_NCL PR_CORR_NCU PR_CORR_BCL PR_CORR_BCU SP_CORR KT_CORR RANKS FRANK_TIES ORANK_TIES ME ME_NCL ME_NCU ME_BCL ME_BCU ESTDEV ESTDEV_NCL ESTDEV_NCU ESTDEV_BCL ESTDEV_BCU MBIAS MBIAS_BCL MBIAS_BCU MAE MAE_BCL MAE_BCU MSE MSE_BCL MSE_BCU BCMSE BCMSE_BCL BCMSE_BCU RMSE RMSE_BCL RMSE_BCU E10 E10_BCL E10_BCU E25 E25_BCL E25_BCU E50 E50_BCL E50_BCU E75 E75_BCL E75_BCU E90 E90_BCL E90_BCU EIQR EIQR_BCL EIQR_BCU MAD MAD_BCL MAD_BCU ANOM_CORR ANOM_CORR_NCL ANOM_CORR_NCU ANOM_CORR_BCL ANOM_CORR_BCU ME2 ME2_BCL ME2_BCU MSESS MSESS_BCL MSESS_BCU RMSFA RMSFA_BCL RMSFA_BCU RMSOA RMSOA_BCL RMSOA_BCU ANOM_CORR_UNCNTR ANOM_CORR_UNCNTR_BCL ANOM_CORR_UNCNTR_BCU SI SI_BCL SI_BCU V10.1 : STAT : CTC : VERSION MODEL DESC FCST_LEAD FCST_VALID_BEG FCST_VALID_END OBS_LEAD OBS_VALID_BEG OBS_VALID_END FCST_VAR FCST_UNITS FCST_LEV OBS_VAR OBS_UNITS OBS_LEV OBTYPE VX_MASK INTERP_MTHD INTERP_PNTS FCST_THRESH OBS_THRESH COV_THRESH ALPHA LINE_TYPE TOTAL FY_OY FY_ON FN_OY FN_ON V10.1 : STAT : CTS : VERSION MODEL DESC FCST_LEAD FCST_VALID_BEG FCST_VALID_END OBS_LEAD OBS_VALID_BEG OBS_VALID_END FCST_VAR FCST_UNITS FCST_LEV OBS_VAR OBS_UNITS OBS_LEV OBTYPE VX_MASK INTERP_MTHD INTERP_PNTS FCST_THRESH OBS_THRESH COV_THRESH ALPHA LINE_TYPE TOTAL BASER BASER_NCL BASER_NCU BASER_BCL BASER_BCU FMEAN FMEAN_NCL FMEAN_NCU FMEAN_BCL FMEAN_BCU ACC ACC_NCL ACC_NCU ACC_BCL ACC_BCU FBIAS FBIAS_BCL FBIAS_BCU PODY PODY_NCL PODY_NCU PODY_BCL PODY_BCU PODN PODN_NCL PODN_NCU PODN_BCL PODN_BCU POFD POFD_NCL POFD_NCU POFD_BCL POFD_BCU FAR FAR_NCL FAR_NCU FAR_BCL FAR_BCU CSI CSI_NCL CSI_NCU CSI_BCL CSI_BCU GSS GSS_BCL GSS_BCU HK HK_NCL HK_NCU HK_BCL HK_BCU HSS HSS_BCL HSS_BCU ODDS ODDS_NCL ODDS_NCU ODDS_BCL ODDS_BCU LODDS LODDS_NCL LODDS_NCU LODDS_BCL LODDS_BCU ORSS ORSS_NCL ORSS_NCU ORSS_BCL ORSS_BCU EDS EDS_NCL EDS_NCU EDS_BCL EDS_BCU SEDS SEDS_NCL SEDS_NCU SEDS_BCL SEDS_BCU EDI EDI_NCL EDI_NCU EDI_BCL EDI_BCU SEDI SEDI_NCL SEDI_NCU SEDI_BCL SEDI_BCU BAGSS BAGSS_BCL BAGSS_BCU V10.1 : STAT : FHO : VERSION MODEL DESC FCST_LEAD FCST_VALID_BEG FCST_VALID_END OBS_LEAD OBS_VALID_BEG OBS_VALID_END FCST_VAR FCST_UNITS FCST_LEV OBS_VAR OBS_UNITS OBS_LEV OBTYPE VX_MASK INTERP_MTHD INTERP_PNTS FCST_THRESH OBS_THRESH COV_THRESH ALPHA LINE_TYPE TOTAL F_RATE H_RATE O_RATE diff --git a/met/docs/Users_Guide/appendixA.rst b/met/docs/Users_Guide/appendixA.rst index 9a0d619648..f681f48361 100644 --- a/met/docs/Users_Guide/appendixA.rst +++ b/met/docs/Users_Guide/appendixA.rst @@ -44,7 +44,7 @@ A. Currently, very few graphics are included. The plotting tools (plot_point_obs **Q. How do I find the version of the tool I am using?** -A. Type the name of the tool followed by **-version**. For example, type “pb2nc **-version**”. +A. Type the name of the tool followed by **-version**. For example, type "pb2nc **-version**". **Q. What are MET's conventions for latitude, longitude, azimuth and bearing angles?** @@ -81,11 +81,11 @@ The first place to look for help with individual commands is this user's guide o **Error while loading shared libraries** -* Add the lib dir to your LD_LIBRARY_PATH. For example, if you receive the following error: “./mode_analysis: error while loading shared libraries: libgsl.so.19: cannot open shared object file: No such file or directory”, you should add the path to the gsl lib (for example, */home/user/MET/gsl-2.1/lib*) to your LD_LIBRARY_PATH. +* Add the lib dir to your LD_LIBRARY_PATH. For example, if you receive the following error: "./mode_analysis: error while loading shared libraries: libgsl.so.19: cannot open shared object file: No such file or directory", you should add the path to the gsl lib (for example, */home/user/MET/gsl-2.1/lib*) to your LD_LIBRARY_PATH. **General troubleshooting** -* For configuration files used, make certain to use empty square brackets (e.g. [ ]) to indicate no stratification is desired. Do NOT use empty double quotation marks inside square brackets (e.g. [“”]). +* For configuration files used, make certain to use empty square brackets (e.g. [ ]) to indicate no stratification is desired. Do NOT use empty double quotation marks inside square brackets (e.g. [""]). * Have you designated all the required command line arguments? diff --git a/met/docs/Users_Guide/appendixB.rst b/met/docs/Users_Guide/appendixB.rst index 4f93087fad..605712ca43 100644 --- a/met/docs/Users_Guide/appendixB.rst +++ b/met/docs/Users_Guide/appendixB.rst @@ -33,7 +33,7 @@ To specify a Lambert Grid, the syntax is lambert Nx Ny lat_ll lon_ll lon_orient D_km R_km standard_lat_1 [ standard_lat_2 ] N|S -Here, **Nx** and **Ny** are the number of points in, respectively, the **x** and **y** grid directions. These two numbers give the overall size of the grid. **lat_ll** and **lon_ll** are the latitude and longitude, in degrees, of the lower left point of the grid. North latitude and east longitude are considered positive. **lon_orient** is the orientation longitude of the grid. It’s the meridian of longitude that’s parallel to one of the vertical grid directions. **D_km** and **R_km** are the grid resolution and the radius of the Earth, both in kilometers. **standard_lat_1** and **standard_lat_2** are the standard parallels of the Lambert projection. If the two latitudes are the same, then only one needs to be given. **N|S** means to write either **N** or **S** depending on whether the Lambert projection is from the north pole or the south pole. +Here, **Nx** and **Ny** are the number of points in, respectively, the **x** and **y** grid directions. These two numbers give the overall size of the grid. **lat_ll** and **lon_ll** are the latitude and longitude, in degrees, of the lower left point of the grid. North latitude and east longitude are considered positive. **lon_orient** is the orientation longitude of the grid. It's the meridian of longitude that's parallel to one of the vertical grid directions. **D_km** and **R_km** are the grid resolution and the radius of the Earth, both in kilometers. **standard_lat_1** and **standard_lat_2** are the standard parallels of the Lambert projection. If the two latitudes are the same, then only one needs to be given. **N|S** means to write either **N** or **S** depending on whether the Lambert projection is from the north pole or the south pole. As an example of specifying a Lambert grid, suppose you have a northern hemisphere Lambert grid with 614 points in the x direction and 428 points in the y direction. The lower left corner of the grid is at latitude :math:`12.190^\circ` north and longitude :math:`133.459^\circ` west. The orientation longitude is :math:`95^\circ` west. The grid spacing is :math:`12.19058^\circ` km. The radius of the Earth is the default value used in many grib files: 6367.47 km. Both standard parallels are at :math:`25^\circ` north. To specify this grid in the config file, you would write @@ -55,7 +55,7 @@ For Plate Carrée (i.e. Lat/Lon) grids, the syntax is latlon Nx Ny lat_ll lon_ll delta_lat delta_lon -The parameters **Nx, Ny, lat_ll** and **lon_ll** are as before. **delta_lat** and **delta_lon** are the latitude and longitude increments of the grid—i.e., the change in latitude or longitude between one grid point and an adjacent grid point. +The parameters **Nx, Ny, lat_ll** and **lon_ll** are as before. **delta_lat** and **delta_lon** are the latitude and longitude increments of the grid-i.e., the change in latitude or longitude between one grid point and an adjacent grid point. For a Rotated Plate Carrée (i.e. Rotated Lat/Lon) grids, the syntax is diff --git a/met/docs/Users_Guide/appendixC.rst b/met/docs/Users_Guide/appendixC.rst index 547e211d7f..3285d19e7d 100644 --- a/met/docs/Users_Guide/appendixC.rst +++ b/met/docs/Users_Guide/appendixC.rst @@ -147,8 +147,13 @@ Called "H_RATE" in FHO output :numref:`table_PS_format_info_FHO` H_RATE is defined as -.. math:: \text{H_RATE } = \frac{n_{11}}{T}. +.. only:: latex + .. math:: \text{H\_RATE } = \frac{n_{11}}{T}. + +.. only:: html + + .. math:: \text{H_RATE } = \frac{n_{11}}{T}. H_RATE is equivalent to the H value computed by the NCEP verification system. H_RATE ranges from 0 to 1; a perfect forecast would have H_RATE = 1. @@ -252,7 +257,13 @@ where A more general format that uses percentages is provided by Ou (:ref:`Ou, 2016 `), -.. math:: \text{HSS(\%) } = 100 \ast \frac{(H - E)}{(T - E)} +.. only:: latex + + .. math:: \text{HSS(\%) } = 100 \ast \frac{(H - E)}{(T - E)} + +.. only:: html + + .. math:: \text{HSS(%) } = 100 \ast \frac{(H - E)}{(T - E)} where H is the number of forecasts in the correct category and E is the expected number of forecasts by chance. @@ -496,6 +507,15 @@ Called "RMSE" in CNT output :numref:`table_PS_format_info_CNT` RMSE is simply the square root of the MSE, :math:`\text{RMSE} = \sqrt{\text{MSE}}`. +Scatter Index (SI) +~~~~~~~~~~~~~~~~~~ + +Called "SI" in CNT output :numref:`table_PS_format_info_CNT` + +SI is the ratio of the root mean squared error to the average observation value, :math:`\text{SI} = \text{RMSE} / \text{OBAR}`. + +Smaller values of SI indicate better agreement between the model and observations (less scatter on scatter plot). + Standard deviation of the error ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -581,11 +601,17 @@ The anomaly correlation coefficient is equivalent to the Pearson correlation coe The centered anomaly correlation coefficient (ANOM_CORR) which includes the mean error is defined as: -.. math:: \text{ANOM_CORR } = \frac{ \bar{[(f - c) - \bar{(f - c)}][(a - c) - \bar{(a - c)}]}}{ \sqrt{ \bar{( (f - c) - \bar{(f - c)})^2} \bar{( (a - c) - \bar{(a - c)})^2}}} +.. only:: latex + + .. math:: \text{ANOM\_CORR } = \frac{ \overline{[(f - c) - \overline{(f - c)}][(a - c) - \overline{(a - c)}]}}{ \sqrt{ \overline{( (f - c) - \overline{(f - c)})^2} \overline{( (a - c) - \overline{(a - c)})^2}}} + +.. only:: html + + .. math:: \text{ANOM_CORR } = \frac{ \overline{[(f - c) - \overline{(f - c)}][(a - c) - \overline{(a - c)}]}}{ \sqrt{ \overline{( (f - c) - \overline{(f - c)})^2} \overline{( (a - c) - \overline{(a - c)})^2}}} The uncentered anomaly correlation coefficient (ANOM_CORR_UNCNTR) which does not include the mean errors is defined as: -.. math:: \text{Anomaly Correlation Raw } = \frac{ \bar{(f - c)(a - c)}}{ \sqrt{\bar{(f - c)^2} \bar{(a - c)^2}}} +.. math:: \text{Anomaly Correlation Raw } = \frac{ \overline{(f - c)(a - c)}}{ \sqrt{\overline{(f - c)^2} \overline{(a - c)^2}}} Anomaly correlation can range between -1 and 1; a value of 1 indicates perfect correlation and a value of -1 indicates perfect negative correlation. A value of 0 indicates that the forecast and observed anomalies are not correlated. @@ -594,9 +620,9 @@ Partial Sums lines (SL1L2, SAL1L2, VL1L2, VAL1L2) :numref:`table_PS_format_info_SL1L2`, :numref:`table_PS_format_info_SAL1L2`, :numref:`table_PS_format_info_VL1L2`, and :numref:`table_PS_format_info_VAL1L2` -The SL1L2, SAL1L2, VL1L2, and VAL1L2 line types are used to store data summaries (e.g. partial sums) that can later be accumulated into verification statistics. These are divided according to scalar or vector summaries (S or V). The climate anomaly values (A) can be stored in place of the actuals, which is just a re-centering of the values around the climatological average. L1 and L2 refer to the L1 and L2 norms, the distance metrics commonly referred to as the “city block” and “Euclidean” distances. The city block is the absolute value of a distance while the Euclidean distance is the square root of the squared distance. +The SL1L2, SAL1L2, VL1L2, and VAL1L2 line types are used to store data summaries (e.g. partial sums) that can later be accumulated into verification statistics. These are divided according to scalar or vector summaries (S or V). The climate anomaly values (A) can be stored in place of the actuals, which is just a re-centering of the values around the climatological average. L1 and L2 refer to the L1 and L2 norms, the distance metrics commonly referred to as the "city block" and "Euclidean" distances. The city block is the absolute value of a distance while the Euclidean distance is the square root of the squared distance. -The partial sums can be accumulated over individual cases to produce statistics for a longer period without any loss of information because these sums are *sufficient* for resulting statistics such as RMSE, bias, correlation coefficient, and MAE (:ref:`Mood et al., 1974 `). Thus, the individual errors need not be stored, all of the information relevant to calculation of statistics are contained in the sums. As an example, the sum of all data points and the sum of all squared data points (or equivalently, the sample mean and sample variance) are *jointly sufficient* for estimates of the Gaussian distribution mean and variance. +The partial sums can be accumulated over individual cases to produce statistics for a longer period without any loss of information because these sums are *sufficient* for resulting statistics such as RMSE, bias, correlation coefficient, and MAE (:ref:`Mood et al., 1974 `). Thus, the individual errors need not be stored, all of the information relevant to calculation of statistics are contained in the sums. As an example, the sum of all data points and the sum of all squared data points (or equivalently, the sample mean and sample variance) are *jointly sufficient* for estimates of the Gaussian distribution mean and variance. *Minimally sufficient* statistics are those that condense the data most, with no loss of information. Statistics based on L1 and L2 norms allow for good compression of information. Statistics based on other norms, such as order statistics, do not result in good compression of information. For this reason, statistics such as RMSE are often preferred to statistics such as the median absolute deviation. The partial sums are not sufficient for order statistics, such as the median or quartiles. @@ -607,15 +633,16 @@ Called "FBAR", "OBAR", "FOBAR", "FFBAR", and "OOBAR" in SL1L2 output :numref:`ta These statistics are simply the 1st and 2nd moments of the forecasts, observations and errors: -.. math:: \text{FBAR} = \text{Mean}(f) = \bar{f} = \frac{1}{n} \sum_{i=1}^n f_i +.. math:: + \text{FBAR} = \text{Mean}(f) = \bar{f} = \frac{1}{n} \sum_{i=1}^n f_i - \text{OBAR} = \text{Mean}(o) = \bar{o} = \frac{1}{n} \sum_{i=1}^n o_i + \text{OBAR} = \text{Mean}(o) = \bar{o} = \frac{1}{n} \sum_{i=1}^n o_i - \text{FOBAR} = \text{Mean}(fo) = \bar{fo} = \frac{1}{n} \sum_{i=1}^n f_i o_i + \text{FOBAR} = \text{Mean}(fo) = \bar{fo} = \frac{1}{n} \sum_{i=1}^n f_i o_i - \text{FFBAR} = \text{Mean}(f^2) = \bar{f}^2 = \frac{1}{n} \sum_{i=1}^n f_i^2 + \text{FFBAR} = \text{Mean}(f^2) = \bar{f}^2 = \frac{1}{n} \sum_{i=1}^n f_i^2 - \text{OOBAR} = \text{Mean}(o^2) = \bar{o}^2 = \frac{1}{n} \sum_{i=1}^n o_i^2 + \text{OOBAR} = \text{Mean}(o^2) = \bar{o}^2 = \frac{1}{n} \sum_{i=1}^n o_i^2 Some of the other statistics for continuous forecasts (e.g., RMSE) can be derived from these moments. @@ -626,15 +653,16 @@ Called "FABAR", "OABAR", "FOABAR", "FFABAR", "OOABAR" in SAL1L2 output :numref:` Computation of these statistics requires a climatological value, c. These statistics are the 1st and 2nd moments of the scalar anomalies. The moments are defined as: -.. math:: \text{FABAR} = \text{Mean}(f - c) = \bar{f - c} = \frac{1}{n} \sum_{i=1}^n (f_i - c) +.. math:: + \text{FABAR} = \text{Mean}(f - c) = \bar{f - c} = \frac{1}{n} \sum_{i=1}^n (f_i - c) - \text{OABAR} = \text{Mean}(o - c) = \bar{o - c} = \frac{1}{n} \sum_{i=1}^n (o_i - c) + \text{OABAR} = \text{Mean}(o - c) = \bar{o - c} = \frac{1}{n} \sum_{i=1}^n (o_i - c) - \text{FOABAR} = \text{Mean}[(f - c)(o - c)] = \bar{(f - c)(o - c)} = \frac{1}{n} \sum_{i=1}^n (f_i - c)(o_i - c) + \text{FOABAR} = \text{Mean}[(f - c)(o - c)] = \bar{(f - c)(o - c)} = \frac{1}{n} \sum_{i=1}^n (f_i - c)(o_i - c) - \text{FFABAR} = \text{Mean}[(f - c)^2] = \bar{(f - c)}^2 = \frac{1}{n} \sum_{i=1}^n (f_i - c)^2 + \text{FFABAR} = \text{Mean}[(f - c)^2] = \bar{(f - c)}^2 = \frac{1}{n} \sum_{i=1}^n (f_i - c)^2 - \text{OOABAR} = \text{Mean}[(o - c)^2] = \bar{(o - c)}^2 = \frac{1}{n} \sum_{i=1}^n (o_i - c)^2 + \text{OOABAR} = \text{Mean}[(o - c)^2] = \bar{(o - c)}^2 = \frac{1}{n} \sum_{i=1}^n (o_i - c)^2 Vector L1 and L2 values ~~~~~~~~~~~~~~~~~~~~~~~ @@ -643,19 +671,20 @@ Called "UFBAR", "VFBAR", "UOBAR", "VOBAR", "UVFOBAR", "UVFFBAR", "UVOOBAR" in VL These statistics are the moments for wind vector values, where **u** is the E-W wind component and **v** is the N-S wind component ( :math:`u_f` is the forecast E-W wind component; :math:`u_o` is the observed E-W wind component; :math:`v_f` is the forecast N-S wind component; and :math:`v_o` is the observed N-S wind component). The following measures are computed: -.. math:: \text{UFBAR} = \text{Mean}(u_f) = \bar{u}_f = \frac{1}{n} \sum_{i=1}^n u_{fi} +.. math:: + \text{UFBAR} = \text{Mean}(u_f) = \bar{u}_f = \frac{1}{n} \sum_{i=1}^n u_{fi} - \text{VFBAR} = \text{Mean}(v_f) = \bar{v}_f = \frac{1}{n} \sum_{i=1}^n v_{fi} + \text{VFBAR} = \text{Mean}(v_f) = \bar{v}_f = \frac{1}{n} \sum_{i=1}^n v_{fi} - \text{UOBAR} = \text{Mean}(u_o) = \bar{u}_o = \frac{1}{n} \sum_{i=1}^n u_{oi} + \text{UOBAR} = \text{Mean}(u_o) = \bar{u}_o = \frac{1}{n} \sum_{i=1}^n u_{oi} - \text{VOBAR} = \text{Mean}(v_o) = \bar{v}_o = \frac{1}{n} \sum_{i=1}^n v_{oi} + \text{VOBAR} = \text{Mean}(v_o) = \bar{v}_o = \frac{1}{n} \sum_{i=1}^n v_{oi} - \text{UVFOBAR} = \text{Mean}(u_f u_o + v_f v_o) = \frac{1}{n} \sum_{i=1}^n (u_{fi} u_{oi} + v_{fi} v_{oi}) + \text{UVFOBAR} = \text{Mean}(u_f u_o + v_f v_o) = \frac{1}{n} \sum_{i=1}^n (u_{fi} u_{oi} + v_{fi} v_{oi}) - \text{UVFFBAR} = \text{Mean}(u_f^2 + v_f^2) = \frac{1}{n} \sum_{i=1}^n (u_{fi}^2 + v_{fi}^2) + \text{UVFFBAR} = \text{Mean}(u_f^2 + v_f^2) = \frac{1}{n} \sum_{i=1}^n (u_{fi}^2 + v_{fi}^2) - \text{UVOOBAR} = \text{Mean}(u_o^2 + v_o^2) = \frac{1}{n} \sum_{i=1}^n (u_{oi}^2 + v_{oi}^2) + \text{UVOOBAR} = \text{Mean}(u_o^2 + v_o^2) = \frac{1}{n} \sum_{i=1}^n (u_{oi}^2 + v_{oi}^2) Vector anomaly L1 and L2 values ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -664,20 +693,21 @@ Called "UFABAR", "VFABAR", "UOABAR", "VOABAR", "UVFOABAR", "UVFFABAR", "UVOOABAR These statistics require climatological values for the wind vector components, :math:`u_c \text{ and } v_c`. The measures are defined below: -.. math:: \text{UFABAR} = \text{Mean}(u_f - u_c) = \frac{1}{n} \sum_{i=1}^n (u_{fi} - u_c) +.. math:: + \text{UFABAR} = \text{Mean}(u_f - u_c) = \frac{1}{n} \sum_{i=1}^n (u_{fi} - u_c) - \text{VFBAR} = \text{Mean}(v_f - v_c) = \frac{1}{n} \sum_{i=1}^n (v_{fi} - v_c) + \text{VFBAR} = \text{Mean}(v_f - v_c) = \frac{1}{n} \sum_{i=1}^n (v_{fi} - v_c) - \text{UOABAR} = \text{Mean}(u_o - u_c) = \frac{1}{n} \sum_{i=1}^n (u_{oi} - u_c) + \text{UOABAR} = \text{Mean}(u_o - u_c) = \frac{1}{n} \sum_{i=1}^n (u_{oi} - u_c) - \text{VOABAR} = \text{Mean}(v_o - v_c) = \frac{1}{n} \sum_{i=1}^n (v_{oi} - v_c) + \text{VOABAR} = \text{Mean}(v_o - v_c) = \frac{1}{n} \sum_{i=1}^n (v_{oi} - v_c) - \text{UVFOABAR} &= \text{Mean}[(u_f - u_c)(u_o - u_c) + (v_f - v_c)(v_o - v_c)] \\ - &= \frac{1}{n} \sum_{i=1}^n (u_{fi} - u_c) + (u_{oi} - u_c) + (v_{fi} - v_c)(v_{oi} - v_c) + \text{UVFOABAR} &= \text{Mean}[(u_f - u_c)(u_o - u_c) + (v_f - v_c)(v_o - v_c)] \\ + &= \frac{1}{n} \sum_{i=1}^n (u_{fi} - u_c) + (u_{oi} - u_c) + (v_{fi} - v_c)(v_{oi} - v_c) - \text{UVFFABAR} = \text{Mean}[(u_f - u_c)^2 + (v_f - v_c)^2] = \frac{1}{n} \sum_{i=1}^n ((u_{fi} - u_c)^2 + (v_{fi} - v_c)^2) + \text{UVFFABAR} = \text{Mean}[(u_f - u_c)^2 + (v_f - v_c)^2] = \frac{1}{n} \sum_{i=1}^n ((u_{fi} - u_c)^2 + (v_{fi} - v_c)^2) - \text{UVOOABAR} = \text{Mean}[(u_o - u_c)^2 + (v_o - v_c)^2] = \frac{1}{n} \sum_{i=1}^n ((u_{oi} - u_c)^2 + (v_{oi} - v_c)^2) + \text{UVOOABAR} = \text{Mean}[(u_o - u_c)^2 + (v_o - v_c)^2] = \frac{1}{n} \sum_{i=1}^n ((u_{oi} - u_c)^2 + (v_{oi} - v_c)^2) Gradient values ~~~~~~~~~~~~~~~ @@ -686,25 +716,40 @@ Called "TOTAL", "FGBAR", "OGBAR", "MGBAR", "EGBAR", "S1", "S1_OG", and "FGOG_RAT These statistics are only computed by the Grid-Stat tool and require vectors. Here :math:`\nabla` is the gradient operator, which in this applications signifies the difference between adjacent grid points in both the grid-x and grid-y directions. TOTAL is the count of grid locations used in the calculations. The remaining measures are defined below: -.. math:: \text{FGBAR} = \text{Mean}|\nabla f| = \frac{1}{n} \sum_{i=1}^n | \nabla f_i| +.. math:: + \text{FGBAR} = \text{Mean}|\nabla f| = \frac{1}{n} \sum_{i=1}^n | \nabla f_i| - \text{OGBAR} = \text{Mean}|\nabla o| = \frac{1}{n} \sum_{i=1}^n | \nabla o_i| + \text{OGBAR} = \text{Mean}|\nabla o| = \frac{1}{n} \sum_{i=1}^n | \nabla o_i| - \text{MGBAR} = \text{Max(FGBAR, OGBAR)} + \text{MGBAR} = \text{Max(FGBAR, OGBAR)} - \text{EGBAR} = \text{Mean}|\nabla f - \nabla o| = \frac{1}{n} \sum_{i=1}^n | \nabla f_i - \nabla o_i| + \text{EGBAR} = \text{Mean}|\nabla f - \nabla o| = \frac{1}{n} \sum_{i=1}^n | \nabla f_i - \nabla o_i| - \text{S1} = 100 \frac{\sum_{i=1}^n (w_i (e_g))}{\sum_{i=1}^n (w_i (G_L))}_i , + \text{S1} = 100 \frac{\sum_{i=1}^n (w_i (e_g))}{\sum_{i=1}^n (w_i (G_L))}_i , where the weights are applied at each grid location, with values assigned according to the weight option specified in the configuration file. The components of the :math:`S1` equation are as follows: -.. math:: e_g = (| \frac{\delta}{\delta x}(f - o)| + | \frac{\delta}{\delta y}(f - o)|) +.. math:: + e_g = (\vert \frac{\delta}{\delta x}(f - o)\vert + \vert \frac{\delta}{\delta y}(f - o)\vert) + + G_L = \text{max }(\vert \frac{\delta f}{\delta x}\vert,\vert \frac{\delta o}{\delta x}\vert) + \text{max }(\vert \frac{\delta f}{\delta y}\vert,\vert \frac{\delta o}{\delta y}|) + - G_L = \text{max}(| \frac{\delta f}{\delta x}|,| \frac{\delta o}{\delta x}|) + \text{max}(| \frac{\delta f}{\delta y}|,| \frac{\delta o}{\delta y}|) +.. only:: latex - \text{S1_OG} = \frac{\text{EGBAR}}{\text{OGBAR}} + .. math:: + + \text{S1\_OG} = \frac{\text{EGBAR}}{\text{OGBAR}} + + \text{FGOG\_RATIO} = \frac{\text{FGBAR}}{\text{OGBAR}} + +.. only:: html + + .. math:: + \text{S1_OG} = \frac{\text{EGBAR}}{\text{OGBAR}} + + \text{FGOG_RATIO} = \frac{\text{FGBAR}}{\text{OGBAR}} - \text{FGOG_RATIO} = \frac{\text{FGBAR}}{\text{OGBAR}} MET verification measures for probabilistic forecasts _____________________________________________________ @@ -903,6 +948,24 @@ The area under the curve can be estimated in a variety of ways. In MET, the simp MET verification measures for ensemble forecasts ________________________________________________ +RPS +~~~ + +Called "RPS" in RPS output :numref:`table_ES_header_info_es_out_ECNT` + +While the above probabilistic verification measures utilize dichotomous observations, the Ranked Probability Score (RPS, :ref:`Epstein, 1969 `, :ref:`Murphy, 1969 `) is the only probabilistic verification measure for discrete multiple-category events available in MET. It is assumed that the categories are ordinal as nominal categorical variables can be collapsed into sequences of binary predictands, which can in turn be evaluated with the above measures for dichotomous variables (:ref:`Wilks, 2011 `). The RPS is the multi-category extension of the Brier score (:ref:`Tödter and Ahrens, 2012`), and is a proper score (:ref:`Mason, 2008`). + +Let :math:`\text{J}` be the number of categories, then both the forecast, :math:`\text{f} = (f_1,…,f_J)`, and observation, :math:`\text{o} = (o_1,…,o_J)`, are length-:math:`\text{J}` vectors, where the components of :math:`\text{f}` include the probabilities forecast for each category :math:`\text{1,…,J}` and :math:`\text{o}` contains 1 in the category that is realized and zero everywhere else. The cumulative forecasts, :math:`F_m`, and observations, :math:`O_m`, are defined to be: + +:math:`F_m = \sum_{j=1}^m (f_j)` and :math:`O_m = \sum_{j=1}^m (o_j), m = 1,…,J`. + + +To clarify, :math:`F_1 = f_1` is the first component of :math:`F_m`, :math:`F_2 = f_1+f_2`, etc., and :math:`F_J = 1`. Similarly, if :math:`o_j = 1` and :math:`i < j`, then :math:`O_i = 0` and when :math:`i≥j`, :math:`O_i = 1`, and of course, :math:`O_J = 1`. Finally, the RPS is defined to be: + +.. math:: \text{RPS} = \sum_{m=1}^J (F_m - O_m)^2 = \sum_{m=1}^J BS_m, + +where :math:`BS_m` is the Brier score for the m-th category (:ref:`Tödter and Ahrens, 2012`). Subsequently, the RPS lends itself to a decomposition into reliability, resolution and uncertainty components, noting that each component is aggregated over the different categories; these are written to the columns named "RPS_REL", "RPS_RES" and "RPS_UNC" in RPS output :numref:`table_ES_header_info_es_out_ECNT`. + CRPS ~~~~ @@ -1078,23 +1141,23 @@ The results of the distance map verification approaches that are included in the Baddeley's :math:`\Delta` Metric and Hausdorff Distance ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Called “BADDELEY” and “HAUSDORFF” in the DMAP +Called "BADDELEY" and "HAUSDORFF" in the DMAP output :numref:`table_GS_format_info_DMAP` The Baddeley's :math:`\Delta` Metric is given by .. math:: \Delta_{p,w} (A,B) = [ \frac{1}{N} \sum_{s \in D} | w(d(s,A)) - w(d(s,B))|]^{\frac{1}{P}} -where :math:`d(s,\cdot)` is the distance map for the respective event area, :math:`w(\cdot)` is an optional concave function (i.e., :math:`w( t + u) \leq w(t)+w(u))` that is strictly increasing at zero with :math:`w(t)=0` if and only if :math:`t=0`, *N* is the size of the domain, and *p* is a user chosen parameter for the :math:`L_{p}` norm. The default choice of :math:`p = 2` corresponds to a Euclidean average, :math:`p = 1` is a simple average of the difference in distance maps, and the limiting case of :math:`p= \infty` gives the maximum difference between the two distance maps and is called the Hausdorff distance, denoted as :math:`H(A,B)`, and is the metric that motivated the development of Baddeley’s :math:`\Delta` metric. A typical choice, and the only available with MET, for :math:`w(\cdot) \text{ is } w(t)= \min\{t,c\}`, where *c* is a user-chosen constant with :math:`c = \infty` meaning that :math:`w(\cdot)` is not applied. This choice of :math:`w(\cdot)` provides a cutoff for distances beyond the pre-specified amount given by *c*. +where :math:`d(s,\cdot)` is the distance map for the respective event area, :math:`w(\cdot)` is an optional concave function (i.e., :math:`w( t + u) \leq w(t)+w(u))` that is strictly increasing at zero with :math:`w(t)=0` if and only if :math:`t=0`, *N* is the size of the domain, and *p* is a user chosen parameter for the :math:`L_{p}` norm. The default choice of :math:`p = 2` corresponds to a Euclidean average, :math:`p = 1` is a simple average of the difference in distance maps, and the limiting case of :math:`p= \infty` gives the maximum difference between the two distance maps and is called the Hausdorff distance, denoted as :math:`H(A,B)`, and is the metric that motivated the development of Baddeley's :math:`\Delta` metric. A typical choice, and the only available with MET, for :math:`w(\cdot) \text{ is } w(t)= \min\{t,c\}`, where *c* is a user-chosen constant with :math:`c = \infty` meaning that :math:`w(\cdot)` is not applied. This choice of :math:`w(\cdot)` provides a cutoff for distances beyond the pre-specified amount given by *c*. -In terms of distance maps, Baddeley’s :math:`\Delta` is the :math:`L_{p}` norm of the top left panel in :numref:`grid-stat_fig4` provided :math:`c= \infty`. If :math:`0` for more details. diff --git a/met/docs/Users_Guide/appendixE.rst b/met/docs/Users_Guide/appendixE.rst index 22826ce420..a50afe1703 100644 --- a/met/docs/Users_Guide/appendixE.rst +++ b/met/docs/Users_Guide/appendixE.rst @@ -31,23 +31,23 @@ The usage statement for wwmca_regrid is wwmca_regrid -out filename config filename [ -nh filename ] [ -sh filename ] -Here, the **-out** switch tells wwmca_regrid what to name the output netCDF file. The **-config** switch gives the name of the config file that wwmca_regrid should use—like many of the MET tools, wwmca-regrid uses a configuration file to specify user-changeable parameters. The format of this file will be explained below. +Here, the **-out** switch tells wwmca_regrid what to name the output netCDF file. The **-config** switch gives the name of the config file that wwmca_regrid should use-like many of the MET tools, wwmca-regrid uses a configuration file to specify user-changeable parameters. The format of this file will be explained below. The **-nh** and **-sh** options give names of WWMCA cloud percent files that wwmca_regrid should use as input. Northern hemisphere files are specified with **-nh**, and southern hemisphere files with **-sh**. At least one of these must be given, but in many cases both need not be given. -In any regridding problem, there are two grids involved: the “From” grid, which is the grid the input data are on, and the “To” grid, which is the grid the data are to be moved onto. For wwmca_regrid, the “To” grid is specified in the config file. If this grid is entirely confined to one hemisphere, then only the WWMCA data file for that hemisphere needs to be given. It’s only when the “To” grid straddles the equator that data files for both hemispheres need to be given (though the interpolation width parameter in the config file can change this—see below). Once the “To” grid is specified in the config file, the WWMCA-Regrid tool will know which input data files it needs, and will complain if it’s not given the right ones. +In any regridding problem, there are two grids involved: the "From" grid, which is the grid the input data are on, and the "To" grid, which is the grid the data are to be moved onto. For wwmca_regrid, the "To" grid is specified in the config file. If this grid is entirely confined to one hemisphere, then only the WWMCA data file for that hemisphere needs to be given. It's only when the "To" grid straddles the equator that data files for both hemispheres need to be given (though the interpolation width parameter in the config file can change this-see below). Once the "To" grid is specified in the config file, the WWMCA-Regrid tool will know which input data files it needs, and will complain if it's not given the right ones. -Now let’s talk about the details of the config file. The config file has the same C-like syntax that all the other MET config files use. The first (and most complicated) thing to specify is the “To” grid. This is given by the **to_grid** parameter. If you are using one of the standard NCEP grids, for example grid #218, you can simply write +Now let's talk about the details of the config file. The config file has the same C-like syntax that all the other MET config files use. The first (and most complicated) thing to specify is the "To" grid. This is given by the **to_grid** parameter. If you are using one of the standard NCEP grids, for example grid #218, you can simply write .. code-block:: none To grid = "G218"; -and that will work. Failing that, you must give the parameters that specify the grid and it’s projection. Please refer the description of the grid specification strings in :ref:`appendixB`. +and that will work. Failing that, you must give the parameters that specify the grid and it's projection. Please refer the description of the grid specification strings in :ref:`appendixB`. Thankfully, the rest of the parameters in the config file are easier to specify. -The next two config file parameters have to do with specifying the interpolation scheme used. The **interp_method** parameter specifies which interpolation method is to be used. Four methods are supported: average, maximum, minimum and nearest neighbor. As an example, to specify the “average” method, one would write +The next two config file parameters have to do with specifying the interpolation scheme used. The **interp_method** parameter specifies which interpolation method is to be used. Four methods are supported: average, maximum, minimum and nearest neighbor. As an example, to specify the "average" method, one would write .. code-block:: none @@ -59,17 +59,17 @@ The other interpolation parameter is **interp_width**. This specifies the width interp_width = 5; -The value must be odd and ≥ 1. If a value of 1 is specified, then nearest neighbor interpolation will be used regardless of the value assigned to **interp_method**. +The value must be odd and :math:`\geqq` 1. If a value of 1 is specified, then nearest neighbor interpolation will be used regardless of the value assigned to **interp_method**. -The fact that an interpolation box is used has one subtle implication—the “To” grid is effectively fattened by half the width of the interpolation box. This means that even for a “To” grid that is entirely contained in one hemisphere, if it comes close to the equator, this virtual fattening may be enough to push it over the equator, and the user will then have to provide input WWMCA files for both hemispheres, even though the “To” grid doesn’t cross the equator. The WWMCA-Regrid tool should detect this situation and complain to the user if not given the correct input files. +The fact that an interpolation box is used has one subtle implication-the "To" grid is effectively fattened by half the width of the interpolation box. This means that even for a "To" grid that is entirely contained in one hemisphere, if it comes close to the equator, this virtual fattening may be enough to push it over the equator, and the user will then have to provide input WWMCA files for both hemispheres, even though the "To" grid doesn't cross the equator. The WWMCA-Regrid tool should detect this situation and complain to the user if not given the correct input files. -The next variable, **good_percent**, tells what fraction of the values in the interpolation square needs to be “good” in order for the interpolation scheme to return a “good” result. Example: +The next variable, **good_percent**, tells what fraction of the values in the interpolation square needs to be "good" in order for the interpolation scheme to return a "good" result. Example: .. code-block:: none good percent = 0; -The rest of the config file parameters have to do with how the output netCDF file represents the data. These should be self-explanatory, so I’ll just give an example: +The rest of the config file parameters have to do with how the output netCDF file represents the data. These should be self-explanatory, so I'll just give an example: .. code-block:: none diff --git a/met/docs/Users_Guide/appendixF.rst b/met/docs/Users_Guide/appendixF.rst index aaaa228318..3a4046e9ea 100644 --- a/met/docs/Users_Guide/appendixF.rst +++ b/met/docs/Users_Guide/appendixF.rst @@ -17,9 +17,9 @@ The local Python installation must also support a minimum set of required packag In addition to the **configure** option mentioned above, two variables, **MET_PYTHON_CC** and **MET_PYTHON_LD**, must also be set for the configuration process. These may either be set as environment variables or as command line options to **configure**. These constants are passed as compiler command line options when building MET to enable the compiler to find the requisite Python header files and libraries in the user's local filesystem. Fortunately, Python provides a way to set these variables properly. This frees the user from the necessity of having any expert knowledge of the compiling and linking process. Along with the **Python** executable, there should be another executable called **python3-config**, whose output can be used to set these environment variables as follows: -• On the command line, run “**python3-config --cflags**”. Set the value of **MET_PYTHON_CC** to the output of that command. +• On the command line, run "**python3-config --cflags**". Set the value of **MET_PYTHON_CC** to the output of that command. -• Again on the command line, run “**python3-config --ldflags**”. Set the value of **MET_PYTHON_LD** to the output of that command. +• Again on the command line, run "**python3-config --ldflags**". Set the value of **MET_PYTHON_LD** to the output of that command. Make sure that these are set as environment variables or that you have included them on the command line prior to running **configure**. @@ -239,7 +239,7 @@ Python Embedding for Point Observations _______________________________________ -The ASCII2NC tool supports the “-format python” option. With this option, point observations may be passed as input. An example of this is provided in :numref:`ascii2nc-pyembed`. That example uses the **read_ascii_point.py** sample script which is included with the MET code. It reads ASCII data in MET's 11-column point observation format and stores it in a Pandas dataframe to be read by the ASCII2NC tool with Python. +The ASCII2NC tool supports the "-format python" option. With this option, point observations may be passed as input. An example of this is provided in :numref:`ascii2nc-pyembed`. That example uses the **read_ascii_point.py** sample script which is included with the MET code. It reads ASCII data in MET's 11-column point observation format and stores it in a Pandas dataframe to be read by the ASCII2NC tool with Python. The **read_ascii_point.py** sample script can be found in: @@ -250,7 +250,7 @@ The **read_ascii_point.py** sample script can be found in: Python Embedding for MPR data _____________________________ -The Stat-Analysis tool supports the “-lookin python” option. With this option, matched pair (MPR) data may be passed as input. An example of this is provided in :numref:`StA-pyembed`. That example uses the **read_ascii_mpr.py** sample script which is included with the MET code. It reads MPR data and stores it in a Pandas dataframe to be read by the Stat-Analysis tool with Python. +The Stat-Analysis tool supports the "-lookin python" option. With this option, matched pair (MPR) data may be passed as input. An example of this is provided in :numref:`StA-pyembed`. That example uses the **read_ascii_mpr.py** sample script which is included with the MET code. It reads MPR data and stores it in a Pandas dataframe to be read by the Stat-Analysis tool with Python. The **read_ascii_mpr.py** sample script can be found in: diff --git a/met/docs/Users_Guide/appendixG.rst b/met/docs/Users_Guide/appendixG.rst index 12316fe477..8c46641ced 100644 --- a/met/docs/Users_Guide/appendixG.rst +++ b/met/docs/Users_Guide/appendixG.rst @@ -73,26 +73,42 @@ _________________________ FBAR and OBAR are the average values of the forecast and observed wind speed. -.. math:: \text{FBAR} = \frac{1}{N} \sum_i s_{fi} +.. math:: + + \text{FBAR} = \frac{1}{N} \sum_i s_{fi} - \text{OBAR} = {1 \over N} \sum_i s_{oi} + \text{OBAR} = {1 \over N} \sum_i s_{oi} _________________________ FS_RMS and OS_RMS are the root-mean-square values of the forecast and observed wind speeds. -.. math:: \text{FS_RMS} = [ \frac{1}{N} \sum_i s_{fi}^2]^{1/2} +.. only:: latex + + .. math:: + + \text{FS\_RMS} = [ \frac{1}{N} \sum_i s_{fi}^2]^{1/2} + + \text{OS\_RMS} = [\frac{1}{N} \sum_i s_{oi}^2]^{1/2} + +.. only:: html + + .. math:: + + \text{FS_RMS} = [ \frac{1}{N} \sum_i s_{fi}^2]^{1/2} - \text{OS_RMS} = [\frac{1}{N} \sum_i s_{oi}^2]^{1/2} + \text{OS_RMS} = [\frac{1}{N} \sum_i s_{oi}^2]^{1/2} ___________________________ MSVE and RMSVE are, respectively, the mean squared, and root mean squared, lengths of the vector difference between the forecast and observed wind vectors. -.. math:: \text{MSVE} = \frac{1}{N} \sum_i | \mathbf{F}_i - \mathbf{O}_i|^2 +.. math:: - \text{RMSVE} = \sqrt{MSVE} + \text{MSVE} = \frac{1}{N} \sum_i | \mathbf{F}_i - \mathbf{O}_i|^2 + + \text{RMSVE} = \sqrt{MSVE} ____________________________ @@ -116,48 +132,104 @@ ________________________ FBAR_SPEED and OBAR_SPEED are the lengths of the average forecast and observed wind vectors. Note that this is *not* the same as the average forecast and observed wind speeds (*ie.,* the length of an average vector :math:`\neq` the average length of the vector). -.. math:: \text{FBAR_SPEED } = | \mathbf{F}_a | - - \text{OBAR_SPEED } = | \mathbf{O}_a | +.. only:: latex + + .. math:: + + \text{FBAR\_SPEED } = | \mathbf{F}_a | + + \text{OBAR\_SPEED } = | \mathbf{O}_a | + +.. only:: html + + .. math:: + + \text{FBAR_SPEED } = | \mathbf{F}_a | + + \text{OBAR_SPEED } = | \mathbf{O}_a | + ________________________ VDIFF_SPEED is the length (*ie. speed*) of the vector difference between the average forecast and average observed wind vectors. -.. math:: \text{VDIFF_SPEED } = | \mathbf{F}_a - \mathbf{O}_a | +.. only:: latex + + .. math:: \text{VDIFF\_SPEED } = | \mathbf{F}_a - \mathbf{O}_a | + +.. only:: html + + .. math:: \text{VDIFF_SPEED } = | \mathbf{F}_a - \mathbf{O}_a | + +.. only:: latex + + Note that this is *not* the same as the difference in lengths (speeds) of the average forecast and observed wind vectors. That quantity is called SPEED_ERR (see below). There is a relationship between these two statistics however: using some of the results obtained in the introduction to this appendix, we can say that :math:`| | \mathbf{F}_a | - | \mathbf{O}_a | | \leq | \mathbf{F}_a - \mathbf{O}_a |` or, equivalently, that :math:`\vert \text{SPEED\_ERR } \vert \leq \text{VDIFF\_SPEED. }` + +.. only:: html -Note that this is *not* the same as the difference in lengths (speeds) of the average forecast and observed wind vectors. That quantity is called SPEED_ERR (see below). There is a relationship between these two statistics however: using some of the results obtained in the introduction to this appendix, we can say that :math:`| | \mathbf{F}_a | - | \mathbf{O}_a | | \leq | \mathbf{F}_a - \mathbf{O}_a |` or , equivalently, that :math:`| \text{SPEED_ERR} | \leq \text{VDIFF_SPEED}`. + Note that this is *not* the same as the difference in lengths (speeds) of the average forecast and observed wind vectors. That quantity is called SPEED_ERR (see below). There is a relationship between these two statistics however: using some of the results obtained in the introduction to this appendix, we can say that :math:`| | \mathbf{F}_a | - | \mathbf{O}_a | | \leq | \mathbf{F}_a - \mathbf{O}_a |` or, equivalently, that :math:`\vert \text{SPEED_ERR } \vert \leq \text{VDIFF_SPEED. }` _________________________ VDIFF_DIR is the direction of the vector difference of the average forecast and average observed wind vectors. Note that this is {\it not} the same as the difference in direction of the average forecast and average observed wind vectors. This latter quantity would be FDIR :math:`-` ODIR. -.. math:: \text{VDIFF_DIR } = \text{ direction of } (\mathbf{F}_a - \mathbf{O}_a) +.. only:: latex + + .. math:: \text{VDIFF\_DIR } = \text{ direction of } (\mathbf{F}_a - \mathbf{O}_a) + +.. only:: html + + .. math:: \text{VDIFF_DIR } = \text{ direction of } (\mathbf{F}_a - \mathbf{O}_a) _________________________ SPEED_ERR is the difference in the lengths (speeds) of the average forecast and average observed wind vectors. (See the discussion of VDIFF_SPEED above.) -.. math:: \text{SPEED_ERR } = | \mathbf{F}_a | - | \mathbf{O}_a | = \text{ FBAR_SPEED } - \text{ OBAR_SPEED} +.. only:: latex + + .. math:: \text{SPEED\_ERR } = | \mathbf{F}_a | - | \mathbf{O}_a | = \text{ FBAR\_SPEED } - \text{ OBAR\_SPEED } + +.. only:: html + + .. math:: \text{SPEED_ERR } = | \mathbf{F}_a | - | \mathbf{O}_a | = \text{ FBAR_SPEED } - \text{ OBAR_SPEED } + ___________________________ SPEED_ABSERR is the absolute value of SPEED_ERR. Note that we have SPEED_ABSERR :math:`\leq` VDIFF_SPEED (see the discussion of VDIFF_SPEED above). -.. math:: \text{SPEED_ABSERR } = | \text{SPEED_ERR} | +.. only:: latex + + .. math:: \text{SPEED\_ABSERR } = \vert \text{SPEED\_ERR } \vert + +.. only:: html + + .. math:: \text{SPEED_ABSERR } = \vert \text{SPEED_ERR } \vert __________________________ DIR_ERR is the signed angle between the directions of the average forecast and average observed wind vectors. Positive if the forecast vector is counterclockwise from the observed vector. -.. math:: \text{DIR_ERR } = \text{ direction between } N(\mathbf{F}_a) \text{ and } N(\mathbf{O}_a) +.. only:: latex + + .. math:: \text{DIR\_ERR } = \text{ direction between } N(\mathbf{F}_a) \text{ and } N(\mathbf{O}_a) + +.. only:: html + + .. math:: \text{DIR_ERR } = \text{ direction between } N(\mathbf{F}_a) \text{ and } N(\mathbf{O}_a) __________________________ DIR_ABSERR is the absolute value of DIR_ERR. In other words, it's an unsigned angle rather than a signed angle. -.. math:: \text{DIR_ABSERR } = | \text{DIR_ERR}| +.. only:: latex + + .. math:: \text{DIR\_ABSERR } = \vert \text{DIR\_ERR } \vert + +.. only:: html + + .. math:: \text{DIR_ABSERR } = \vert \text{DIR_ERR } \vert diff --git a/met/docs/Users_Guide/data_io.rst b/met/docs/Users_Guide/data_io.rst index 3dd4552ab9..8b6d41ea95 100644 --- a/met/docs/Users_Guide/data_io.rst +++ b/met/docs/Users_Guide/data_io.rst @@ -92,7 +92,7 @@ The following is a summary of the input and output formats for each of the tools #. **Pcp-Combine Tool** - * **Input**: Two or more gridded model or observation files (in GRIB format for “sum” command, or any gridded file for “add”, “subtract”, and “derive” commands) containing data (often accumulated precipitation) to be combined. + * **Input**: Two or more gridded model or observation files (in GRIB format for "sum" command, or any gridded file for "add", "subtract", and "derive" commands) containing data (often accumulated precipitation) to be combined. * **Output**: One NetCDF file containing output for the requested operation(s). @@ -142,7 +142,7 @@ The following is a summary of the input and output formats for each of the tools * **Input**: One gridded model file, one gridded observation file, and one configuration file. - * **Output**: One STAT file containing the “ISC” line type, one ASCII file containing intensity-scale information and statistics, one NetCDF file containing information about the wavelet decomposition of forecast and observed fields and their differences, and one PostScript file containing plots and summaries of the intensity-scale verification. + * **Output**: One STAT file containing the "ISC" line type, one ASCII file containing intensity-scale information and statistics, one NetCDF file containing information about the wavelet decomposition of forecast and observed fields and their differences, and one PostScript file containing plots and summaries of the intensity-scale verification. #. **GSID2MPR Tool** @@ -160,7 +160,7 @@ The following is a summary of the input and output formats for each of the tools * **Input**: One or more STAT files output from the Point-Stat, Grid-Stat, Ensemble Stat, Wavelet-Stat, or TC-Gen tools and, optionally, one configuration file containing specifications for the analysis job(s) to be run on the STAT data. - * **Output**: ASCII output of the analysis jobs is printed to the screen unless redirected to a file using the “-out” option or redirected to a STAT output file using the “-out_stat” option. + * **Output**: ASCII output of the analysis jobs is printed to the screen unless redirected to a file using the "-out" option or redirected to a STAT output file using the "-out_stat" option. #. **Series-Analysis Tool** @@ -184,7 +184,7 @@ The following is a summary of the input and output formats for each of the tools * **Input**: One or more MODE object statistics files from the MODE tool and, optionally, one configuration file containing specification for the analysis job(s) to be run on the object data. - * **Output**: ASCII output of the analysis jobs will be printed to the screen unless redirected to a file using the “-out” option. + * **Output**: ASCII output of the analysis jobs will be printed to the screen unless redirected to a file using the "-out" option. #. **MODE-TD Tool** @@ -208,7 +208,7 @@ The following is a summary of the input and output formats for each of the tools * **Input**: One or more TCSTAT output files output from the TC-Pairs tool and, optionally, one configuration file containing specifications for the analysis job(s) to be run on the TCSTAT data. - * **Output**: ASCII output of the analysis jobs will be printed to the screen unless redirected to a file using the “-out” option. + * **Output**: ASCII output of the analysis jobs will be printed to the screen unless redirected to a file using the "-out" option. #. **TC-Gen Tool** diff --git a/met/docs/Users_Guide/ensemble-stat.rst b/met/docs/Users_Guide/ensemble-stat.rst index cfe920c0e6..d4763fe32f 100644 --- a/met/docs/Users_Guide/ensemble-stat.rst +++ b/met/docs/Users_Guide/ensemble-stat.rst @@ -106,9 +106,9 @@ Optional arguments for ensemble_stat 10. The **-log** file outputs log messages to the specified file. -11. The **-v level** option indicates the desired level of verbosity. The value of “level” will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity will increase the amount of logging. +11. The **-v level** option indicates the desired level of verbosity. The value of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity will increase the amount of logging. -12. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of “level” will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. +12. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of "level" will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. An example of the ensemble_stat calling sequence is shown below: diff --git a/met/docs/Users_Guide/figure/plotting-Gilbert-skill-score.png b/met/docs/Users_Guide/figure/plotting-Gilbert-skill-score.png new file mode 100644 index 0000000000..0b8b71056a Binary files /dev/null and b/met/docs/Users_Guide/figure/plotting-Gilbert-skill-score.png differ diff --git a/met/docs/Users_Guide/figure/plotting-verification.png b/met/docs/Users_Guide/figure/plotting-verification.png new file mode 100644 index 0000000000..d207a261ff Binary files /dev/null and b/met/docs/Users_Guide/figure/plotting-verification.png differ diff --git a/met/docs/Users_Guide/figure/plotting_Gilbert_skill_score.gif b/met/docs/Users_Guide/figure/plotting_Gilbert_skill_score.gif deleted file mode 100644 index 7840e1e6ea..0000000000 Binary files a/met/docs/Users_Guide/figure/plotting_Gilbert_skill_score.gif and /dev/null differ diff --git a/met/docs/Users_Guide/figure/plotting_verification.gif b/met/docs/Users_Guide/figure/plotting_verification.gif deleted file mode 100644 index 6308c708ed..0000000000 Binary files a/met/docs/Users_Guide/figure/plotting_verification.gif and /dev/null differ diff --git a/met/docs/Users_Guide/grid-diag.rst b/met/docs/Users_Guide/grid-diag.rst index fb6c14f58c..22200ad0e2 100644 --- a/met/docs/Users_Guide/grid-diag.rst +++ b/met/docs/Users_Guide/grid-diag.rst @@ -48,9 +48,9 @@ Optional arguments for grid_diag 4. The **-log file** option directs output and errors to the specified log file. All messages will be written to that file as well as standard out and error. Thus, users can save the messages without having to redirect the output on the command line. The default behavior is no log file. -5. The **-v level** option indicates the desired level of verbosity. The contents of “level” will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. +5. The **-v level** option indicates the desired level of verbosity. The contents of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. -6. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of “level” will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. +6. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of "level" will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. grid_diag configuration file ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/met/docs/Users_Guide/grid-stat.rst b/met/docs/Users_Guide/grid-stat.rst index 123954bc47..f626f77ef8 100644 --- a/met/docs/Users_Guide/grid-stat.rst +++ b/met/docs/Users_Guide/grid-stat.rst @@ -31,7 +31,7 @@ Measures for continuous variables For continuous variables, many verification measures are based on the forecast error (i.e., f - o). However, it also is of interest to investigate characteristics of the forecasts, and the observations, as well as their relationship. These concepts are consistent with the general framework for verification outlined by :ref:`Murphy and Winkler (1987) `. The statistics produced by MET for continuous forecasts represent this philosophy of verification, which focuses on a variety of aspects of performance rather than a single measure. See :numref:`Appendix C, Section %s ` for specific information. -A user may wish to eliminate certain values of the forecasts from the calculation of statistics, a process referred to here as “conditional verification”. For example, a user may eliminate all temperatures above freezing and then calculate the error statistics only for those forecasts of below freezing temperatures. Another common example involves verification of wind forecasts. Since wind direction is indeterminate at very low wind speeds, the user may wish to set a minimum wind speed threshold prior to calculating error statistics for wind direction. The user may specify these thresholds in the configuration file to specify the conditional verification. Thresholds can be specified using the usual Fortran conventions (<, <=, ==, !-, >=, or >) followed by a numeric value. The threshold type may also be specified using two letter abbreviations (lt, le, eq, ne, ge, gt). Further, more complex thresholds can be achieved by defining multiple thresholds and using && or || to string together event definition logic. The forecast and observation threshold can be used together according to user preference by specifying one of: UNION, INTERSECTION, or SYMDIFF (symmetric difference). +A user may wish to eliminate certain values of the forecasts from the calculation of statistics, a process referred to here as "conditional verification". For example, a user may eliminate all temperatures above freezing and then calculate the error statistics only for those forecasts of below freezing temperatures. Another common example involves verification of wind forecasts. Since wind direction is indeterminate at very low wind speeds, the user may wish to set a minimum wind speed threshold prior to calculating error statistics for wind direction. The user may specify these thresholds in the configuration file to specify the conditional verification. Thresholds can be specified using the usual Fortran conventions (<, <=, ==, !-, >=, or >) followed by a numeric value. The threshold type may also be specified using two letter abbreviations (lt, le, eq, ne, ge, gt). Further, more complex thresholds can be achieved by defining multiple thresholds and using && or || to string together event definition logic. The forecast and observation threshold can be used together according to user preference by specifying one of: UNION, INTERSECTION, or SYMDIFF (symmetric difference). Measures for probabilistic forecasts and dichotomous outcomes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -65,7 +65,7 @@ When computing continuous statistics on a regular large scale or global latitude Neighborhood methods ~~~~~~~~~~~~~~~~~~~~ -MET also incorporates several neighborhood methods to give credit to forecasts that are close to the observations, but not necessarily exactly matched up in space. Also referred to as “fuzzy” verification methods, these methods do not just compare a single forecast at each grid point to a single observation at each grid point; they compare the forecasts and observations in a neighborhood surrounding the point of interest. With the neighborhood method, the user chooses a distance within which the forecast event can fall from the observed event and still be considered a hit. In MET this is implemented by defining a square search window around each grid point. Within the search window, the number of observed events is compared to the number of forecast events. In this way, credit is given to forecasts that are close to the observations without requiring a strict match between forecasted events and observed events at any particular grid point. The neighborhood methods allow the user to see how forecast skill varies with neighborhood size and can help determine the smallest neighborhood size that can be used to give sufficiently accurate forecasts. +MET also incorporates several neighborhood methods to give credit to forecasts that are close to the observations, but not necessarily exactly matched up in space. Also referred to as "fuzzy" verification methods, these methods do not just compare a single forecast at each grid point to a single observation at each grid point; they compare the forecasts and observations in a neighborhood surrounding the point of interest. With the neighborhood method, the user chooses a distance within which the forecast event can fall from the observed event and still be considered a hit. In MET this is implemented by defining a square search window around each grid point. Within the search window, the number of observed events is compared to the number of forecast events. In this way, credit is given to forecasts that are close to the observations without requiring a strict match between forecasted events and observed events at any particular grid point. The neighborhood methods allow the user to see how forecast skill varies with neighborhood size and can help determine the smallest neighborhood size that can be used to give sufficiently accurate forecasts. There are several ways to present the results of the neighborhood approaches, such as the Fractions Skill Score (FSS) or the Fractions Brier Score (FBS). These scores are presented in :numref:`Appendix C, Section %s `. One can also simply up-scale the information on the forecast verification grid by smoothing or resampling within a specified neighborhood around each grid point and recalculate the traditional verification metrics on the coarser grid. The MET output includes traditional contingency table statistics for each threshold and neighborhood window size. @@ -90,7 +90,7 @@ Differences are computed in both of the horizontal grid directions and is not a Distance Maps ~~~~~~~~~~~~~ -The following methods can all be computed efficiently by utilizing fast algorithms developed for calculating distance maps. A distance map results from calculating the shortest distance from every grid point, :math:`s=(x,y)`, in the domain, :math:`D`, to the nearest one-valued grid point. In each of the following, it is understood that they are calculated between event areas :math:`A`, from one field and observation event areas :math:`B` from another. If the measure is applied to a feature within a field, then the distance map is still calculated over the entire original domain. Some of the distance map statistics are computed over the entire distance map, while others use only parts of it. +The following methods can all be computed efficiently by utilizing fast algorithms developed for calculating distance maps. A distance map results from calculating the shortest distance from every grid point, **s=(x,y)**, in the domain, **D**, to the nearest one-valued grid point. In each of the following, it is understood that they are calculated between event areas **A**, from one field and observation event areas **B** from another. If the measure is applied to a feature within a field, then the distance map is still calculated over the entire original domain. Some of the distance map statistics are computed over the entire distance map, while others use only parts of it. Because these methods rely on the distance map, it is helpful to understand precisely what such maps do. :numref:`grid-stat_fig1` demonstrates the path of the shortest distance to the nearest event point in the event area A marked by the gray rectangle in the diagram. Note that the arrows all point to a grid point on the boundary of the event area A as it would be a longer distance to any point in its interior. :numref:`grid-stat_fig2` demonstrates the shortest distances from every grid point inside a second event area marked by the gray circle labeled B to the same event area A as in :numref:`grid-stat_fig1`. Note that all of the distances are to points on a small subsection (indicated by the yellow stretch) of the subset A. @@ -163,9 +163,9 @@ Optional arguments for grid_stat 5. The **-log file** option directs output and errors to the specified log file. All messages will be written to that file as well as standard out and error. Thus, users can save the messages without having to redirect the output on the command line. The default behavior is no log file. -6. The **-v level** option indicates the desired level of verbosity. The contents of “level” will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. +6. The **-v level** option indicates the desired level of verbosity. The contents of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. -7. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of “level” will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. +7. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of "level" will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. An example of the grid_stat calling sequence is listed below: @@ -251,7 +251,7 @@ The **field** entry is set to **BOTH, FCST, OBS**, or **NONE** to indicate the f The **vld_thresh** entry contains a number between 0 and 1. When performing neighborhood verification over some neighborhood of points the ratio of the number of valid data points to the total number of points in the neighborhood is computed. If that ratio is greater than this threshold, that value is included in the neighborhood verification. Setting this threshold to 1, which is the default, requires that the entire neighborhood must contain valid data. This variable will typically come into play only along the boundaries of the verification region chosen. -The **cov_thresh** entry contains a comma separated list of thresholds to be applied to the neighborhood coverage field. The coverage is the proportion of forecast points in the neighborhood that exceed the forecast threshold. For example, if 10 of the 25 forecast grid points contain values larger than a threshold of 2, then the coverage is 10/25 = 0.4. If the coverage threshold is set to 0.5, then this neighborhood is considered to be a “No” forecast. +The **cov_thresh** entry contains a comma separated list of thresholds to be applied to the neighborhood coverage field. The coverage is the proportion of forecast points in the neighborhood that exceed the forecast threshold. For example, if 10 of the 25 forecast grid points contain values larger than a threshold of 2, then the coverage is 10/25 = 0.4. If the coverage threshold is set to 0.5, then this neighborhood is considered to be a "No" forecast. ___________________ @@ -291,7 +291,7 @@ ____________________ zhu_weight = 0.5; } -The **distance_map** entry is a dictionary containing options related to the distance map statistics in the **DMAP** output line type. The **baddeley_p** entry is an integer specifying the exponent used in the Lp-norm when computing the Baddeley :math:`\Delta` metric. The **baddeley_max_dist** entry is a floating point number specifying the maximum allowable distance for each distance map. Any distances larger than this number will be reset to this constant. A value of **NA** indicates that no maximum distance value should be used. The **fom_alpha** entry is a floating point number specifying the scaling constant to be used when computing Pratt's Figure of Merit. The **zhu_weight** specifies a value between 0 and 1 to define the importance of the RMSE of the binary fields (i.e. amount of overlap) versus the mean-error distance (MED). The default value of 0.5 gives equal weighting. This configuration option may be set separately in each **obs.field** entry. +The **distance_map** entry is a dictionary containing options related to the distance map statistics in the **DMAP** output line type. The **baddeley_p** entry is an integer specifying the exponent used in the Lp-norm when computing the Baddeley Delta metric. The **baddeley_max_dist** entry is a floating point number specifying the maximum allowable distance for each distance map. Any distances larger than this number will be reset to this constant. A value of **NA** indicates that no maximum distance value should be used. The **fom_alpha** entry is a floating point number specifying the scaling constant to be used when computing Pratt's Figure of Merit. The **zhu_weight** specifies a value between 0 and 1 to define the importance of the RMSE of the binary fields (i.e. amount of overlap) versus the mean-error distance (MED). The default value of 0.5 gives equal weighting. This configuration option may be set separately in each **obs.field** entry. _____________________ @@ -755,7 +755,7 @@ The format of the STAT and ASCII output of the Grid-Stat tool are the same as th - Frequency Bias * - 29 - BADDELEY - - Baddeley's :math:`\Delta` Metric + - Baddeley's Delta Metric * - 30 - HAUSDORFF - Hausdorff Distance diff --git a/met/docs/Users_Guide/index.rst b/met/docs/Users_Guide/index.rst index 6f62391dc6..213fcae61d 100644 --- a/met/docs/Users_Guide/index.rst +++ b/met/docs/Users_Guide/index.rst @@ -79,11 +79,12 @@ The National Center for Atmospheric Research (NCAR) is sponsored by NSF. The DTC appendixF appendixG +.. only:: html -Indices and tables -================== + Indices and tables + ================== -* :ref:`genindex` -* :ref:`search` + * :ref:`genindex` + * :ref:`search` diff --git a/met/docs/Users_Guide/masking.rst b/met/docs/Users_Guide/masking.rst index 08ef85727c..db695f97f1 100644 --- a/met/docs/Users_Guide/masking.rst +++ b/met/docs/Users_Guide/masking.rst @@ -3,7 +3,7 @@ Regional Verification using Spatial Masking =========================================== -Verification over a particular region or area of interest may be performed using “masking”. Defining a masking region is simply selecting the desired set of grid points to be used. The Gen-Vx-Mask tool automates this process and replaces the Gen-Poly-Mask and Gen-Circle-Mask tools from previous releases. It may be run to create a bitmap verification masking region to be used by many of the statistical tools. This tool enables the user to generate a masking region once for a domain and apply it to many cases. It has been enhanced to support additional types of masking region definition (e.g. tropical-cyclone track over water only). An iterative approach may be used to define complex areas by combining multiple masking regions together. +Verification over a particular region or area of interest may be performed using "masking". Defining a masking region is simply selecting the desired set of grid points to be used. The Gen-Vx-Mask tool automates this process and replaces the Gen-Poly-Mask and Gen-Circle-Mask tools from previous releases. It may be run to create a bitmap verification masking region to be used by many of the statistical tools. This tool enables the user to generate a masking region once for a domain and apply it to many cases. It has been enhanced to support additional types of masking region definition (e.g. tropical-cyclone track over water only). An iterative approach may be used to define complex areas by combining multiple masking regions together. Gen-Vx-Mask tool ________________ @@ -45,15 +45,15 @@ Required arguments for gen_vx_mask 2. The **mask_file** argument defines the masking information, see below. -• For “poly”, “box”, “circle”, and “track” masking, specify an ASCII Lat/Lon file. +• For "poly", "box", "circle", and "track" masking, specify an ASCII Lat/Lon file. -• For “grid” and “data” masking, specify a gridded data file. +• For "grid" and "data" masking, specify a gridded data file. -• For “solar_alt” and “solar_azi” masking, specify a gridded data file or a time string in YYYYMMDD[_HH[MMSS]] format. +• For "solar_alt" and "solar_azi" masking, specify a gridded data file or a time string in YYYYMMDD[_HH[MMSS]] format. -• For “lat” and “lon” masking, no “mask_file” needed, simply repeat the path for “input_file”. +• For "lat" and "lon" masking, no "mask_file" needed, simply repeat the path for "input_file". -• For “shape” masking, specify an ESRI shapefile (.shp). +• For "shape" masking, specify an ESRI shapefile (.shp). 3. The **out_file** argument is the output NetCDF mask file to be written. @@ -62,25 +62,25 @@ Required arguments for gen_vx_mask Optional arguments for gen_vx_mask ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -5. The **-input_field string** option can be used to read existing mask data from “input_file”. +5. The **-input_field string** option can be used to read existing mask data from "input_file". -6. The **-mask_field string** option can be used to define the field from “mask_file” to be used for “data” masking. +6. The **-mask_field string** option can be used to define the field from "mask_file" to be used for "data" masking. -7. The **-complement** option can be used to compute the complement of the area defined by “mask_file”. +7. The **-complement** option can be used to compute the complement of the area defined by "mask_file". -8. The **-union | -intersection | -symdiff** option can be used to specify how to combine the masks from “input_file” and “mask_file”. +8. The **-union | -intersection | -symdiff** option can be used to specify how to combine the masks from "input_file" and "mask_file". 9. The **-thresh string** option can be used to define the threshold to be applied. -• For “circle” and “track” masking, threshold the distance (km). +• For "circle" and "track" masking, threshold the distance (km). -• For “data” masking, threshold the values of “mask_field”. +• For "data" masking, threshold the values of "mask_field". -• For “solar_alt” and “solar_azi” masking, threshold the computed solar values. +• For "solar_alt" and "solar_azi" masking, threshold the computed solar values. -• For “lat” and “lon” masking, threshold the latitude and longitude values. +• For "lat" and "lon" masking, threshold the latitude and longitude values. -10. The **-height n** and **-width n** options set the size in grid units for “box”masking. +10. The **-height n** and **-width n** options set the size in grid units for "box"masking. 11. The **-shapeno n** option is only used for shapefile masking. (See description of shapefile masking below). @@ -92,7 +92,7 @@ Optional arguments for gen_vx_mask 15. The **-v level** option indicates the desired level of verbosity. The value of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity will increase the amount of logging. -16. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of “level” will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. +16. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of "level" will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. The Gen-Vx-Mask tool supports the following types of masking region definition selected using the **-type** command line option: @@ -112,7 +112,7 @@ The Gen-Vx-Mask tool supports the following types of masking region definition s 8. Latitude (**lat**) and longitude (**lon**) masking computes the latitude and longitude value at each grid point. This logic only requires the definition of the grid, specified by the **input_file**. Technically, the **mask_file** is not needed, but a value must be specified for the command line to parse correctly. Users are advised to simply repeat the **input_file** setting twice. If the **-thresh** command line option is not used, the raw latitude or longitude values for each grid point will be written to the output. This option is useful when defining latitude or longitude bands over which to compute statistics. -9. Shapefile (**shape**) masking uses a closed polygon taken from an ESRI shapefile to define the masking region. Gen-Vx-Mask reads the shapefile with the ".shp" suffix and extracts the latitude and longitudes of the vertices. The other types of shapefiles (index file, suffix “.shx”, and dBASE file, suffix “.dbf”) are not currently used. The shapefile must consist of closed polygons rather than polylines, points, or any of the other data types that shapefiles support. Shapefiles usually contain more than one polygon, and the **-shape n** command line option enables the user to select one polygon from the shapefile. The integer **n** tells which shape number to use from the shapefile. Note that this value is zero-based, so that the first polygon in the shapefile is polygon number 0, the second polygon in the shapefile is polygon number 1, etc. For the user's convenience, some utilities that perform human-readable screen dumps of shapefile contents are provided. The gis_dump_shp, gis_dump_shx and gis_dump_dbf tools enable the user to examine the contents of her shapefiles. As an example, if the user knows the name of the particular polygon but not the number of the polygon in the shapefile, the user can use the gis_dump_dbf utility to examine the names of the polygons in the shapefile. The information written to the screen will display the corresponding polygon number. +9. Shapefile (**shape**) masking uses a closed polygon taken from an ESRI shapefile to define the masking region. Gen-Vx-Mask reads the shapefile with the ".shp" suffix and extracts the latitude and longitudes of the vertices. The other types of shapefiles (index file, suffix ".shx", and dBASE file, suffix ".dbf") are not currently used. The shapefile must consist of closed polygons rather than polylines, points, or any of the other data types that shapefiles support. Shapefiles usually contain more than one polygon, and the **-shape n** command line option enables the user to select one polygon from the shapefile. The integer **n** tells which shape number to use from the shapefile. Note that this value is zero-based, so that the first polygon in the shapefile is polygon number 0, the second polygon in the shapefile is polygon number 1, etc. For the user's convenience, some utilities that perform human-readable screen dumps of shapefile contents are provided. The gis_dump_shp, gis_dump_shx and gis_dump_dbf tools enable the user to examine the contents of her shapefiles. As an example, if the user knows the name of the particular polygon but not the number of the polygon in the shapefile, the user can use the gis_dump_dbf utility to examine the names of the polygons in the shapefile. The information written to the screen will display the corresponding polygon number. The polyline, box, circle, and track masking methods all read an ASCII file containing Lat/Lon locations. Those files must contain a string, which defines the name of the masking region, followed by a series of whitespace-separated latitude (degrees north) and longitude (degree east) values. @@ -150,7 +150,7 @@ This three step process enables the Gen-Vx-Mask tool to be run iteratively on it • Rerun the Gen-Vx-Mask tool passing in the output of the first call and applying polyline masking to define the geographic area of interest. - – Use the **-intersection** option to only select grid points whose value is non-zero in both the input field and the current mask. + - Use the **-intersection** option to only select grid points whose value is non-zero in both the input field and the current mask. An example of the gen_vx_mask calling sequence is shown below: @@ -164,4 +164,4 @@ In this example, the Gen-Vx-Mask tool will read the ASCII Lat/Lon file named **C Feature-Relative Methods ________________________ -This section contains a description of several methods that may be used to perform feature-relative (or event -based) evaluation. The methodology pertains to examining the environment surrounding a particular feature or event such as a tropical, extra-tropical cyclone, convective cell, snow-band, etc. Several approaches are available for these types of investigations including applying masking described above (e.g. circle or box) or using the “FORCE” interpolation method in the regrid configuration option (see :numref:`config_options`). These methods generally require additional scripting, including potentially storm-track identification, outside of MET to be paired with the features of the MET tools. METplus may be used to execute this type of analysis. Please refer to the `METplus User's Guide `__. +This section contains a description of several methods that may be used to perform feature-relative (or event -based) evaluation. The methodology pertains to examining the environment surrounding a particular feature or event such as a tropical, extra-tropical cyclone, convective cell, snow-band, etc. Several approaches are available for these types of investigations including applying masking described above (e.g. circle or box) or using the "FORCE" interpolation method in the regrid configuration option (see :numref:`config_options`). These methods generally require additional scripting, including potentially storm-track identification, outside of MET to be paired with the features of the MET tools. METplus may be used to execute this type of analysis. Please refer to the `METplus User's Guide `__. diff --git a/met/docs/Users_Guide/mode-analysis.rst b/met/docs/Users_Guide/mode-analysis.rst index 53852534e3..c641f8b8e6 100644 --- a/met/docs/Users_Guide/mode-analysis.rst +++ b/met/docs/Users_Guide/mode-analysis.rst @@ -13,9 +13,9 @@ Users may wish to summarize multiple ASCII files produced by MODE across many ca Scientific and statistical aspects __________________________________ -The MODE-Analysis tool operates in two modes, called “summary” and “bycase”. In summary mode, the user specifies on the command line the MODE output columns of interest as well as filtering criteria that determine which input lines should be used. For example, a user may be interested in forecast object areas, but only if the object was matched, and only if the object centroid is inside a particular region. The summary statistics generated for each specified column of data are the minimum, maximum, mean, standard deviation, and the 10th, 25th, 50th, 75th and 90th percentiles. In addition, the user may specify a “dump'” file: the individual MODE lines used to produce the statistics will be written to this file. This option provides the user with a filtering capability. The dump file will consist only of lines that match the specified criteria. +The MODE-Analysis tool operates in two modes, called "summary" and "bycase". In summary mode, the user specifies on the command line the MODE output columns of interest as well as filtering criteria that determine which input lines should be used. For example, a user may be interested in forecast object areas, but only if the object was matched, and only if the object centroid is inside a particular region. The summary statistics generated for each specified column of data are the minimum, maximum, mean, standard deviation, and the 10th, 25th, 50th, 75th and 90th percentiles. In addition, the user may specify a "dump'" file: the individual MODE lines used to produce the statistics will be written to this file. This option provides the user with a filtering capability. The dump file will consist only of lines that match the specified criteria. -The other option for operating the analysis tool is “bycase”. Given initial and final values for forecast lead time, the tool will output, for each valid time in the interval, the matched area, unmatched area, and the number of forecast and observed objects that were matched or unmatched. For the areas, the user can specify forecast or observed objects, and also simple or cluster objects. A dump file may also be specified in this mode. +The other option for operating the analysis tool is "bycase". Given initial and final values for forecast lead time, the tool will output, for each valid time in the interval, the matched area, unmatched area, and the number of forecast and observed objects that were matched or unmatched. For the areas, the user can specify forecast or observed objects, and also simple or cluster objects. A dump file may also be specified in this mode. Practical information _____________________ @@ -591,7 +591,7 @@ mode_analysis configuration file To use the MODE-Analysis tool, the user must un-comment the options in the configuration file to apply them and comment out unwanted options. The options in the configuration file for the MODE-Analysis tools are the same as the MODE command line options described in :numref:`mode_analysis-usage`. -The parameters that are set in the configuration file either add to or override parameters that are set on the command line. For the “set string” and “set integer type” options enclosed in brackets, the values specified in the configuration file are added to any values set on the command line. For the “toggle” and “min/max type” options, the values specified in the configuration file override those set on the command line. +The parameters that are set in the configuration file either add to or override parameters that are set on the command line. For the "set string" and "set integer type" options enclosed in brackets, the values specified in the configuration file are added to any values set on the command line. For the "toggle" and "min/max type" options, the values specified in the configuration file override those set on the command line. mode_analysis output ~~~~~~~~~~~~~~~~~~~~ diff --git a/met/docs/Users_Guide/mode-td.rst b/met/docs/Users_Guide/mode-td.rst index 75f45b2054..b646410835 100644 --- a/met/docs/Users_Guide/mode-td.rst +++ b/met/docs/Users_Guide/mode-td.rst @@ -42,11 +42,11 @@ Convolution As in MODE, MTD applies a convolution filter to the raw data as a preliminary step in resolving the field into objects. The convolution step in MTD differs in several respects from that performed in MODE, however. -First, MTD typically reads in several planes of data for each data field—one plane for each time step, and there is really no limit to the number of time steps. So MTD is convolving much more data than it would be if it were simply analyzing a 2D data field. Secondly, MTD convolves in time as well as space, which again increases the amount of data needing to be processed. The net effect of all this is to greatly increase the time needed to perform the convolution step. +First, MTD typically reads in several planes of data for each data field-one plane for each time step, and there is really no limit to the number of time steps. So MTD is convolving much more data than it would be if it were simply analyzing a 2D data field. Secondly, MTD convolves in time as well as space, which again increases the amount of data needing to be processed. The net effect of all this is to greatly increase the time needed to perform the convolution step. Because of this, the developers decided to make several changes in the way convolution was performed in MTD. Most of the differences come from the need to make the convolution step as fast as possible. -The most basic change is to use a square convolution filter rather than the circular one that MODE uses. The overall “size” of the filter is still determined by one parameter (denoted :math:`R`, as in MODE), but this should not be thought of as a radius. Instead, the size of the square is :math:`(2 R + 1) \times (2 R + 1)`, as shown in :numref:`mtd-two_r_plus_one`. +The most basic change is to use a square convolution filter rather than the circular one that MODE uses. The overall "size" of the filter is still determined by one parameter (denoted :math:`R`, as in MODE), but this should not be thought of as a radius. Instead, the size of the square is :math:`(2 R + 1) \times (2 R + 1)`, as shown in :numref:`mtd-two_r_plus_one`. .. _mtd-two_r_plus_one: @@ -73,7 +73,7 @@ The vector **velocity** :math:`(v_x, v_y)` is obtained by fitting a line to a 3D The spatial orientation of an object (what traditional MODE calls the **axis angle** of an object) is gotten by fitting a plane to an object. As with the case of velocity, our optimization criterion is that the sum of the squares of the spatial distances from each point of the object to the plane be minimized. -:numref:`mtd-axis_3d` gives some idea of the reason for fitting a plane, rather than a line, as MODE does. On the left in the figure, we see an object (in blue shaped like an “A”) at several time steps moving through the grid. For simplicity, the object is not rotating as it moves (though of course real objects can certainly do this). At each time step, the 2D MODE spatial axis of the object is indicated by the red line. In the center of the figure, we see the same thing, just with more time steps. And on the right, even more time steps. We see that the axis lines at each time step sweep out a plane in three dimensions, shown in red on the right. This plane is the same one that MTD would calculate for this 3D object to determine its spatial orientation, *i.e.,* axis angle. Indeed, for the special case of an object that is not moving at all, the MTD calculation of axis angle reduces to the same one that traditional MODE uses, as it should. +:numref:`mtd-axis_3d` gives some idea of the reason for fitting a plane, rather than a line, as MODE does. On the left in the figure, we see an object (in blue shaped like an "A") at several time steps moving through the grid. For simplicity, the object is not rotating as it moves (though of course real objects can certainly do this). At each time step, the 2D MODE spatial axis of the object is indicated by the red line. In the center of the figure, we see the same thing, just with more time steps. And on the right, even more time steps. We see that the axis lines at each time step sweep out a plane in three dimensions, shown in red on the right. This plane is the same one that MTD would calculate for this 3D object to determine its spatial orientation, *i.e.,* axis angle. Indeed, for the special case of an object that is not moving at all, the MTD calculation of axis angle reduces to the same one that traditional MODE uses, as it should. .. _mtd-axis_3d: @@ -92,9 +92,9 @@ Finally, MTD calculates several **intensity percentiles** of the raw data values 3D Pair Attributes ~~~~~~~~~~~~~~~~~~ -The next category of spatial attributes is for pairs of objects — one of the pair coming from the collection of forecast objects, the other coming from the observation objects. +The next category of spatial attributes is for pairs of objects - one of the pair coming from the collection of forecast objects, the other coming from the observation objects. -Note: whenever a pair attribute is described below as a *delta*, that means it's a simple difference of two single-object attributes. The difference is always taken as “forecast minus observed”. +Note: whenever a pair attribute is described below as a *delta*, that means it's a simple difference of two single-object attributes. The difference is always taken as "forecast minus observed". The **spatial centroid distance** is the purely spatial part of the centroid separation of two objects. If one centroid is at :math:`(\bar{x}_1, \bar{y}_1, \bar{t}_1)` and the other is at :math:`(\bar{x}_2, \bar{y}_2, \bar{t}_2)` then the distance is calculated as @@ -184,7 +184,7 @@ MTD input The formats for two-dimensional data files used as input to MTD are the same ones supported by most of the MET tools. Generally speaking, if MODE can use a forecast or observation data file as input, then that file can also be used by MTD. The only difference is that while MODE takes only one forecast and one observed data file as input, MTD takes a series of files. -As shown in the next section, filenames for each time used must be given. Thus, for example, if MTD is being used for verification over a period of 24 hours, and the data file valid times are separated by one hour, then a total of 48 filenames must be specified on the MTD command line — 24 filenames for the forecast files, and 24 for the observation files. Further, the filenames must be given in order of increasing valid time. Many users will prefer to write scripts to automate this, rather than type in a lengthy command line by hand. +As shown in the next section, filenames for each time used must be given. Thus, for example, if MTD is being used for verification over a period of 24 hours, and the data file valid times are separated by one hour, then a total of 48 filenames must be specified on the MTD command line - 24 filenames for the forecast files, and 24 for the observation files. Further, the filenames must be given in order of increasing valid time. Many users will prefer to write scripts to automate this, rather than type in a lengthy command line by hand. MTD usage ~~~~~~~~~ @@ -558,7 +558,7 @@ The contents of the OBJECT_ID and OBJECT_CAT columns identify the objects using - Angle that the axis plane of an object makes with the grid x direction * - 33 - VOLUME - - Integer count of the number of 3D “cells” in an object + - Integer count of the number of 3D "cells" in an object * - 34 - START_TIME - Object start time @@ -631,7 +631,7 @@ The contents of the OBJECT_ID and OBJECT_CAT columns identify the objects using - Difference in object ending time steps * - 33 - INTERSECTION_VOLUME - - “Volume” of object intersection + - "Volume" of object intersection * - 34 - DURATION_DIFF - Difference in the lifetimes of the two objects diff --git a/met/docs/Users_Guide/mode.rst b/met/docs/Users_Guide/mode.rst index 68556c2c9c..defbb38603 100644 --- a/met/docs/Users_Guide/mode.rst +++ b/met/docs/Users_Guide/mode.rst @@ -30,7 +30,7 @@ The process used for resolving objects in a raw data field is called *convolutio In this formula, :math:`f` is the raw data field, :math:`\phi` is the filter function, and :math:`C` is the resulting convolved field. The variables :math:`(x, y)` and :math:`(u, v)` are grid coordinates. The filter function :math:`\phi` is a simple circular filter determined by a radius of influence :math:`R` , and a height :math:`H` : -.. math:: \phi (x,y) = \begin{eqnarray}\begin{cases} H &\text{if } x^2 + y^2\leq R^2\\ 0 &\text{otherwise.} \end{cases}\end{eqnarray} +.. math:: \phi (x,y) = \begin{align}\begin{cases} H &\text{if } x^2 + y^2\leq R^2\\ 0 &\text{otherwise.} \end{cases}\end{align} The parameters :math:`R` and :math:`H` are not independent. They are related by the requirement that the integral of :math:`\phi` over the grid be unity: @@ -40,13 +40,13 @@ Thus, the radius of influence :math:`R` is the only tunable parameter in the con Once the convolved field :math:`C` is in hand, it is thresholded to create a mask field :math:`M` : -.. math:: M(x,y) = \begin{eqnarray}\begin{cases} 1 &\text{if } C(x,y)\ge T\\ 0 &\text{otherwise.} \end{cases}\end{eqnarray} +.. math:: M(x,y) = \begin{align}\begin{cases} 1 &\text{if } C(x,y)\ge T\\ 0 &\text{otherwise.} \end{cases}\end{align} where :math:`T` is the threshold. The objects are the connected regions where :math:`M = 1` . Finally, the raw data are restored to object interiors to obtain the object field :math:`F` : .. math:: F(x,y)=M(x,y)f(x,y). -Thus, two parameters — the radius of influence :math:`R`, and the threshold :math:`T` — control the entire process of resolving objects in the raw data field. +Thus, two parameters - the radius of influence :math:`R`, and the threshold :math:`T` - control the entire process of resolving objects in the raw data field. An example of the steps involved in resolving objects is shown in :numref:`mode-object_id`. It shows a "raw" precipitation field, where the vertical coordinate represents the precipitation amount. Part (b) shows the convolved field, and part (c) shows the masked field obtained after the threshold is applied. Finally, :numref:`mode-object_id` shows the objects once the original precipitation values have been restored to the interiors of the objects. @@ -148,7 +148,7 @@ Optional arguments for mode 7. The **-v level** option indicates the desired level of verbosity. The contents of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. -8. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of “level” will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. +8. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of "level" will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. An example of the MODE calling sequence is listed below: @@ -641,7 +641,7 @@ This first file uses the following naming convention: where *PREFIX* indicates the user-defined output prefix, *FCST\_VAR\_LVL* is the forecast variable and vertical level being used, *OBS\_VAR\_LVL* is the observation variable and vertical level being used, *HHMMSSL* indicates the forecast lead time, *YYYYMMDD\_HHMMSSV* indicates the forecast valid time, and *HHMMSSA* indicates the accumulation period. The {\tt cts} string stands for contingency table statistics. The generation of this file can be disabled using the *ct\_stats\_flag* option in the configuration file. This CTS output file differs somewhat from the CTS output of the Point-Stat and Grid-Stat tools. The columns of this output file are summarized in :numref:`CTS_output`. -The second ASCII file the MODE tool generates contains all of the attributes for simple objects, the merged cluster objects, and pairs of objects. Each line in this file contains the same number of columns, though those columns not applicable to a given line contain fill data. The first row of every MODE object attribute file is a header containing the column names. The number of lines in this file depends on the number of objects defined. This file contains lines of 6 types that are indicated by the contents of the **OBJECT_ID** column. The **OBJECT_ID** can take the following 6 forms: **FNN, ONN, FNNN_ONNN, CFNNN, CONNN, CFNNN_CONNN**. In each case, **NNN** is a three-digit number indicating the object index. While all lines have the first 18 header columns in common, these 6 forms for **OBJECT_ID** can be divided into two types - one for single objects and one for pairs of objects. The single object lines **(FNN, ONN, CFNNN**, and **CONNN)** contain valid data in columns 19–39 and fill data in columns 40–51. The object pair lines **(FNNN_ONNN** and **CFNNN_CONNN)** contain valid data in columns 40–51 and fill data in columns 19–39. +The second ASCII file the MODE tool generates contains all of the attributes for simple objects, the merged cluster objects, and pairs of objects. Each line in this file contains the same number of columns, though those columns not applicable to a given line contain fill data. The first row of every MODE object attribute file is a header containing the column names. The number of lines in this file depends on the number of objects defined. This file contains lines of 6 types that are indicated by the contents of the **OBJECT_ID** column. The **OBJECT_ID** can take the following 6 forms: **FNN, ONN, FNNN_ONNN, CFNNN, CONNN, CFNNN_CONNN**. In each case, **NNN** is a three-digit number indicating the object index. While all lines have the first 18 header columns in common, these 6 forms for **OBJECT_ID** can be divided into two types - one for single objects and one for pairs of objects. The single object lines **(FNN, ONN, CFNNN**, and **CONNN)** contain valid data in columns 19-39 and fill data in columns 40-51. The object pair lines **(FNNN_ONNN** and **CFNNN_CONNN)** contain valid data in columns 40-51 and fill data in columns 19-39. These object identifiers are described in :numref:`MODE_object_attribute`. diff --git a/met/docs/Users_Guide/plotting.rst b/met/docs/Users_Guide/plotting.rst index 04e9ee629a..7f748e7885 100644 --- a/met/docs/Users_Guide/plotting.rst +++ b/met/docs/Users_Guide/plotting.rst @@ -320,7 +320,7 @@ The plots in :numref:`plotting_Gilbert_skill_score` show time series of frequenc .. _plotting_Gilbert_skill_score: -.. figure:: figure/plotting_Gilbert_skill_score.gif +.. figure:: figure/plotting-Gilbert-skill-score.png Time series of forecast area bias and Gilbert Skill Score for four model configurations (different lines) stratified by time-of-day. @@ -333,7 +333,7 @@ When using the MODE tool, it is possible to think of matched objects as hits and .. _plotting_verification: -.. figure:: figure/plotting_verification.gif +.. figure:: figure/plotting-verification.png Traditional verification scores applied to output of the MODE tool, computed by defining matched observed objects to be hits, unmatched observed objects to be misses, and unmatched forecast objects to be false alarms; weighted by object area. Bar plots show numbers (penultimate row) and areas (bottom row) of observed and forecast objects, respectively. diff --git a/met/docs/Users_Guide/point-stat.rst b/met/docs/Users_Guide/point-stat.rst index a1a7cdd9cf..162f86926c 100644 --- a/met/docs/Users_Guide/point-stat.rst +++ b/met/docs/Users_Guide/point-stat.rst @@ -852,6 +852,10 @@ The first set of header columns are common to all of the output files generated * - 120-122 - ANOM_CORR_UNCNTR, :raw-html:`
` ANOM_CORR_UNCNTR_BCL, :raw-html:`
` ANOM_CORR_UNCNTR_BCU - The uncentered Anomaly Correlation excluding mean error including bootstrap upper and lower confidence limits + * - 123-125 + - SI, :raw-html:`
` SI_BCL, :raw-html:`
` SI_BCU + - Scatter Index including bootstrap upper and lower confidence limits + .. _table_PS_format_info_MCTC: @@ -1307,58 +1311,58 @@ The first set of header columns are common to all of the output files generated * - 25 - TOTAL - Total number of data points - * - 26–28 + * - 26-28 - FBAR - Mean value of forecast wind speed - * - 29–31 + * - 29-31 - OBAR - Mean value of observed wind speed - * - 32–34 + * - 32-34 - FS_RMS - Root mean square forecast wind speed - * - 35–37 + * - 35-37 - OS_RMS - Root mean square observed wind speed - * - 38–40 + * - 38-40 - MSVE - Mean squared length of the vector difference between the forecast and observed winds - * - 41–43 + * - 41-43 - RMSVE - Square root of MSVE - * - 45–46 + * - 45-46 - FSTDEV - Standard deviation of the forecast wind speed - * - 47–49 + * - 47-49 - OSTDEV - Standard deviation of the observed wind field - * - 50–52 + * - 50-52 - FDIR - Direction of the average forecast wind vector - * - 53–55 + * - 53-55 - ODIR - Direction of the average observed wind vector - * - 56–58 + * - 56-58 - FBAR_SPEED - Length (speed) of the average forecast wind vector - * - 59–61 + * - 59-61 - OBAR_SPEED - Length (speed) of the average observed wind vector - * - 62–64 + * - 62-64 - VDIFF_SPEED - Length (speed) of the vector difference between the average forecast and average observed wind vectors - * - 65–67 + * - 65-67 - VDIFF_DIR - Direction of the vector difference between the average forecast and average wind vectors - * - 68–70 + * - 68-70 - SPEED_ERR - Difference between the length of the average forecast wind vector and the average observed wind vector (in the sense F - O) - * - 71–73 + * - 71-73 - SPEED_ABSERR - Absolute value of SPEED_ERR - * - 74–76 + * - 74-76 - DIR_ERR - Signed angle between the directions of the average forecast and observed wing vectors. Positive if the forecast wind vector is counterclockwise from the observed wind vector - * - 77–79 + * - 77-79 - DIR_ABSERR - Absolute value of DIR_ABSERR diff --git a/met/docs/Users_Guide/reformat_grid.rst b/met/docs/Users_Guide/reformat_grid.rst index c2c5fe36ba..5975de88d1 100644 --- a/met/docs/Users_Guide/reformat_grid.rst +++ b/met/docs/Users_Guide/reformat_grid.rst @@ -10,17 +10,17 @@ ________________ This section describes the Pcp-Combine tool which summarizes data across multiple input gridded data files and writes the results to a single NetCDF output file. It is often used to modify precipitation accumulation intervals in the forecast and/or observation datasets to make them comparable. However it can also be used to derive summary fields, such as daily min/max temperature or average precipitation rate. -The Pcp-Combine tool supports four types of commands (“sum”, “add”, “subtract”, and “derive”) which may be run on any gridded data files supported by MET. +The Pcp-Combine tool supports four types of commands ("sum", "add", "subtract", and "derive") which may be run on any gridded data files supported by MET. -1. The “sum” command is the default command and therefore specifying “-sum” on the command line is optional. Using the sum arguments described below, Pcp-Combine searches the input directories (“-pcpdir” option) for data that matches the requested time stamps and accumulation intervals. Pcp-Combine only considers files from the input data directory which match the specified regular expression (“-pcprx” option). While “sum” searches for matching data, all the other commands are run on the explicit set of input files specified. +1. The "sum" command is the default command and therefore specifying "-sum" on the command line is optional. Using the sum arguments described below, Pcp-Combine searches the input directories ("-pcpdir" option) for data that matches the requested time stamps and accumulation intervals. Pcp-Combine only considers files from the input data directory which match the specified regular expression ("-pcprx" option). While "sum" searches for matching data, all the other commands are run on the explicit set of input files specified. -2. The “add” command reads the requested data from the input data files and adds them together. +2. The "add" command reads the requested data from the input data files and adds them together. -3. The “subtract” command reads the requested data from exactly two input files and computes their difference. +3. The "subtract" command reads the requested data from exactly two input files and computes their difference. -4. The “derive” command reads the requested data from the input data files and computes the requested summary fields. +4. The "derive" command reads the requested data from the input data files and computes the requested summary fields. -By default, the Pcp-Combine tool processes data for **APCP**, the GRIB string for accumulated precipitation. When requesting data using time strings (i.e. [HH]MMSS), Pcp-Combine searches for accumulated precipitation for that accumulation interval. Alternatively, use the “-field” option to process fields other than **APCP** or for non-GRIB files. The “-field” option may be used multiple times to process multiple fields in a single run. Since the Pcp-Combine tool does not support automated regridding, all input data must be on the same grid. In general the input files should have the same initialization time unless the user has indicated that it should ignore the initialization time for the “sum” command. The “subtract” command produces a warning when the input initialization times differ or the subtraction results in a negative accumulation interval. +By default, the Pcp-Combine tool processes data for **APCP**, the GRIB string for accumulated precipitation. When requesting data using time strings (i.e. [HH]MMSS), Pcp-Combine searches for accumulated precipitation for that accumulation interval. Alternatively, use the "-field" option to process fields other than **APCP** or for non-GRIB files. The "-field" option may be used multiple times to process multiple fields in a single run. Since the Pcp-Combine tool does not support automated regridding, all input data must be on the same grid. In general the input files should have the same initialization time unless the user has indicated that it should ignore the initialization time for the "sum" command. The "subtract" command produces a warning when the input initialization times differ or the subtraction results in a negative accumulation interval. pcp_combine usage ~~~~~~~~~~~~~~~~~ @@ -82,9 +82,9 @@ Optional arguments for pcp_combine 6. The **-log file** option directs output and errors to the specified log file. All messages will be written to that file as well as standard out and error. Thus, users can save the messages without having to redirect the output on the command line. The default behavior is no log file. -7. The **-v level** option indicates the desired level of verbosity. The contents of “level” will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. +7. The **-v level** option indicates the desired level of verbosity. The contents of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. -8. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of “level” will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. +8. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of "level" will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. Required arguments for the pcp_combine sum command ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -100,14 +100,14 @@ Required arguments for the pcp_combine sum command Optional arguments for pcp_combine sum command ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -5. The **-pcpdir path** option indicates the directories in which the input files reside. The contents of “**path**” will override the default setting. This option may be used multiple times and can accept multiple arguments, supporting the use of wildcards. +5. The **-pcpdir path** option indicates the directories in which the input files reside. The contents of "**path**" will override the default setting. This option may be used multiple times and can accept multiple arguments, supporting the use of wildcards. -6. The **-pcprx reg_exp** option indicates the regular expression to be used in matching files in the search directories specified. The contents of “reg_exp” will override the default setting that matches all file names. If the search directories contain a large number of files, the user may specify that only a subset of those files be processed using a regular expression which will speed up the run time. +6. The **-pcprx reg_exp** option indicates the regular expression to be used in matching files in the search directories specified. The contents of "reg_exp" will override the default setting that matches all file names. If the search directories contain a large number of files, the user may specify that only a subset of those files be processed using a regular expression which will speed up the run time. Required arguments for the pcp_combine derive command ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -1. The “derive” run command must be followed by **stat_list** which is a comma-separated list of summary fields to be computed. The **stat_list** may be set to sum, min, max, range, mean, stdev, and vld_count for the sum, minimum, maximum, range (max-min), average, standard deviation, and valid data count fields, respectively. +1. The "derive" run command must be followed by **stat_list** which is a comma-separated list of summary fields to be computed. The **stat_list** may be set to sum, min, max, range, mean, stdev, and vld_count for the sum, minimum, maximum, range (max-min), average, standard deviation, and valid data count fields, respectively. Input files for pcp_combine add, subtract, and derive commands ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -116,9 +116,9 @@ The input files for the add, subtract, and derive command can be specified in on 1. Use **file_1 config_str_1 ... file_n config_str_n** to specify the full path to each input file followed by a description of the data to be read from it. The **config_str_i** argument describing the data can be a set to a time string in HH[MMSS] format for accumulated precipitation or a full configuration string. For example, use **'name="TMP"; level="P500";'** to process temperature at 500mb. -2. Use **file_1 ... file_n** to specify the list of input files to be processed on the command line. Rather than specifying a separate configuration string for each input file, the “-field” command line option is required to specify the data to be processed. +2. Use **file_1 ... file_n** to specify the list of input files to be processed on the command line. Rather than specifying a separate configuration string for each input file, the "-field" command line option is required to specify the data to be processed. -3. Use **input_file_list** to specify the name of an ASCII file which contains the paths for the gridded data files to be processed. As in the previous option, the “-field” command line option is required to specify the data to be processed. +3. Use **input_file_list** to specify the name of an ASCII file which contains the paths for the gridded data files to be processed. As in the previous option, the "-field" command line option is required to specify the data to be processed. An example of the pcp_combine calling sequence is presented below: @@ -260,7 +260,7 @@ Optional arguments for regrid_data_plane 12. The **-log file** option directs output and errors to the specified log file. All messages will be written to that file as well as standard out and error. Thus, users can save the messages without having to redirect the output on the command line. The default behavior is no log file. -13. The **-v level** option indicates the desired level of verbosity. The contents of “level” will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. +13. The **-v level** option indicates the desired level of verbosity. The contents of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. 14. The **-compress level** option specifies the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. @@ -337,9 +337,9 @@ Optional arguments for shift_data_plane 9. The **-log file** option directs output and errors to the specified log file. All messages will be written to that file as well as standard out and error. Thus, users can save the messages without having to redirect the output on the command line. The default behavior is no log file. -10. The **-v level** option indicates the desired level of verbosity. The contents of “level” will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. +10. The **-v level** option indicates the desired level of verbosity. The contents of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. -11. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of “level” will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. +11. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of "level" will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. For more details on setting the **-method** and **-width** options, see the **regrid** entry in :numref:`config_options`. An example of the shift_data_plane calling sequence is shown below: @@ -402,7 +402,7 @@ Optional arguments for modis_regrid 8. The **-units text** option specifies the units string in the global attributes section of the output file. -9. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of “level” will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. +9. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of "level" will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. An example of the modis_regrid calling sequence is shown below: @@ -462,7 +462,7 @@ Optional arguments for wwmca_plot 4. The **-log file** option directs output and errors to the specified log file. All messages will be written to that file as well as standard out and error. Thus, users can save the messages without having to redirect the output on the command line. The default behavior is no log file. -5. The **-v level** option indicates the desired level of verbosity. The value of “level” will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity will increase the amount of logging. +5. The **-v level** option indicates the desired level of verbosity. The value of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity will increase the amount of logging. .. figure:: figure/reformat_grid_fig2.png @@ -502,11 +502,11 @@ Optional arguments for wwmca_regrid 5. The **-log file** option directs output and errors to the specified log file. All messages will be written to that file as well as standard out and error. Thus, users can save the messages without having to redirect the output on the command line. The default behavior is no log file. -6. The **-v level** option indicates the desired level of verbosity. The value of “level” will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity will increase the amount of logging. +6. The **-v level** option indicates the desired level of verbosity. The value of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity will increase the amount of logging. -7. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of “level” will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. +7. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of "level" will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. -In any regridding problem, there are two grids involved: the “From” grid, which is the grid the input data are on, and the “To” grid, which is the grid the data are to be moved onto. In **WWMCA-Regrid** the “From” grid is pre-defined by the hemisphere of the WWMCA binary files being processed. The “To” grid and corresponding regridding logic are specified using the **regrid** section of the configuration file. If the “To” grid is entirely confined to one hemisphere, then only the WWMCA data file for that hemisphere needs to be given. If the “To” grid or the interpolation box used straddles the equator, the data files for both hemispheres need to be given. Once the “To” grid is specified in the config file, the WWMCA-Regrid tool will know which input data files it needs and will complain if it is not given the right ones. +In any regridding problem, there are two grids involved: the "From" grid, which is the grid the input data are on, and the "To" grid, which is the grid the data are to be moved onto. In **WWMCA-Regrid** the "From" grid is pre-defined by the hemisphere of the WWMCA binary files being processed. The "To" grid and corresponding regridding logic are specified using the **regrid** section of the configuration file. If the "To" grid is entirely confined to one hemisphere, then only the WWMCA data file for that hemisphere needs to be given. If the "To" grid or the interpolation box used straddles the equator, the data files for both hemispheres need to be given. Once the "To" grid is specified in the config file, the WWMCA-Regrid tool will know which input data files it needs and will complain if it is not given the right ones. wwmca_regrid configuration file ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/met/docs/Users_Guide/reformat_point.rst b/met/docs/Users_Guide/reformat_point.rst index f872a12b40..999393b72d 100644 --- a/met/docs/Users_Guide/reformat_point.rst +++ b/met/docs/Users_Guide/reformat_point.rst @@ -61,10 +61,10 @@ The **-valid_beg** time option in YYYYMMDD[_HH[MMSS]] format sets the beginning The **-valid_end** time option in YYYYMMDD[_HH[MMSS]] format sets the end of the retention time window. 4. -The **-nmsg num_messages** option may be used for testing purposes. This argument indicates that only the first “num_messages” PrepBUFR messages should be processed rather than the whole file. This option is provided to speed up testing because running the PB2NC tool can take a few minutes for each file. Most users will not need this option. +The **-nmsg num_messages** option may be used for testing purposes. This argument indicates that only the first "num_messages" PrepBUFR messages should be processed rather than the whole file. This option is provided to speed up testing because running the PB2NC tool can take a few minutes for each file. Most users will not need this option. 5. -The **-dump path** option may be used to dump the entire contents of the PrepBUFR file to several ASCII files written to the directory specified by “path”. The user may use this option to view a human-readable version of the input PrepBUFR file, although writing the contents to ASCII files can be slow. +The **-dump path** option may be used to dump the entire contents of the PrepBUFR file to several ASCII files written to the directory specified by "path". The user may use this option to view a human-readable version of the input PrepBUFR file, although writing the contents to ASCII files can be slow. 6. The **-index** option shows the available variables with valid data from the BUFR input. It collects the available variable list from BUFR input and checks the existence of valid data and directs the variable names with valid data to the screen. The NetCDF output won't be generated. @@ -73,10 +73,10 @@ The **-index** option shows the available variables with valid data from the BUF The **-log** file option directs output and errors to the specified log file. All messages will be written to that file as well as standard out and error. Thus, users can save the messages without having to redirect the output on the command line. The default behavior is no log file. 8. -The **-v level** option indicates the desired level of verbosity. The value of “level” will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. +The **-v level** option indicates the desired level of verbosity. The value of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. 9. -The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of “level” will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. +The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of "level" will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. An example of the pb2nc calling sequence is shown below: @@ -99,7 +99,7 @@ When editing configuration files, environment variables may be used for setting For example, using an environment variable to set the **message_type** (see below) parameter to use ADPUPA and ADPSFC message types might consist of the following: -\* In a C-Shell: **setenv MSG_TYP ' “ADPUPA”, “ADPSFC” '** +\* In a C-Shell: **setenv MSG_TYP ' "ADPUPA", "ADPSFC" '** \* In the configuration file: **message_type = [ ${MSG_TYP} ];** @@ -128,7 +128,7 @@ ___________________ .. code-block:: none - message_type_map = [ { key = “AIRCAR”; val = “AIRCAR_PROFILES”; } ]; + message_type_map = [ { key = "AIRCAR"; val = "AIRCAR_PROFILES"; } ]; The **message_type_map** entry is an array of dictionaries, each containing a **key** string and **val** string. This defines a mapping of input PrepBUFR message types to output message types. This provides a method for renaming input PrepBUFR message types. @@ -293,7 +293,7 @@ ___________________ The **time_summary** dictionary enables additional processing for observations with high temporal resolution. The **flag** entry toggles the **time_summary** on (**TRUE**) and off (**FALSE**). If the **raw_data** flag is set to TRUE, then both the individual observation values and the derived time summary value will be written to the output. If FALSE, only the summary values are written. Observations may be summarized across the user specified time period defined by the **beg** and **end** entries in HHMMSS format. The **step** entry defines the time between intervals in seconds. The **width** entry specifies the summary interval in seconds. It may either be set as an integer number of seconds for a centered time interval or a dictionary with beginning and ending time offsets in seconds. -This example listed above does a 10-minute time summary (width = 600;) every 5 minutes (step = 300;) throughout the day (beg = “000000”; end = 235959”;). The first interval will be from 23:55:00 the previous day through 00:04:59 of the current day. The second interval will be from 0:00:00 through 00:09:59. And so on. +This example listed above does a 10-minute time summary (width = 600;) every 5 minutes (step = 300;) throughout the day (beg = "000000"; end = 235959";). The first interval will be from 23:55:00 the previous day through 00:04:59 of the current day. The second interval will be from 0:00:00 through 00:09:59. And so on. The two **width** settings listed above are equivalent. Both define a centered 10-minute time interval. Use the **beg** and **end** entries to define uncentered time intervals. The following example requests observations for one hour prior: @@ -422,7 +422,7 @@ This section describes how to run the ASCII2NC tool. The ASCII2NC tool is used t Initial versions of the ASCII2NC tool supported only a simple 11 column ASCII point observation format. It currently supports point observation data in the following formats: the default 11 column format, little_r format, `SURFace RADiation (SURFRAD) `_ and Integrated Surface Irradiance Study (ISIS) formats, the Western Wind and Solar Integration Study (WWSIS) format, and the `AErosol RObotic NEtwork (AERONET) versions 2 and 3 format. `_ WWSIS data are available by request from National Renewable Energy Laboratory (NREL) in Boulder, CO. -MET version 9.0 adds support for the passing observations to ascii2nc using a Python script with the “-format python” option. An example of running ASCII2NC with Python embedding is included below. +MET version 9.0 adds support for the passing observations to ascii2nc using a Python script with the "-format python" option. An example of running ASCII2NC with Python embedding is included below. The default ASCII point observation format consists of one row of data per observation value. Each row of data consists of 11 columns as shown in :numref:`table_reform-point_ascii2nc_format`. @@ -496,14 +496,14 @@ ascii2nc has two required arguments and can take several optional ones. Required arguments for ascii2nc ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -1. The **ascii_file** argument is the ASCII point observation file(s) to be processed. If using Python embedding with “-format python” provides a quoted string containing the Python script to be run followed by any command line arguments that script takes. +1. The **ascii_file** argument is the ASCII point observation file(s) to be processed. If using Python embedding with "-format python" provides a quoted string containing the Python script to be run followed by any command line arguments that script takes. 2. The **netcdf_file** argument is the NetCDF output file to be written. Optional arguments for ascii2nc ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -3. The **-format ASCII_format** option may be set to “met_point”, “little_r”, “surfrad”, “wwsis”, “aeronet”, “aeronetv2”, “aeronetv3”, or “python”. If passing in ISIS data, use the “surfrad” format flag. +3. The **-format ASCII_format** option may be set to "met_point", "little_r", "surfrad", "wwsis", "aeronet", "aeronetv2", "aeronetv3", or "python". If passing in ISIS data, use the "surfrad" format flag. 4. The **-config file** option is the configuration file for generating time summaries. @@ -511,13 +511,13 @@ Optional arguments for ascii2nc 6. The **-mask_poly** file option is a polyline masking file to filter the point observations spatially. -7. The **-mask_sid** file|list option is a station ID masking file or a comma-separated list of station ID's to filter the point observations spatially. See the description of the “sid” entry in :numref:`config_options`. +7. The **-mask_sid** file|list option is a station ID masking file or a comma-separated list of station ID's to filter the point observations spatially. See the description of the "sid" entry in :numref:`config_options`. 8. The **-log file** option directs output and errors to the specified log file. All messages will be written to that file as well as standard out and error. Thus, users can save the messages without having to redirect the output on the command line. The default behavior is no log file. -9. The **-v level** option indicates the desired level of verbosity. The value of “level” will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. +9. The **-v level** option indicates the desired level of verbosity. The value of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. -10. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of “level” will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. +10. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of "level" will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. An example of the ascii2nc calling sequence is shown below: @@ -538,7 +538,7 @@ Here is an example of processing the same set of observations but using Python e .. code-block:: none ascii2nc -format python \ - “MET_BASE/python/read_ascii_point.py sample_ascii_obs.txt" \ + "MET_BASE/python/read_ascii_point.py sample_ascii_obs.txt" \ sample_ascii_obs_python.nc Please refer to :numref:`Appendix F, Section %s ` for more details about Python embedding in MET. @@ -592,7 +592,7 @@ ascii2nc output The NetCDF output of the ASCII2NC tool is structured in the same way as the output of the PB2NC tool described in :numref:`pb2nc output`. -“obs_vid” variable is replaced with “obs_gc” when the GRIB code is given instead of the variable names. In this case, the global variable “use_var_id” does not exist or set to false (use_var_id = "false" ;). Three variables (obs_var, obs_units, and obs_desc) related with variable names are not added. +"obs_vid" variable is replaced with "obs_gc" when the GRIB code is given instead of the variable names. In this case, the global variable "use_var_id" does not exist or set to false (use_var_id = "false" ;). Three variables (obs_var, obs_units, and obs_desc) related with variable names are not added. MADIS2NC tool @@ -662,13 +662,13 @@ Optional arguments for madis2nc 9. The **-mask_poly file** option defines a polyline masking file for filtering the point observations spatially. -10. The **-mask_sid file|list** option is a station ID masking file or a comma-separated list of station ID's for filtering the point observations spatially. See the description of the “sid” entry in :numref:`config_options`. +10. The **-mask_sid file|list** option is a station ID masking file or a comma-separated list of station ID's for filtering the point observations spatially. See the description of the "sid" entry in :numref:`config_options`. 11. The **-log file** option directs output and errors to the specified log file. All messages will be written to that file as well as standard out and error. Thus, users can save the messages without having to redirect the output on the command line. The default behavior is no log file. -12. The **-v level** option indicates the desired level of verbosity. The value of “level” will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity will increase the amount of logging. +12. The **-v level** option indicates the desired level of verbosity. The value of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity will increase the amount of logging. 13. The **-compress level** option specifies the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. @@ -720,7 +720,7 @@ madis2nc output The NetCDF output of the MADIS2NC tool is structured in the same way as the output of the PB2NC tool described in :numref:`pb2nc output`. -“obs_vid” variable is replaced with “obs_gc” when the GRIB code is given instead of the variable names. In this case, the global variable “use_var_id” does not exist or set to false (use_var_id = "false" ;). Three variables (obs_var, obs_units, and obs_desc) related with variable names are not added. +"obs_vid" variable is replaced with "obs_gc" when the GRIB code is given instead of the variable names. In this case, the global variable "use_var_id" does not exist or set to false (use_var_id = "false" ;). Three variables (obs_var, obs_units, and obs_desc) related with variable names are not added. LIDAR2NC tool @@ -762,9 +762,9 @@ Optional arguments for lidar2nc 3. The **-log file** option directs output and errors to the specified log file. All messages will be written to that file as well as standard out and error. Thus, users can save the messages without having to redirect the output on the command line. The default behavior is no log file. -4. The **-v level** option indicates the desired level of verbosity. The value of “level” will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. +4. The **-v level** option indicates the desired level of verbosity. The value of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. -5. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of “level” will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. +5. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of "level" will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. lidar2nc output ~~~~~~~~~~~~~~~ @@ -889,9 +889,9 @@ Optional arguments for ioda2nc 8. The **-log** file option directs output and errors to the specified log file. All messages will be written to that file as well as standard out and error. Thus, users can save the messages without having to redirect the output on the command line. The default behavior is no log file. -9. The **-v level** option indicates the desired level of verbosity. The value of “level” will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. +9. The **-v level** option indicates the desired level of verbosity. The value of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. -10. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of “level” will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. +10. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of "level" will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. An example of the ioda2nc calling sequence is shown below: @@ -1017,7 +1017,7 @@ Required arguments for point2grid 3. The **output_filename** argument is the name of the output NetCDF file to be written. -4. The **-field** string argument is a string that defines the data to be regridded. It may be used multiple times. If **-adp** option is given (for AOD data from GOES16/17), the name consists with the variable name from the input data file and the variable name from ADP data file (for example, “AOD_Smoke” or “AOD_Dust”: getting AOD variable from the input data and applying smoke or dust variable from ADP data file). +4. The **-field** string argument is a string that defines the data to be regridded. It may be used multiple times. If **-adp** option is given (for AOD data from GOES16/17), the name consists with the variable name from the input data file and the variable name from ADP data file (for example, "AOD_Smoke" or "AOD_Dust": getting AOD variable from the input data and applying smoke or dust variable from ADP data file). Optional arguments for point2grid @@ -1025,9 +1025,9 @@ Optional arguments for point2grid 5. The **-config** file option is the configuration file to be used. -6. The **-qc** flags option specifies a comma-separated list of quality control (QC) flags, for example “0,1”. This should only be applied if grid_mapping is set to “goes_imager_projection” and the QC variable exists. +6. The **-qc** flags option specifies a comma-separated list of quality control (QC) flags, for example "0,1". This should only be applied if grid_mapping is set to "goes_imager_projection" and the QC variable exists. -7. The **-adp adp_file_name** option provides an additional Aerosol Detection Product (ADP) information on aerosols, dust, and smoke. This option is ignored if the requested variable is not AOD (“AOD_Dust” or “AOD_Smoke”) from GOES16/17. The gridded data is filtered by the presence of dust/smoke. If -qc options are given, it's applied to QC of dust/smoke, too (First filtering with AOD QC values and the second filtering with dust/smoke QC values). +7. The **-adp adp_file_name** option provides an additional Aerosol Detection Product (ADP) information on aerosols, dust, and smoke. This option is ignored if the requested variable is not AOD ("AOD_Dust" or "AOD_Smoke") from GOES16/17. The gridded data is filtered by the presence of dust/smoke. If -qc options are given, it's applied to QC of dust/smoke, too (First filtering with AOD QC values and the second filtering with dust/smoke QC values). 8. The **-method type** option specifies the regridding method. The default method is UW_MEAN. @@ -1043,9 +1043,9 @@ Optional arguments for point2grid 14. The **-log file** option directs output and errors to the specified log file. All messages will be written to that file as well as standard out and error. Thus, users can save the messages without having to redirect the output on the command line. The default behavior is no log file. -15. The **-v level** option indicates the desired level of verbosity. The value of “level” will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. +15. The **-v level** option indicates the desired level of verbosity. The value of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. -16. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of “level” will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. +16. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of "level" will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. Only 4 interpolation methods are applied to the field variables; MIN/MAX/MEDIAN/UW_MEAN. The GAUSSIAN method is applied to the probability variable only. Unlike regrad_data_plane, MAX method is applied to the file variable and Gaussian method to the probability variable with the MAXGAUSS method. If the probability variable is not requested, MAXGAUSS method is the same as MAX method. @@ -1083,13 +1083,13 @@ The point2grid tool will output a gridded NetCDF file containing the following: 4. The count field which represents the number of point observations that were included calculating the value of the variable at that grid cell. -5. The mask field which is a binary field representing the presence or lack thereof of point observations at that grid cell. A value of “1” indicates that there was at least one point observation within the bounds of that grid cell and a value of “0” indicates the lack of point observations at that grid cell. +5. The mask field which is a binary field representing the presence or lack thereof of point observations at that grid cell. A value of "1" indicates that there was at least one point observation within the bounds of that grid cell and a value of "0" indicates the lack of point observations at that grid cell. 6. The probability field which is the probability of the event defined by the **-prob_cat_thresh** command line option. The output variable name includes the threshold used to define the probability. Ranges from 0 to 1. -7. The probability mask field which is a binary field that represents whether or not there is probability data at that grid point. Can be either “0” or “1” with “0” meaning the probability value does not exist and a value of “1” meaning that the probability value does exist. +7. The probability mask field which is a binary field that represents whether or not there is probability data at that grid point. Can be either "0" or "1" with "0" meaning the probability value does not exist and a value of "1" meaning that the probability value does exist. For MET observation input and CF complaint NetCDF input with 2D time variable: The latest observation time within the target grid is saved as the observation time. If the "valid_time" is configured at the configuration file, the valid_time from the configuration file is saved into the output file. diff --git a/met/docs/Users_Guide/refs.rst b/met/docs/Users_Guide/refs.rst index a039a91ab8..118258f15c 100644 --- a/met/docs/Users_Guide/refs.rst +++ b/met/docs/Users_Guide/refs.rst @@ -13,7 +13,7 @@ References | Barker, T. W., 1991: The relationship between spread and forecast error in -| extended-range forecasts. *Journal of Climate*, 4, 733–742. +| extended-range forecasts. *Journal of Climate*, 4, 733-742. | .. _Bradley-2008: @@ -27,7 +27,7 @@ References | Brill, K. F., and F. Mesinger, 2009: Applying a general analytic method | for assessing bias sensitivity to bias-adjusted threat and equitable -| threat scores. *Weather and Forecasting*, 24, 1748–1754. +| threat scores. *Weather and Forecasting*, 24, 1748-1754. | .. _Brown-2007: @@ -45,7 +45,7 @@ References | Buizza, R., 1997: Potential forecast skill of ensemble prediction and spread | and skill distributions of the ECMWF ensemble prediction system. *Monthly* -| *Weather Review*,125, 99–119. +| *Weather Review*,125, 99-119. | .. _Bullock-2016: @@ -58,7 +58,7 @@ References | Candille, G., and O. Talagrand, 2008: Impact of observational error on the | validation of ensemble prediction systems. *Quarterly Journal of the Royal* -| *Meteorological Society* 134: 959–971. +| *Meteorological Society* 134: 959-971. | .. _Casati-2004: @@ -103,7 +103,13 @@ References | Efron, B. 2007: Correlation and large-scale significance testing. *Journal* | of the American Statistical Association,* 102(477), 93-103. -| +| + +.. _Epstein-1969: + +| Epstein, E. S., 1969: A scoring system for probability forecasts of ranked categories. +| *J. Appl. Meteor.*, 8, 985–987, 10.1175/1520-0450(1969)008<0985:ASSFPF>2.0.CO;2. +| .. _Gilleland-2010: @@ -153,11 +159,18 @@ References .. _Mason-2004: -| Mason, S. J., 2004: On Using “Climatology” as a Reference Strategy +| Mason, S. J., 2004: On Using "Climatology" as a Reference Strategy | in the Brier and Ranked Probability Skill Scores. *Monthly Weather Review*, -| 132, 1891–1895. +| 132, 1891-1895. | +.. _Mason-2008: + +| Mason, S. J., 2008: Understanding forecast verification statistics. +| *Meteor. Appl.*, 15, 31–40, doi: 10.1002/met.51. +| + + .. _Mittermaier-2014: | Mittermaier, M., 2014: A strategy for verifying near-convection-resolving @@ -166,10 +179,17 @@ References .. _Mood-1974: -| Mood, A. M., F. A. Graybill and D. C. Boes, 1974: *Introduction to the* +| Mood, A. M., F. A. Graybill and D. C. Boes, 1974: *Introduction to the* | *Theory of Statistics*, McGraw-Hill, 299-338. | +.. _Murphy-1969: + +| Murphy, A.H., 1969: On the ranked probability score. *Journal of Applied* +| *Meteorology and Climatology*, 8 (6), 988 – 989, +| doi: 10.1175/1520-0450(1969)008<0988:OTPS>2.0.CO;2. +| + .. _Murphy-1987: | Murphy, A.H., and R.L. Winkler, 1987: A general framework for forecast @@ -194,14 +214,14 @@ References | Saetra O., H. Hersbach, J-R Bidlot, D. Richardson, 2004: Effects of | observation errors on the statistics for ensemble spread and -| reliability. *Monthly Weather Review* 132: 1487–1501. +| reliability. *Monthly Weather Review* 132: 1487-1501. | .. _Santos-2012: | Santos C. and A. Ghelli, 2012: Observational probability method to assess | ensemble precipitation forecasts. *Quarterly Journal of the Royal* -| *Meteorological Society* 138: 209–221. +| *Meteorological Society* 138: 209-221. | .. _Schwartz-2017: @@ -213,7 +233,7 @@ References .. _Stephenson-2000: -| Stephenson, D.B., 2000: Use of the “Odds Ratio” for diagnosing +| Stephenson, D.B., 2000: Use of the "Odds Ratio" for diagnosing | forecast skill. *Weather and Forecasting*, 15, 221-232. | @@ -224,6 +244,13 @@ References | *Meteorological Applications* 15, 41-50. | +.. _Todter-2012: + +| Tödter, J. and B. Ahrens, 2012: Generalization of the Ignorance Score: +| Continuous ranked version and its decomposition. *Mon. Wea. Rev.*, +| 140 (6), 2005 – 2017, doi: 10.1175/MWR-D-11-00266.1. +| + .. _Weniger-2016: | Weniger, M., F. Kapp, and P. Friederichs, 2016: Spatial Verification Using @@ -235,7 +262,7 @@ References | Wilks, D.S. 2010: Sampling distributions of the Brier score and Brier skill | score under serial dependence. *Quarterly Journal of the Royal* -| *Meteorological Society,*, 136, 2109–2118. doi:10.1002/qj.709 +| *Meteorological Society,*, 136, 2109-2118. doi:10.1002/qj.709 | .. _Wilks-2011: diff --git a/met/docs/Users_Guide/rmw-analysis.rst b/met/docs/Users_Guide/rmw-analysis.rst index c7247446f5..9ae27fe82f 100644 --- a/met/docs/Users_Guide/rmw-analysis.rst +++ b/met/docs/Users_Guide/rmw-analysis.rst @@ -43,7 +43,7 @@ Optional arguments for rmw_analysis 4. The **-log file** option directs output and errors to the specified log file. All messages will be written to that file as well as standard out and error. Thus, users can save the messages without having to redirect the output on the command line. The default behavior is no logfile. -5. The **-v level** option indicates the desired level of verbosity. The contents of “level” will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. +5. The **-v level** option indicates the desired level of verbosity. The contents of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. rmw_analysis configuration file ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/met/docs/Users_Guide/series-analysis.rst b/met/docs/Users_Guide/series-analysis.rst index 26e7e200ea..bc9095dbf1 100644 --- a/met/docs/Users_Guide/series-analysis.rst +++ b/met/docs/Users_Guide/series-analysis.rst @@ -63,7 +63,7 @@ Optional arguments for series_analysis 8. The -v level overrides the default level of logging (2). -9. The -compress level option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of “level” will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. +9. The -compress level option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of "level" will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. An example of the series_analysis calling sequence is shown below: diff --git a/met/docs/Users_Guide/stat-analysis.rst b/met/docs/Users_Guide/stat-analysis.rst index d12ae5746a..2267f7ba03 100644 --- a/met/docs/Users_Guide/stat-analysis.rst +++ b/met/docs/Users_Guide/stat-analysis.rst @@ -8,23 +8,23 @@ ____________ The Stat-Analysis tool ties together results from the Point-Stat, Grid-Stat, Ensemble-Stat, Wavelet-Stat, and TC-Gen tools by providing summary statistical information and a way to filter their STAT output files. It processes the STAT output created by the other MET tools in a variety of ways which are described in this section. -MET version 9.0 adds support for the passing matched pair data (MPR) into Stat-Analysis using a Python script with the “-lookin python ...” option. An example of running Stat-Analysis with Python embedding is shown in :numref:`stat_analysis-usage`. +MET version 9.0 adds support for the passing matched pair data (MPR) into Stat-Analysis using a Python script with the "-lookin python ..." option. An example of running Stat-Analysis with Python embedding is shown in :numref:`stat_analysis-usage`. Scientific and statistical aspects __________________________________ -The Stat-Analysis tool can perform a variety of analyses, and each type of analysis is called a “job”. The job types include the ability to (i) aggregate results over a user-specified time; (ii) stratify statistics based on time of day, model initialization time, lead-time, model run identifier, output filename, or wavelet decomposition scale; and (iii) compute specific verification indices such as the GO Index [1]_ +The Stat-Analysis tool can perform a variety of analyses, and each type of analysis is called a "job". The job types include the ability to (i) aggregate results over a user-specified time; (ii) stratify statistics based on time of day, model initialization time, lead-time, model run identifier, output filename, or wavelet decomposition scale; and (iii) compute specific verification indices such as the GO Index [1]_ and wind direction statistics. Future functionality may include information about time-trends and/or calculations based on climatology (e.g., anomaly correlation). This section summarizes the capabilities of the supported Stat-Analysis jobs. Filter STAT lines ~~~~~~~~~~~~~~~~~ -The Stat-Analysis “filter” job simply filters out specific STAT lines based on user-specified search criteria. All of the STAT lines that are retained from one or many files are written to a single output file. The output file for filtered STAT lines must be specified using the **-dump_row** job command option. +The Stat-Analysis "filter" job simply filters out specific STAT lines based on user-specified search criteria. All of the STAT lines that are retained from one or many files are written to a single output file. The output file for filtered STAT lines must be specified using the **-dump_row** job command option. Summary statistics for columns ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The Stat-Analysis “summary” job produces summary information for columns of data. After the user specifies the column(s) of interest and any other relevant search criteria, summary information is produced from values in those column(s) of data. The summary statistics produced are: mean, standard deviation, minimum, maximum, the 10th, 25th, 50th, 75th, and 90th percentiles, the interquartile range, the range, and both weighted and unweighted means using the logic prescribed by the World Meteorological Organization (WMO). +The Stat-Analysis "summary" job produces summary information for columns of data. After the user specifies the column(s) of interest and any other relevant search criteria, summary information is produced from values in those column(s) of data. The summary statistics produced are: mean, standard deviation, minimum, maximum, the 10th, 25th, 50th, 75th, and 90th percentiles, the interquartile range, the range, and both weighted and unweighted means using the logic prescribed by the World Meteorological Organization (WMO). Confidence intervals are computed for the mean and standard deviation of the column of data. For the mean, the confidence interval is computed two ways - based on an assumption of normality and also using the bootstrap method. For the standard deviation, the confidence interval is computed using the bootstrap method. In this application of the bootstrap method, the values in the column of data being summarized are resampled, and for each replicated sample, the mean and standard deviation are computed. @@ -39,14 +39,14 @@ The **-derive** job command option can be used to perform the derivation of stat Aggregated values from multiple STAT lines ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The Stat-Analysis “aggregate” job aggregates values from multiple STAT lines of the same type. The user may specify the specific line type of interest and any other relevant search criteria. The Stat-Analysis tool then creates sums of each of the values in all lines matching the search criteria. The aggregated data are output as the same line type as the user specified. The STAT line types which may be aggregated in this way are the contingency table (FHO, CTC, PCT, MCTC, NBRCTC), partial sums (SL1L2, SAL1L2, VL1L2, and VAL1L2), and other (ISC, ECNT, RPS, RHIST, PHIST, RELP, NBRCNT, SSVAR, and GRAD) line types. +The Stat-Analysis "aggregate" job aggregates values from multiple STAT lines of the same type. The user may specify the specific line type of interest and any other relevant search criteria. The Stat-Analysis tool then creates sums of each of the values in all lines matching the search criteria. The aggregated data are output as the same line type as the user specified. The STAT line types which may be aggregated in this way are the contingency table (FHO, CTC, PCT, MCTC, NBRCTC), partial sums (SL1L2, SAL1L2, VL1L2, and VAL1L2), and other (ISC, ECNT, RPS, RHIST, PHIST, RELP, NBRCNT, SSVAR, and GRAD) line types. Aggregate STAT lines and produce aggregated statistics ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The Stat-Analysis “aggregate-stat” job aggregates multiple STAT lines of the same type together and produces relevant statistics from the aggregated line. This may be done in the same manner listed above in :numref:`StA_Aggregated-values-from`. However, rather than writing out the aggregated STAT line itself, the relevant statistics generated from that aggregated line are provided in the output. Specifically, if a contingency table line type (FHO, CTC, PCT, MCTC, or NBRCTC) has been aggregated, contingency table statistics (CTS, ECLV, PSTD, MCTS, or NBRCTS) line types can be computed. If a partial sums line type (SL1L2 or SAL1L2) has been aggregated, the continuous statistics (CNT) line type can be computed. If a vector partial sums line type (VL1L2) has been aggregated, the vector continuous statistics (VCNT) line type can be computed. For ensembles, the ORANK line type can be accumulated into ECNT, RPS, RHIST, PHIST, RELP, or SSVAR output. If the matched pair line type (MPR) has been aggregated, may output line types (FHO, CTC, CTS, CNT, MCTC, MCTS, SL1L2, SAL1L2, VL1L2, VCNT, WDIR, PCT, PSTD, PJC, PRC, or ECLV) can be computed. Multiple output line types may be specified for each “aggregate-stat” job, as long as each output is derivable from the input. +The Stat-Analysis "aggregate-stat" job aggregates multiple STAT lines of the same type together and produces relevant statistics from the aggregated line. This may be done in the same manner listed above in :numref:`StA_Aggregated-values-from`. However, rather than writing out the aggregated STAT line itself, the relevant statistics generated from that aggregated line are provided in the output. Specifically, if a contingency table line type (FHO, CTC, PCT, MCTC, or NBRCTC) has been aggregated, contingency table statistics (CTS, ECLV, PSTD, MCTS, or NBRCTS) line types can be computed. If a partial sums line type (SL1L2 or SAL1L2) has been aggregated, the continuous statistics (CNT) line type can be computed. If a vector partial sums line type (VL1L2) has been aggregated, the vector continuous statistics (VCNT) line type can be computed. For ensembles, the ORANK line type can be accumulated into ECNT, RPS, RHIST, PHIST, RELP, or SSVAR output. If the matched pair line type (MPR) has been aggregated, may output line types (FHO, CTC, CTS, CNT, MCTC, MCTS, SL1L2, SAL1L2, VL1L2, VCNT, WDIR, PCT, PSTD, PJC, PRC, or ECLV) can be computed. Multiple output line types may be specified for each "aggregate-stat" job, as long as each output is derivable from the input. -When aggregating the matched pair line type (MPR), additional required job command options are determined by the requested output line type(s). For example, the “-out_thresh” (or “-out_fcst_thresh” and “-out_obs_thresh” options) are required to compute contingnecy table counts (FHO, CTC) or statistics (CTS). Those same job command options can also specify filtering thresholds when computing continuous partial sums (SL1L2, SAL1L2) or statistics (CNT). Output is written for each threshold specified. +When aggregating the matched pair line type (MPR), additional required job command options are determined by the requested output line type(s). For example, the "-out_thresh" (or "-out_fcst_thresh" and "-out_obs_thresh" options) are required to compute contingnecy table counts (FHO, CTC) or statistics (CTS). Those same job command options can also specify filtering thresholds when computing continuous partial sums (SL1L2, SAL1L2) or statistics (CNT). Output is written for each threshold specified. When aggregating the matched pair line type (MPR) and computing an output contingency table statistics (CTS) or continuous statistics (CNT) line type, the bootstrapping method can be applied to compute confidence intervals. The bootstrapping method is applied here in the same way that it is applied in the statistics tools. For a set of n matched forecast-observation pairs, the matched pairs are resampled with replacement many times. For each replicated sample, the corresponding statistics are computed. The confidence intervals are derived from the statistics computed for each replicated sample. @@ -55,7 +55,7 @@ When aggregating the matched pair line type (MPR) and computing an output contin Skill Score Index, including GO Index ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The Stat-Analysis “ss_index” and “go_index” jobs calculate the skill score indices by weighting scores for different meteorological fields at different pressure levels and for different lead times. The GO Index is a special case of the Skill Score index for which a specific configuration file is provided. The GO index is a weighted average of the RMSE values for wind speed, dew point temperature, temperature, height, and pressure at several levels in the atmosphere. The variables, levels, and lead times included in the index are shown in :numref:`compute_GO_Index` and are defined by a default Stat-Analysis configuration file. The partial sums (SL1L2 lines in the STAT output) for each of these variables at each level and lead time must have been computed in a previous step. The Stat-Analysis tool then uses the weights in :numref:`compute_GO_Index` to compute values for the GO Index. For a general skill score index, the user can specify the weights and variables to use in the calculations in a Stat-Analysis configuration file and run the ss_index job type. +The Stat-Analysis "ss_index" and "go_index" jobs calculate the skill score indices by weighting scores for different meteorological fields at different pressure levels and for different lead times. The GO Index is a special case of the Skill Score index for which a specific configuration file is provided. The GO index is a weighted average of the RMSE values for wind speed, dew point temperature, temperature, height, and pressure at several levels in the atmosphere. The variables, levels, and lead times included in the index are shown in :numref:`compute_GO_Index` and are defined by a default Stat-Analysis configuration file. The partial sums (SL1L2 lines in the STAT output) for each of these variables at each level and lead time must have been computed in a previous step. The Stat-Analysis tool then uses the weights in :numref:`compute_GO_Index` to compute values for the GO Index. For a general skill score index, the user can specify the weights and variables to use in the calculations in a Stat-Analysis configuration file and run the ss_index job type. .. _compute_GO_Index: @@ -151,12 +151,12 @@ The Stat-Analysis “ss_index” and “go_index” jobs calculate the skill sco Ramp Events ~~~~~~~~~~~ -The Stat-Analysis “ramp” job identifies ramp events (large increases or decreases in values over a time window) in both the forecast and observation data. It categorizes these events as hits, misses, false alarms, or correct negatives by applying a configurable matching time window and computes the corresponding categorical statistics. +The Stat-Analysis "ramp" job identifies ramp events (large increases or decreases in values over a time window) in both the forecast and observation data. It categorizes these events as hits, misses, false alarms, or correct negatives by applying a configurable matching time window and computes the corresponding categorical statistics. Wind Direction Statistics ~~~~~~~~~~~~~~~~~~~~~~~~~ -The Stat-Analysis “aggregate_stat” job can read vector partial sums and derive wind direction error statistics (WDIR). The vector partial sums (VL1L2 or VAL1L2) or matched pairs (MPR) for the UGRD and VGRD must have been computed in a previous step, i.e. by Point-Stat or Grid-Stat tools. This job computes an average forecast wind direction and an average observed wind direction along with their difference. The output is in degrees. In Point-Stat and Grid-Stat, the UGRD and VGRD can be verified using thresholds on their values or on the calculated wind speed. If thresholds have been applied, the wind direction statistics are calculated for each threshold. +The Stat-Analysis "aggregate_stat" job can read vector partial sums and derive wind direction error statistics (WDIR). The vector partial sums (VL1L2 or VAL1L2) or matched pairs (MPR) for the UGRD and VGRD must have been computed in a previous step, i.e. by Point-Stat or Grid-Stat tools. This job computes an average forecast wind direction and an average observed wind direction along with their difference. The output is in degrees. In Point-Stat and Grid-Stat, the UGRD and VGRD can be verified using thresholds on their values or on the calculated wind speed. If thresholds have been applied, the wind direction statistics are calculated for each threshold. The first step in verifying wind direction is running the Grid-Stat and/or Point-Stat tools to verify each forecast of interest and generate the VL1L2 or MPR line(s). When running these tools, please note: @@ -203,7 +203,7 @@ In the usage statement for the Stat-Analysis tool, some additional terminology i Required arguments for stat_analysis ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -1. The **-lookin path** specifies the name of a directory to be searched recursively for STAT files (ending in “.stat”) or any explicit file name with any suffix (such as “_ctc.txt”) to be read. This option may be used multiple times to specify multiple directories and/or files to be read. If “-lookin python” is used, it must be followed by a Python embedding script and any command line arguments it takes. Python embedding can be used to pass matched pair (MPR) lines as input to Stat-Analysis. +1. The **-lookin path** specifies the name of a directory to be searched recursively for STAT files (ending in ".stat") or any explicit file name with any suffix (such as "_ctc.txt") to be read. This option may be used multiple times to specify multiple directories and/or files to be read. If "-lookin python" is used, it must be followed by a Python embedding script and any command line arguments it takes. Python embedding can be used to pass matched pair (MPR) lines as input to Stat-Analysis. 2. Either a configuration file must be specified with the **-config** option, or a **JOB COMMAND LINE** must be denoted. The **JOB COMMAND LINE** is described in :numref:`stat_analysis-configuration-file` @@ -553,9 +553,9 @@ This option specifies the desired output line type(s) for the **aggregate_stat** The Stat-Analysis tool writes its output to either the log file or the file specified using the **-out** command line option. However the **aggregate** and **aggregate_stat** jobs create STAT output lines and the standard output written lacks the full set of STAT header columns. The **-out_stat** job command option may be used for these jobs to specify the name of an output file to which full STAT output lines should be written. When the **-out_stat** job command option is used for **aggregate** and **aggregate_stat** jobs the output is sent to the **-out_stat** file instead of the log or **-out** file. -Jobs will often combine output with multiple entries in the header columns. For example, a job may aggregate output with three different values in the **VX_MASK** column, such as “mask1”, “mask2”, and “mask3”. The output **VX_MASK** column will contain the unique values encountered concatenated together with commas: “mask1,mask2,mask3”. Alternatively, the **-set_hdr** option may be used to specify what should be written to the output header columns, such as “-set_hdr VX_MASK all_three_masks”. +Jobs will often combine output with multiple entries in the header columns. For example, a job may aggregate output with three different values in the **VX_MASK** column, such as "mask1", "mask2", and "mask3". The output **VX_MASK** column will contain the unique values encountered concatenated together with commas: "mask1,mask2,mask3". Alternatively, the **-set_hdr** option may be used to specify what should be written to the output header columns, such as "-set_hdr VX_MASK all_three_masks". -When using the “-out_stat” option to create a .stat output file and stratifying results using one or more “-by” job command options, those columns may be referenced in the “-set_hdr” option. When using multiple “-by” options, use “CASE” to reference the full case information string: +When using the "-out_stat" option to create a .stat output file and stratifying results using one or more "-by" job command options, those columns may be referenced in the "-set_hdr" option. When using multiple "-by" options, use "CASE" to reference the full case information string: .. code-block:: none @@ -570,7 +570,7 @@ The example above reads MPR lines, stratifies the data by forecast variable name -mask_poly file -mask_sid file|list -When processing input MPR lines, these options may be used to define a masking grid, polyline, or list of station ID's to filter the matched pair data geographically prior to computing statistics. The **-mask_sid** option is a station ID masking file or a comma-separated list of station ID's for filtering the matched pairs spatially. See the description of the “sid” entry in :numref:`config_options`. +When processing input MPR lines, these options may be used to define a masking grid, polyline, or list of station ID's to filter the matched pair data geographically prior to computing statistics. The **-mask_sid** option is a station ID masking file or a comma-separated list of station ID's for filtering the matched pairs spatially. See the description of the "sid" entry in :numref:`config_options`. .. code-block:: none diff --git a/met/docs/Users_Guide/tc-dland.rst b/met/docs/Users_Guide/tc-dland.rst index d902be5569..163c732968 100644 --- a/met/docs/Users_Guide/tc-dland.rst +++ b/met/docs/Users_Guide/tc-dland.rst @@ -58,6 +58,6 @@ Optional arguments for tc_dland 5. The **-log file** argument outputs log messages to the specified file. -6. The **-v level** option indicates the desired level of verbosity. The contents of “level” will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. +6. The **-v level** option indicates the desired level of verbosity. The contents of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. 7. The **-compress level** option specifies the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. Setting the compression level to 0 will make no compression for the NetCDF output. Lower numbers result in minimal compression and faster I/O processing speed; higher numbers result in better compression, but at the expense of I/O processing speed. diff --git a/met/docs/Users_Guide/tc-gen.rst b/met/docs/Users_Guide/tc-gen.rst index 763c5663b4..61209566dc 100644 --- a/met/docs/Users_Guide/tc-gen.rst +++ b/met/docs/Users_Guide/tc-gen.rst @@ -6,7 +6,7 @@ TC-Gen Tool Introduction ____________ -The TC-Gen tool provides verification of tropical cyclone genesis forecasts in ATCF file format. Producing reliable tropical cyclone genesis forecasts is an important metric for global numerical weather prediction models. This tool ingests deterministic model output post-processed by a genesis tracking software (e.g. GFDL vortex tracker) and ATCF format reference dataset(s) (e.g. Best Track analysis and CARQ operational tracks) and outputs categorical counts and statistics. The capability to modify the spatial and temporal tolerances that define a “hit” forecast is included to give users the ability to condition the criteria based on model performance and/or conduct sensitivity analyses. Statistical aspects are outlined in :numref:`tc-gen_stat_aspects` and practical aspects of the TC-Gen tool are described in :numref:`tc-gen_practical_info`. +The TC-Gen tool provides verification of tropical cyclone genesis forecasts in ATCF file format. Producing reliable tropical cyclone genesis forecasts is an important metric for global numerical weather prediction models. This tool ingests deterministic model output post-processed by a genesis tracking software (e.g. GFDL vortex tracker) and ATCF format reference dataset(s) (e.g. Best Track analysis and CARQ operational tracks) and outputs categorical counts and statistics. The capability to modify the spatial and temporal tolerances that define a "hit" forecast is included to give users the ability to condition the criteria based on model performance and/or conduct sensitivity analyses. Statistical aspects are outlined in :numref:`tc-gen_stat_aspects` and practical aspects of the TC-Gen tool are described in :numref:`tc-gen_practical_info`. .. _tc-gen_stat_aspects: @@ -48,7 +48,7 @@ Required arguments for tc_gen 1. The **-genesis path** argument is the path to one or more ATCF or fort.66 (see documentation listed below) files generated by the Geophysical Fluid Dynamics Laboratory (GFDL) Vortex Tracker when run in tcgen mode or an ASCII file list or a top-level directory containing them. The **-genesis** option must be used at least once. The required file format is described in the "Output formats" section of the `GFDL Vortex Tracker users guide. `_ -2. The **-track path** argument is one or more ATCF reference track files or an ASCII file list or top-level directory containing them, with files ending in “.dat”. This tool processes either Best track data from bdeck files, or operational track data (e.g. CARQ) from adeck files, or both. Providing both bdeck and adeck files will result in a richer dataset to match with the **-genesis** files. Both adeck and bdeck data should be provided using the **-track** option. The **-track** option must be used at least once. +2. The **-track path** argument is one or more ATCF reference track files or an ASCII file list or top-level directory containing them, with files ending in ".dat". This tool processes either Best track data from bdeck files, or operational track data (e.g. CARQ) from adeck files, or both. Providing both bdeck and adeck files will result in a richer dataset to match with the **-genesis** files. Both adeck and bdeck data should be provided using the **-track** option. The **-track** option must be used at least once. 3. The **-config** file argument indicates the name of the configuration file to be used. The contents of the configuration file are discussed below. @@ -59,7 +59,7 @@ Optional arguments for tc_gen 5. The **-log file** option directs output and errors to the specified log file. All messages will be written to that file as well as standard out and error. Thus, users can save the messages without having to redirect the output on the command line. The default behavior is no log file. -6. The **-v level** option indicates the desired level of verbosity. The contents of “level” will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. +6. The **-v level** option indicates the desired level of verbosity. The contents of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. The TC-Gen tool implements the following logic: diff --git a/met/docs/Users_Guide/tc-pairs.rst b/met/docs/Users_Guide/tc-pairs.rst index de8ff0f957..f2ce129846 100644 --- a/met/docs/Users_Guide/tc-pairs.rst +++ b/met/docs/Users_Guide/tc-pairs.rst @@ -35,11 +35,11 @@ tc_pairs has required arguments and can accept several optional arguments. Required arguments for tc_pairs ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -1. The **-adeck source** argument indicates the adeck TC-Pairs acceptable format data source containing tropical cyclone model forecast (output from tracker) data to be verified. Acceptable data formats are limited to the standard ATCF format and the one column modified ATCF file, generated by running the tracker in genesis mode. It specifies the name of a TC-Pairs acceptable format file or top-level directory containing TC-Pairs acceptable format files ending in “.dat” to be processed. The **-adeck** or **-edeck** option must be used at least once. +1. The **-adeck source** argument indicates the adeck TC-Pairs acceptable format data source containing tropical cyclone model forecast (output from tracker) data to be verified. Acceptable data formats are limited to the standard ATCF format and the one column modified ATCF file, generated by running the tracker in genesis mode. It specifies the name of a TC-Pairs acceptable format file or top-level directory containing TC-Pairs acceptable format files ending in ".dat" to be processed. The **-adeck** or **-edeck** option must be used at least once. -2. The **-edeck source** argument indicates the edeck ATCF format data source containing probabilistic track data to be verified. It specifies the name of an ATCF format file or top-level directory containing ATCF format files ending in “.dat” to be processed. The **-adeck** or **-edeck** option must be used at least once. +2. The **-edeck source** argument indicates the edeck ATCF format data source containing probabilistic track data to be verified. It specifies the name of an ATCF format file or top-level directory containing ATCF format files ending in ".dat" to be processed. The **-adeck** or **-edeck** option must be used at least once. -3. The **-bdeck source** argument indicates the TC-Pairs acceptable format data source containing the tropical cyclone reference dataset to be used for verifying the adeck source. This source is typically the NHC Best Track Analysis, but could be any TC-Pairs acceptable formatted reference. The acceptable data formats for bdecks are the same as those for adecks. This argument specifies the name of a TC-Pairs acceptable format file or top-level directory containing TC-Pairs acceptable format files ending in “.dat” to be processed. +3. The **-bdeck source** argument indicates the TC-Pairs acceptable format data source containing the tropical cyclone reference dataset to be used for verifying the adeck source. This source is typically the NHC Best Track Analysis, but could be any TC-Pairs acceptable formatted reference. The acceptable data formats for bdecks are the same as those for adecks. This argument specifies the name of a TC-Pairs acceptable format file or top-level directory containing TC-Pairs acceptable format files ending in ".dat" to be processed. 4. The **-config file** argument indicates the name of the configuration file to be used. The contents of the configuration file are discussed below. @@ -50,7 +50,7 @@ Optional arguments for tc_pairs 6. The **-log file** option directs output and errors to the specified log file. All messages will be written to that file as well as standard out and error. Thus, users can save the messages without having to redirect the output on the command line. The default behavior is no log file. -7. The **-v level** option indicates the desired level of verbosity. The contents of “level” will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. +7. The **-v level** option indicates the desired level of verbosity. The contents of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. This tool currently only supports the rapid intensification (**RI**) edeck probability type but support for additional edeck probability types will be added in future releases. At least one **-adeck** or **-edeck** option must be specified. The **-adeck, -edeck**, and **-bdeck** options may optionally be followed with **suffix=string** to append that string to all model names found within that data source. This option may be useful when processing track data from two different sources which reuse the same model names. @@ -151,7 +151,7 @@ ____________________ .. code-block:: none - lag_time = [ “06”, “12” ]; + lag_time = [ "06", "12" ]; The **lag_time** field is a comma-separated list of forecast lag times to be used in HH[MMSS] format. For each adeck track identified, a lagged track will be derived for each entry. In the tc_pairs output, the original adeck record will be retained, with the lagged entry listed as the adeck name with "_LAG_HH" appended. diff --git a/met/docs/Users_Guide/tc-rmw.rst b/met/docs/Users_Guide/tc-rmw.rst index efe5273c84..852973b0f1 100644 --- a/met/docs/Users_Guide/tc-rmw.rst +++ b/met/docs/Users_Guide/tc-rmw.rst @@ -44,7 +44,7 @@ Optional arguments for tc_rmw 5. The **-log file** option directs output and errors to the specified log file. All messages will be written to that file as well as standard out and error. Thus, users can save the messages without having to redirect the output on the command line. The default behavior is no logfile. -6. The **-v level** option indicates the desired level of verbosity. The contents of “level” will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. +6. The **-v level** option indicates the desired level of verbosity. The contents of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. tc_rmw configuration file ~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/met/docs/Users_Guide/tc-stat.rst b/met/docs/Users_Guide/tc-stat.rst index c66a6f6894..ee774eee0d 100644 --- a/met/docs/Users_Guide/tc-stat.rst +++ b/met/docs/Users_Guide/tc-stat.rst @@ -104,7 +104,7 @@ Optional arguments for tc_stat 4. The **-log file** option directs output and errors to the specified log file. All messages will be written to that file as well as standard out and error. Thus, users can save the messages without having to redirect the output on the command line. The default behavior is no log file. -5. The **-v level** option indicates the desired level of verbosity. The contents of “level” will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. +5. The **-v level** option indicates the desired level of verbosity. The contents of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity above 1 will increase the amount of logging. 6. The **-config file** argument indicates the name of the configuration file to be used. The contents of the configuration file are discussed below. @@ -396,13 +396,13 @@ This job produces summary statistics for the column name specified by the **-col "COL_NAME", followed by the summary statistics that are applied; 3. -“SUMMARY”, which is followed by the total, mean (with confidence intervals), standard deviation, minimum value, percentiles (10th, 25th, 50th, 75th, 90th), maximum value, interquartile range, range, sum, time to independence, and frequency of superior performance. +"SUMMARY", which is followed by the total, mean (with confidence intervals), standard deviation, minimum value, percentiles (10th, 25th, 50th, 75th, 90th), maximum value, interquartile range, range, sum, time to independence, and frequency of superior performance. The output columns are shown below in :numref:`table_columnar_output_summary_tc_stat` The **-by** option can also be used one or more times to make this job more powerful. Rather than running the specified job once, it will be run once for each unique combination of the entries found in the column(s) specified with the **-by** option. .. _table_columnar_output_summary_tc_stat: -.. list-table:: Columnar output of “summary” job output from the TC-Stat tool. +.. list-table:: Columnar output of "summary" job output from the TC-Stat tool. :widths: auto :header-rows: 2 diff --git a/met/docs/Users_Guide/wavelet-stat.rst b/met/docs/Users_Guide/wavelet-stat.rst index 19db97d1ed..e449a513e3 100644 --- a/met/docs/Users_Guide/wavelet-stat.rst +++ b/met/docs/Users_Guide/wavelet-stat.rst @@ -32,7 +32,7 @@ The Intensity Scale approach can be summarized in the following 5 steps: 1. For each threshold, the forecast and observation fields are transformed into binary fields: where the grid-point precipitation value meets the threshold criteria it is assigned 1, where the threshold criteria are not met it is assigned 0. This can also be done with no thresholds indicated at all and in that case the grid-point values are not transformed to binary fields and instead the raw data is used as is for statistics. :numref:`wavelet-stat_NIMROD_3h_fcst` illustrates an example of a forecast and observation fields, and their corresponding binary fields for a threshold of 1mm/h. This case shows an intense storm of the scale of 160 km displaced almost its entire length. The displacement error is clearly visible from the binary field difference and the contingency table image obtained for the same threshold :numref:`contingency_table_counts`. -2. The binary forecast and observation fields obtained from the thresholding are then decomposed into the sum of components on different scales, by using a 2D Haar wavelet filter (:numref:`wavelet-stat_NIMROD_diff`). Note that the scale components are fields, and their sum adds up to the original binary field. For a forecast defined over square domain of **2ⁿ x 2ⁿ** grid-points, the scale components are **n+1: n** mother wavelet components + the largest father wavelet (or scale-function) component. The **n** mother wavelet components have resolution equal to **1, 2, 4, ...** :math:`\mathbf{2^{n-1}}` grid-points. The largest father wavelet component is a constant field over the **2ⁿ x 2ⁿ** grid-point domain with value equal to the field mean. +2. The binary forecast and observation fields obtained from the thresholding are then decomposed into the sum of components on different scales, by using a 2D Haar wavelet filter (:numref:`wavelet-stat_NIMROD_diff`). Note that the scale components are fields, and their sum adds up to the original binary field. For a forecast defined over square domain of :math:`\mathbf{2^n} **x** :math:`\mathbf{2^n} grid-points, the scale components are **n+1: n** mother wavelet components + the largest father wavelet (or scale-function) component. The **n** mother wavelet components have resolution equal to **1, 2, 4, ...** :math:`\mathbf{2^{n-1}}` grid-points. The largest father wavelet component is a constant field over the :math:`\mathbf{2^n} **x** :math:`\mathbf{2^n} grid-point domain with value equal to the field mean. **Note** that the wavelet transform is a linear operator: this implies that the difference of the spatial scale components of the binary forecast and observation fields (:numref:`wavelet-stat_NIMROD_diff`) are equal to the spatial scale components of the difference of the binary forecast and observation fields (:numref:`wavelet-stat_NIMROD_binary_fcst_and_obs`), and these scale components also add up to the original binary field difference (:numref:`wavelet-stat_NIMROD_3h_fcst`). The intensity-scale technique considers thus the spatial scale of the error. For the case illustrated (:numref:`wavelet-stat_NIMROD_3h_fcst` and :numref:`wavelet-stat_NIMROD_binary_fcst_and_obs`) note the large error associated at the scale of 160 km, due the storm, 160km displaced almost its entire length. @@ -59,14 +59,14 @@ The Intensity-Scale (IS) skill score evaluates the forecast skill as a function - - Total * - - - o = 1 (e.g., “Yes”) - - o = 0 (e.g., “No”) + - o = 1 (e.g., "Yes") + - o = 0 (e.g., "No") - - * - f = 1 (e.g., “Yes”) + * - f = 1 (e.g., "Yes") - Hits **= a** - False Alarms **= b** - **a+b** - * - f = 0 (e.g., “No”) + * - f = 0 (e.g., "No") - Misses **= c** - Correct rejections **= d** - **c+d** @@ -128,18 +128,18 @@ Note that the energy squared of the observation binary field is identical to the The spatial domain constraints ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The Intensity-Scale technique is constrained by the fact that orthogonal wavelets (discrete wavelet transforms) are usually performed dyadic domains, square domains of **2ⁿ x 2ⁿ** grid-points. The Wavelet-Stat tool handles this issue based on settings in the configuration file by defining tiles of dimensions **2ⁿ x 2ⁿ** over the input domain in the following ways: +The Intensity-Scale technique is constrained by the fact that orthogonal wavelets (discrete wavelet transforms) are usually performed dyadic domains, square domains of :math:`\mathbf{2^n} **x** :math:`\mathbf{2^n} grid-points. The Wavelet-Stat tool handles this issue based on settings in the configuration file by defining tiles of dimensions :math:`\mathbf{2^n} **x** :math:`\mathbf{2^n} over the input domain in the following ways: -1. User-Defined Tiling: The user may define one or more tiles of size **2ⁿ x 2ⁿ** over their domain to be applied. This is done by selecting the grid coordinates for the lower-left corner of the tile(s) and the tile dimension to be used. If the user specifies more than one tile, the Intensity-Scale method will be applied to each tile separately. At the end, the results will automatically be aggregated across all the tiles and written out with the results for each of the individual tiles. Users are encouraged to select tiles which consist entirely of valid data. +1. User-Defined Tiling: The user may define one or more tiles of size :math:`\mathbf{2^n} **x** :math:`\mathbf{2^n} over their domain to be applied. This is done by selecting the grid coordinates for the lower-left corner of the tile(s) and the tile dimension to be used. If the user specifies more than one tile, the Intensity-Scale method will be applied to each tile separately. At the end, the results will automatically be aggregated across all the tiles and written out with the results for each of the individual tiles. Users are encouraged to select tiles which consist entirely of valid data. -2. Automated Tiling: This tiling method is essentially the same as the user-defined tiling method listed above except that the tool automatically selects the location and size of the tile(s) to be applied. It figures out the maximum tile of dimension **2ⁿ x 2ⁿ** that fits within the domain and places the tile at the center of the domain. For domains that are very elongated in one direction, it defines as many of these tiles as possible that fit within the domain. +2. Automated Tiling: This tiling method is essentially the same as the user-defined tiling method listed above except that the tool automatically selects the location and size of the tile(s) to be applied. It figures out the maximum tile of dimension :math:`\mathbf{2^n} **x** :math:`\mathbf{2^n} that fits within the domain and places the tile at the center of the domain. For domains that are very elongated in one direction, it defines as many of these tiles as possible that fit within the domain. -3. Padding: If the domain size is only slightly smaller than **2ⁿ x 2ⁿ**, for certain variables (e.g. precipitation), it is advisable to expand the domain out to **2ⁿ x 2ⁿ** grid-points by adding extra rows and/or columns of fill data. For precipitation variables, a fill value of zero is used. For continuous variables, such as temperature, the fill value is defined as the mean of the valid data in the rest of the field. A drawback to the padding method is the introduction of artificial data into the original field. Padding should only be used when a very small number of rows and/or columns need to be added. +3. Padding: If the domain size is only slightly smaller than :math:`\mathbf{2^n} **x** :math:`\mathbf{2^n}, for certain variables (e.g. precipitation), it is advisable to expand the domain out to :math:`\mathbf{2^n} **x** :math:`\mathbf{2^n} grid-points by adding extra rows and/or columns of fill data. For precipitation variables, a fill value of zero is used. For continuous variables, such as temperature, the fill value is defined as the mean of the valid data in the rest of the field. A drawback to the padding method is the introduction of artificial data into the original field. Padding should only be used when a very small number of rows and/or columns need to be added. Aggregation of statistics on multiple cases ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The Stat-Analysis tool aggregates the intensity scale technique results. Since the results are scale-dependent, it is sensible to aggregate results from multiple model runs (e.g. daily runs for a season) on the same spatial domain, so that the scale components for each singular case will be the same number, and the domain, if not a square domain of **2ⁿ x 2ⁿ** grid-points, will be treated in the same fashion. Similarly, the intensity thresholds for each run should all be the same. +The Stat-Analysis tool aggregates the intensity scale technique results. Since the results are scale-dependent, it is sensible to aggregate results from multiple model runs (e.g. daily runs for a season) on the same spatial domain, so that the scale components for each singular case will be the same number, and the domain, if not a square domain of :math:`\mathbf{2^n} **x** :math:`\mathbf{2^n} grid-points, will be treated in the same fashion. Similarly, the intensity thresholds for each run should all be the same. The MSE and forecast and observation squared energy for each scale and thresholds are aggregated simply with a weighted average, where weights are proportional to the number of grid-points used in each single run to evaluate the statistics. If the same domain is always used (and it should) the weights result all the same, and the weighted averaging is a simple mean. For each threshold, the aggregated Br is equal to the aggregated squared energy of the binary observation field, and the aggregated FBI is obtained as the ratio of the aggregated squared energies of the forecast and observation binary fields. From aggregated Br and FBI, the MSErandom for the aggregated runs can be evaluated using the same formula as for the single run. Finally, the Intensity-Scale Skill Score is evaluated by using the aggregated statistics within the same formula used for the single case. @@ -182,9 +182,9 @@ Optional arguments for wavelet_stat 5. The **-log file** option directs output and errors to the specified log file. All messages will be written to that file as well as standard out and error. Thus, users can save the messages without having to redirect the output on the command line. The default behavior is no log file. -6. The **-v level** option indicates the desired level of verbosity. The contents of “level” will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity will increase the amount of logging. +6. The **-v level** option indicates the desired level of verbosity. The contents of "level" will override the default setting of 2. Setting the verbosity to 0 will make the tool run with no log messages, while increasing the verbosity will increase the amount of logging. -7. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of “level” will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. +7. The **-compress level** option indicates the desired level of compression (deflate level) for NetCDF variables. The valid level is between 0 and 9. The value of "level" will override the default setting of 0 from the configuration file or the environment variable MET_NC_COMPRESS. Setting the compression level to 0 will make no compression for the NetCDF output. Lower number is for fast compression and higher number is for better compression. An example of the wavelet_stat calling sequence is listed below: @@ -217,7 +217,7 @@ _______________________ mask_missing_flag = NONE; met_data_dir = "MET_BASE"; ps_plot_flag = TRUE; - fcst_raw_plot = { color_table = "MET_BASE/colortables/met_default.ctable”; + fcst_raw_plot = { color_table = "MET_BASE/colortables/met_default.ctable"; plot_min = 0.0; plot_max = 0.0; } obs_raw_plot = { ... } wvlt_plot = { ... } @@ -260,7 +260,7 @@ The **grid_decomp_flag** variable specifies how tiling should be performed: • **TILE** indicates that the user-defined tiles should be applied. -• **PAD** indicated that the data should be padded out to the nearest dimension of **2ⁿ x 2ⁿ** +• **PAD** indicated that the data should be padded out to the nearest dimension of :math:`\mathbf{2^n} **x** :math:`\mathbf{2^n} The **width** and **location** variables allow users to manually define the tiles of dimension they would like to apply. The x_ll and y_ll variables specify the location of one or more lower-left tile grid (x, y) points. @@ -477,11 +477,11 @@ The dimensions and variables included in the wavelet_stat NetCDF files are descr * - NetCDF Dimension - Description * - x - - Dimension of the tile which equals **2ⁿ** + - Dimension of the tile which equals :math:`\mathbf{2^n}` * - y - - Dimension of the tile which equals **2ⁿ** + - Dimension of the tile which equals :math:`\mathbf{2^n}` * - scale - - Dimension for the number of scales. This is set to **n+2**, where **2ⁿ** is the tile dimension. The 2 extra scales are for the binary image and the wavelet averaged over the whole tile. + - Dimension for the number of scales. This is set to **n+2**, where :math:`\mathbf{2^n}` is the tile dimension. The 2 extra scales are for the binary image and the wavelet averaged over the whole tile. * - tile - Dimension for the number of tiles used @@ -499,19 +499,19 @@ The dimensions and variables included in the wavelet_stat NetCDF files are descr - Description * - FCST_FIELD_LEVEL_RAW - tile, x, y - - Raw values for the forecast field specified by “FIELD_LEVEL” + - Raw values for the forecast field specified by "FIELD_LEVEL" * - OBS_FIELD_LEVEL_RAW - tile, x, y - - Raw values for the observation field specified by “FIELD_LEVEL” + - Raw values for the observation field specified by "FIELD_LEVEL" * - DIFF_FIELD_LEVEL_RAW - tile, x, y - - Raw values for the difference field (**f-o**) specified by “FIELD_LEVEL” + - Raw values for the difference field (**f-o**) specified by "FIELD_LEVEL" * - FCST_FIELD_LEVEL_THRESH - tile, scale, x, y - - Wavelet scale-decomposition of the forecast field specified by “FIELD_LEVEL_THRESH” + - Wavelet scale-decomposition of the forecast field specified by "FIELD_LEVEL_THRESH" * - OBS_FIELD_LEVEL_THRESH - tile, scale, x, y - - Wavelet scale-decomposition of the observation field specified by “FIELD_LEVEL_THRESH” + - Wavelet scale-decomposition of the observation field specified by "FIELD_LEVEL_THRESH" Lastly, the **Wavelet-Stat** tool creates a PostScript plot summarizing the scale-decomposition approach used in the verification. The PostScript plot is generated using internal libraries and does not depend on an external plotting package. The generation of this PostScript output can be disabled using the **ps_plot_flag** configuration file option. diff --git a/met/docs/conf.py b/met/docs/conf.py index 61d78fba23..16bb9bcd99 100644 --- a/met/docs/conf.py +++ b/met/docs/conf.py @@ -20,11 +20,11 @@ project = 'MET' author = 'UCAR/NCAR, NOAA, CSU/CIRA, and CU/CIRES' author_list = 'Halley Gotway, J., K. Newman, H. Soh, J. Opatz, T. Jensen, J. Prestopnik, L. Goodrich, D. Fillmore, B. Brown, R. Bullock, T. Fowler' -version = '10.1.0-beta1' +version = '10.1.0-beta2' verinfo = version release = f'{version}' release_year = '2021' -release_date = f'{release_year}-06-13' +release_date = f'{release_year}-07-20' copyright = f'{release_year}, {author}' # -- General configuration --------------------------------------------------- @@ -34,6 +34,57 @@ # ones. extensions = ['sphinx.ext.autodoc','sphinx.ext.intersphinx'] +# settings for ReadTheDocs PDF creation +latex_engine = 'pdflatex' +latex_theme = 'manual' +latex_logo = os.path.join('_static','met_logo_2019_09.png') +latex_show_pagerefs = True +latex_master_doc = 'Users_Guide/index' + +latex_elements = { + # The paper size ('letterpaper' or 'a4paper'). + # + 'papersize': 'letterpaper', + 'releasename':"{version}", + 'fncychap': '\\usepackage{fncychap}', + 'fontpkg': '\\usepackage{amsmath,amsfonts,amssymb,amsthm}', + 'inputenc': '\\usepackage[utf8]{inputenc}', + 'fontenc': '\\usepackage[LGR,T1]{fontenc}', + + 'figure_align':'htbp', + 'pointsize': '11pt', + + 'preamble': r''' + \usepackage{charter} + \usepackage[defaultsans]{lato} + \usepackage{inconsolata} + \setcounter{secnumdepth}{4} + \setcounter{tocdepth}{4} + ''', + + 'sphinxsetup': \ + 'hmargin={0.7in,0.7in}, vmargin={1in,1in}, \ + verbatimwithframe=true, \ + TitleColor={rgb}{0,0,0}, \ + HeaderFamily=\\rmfamily\\bfseries, \ + InnerLinkColor={rgb}{0,0,1}, \ + OuterLinkColor={rgb}{0,0,1}', + 'maketitle': '\\sphinxmaketitle', +# 'tableofcontents': ' ', + 'printindex': ' ' +} + +# Grouping the document tree into LaTeX files. List of tuples +# (source start file, target name, title, +# author, documentclass [howto, manual, or own class]). +latex_documents = [ + (latex_master_doc, + 'users_guide.tex', + 'MET User\'s Guide', + ' ', + 'manual') +] + # Add any paths that contain templates here, relative to this directory. templates_path = ['_templates'] diff --git a/met/src/basic/vx_util/stat_column_defs.h b/met/src/basic/vx_util/stat_column_defs.h index d34fa22fdd..02f5648ede 100644 --- a/met/src/basic/vx_util/stat_column_defs.h +++ b/met/src/basic/vx_util/stat_column_defs.h @@ -103,7 +103,8 @@ static const char * cnt_columns [] = { "MSESS", "MSESS_BCL", "MSESS_BCU", "RMSFA", "RMSFA_BCL", "RMSFA_BCU", "RMSOA", "RMSOA_BCL", "RMSOA_BCU", - "ANOM_CORR_UNCNTR", "ANOM_CORR_UNCNTR_BCL", "ANOM_CORR_UNCNTR_BCU" + "ANOM_CORR_UNCNTR", "ANOM_CORR_UNCNTR_BCL", "ANOM_CORR_UNCNTR_BCU", + "SI", "SI_BCL", "SI_BCL" }; static const char * sl1l2_columns [] = { diff --git a/met/src/libcode/vx_nc_util/nc_utils.cc b/met/src/libcode/vx_nc_util/nc_utils.cc index eb066df60a..14c473702c 100644 --- a/met/src/libcode/vx_nc_util/nc_utils.cc +++ b/met/src/libcode/vx_nc_util/nc_utils.cc @@ -1030,7 +1030,7 @@ char get_char_val(NcVar *var, const int index) { //////////////////////////////////////////////////////////////////////// ConcatString* get_string_val(NcFile * nc, const char * var_name, const int index, - const int len, ConcatString &tmp_cs) { + const int len, ConcatString &tmp_cs) { NcVar var = get_var(nc, var_name); return (get_string_val(&var, index, len, tmp_cs)); @@ -1039,10 +1039,29 @@ ConcatString* get_string_val(NcFile * nc, const char * var_name, const int index //////////////////////////////////////////////////////////////////////// ConcatString* get_string_val(NcVar *var, const int index, - const int len, ConcatString &tmp_cs) { + const int len, ConcatString &tmp_cs) { char tmp_str[len]; std::vector start; std::vector count; + const char *method_name = "get_string_val() "; + + if (2 != get_dim_count(var)) { + mlog << Error << "\n" << method_name << GET_NC_NAME_P(var) + << " is not a two dimensional variablle. start offset and count: (" + << index << ", " << len << ").\n\n"; + exit(1); + } + else { + int dim_size1 = get_dim_size(var, 0); + int dim_size2 = get_dim_size(var, 1); + if ((index > dim_size1) || (len > dim_size2)) { + mlog << Error << "\n" << method_name << "The start offset and count (" + << index << ", " << len << ") exceeds the dimension size (" + << dim_size1 << ", " << dim_size2 << ") for the variable " + << GET_NC_NAME_P(var) << ".\n\n"; + exit(1); + } + } // // Retrieve the character array value from the NetCDF variable. @@ -1074,9 +1093,29 @@ int get_int_var(NcVar * var, const int index) { int k; std::vector start; std::vector count; + const char *method_name = "get_int_var() "; k = bad_data_int; if (IS_VALID_NC_P(var)) { + int dim_idx = 0; + int dim_size = get_dim_size(var, dim_idx); + if (0 >= dim_size) { + if ((index > 0) && (0 >= dim_size)) { + mlog << Error << "\n" << method_name << "The start offset (" + << index << ") should be 0 because of no dimension at the variable " + << GET_NC_NAME_P(var) << ".\n\n"; + exit(1); + } + } + else if (index > dim_size) { + NcDim nc_dim = get_nc_dim(var, dim_idx); + mlog << Error << "\n" << method_name << "The start offset (" + << index << ") exceeds the dimension " << dim_size << " " + << (IS_VALID_NC(nc_dim) ? GET_NC_NAME(nc_dim) : " ") + << " for the variable " << GET_NC_NAME_P(var) << ".\n\n"; + exit(1); + } + start.push_back(index); count.push_back(1); var->getVar(start, count, &k); @@ -1095,6 +1134,25 @@ double get_nc_time(NcVar * var, const int index) { k = bad_data_double; if (IS_VALID_NC_P(var)) { + int dim_idx = 0; + int dim_size = get_dim_size(var, dim_idx); + if (0 >= dim_size) { + if (index > 0) { + mlog << Error << "\n" << method_name << "The start offset (" + << index << ") should be 0 because of no dimension at the variable " + << GET_NC_NAME_P(var) << ".\n\n"; + exit(1); + } + } + else if (index > dim_size) { + NcDim nc_dim = get_nc_dim(var, dim_idx); + mlog << Error << "\n" << method_name << "The start offset (" + << index << ") exceeds the dimension " << dim_size << " " + << (IS_VALID_NC(nc_dim) ? GET_NC_NAME(nc_dim) : " ") + << " for the variable " << GET_NC_NAME_P(var) << ".\n\n"; + exit(1); + } + start.push_back(index); count.push_back(1); @@ -1160,9 +1218,29 @@ float get_float_var(NcVar * var, const int index) { float k; std::vector start; std::vector count; + const char *method_name = "get_float_var() -> "; k = bad_data_float; if (IS_VALID_NC_P(var)) { + int dim_idx = 0; + int dim_size = get_dim_size(var, dim_idx); + if (0 >= dim_size) { + if (index > 0) { + mlog << Error << "\n" << method_name << "The start offset (" + << index << ") should be 0 because of no dimension at the variable " + << GET_NC_NAME_P(var) << ".\n\n"; + exit(1); + } + } + else if ((index > dim_size) && (0 < dim_size)){ + NcDim nc_dim = get_nc_dim(var, dim_idx); + mlog << Error << "\n" << method_name << "The start offset (" + << index << ") exceeds the dimension " << dim_size << " " + << (IS_VALID_NC(nc_dim) ? GET_NC_NAME(nc_dim) : " ") + << " for the variable " << GET_NC_NAME_P(var) << ".\n\n"; + exit(1); + } + start.push_back(index); count.push_back(1); var->getVar(start, count, &k); @@ -1228,6 +1306,7 @@ bool get_nc_data(NcVar *var, int *data) { template bool _get_nc_data(NcVar *var, T *data, T bad_data, const long *curs) { bool return_status = false; + const char *method_name = "_get_nc_data(const long *curs) "; if (IS_VALID_NC_P(var)) { std::vector start; @@ -1235,6 +1314,15 @@ bool _get_nc_data(NcVar *var, T *data, T bad_data, const long *curs) { const int dimC = get_dim_count(var); for (int idx = 0 ; idx < dimC; idx++) { + int dim_size = get_dim_size(var, idx); + if ((curs[idx] > dim_size) && (0 < dim_size)) { + NcDim nc_dim = get_nc_dim(var, idx); + mlog << Error << "\n" << method_name << "The start offset (" + << curs[idx] << ") exceeds the dimension[" << idx << "] " << dim_size << " " + << (IS_VALID_NC(nc_dim) ? GET_NC_NAME(nc_dim) : " ") + << " for the variable " << GET_NC_NAME_P(var) << ".\n\n"; + exit(1); + } start.push_back((size_t)curs[idx]); count.push_back((size_t)1); } @@ -1265,12 +1353,31 @@ bool get_nc_data(NcVar *var, int *data, const long *curs) { template bool _get_nc_data(NcVar *var, T *data, T bad_data, const long dim, const long cur) { bool return_status = false; + const char *method_name = "_get_nc_data(const long dim, const long cur) "; if (IS_VALID_NC_P(var)) { + int dim_idx = 0; std::vector start; std::vector count; start.push_back((size_t)cur); count.push_back((size_t)dim); + int dim_size = get_dim_size(var, dim_idx); + if (0 >= dim_size) { + if ((cur > 0) || (dim > 1)) { + mlog << Error << "\n" << method_name << "The start offset and count (" + << cur << ", " << dim << ") should be (0, 1) because of no dimension at the variable " + << GET_NC_NAME_P(var) << ".\n\n"; + exit(1); + } + } + else if (((cur+dim) > dim_size) && (0 < dim_size)) { + NcDim nc_dim = get_nc_dim(var, dim_idx); + mlog << Error << "\n" << method_name << "The start offset and count (" + << cur << " + " << dim << ") exceeds the dimension " << dim_size << " " + << (IS_VALID_NC(nc_dim) ? GET_NC_NAME(nc_dim) : " ") + << " for the variable " << GET_NC_NAME_P(var) << ".\n\n"; + exit(1); + } for (int idx1=0; idx1 start; - std::vector count; - start.push_back((size_t)cur); - count.push_back((size_t)dim); - - for (int idx1=0; idx1getVar(start, count, data); - return_status = true; - } - return(return_status); + return(_get_nc_data(var, data, bad_data_int, dim, cur)); } //////////////////////////////////////////////////////////////////////// @@ -1316,6 +1404,7 @@ bool get_nc_data(NcVar *var, int *data, const long dim, const long cur) { template bool _get_nc_data(NcVar *var, T *data, T bad_data, const long *dims, const long *curs) { bool return_status = false; + const char *method_name = "_get_nc_data(const long *dims, const long *curs) "; if (IS_VALID_NC_P(var)) { std::vector start; @@ -1324,6 +1413,17 @@ bool _get_nc_data(NcVar *var, T *data, T bad_data, const long *dims, const long int data_size = 1; int dimC = get_dim_count(var); for (int idx = 0 ; idx < dimC; idx++) { + int dim_size = get_dim_size(var, idx); + if ((curs[idx]+dims[idx]) > dim_size) { + NcDim nc_dim = get_nc_dim(var, idx); + mlog << Error << "\n" << method_name << "The start offset and count (" + << curs[idx] << ", " << dims[idx] << ") exceeds the dimension[" + << idx << "] " << dim_size << " " + << (IS_VALID_NC(nc_dim) ? GET_NC_NAME(nc_dim) : " ") + << " for the variable " << GET_NC_NAME_P(var) << ".\n\n"; + exit(1); + } + start.push_back((size_t)curs[idx]); count.push_back((size_t)dims[idx]); data_size *= dims[idx]; diff --git a/met/src/libcode/vx_stat_out/stat_columns.cc b/met/src/libcode/vx_stat_out/stat_columns.cc index e385cfcfc7..b38c2e2992 100644 --- a/met/src/libcode/vx_stat_out/stat_columns.cc +++ b/met/src/libcode/vx_stat_out/stat_columns.cc @@ -2341,7 +2341,8 @@ void write_cnt_cols(const CNTInfo &cnt_info, int i, // MSESS, MSESS_BCL, MSESS_BCU, // RMSFA, RMSFA_BCL, RMSFA_BCU, // RMSOA, RMSOA_BCL, RMSOA_BCU, - // ANOM_CORR_UNCNTR, ANOM_CORR_UNCNTR_BCL, ANOM_CORR_UNCNTR_BCU + // ANOM_CORR_UNCNTR, ANOM_CORR_UNCNTR_BCL, ANOM_CORR_UNCNTR_BCU, + // SI, SI_BCL, SI_BCU // at.set_entry(r, c+0, // Total Number of Grid Points @@ -2635,6 +2636,15 @@ void write_cnt_cols(const CNTInfo &cnt_info, int i, at.set_entry(r, c+96, // Anomaly Correlation Uncentered BCU cnt_info.anom_corr_uncntr.v_bcu[i]); + at.set_entry(r, c+97, // Scatter Index + cnt_info.si.v); + + at.set_entry(r, c+98, // Scatter Index BCL + cnt_info.si.v_bcl[i]); + + at.set_entry(r, c+99, // Scatter Index BCU + cnt_info.si.v_bcu[i]); + return; } diff --git a/met/src/libcode/vx_statistics/compute_ci.cc b/met/src/libcode/vx_statistics/compute_ci.cc index dc58de48cf..c3dcd1ee7f 100644 --- a/met/src/libcode/vx_statistics/compute_ci.cc +++ b/met/src/libcode/vx_statistics/compute_ci.cc @@ -1265,6 +1265,18 @@ void compute_cnt_stats_ci_bca(const gsl_rng *rng_ptr, cnt_info.rmse.v_bcl[i], cnt_info.rmse.v_bcu[i]); + // + // Compute bootstrap interval for si + // + s = cnt_info.si.v; + read_ldf(cnt_i_file, c, si_na); + read_ldf(cnt_r_file, c++, sr_na); + for(i=0; i obs_vector; static vector< ConcatString > md_files; @@ -867,9 +866,9 @@ void process_madis_metar(NcFile *&f_in) { // Arrays of longs for indexing into NetCDF variables // long *cur = new long [2]; - long *dim = new long [1]; + long *dim = new long [2]; cur[0] = cur[1] = 0; - dim[0] = 1; + dim[0] = dim[1] = 1; int hdr_idx = 0; processed_count = 0; @@ -878,7 +877,6 @@ void process_madis_metar(NcFile *&f_in) { // Loop through each record and get the header data. // for(i_hdr_s=rec_beg; i_hdr_s BUFFER_SIZE) ? BUFFER_SIZE: (my_rec_end - i_hdr_s); dim[0] = buf_size; cur[0] = i_hdr_s; @@ -921,9 +919,6 @@ void process_madis_metar(NcFile *&f_in) { char hdr_typ_arr[buf_size][hdr_typ_len]; char hdr_sid_arr[buf_size][hdr_sid_len]; - nc_buf_size = buf_size * FIELD_COUNT; - if (nc_buf_size > BUFFER_SIZE) nc_buf_size = BUFFER_SIZE; - get_nc_data(&in_hdr_vld_var, &tmp_dbl_arr[0], buf_size, i_hdr_s); get_nc_data(&in_hdr_lat_var, &hdr_lat_arr[0], buf_size, i_hdr_s); get_nc_data(&in_hdr_lon_var, &hdr_lon_arr[0], buf_size, i_hdr_s); @@ -973,11 +968,11 @@ void process_madis_metar(NcFile *&f_in) { get_filtered_nc_data(precip24Hour_var, precip24Hour, buf_size, i_hdr_s, "precip24Hour" ); get_filtered_nc_data(snowCover_var, snowCover, buf_size, i_hdr_s, "snowCover" ); - dim2D[0] = buf_size; - dim2D[1] = hdr_typ_len; - get_nc_data(&in_hdr_typ_var, (char *)&hdr_typ_arr[0], dim2D, cur); - dim2D[1] = hdr_sid_len; - get_nc_data(&in_hdr_sid_var, (char *)&hdr_sid_arr[0], dim2D, cur); + dim[0] = buf_size; + dim[1] = hdr_typ_len; + get_nc_data(&in_hdr_typ_var, (char *)&hdr_typ_arr[0], dim, cur); + dim[1] = hdr_sid_len; + get_nc_data(&in_hdr_sid_var, (char *)&hdr_sid_arr[0], dim, cur); for (i_idx=0; i_idx BUFFER_SIZE) ? BUFFER_SIZE: (my_rec_end - i_hdr_s); int nlvl_manLevel[buf_size]; @@ -1443,9 +1436,6 @@ void process_madis_raob(NcFile *&f_in) { //char *hdr_typ_arr_ptr = &hdr_typ_arr[0]; //char *hdr_sid_arr_ptr = &hdr_sid_arr[0]; - nc_buf_size = buf_size * FIELD_COUNT; - if (nc_buf_size > BUFFER_SIZE) nc_buf_size = BUFFER_SIZE; - cur[0] = i_hdr_s; dim[0] = buf_size; @@ -1462,97 +1452,95 @@ void process_madis_raob(NcFile *&f_in) { get_nc_data(&in_hdr_lon_var, hdr_lon_arr, buf_size, i_hdr_s); get_filtered_nc_data(in_hdr_elv_var, hdr_elv_arr, buf_size, i_hdr_s, "eleveation"); - dim2D[0] = buf_size; - //dim2D[1] = hdr_typ_len; - //get_nc_data(in_hdr_typ_var, (char *)&hdr_typ_arr[0], dim2D, cur); - dim2D[1] = hdr_sid_len; - get_nc_data(&in_hdr_sid_var, (char *)&hdr_sid_arr, dim2D, cur); - - dim3D[0] = buf_size; - dim3D[1] = maxlvl_manLevel; - if (IS_VALID_NC(prManQty_var)) get_nc_data(&prManQty_var, (char *)&prManQty, dim3D, cur); - else memset(prManQty, 0, buf_size*dim3D[1]*sizeof(char)); - if (IS_VALID_NC(htManQty_var)) get_nc_data(&htManQty_var, (char *)&htManQty, dim3D, cur); - else memset(htManQty, 0, buf_size*dim3D[1]*sizeof(char)); - if (IS_VALID_NC(tpManQty_var)) get_nc_data(&tpManQty_var, (char *)&tpManQty, dim3D, cur); - else memset(tpManQty, 0, buf_size*dim3D[1]*sizeof(char)); - if (IS_VALID_NC(tdManQty_var)) get_nc_data(&tdManQty_var, (char *)&tdManQty, dim3D, cur); - else memset(tdManQty, 0, buf_size*dim3D[1]*sizeof(char)); - if (IS_VALID_NC(wdManQty_var)) get_nc_data(&wdManQty_var, (char *)&wdManQty, dim3D, cur); - else memset(wdManQty, 0, buf_size*dim3D[1]*sizeof(char)); - if (IS_VALID_NC(wsManQty_var)) get_nc_data(&wsManQty_var, (char *)&wsManQty, dim3D, cur); - else memset(wsManQty, 0, buf_size*dim3D[1]*sizeof(char)); - dim3D[1] = maxlvl_sigTLevel; - if (IS_VALID_NC(prSigTQty_var)) get_nc_data(&prSigTQty_var, (char *)&prSigTQty, dim3D, cur); - else memset(prSigTQty, 0, buf_size*dim3D[1]*sizeof(char)); - if (IS_VALID_NC(tpSigTQty_var)) get_nc_data(&tpSigTQty_var, (char *)&tpSigTQty, dim3D, cur); - else memset(tpSigTQty, 0, buf_size*dim3D[1]*sizeof(char)); - if (IS_VALID_NC(tdSigTQty_var)) get_nc_data(&tdSigTQty_var, (char *)&tdSigTQty, dim3D, cur); - else memset(tdSigTQty, 0, buf_size*dim3D[1]*sizeof(char)); - dim3D[1] = maxlvl_sigWLevel; - if (IS_VALID_NC(htSigWQty_var)) get_nc_data(&htSigWQty_var, (char *)&htSigWQty, dim3D, cur); - else memset(htSigWQty, 0, buf_size*dim3D[1]*sizeof(char)); - if (IS_VALID_NC(wdSigWQty_var)) get_nc_data(&wdSigWQty_var, (char *)&wdSigWQty, dim3D, cur); - else memset(wdSigWQty, 0, buf_size*dim3D[1]*sizeof(char)); - if (IS_VALID_NC(wsSigWQty_var)) get_nc_data(&wsSigWQty_var, (char *)&wsSigWQty, dim3D, cur); - else memset(wsSigWQty, 0, buf_size*dim3D[1]*sizeof(char)); - dim3D[1] = maxlvl_sigPresWLevel; - if (IS_VALID_NC(prSigWQty_var )) get_nc_data(&prSigWQty_var , (char *)&prSigWQty, dim3D, cur); - else memset(prSigWQty, 0, buf_size*dim3D[1]*sizeof(char)); - if (IS_VALID_NC(wdSigPrWQty_var)) get_nc_data(&wdSigPrWQty_var, (char *)&wdSigPrWQty, dim3D, cur); - else memset(wdSigPrWQty, 0, buf_size*dim3D[1]*sizeof(char)); - if (IS_VALID_NC(wsSigPrWQty_var)) get_nc_data(&wsSigPrWQty_var, (char *)&wsSigPrWQty, dim3D, cur); - else memset(wsSigPrWQty, 0, buf_size*dim3D[1]*sizeof(char)); - dim3D[1] = maxlvl_mTropNum; - if (IS_VALID_NC(prTropQty_var)) get_nc_data(&prTropQty_var, (char *)&prTropQty, dim3D, cur); - else memset(prTropQty, 0, buf_size*dim3D[1]*sizeof(char)); - if (IS_VALID_NC(tpTropQty_var)) get_nc_data(&tpTropQty_var, (char *)&tpTropQty, dim3D, cur); - else memset(tpTropQty, 0, buf_size*dim3D[1]*sizeof(char)); - if (IS_VALID_NC(tdTropQty_var)) get_nc_data(&tdTropQty_var, (char *)&tdTropQty, dim3D, cur); - else memset(tdTropQty, 0, buf_size*dim3D[1]*sizeof(char)); - if (IS_VALID_NC(wdTropQty_var)) get_nc_data(&wdTropQty_var, (char *)&wdTropQty, dim3D, cur); - else memset(wdTropQty, 0, buf_size*dim3D[1]*sizeof(char)); - if (IS_VALID_NC(wsTropQty_var)) get_nc_data(&wsTropQty_var, (char *)&wsTropQty, dim3D, cur); - else memset(wsTropQty, 0, buf_size*dim3D[1]*sizeof(char)); - dim3D[1] = maxlvl_mWndNum; - if (IS_VALID_NC(prMaxWQty_var)) get_nc_data(&prMaxWQty_var, (char *)&prMaxWQty, dim3D, cur); - else memset(prMaxWQty, 0, buf_size*dim3D[1]*sizeof(char)); - if (IS_VALID_NC(wdMaxWQty_var)) get_nc_data(&wdMaxWQty_var, (char *)&wdMaxWQty, dim3D, cur); - else memset(wdMaxWQty, 0, buf_size*dim3D[1]*sizeof(char)); - if (IS_VALID_NC(wsMaxWQty_var)) get_nc_data(&wsMaxWQty_var, (char *)&wsMaxWQty, dim3D, cur); - else memset(wsMaxWQty, 0, buf_size*dim3D[1]*sizeof(char)); - - dim3D[1] = maxlvl_manLevel; - get_filtered_nc_data_2d(prMan_var, (float *)&prMan[0], dim3D, cur, "prMan"); - get_filtered_nc_data_2d(htMan_var, (float *)&htMan[0], dim3D, cur, "htMan"); - get_filtered_nc_data_2d(tpMan_var, (float *)&tpMan[0], dim3D, cur, "tpMan"); - get_filtered_nc_data_2d(tdMan_var, (float *)&tdMan[0], dim3D, cur, "tdMan"); - get_filtered_nc_data_2d(wdMan_var, (float *)&wdMan[0], dim3D, cur, "wdMan"); - get_filtered_nc_data_2d(wsMan_var, (float *)&wsMan[0], dim3D, cur, "wsMan"); - dim3D[1] = maxlvl_sigTLevel; - get_filtered_nc_data_2d(prSigT_var, (float *)&prSigT, dim3D, cur, "prSigT"); - get_filtered_nc_data_2d(tpSigT_var, (float *)&tpSigT, dim3D, cur, "tpSigT"); - get_filtered_nc_data_2d(tdSigT_var, (float *)&tdSigT, dim3D, cur, "tdSigT"); - dim3D[1] = maxlvl_sigWLevel; - get_filtered_nc_data_2d(htSigW_var, (float *)&htSigW, dim3D, cur, "htSigW"); - get_filtered_nc_data_2d(wdSigW_var, (float *)&wdSigW, dim3D, cur, "wdSigW"); - get_filtered_nc_data_2d(wsSigW_var, (float *)&wsSigW, dim3D, cur, "wsSigW"); - dim3D[1] = maxlvl_sigPresWLevel; - get_filtered_nc_data_2d(prSigW_var , (float *)&prSigW, dim3D, cur, "prSigW"); - get_filtered_nc_data_2d(wdSigPrW_var, (float *)&wdSigPrW, dim3D, cur, "wdSigPrW"); - get_filtered_nc_data_2d(wsSigPrW_var, (float *)&wsSigPrW, dim3D, cur, "wsSigPrW"); - dim3D[1] = maxlvl_mTropNum; - get_filtered_nc_data_2d(prTrop_var, (float *)&prTrop, dim3D, cur, "prTrop"); - get_filtered_nc_data_2d(tpTrop_var, (float *)&tpTrop, dim3D, cur, "tpTrop"); - get_filtered_nc_data_2d(tdTrop_var, (float *)&tdTrop, dim3D, cur, "tdTrop"); - get_filtered_nc_data_2d(wdTrop_var, (float *)&wdTrop, dim3D, cur, "wdTrop"); - get_filtered_nc_data_2d(wsTrop_var, (float *)&wsTrop, dim3D, cur, "wsTrop"); - dim3D[1] = maxlvl_mWndNum; - get_filtered_nc_data_2d(prMaxW_var, (float *)&prMaxW, dim3D, cur, "prMaxW"); - get_filtered_nc_data_2d(wdMaxW_var, (float *)&wdMaxW, dim3D, cur, "wdMaxW"); - get_filtered_nc_data_2d(wsMaxW_var, (float *)&wsMaxW, dim3D, cur, "wsMaxW"); + dim[0] = buf_size; + //dim[1] = hdr_typ_len; + //get_nc_data(in_hdr_typ_var, (char *)&hdr_typ_arr[0], dim, cur); + dim[1] = hdr_sid_len; + get_nc_data(&in_hdr_sid_var, (char *)&hdr_sid_arr, dim, cur); - dim[0] = 1; + dim[0] = buf_size; + dim[1] = maxlvl_manLevel; + if (IS_VALID_NC(prManQty_var)) get_nc_data(&prManQty_var, (char *)&prManQty, dim, cur); + else memset(prManQty, 0, buf_size*dim[1]*sizeof(char)); + if (IS_VALID_NC(htManQty_var)) get_nc_data(&htManQty_var, (char *)&htManQty, dim, cur); + else memset(htManQty, 0, buf_size*dim[1]*sizeof(char)); + if (IS_VALID_NC(tpManQty_var)) get_nc_data(&tpManQty_var, (char *)&tpManQty, dim, cur); + else memset(tpManQty, 0, buf_size*dim[1]*sizeof(char)); + if (IS_VALID_NC(tdManQty_var)) get_nc_data(&tdManQty_var, (char *)&tdManQty, dim, cur); + else memset(tdManQty, 0, buf_size*dim[1]*sizeof(char)); + if (IS_VALID_NC(wdManQty_var)) get_nc_data(&wdManQty_var, (char *)&wdManQty, dim, cur); + else memset(wdManQty, 0, buf_size*dim[1]*sizeof(char)); + if (IS_VALID_NC(wsManQty_var)) get_nc_data(&wsManQty_var, (char *)&wsManQty, dim, cur); + else memset(wsManQty, 0, buf_size*dim[1]*sizeof(char)); + dim[1] = maxlvl_sigTLevel; + if (IS_VALID_NC(prSigTQty_var)) get_nc_data(&prSigTQty_var, (char *)&prSigTQty, dim, cur); + else memset(prSigTQty, 0, buf_size*dim[1]*sizeof(char)); + if (IS_VALID_NC(tpSigTQty_var)) get_nc_data(&tpSigTQty_var, (char *)&tpSigTQty, dim, cur); + else memset(tpSigTQty, 0, buf_size*dim[1]*sizeof(char)); + if (IS_VALID_NC(tdSigTQty_var)) get_nc_data(&tdSigTQty_var, (char *)&tdSigTQty, dim, cur); + else memset(tdSigTQty, 0, buf_size*dim[1]*sizeof(char)); + dim[1] = maxlvl_sigWLevel; + if (IS_VALID_NC(htSigWQty_var)) get_nc_data(&htSigWQty_var, (char *)&htSigWQty, dim, cur); + else memset(htSigWQty, 0, buf_size*dim[1]*sizeof(char)); + if (IS_VALID_NC(wdSigWQty_var)) get_nc_data(&wdSigWQty_var, (char *)&wdSigWQty, dim, cur); + else memset(wdSigWQty, 0, buf_size*dim[1]*sizeof(char)); + if (IS_VALID_NC(wsSigWQty_var)) get_nc_data(&wsSigWQty_var, (char *)&wsSigWQty, dim, cur); + else memset(wsSigWQty, 0, buf_size*dim[1]*sizeof(char)); + dim[1] = maxlvl_sigPresWLevel; + if (IS_VALID_NC(prSigWQty_var )) get_nc_data(&prSigWQty_var , (char *)&prSigWQty, dim, cur); + else memset(prSigWQty, 0, buf_size*dim[1]*sizeof(char)); + if (IS_VALID_NC(wdSigPrWQty_var)) get_nc_data(&wdSigPrWQty_var, (char *)&wdSigPrWQty, dim, cur); + else memset(wdSigPrWQty, 0, buf_size*dim[1]*sizeof(char)); + if (IS_VALID_NC(wsSigPrWQty_var)) get_nc_data(&wsSigPrWQty_var, (char *)&wsSigPrWQty, dim, cur); + else memset(wsSigPrWQty, 0, buf_size*dim[1]*sizeof(char)); + dim[1] = maxlvl_mTropNum; + if (IS_VALID_NC(prTropQty_var)) get_nc_data(&prTropQty_var, (char *)&prTropQty, dim, cur); + else memset(prTropQty, 0, buf_size*dim[1]*sizeof(char)); + if (IS_VALID_NC(tpTropQty_var)) get_nc_data(&tpTropQty_var, (char *)&tpTropQty, dim, cur); + else memset(tpTropQty, 0, buf_size*dim[1]*sizeof(char)); + if (IS_VALID_NC(tdTropQty_var)) get_nc_data(&tdTropQty_var, (char *)&tdTropQty, dim, cur); + else memset(tdTropQty, 0, buf_size*dim[1]*sizeof(char)); + if (IS_VALID_NC(wdTropQty_var)) get_nc_data(&wdTropQty_var, (char *)&wdTropQty, dim, cur); + else memset(wdTropQty, 0, buf_size*dim[1]*sizeof(char)); + if (IS_VALID_NC(wsTropQty_var)) get_nc_data(&wsTropQty_var, (char *)&wsTropQty, dim, cur); + else memset(wsTropQty, 0, buf_size*dim[1]*sizeof(char)); + dim[1] = maxlvl_mWndNum; + if (IS_VALID_NC(prMaxWQty_var)) get_nc_data(&prMaxWQty_var, (char *)&prMaxWQty, dim, cur); + else memset(prMaxWQty, 0, buf_size*dim[1]*sizeof(char)); + if (IS_VALID_NC(wdMaxWQty_var)) get_nc_data(&wdMaxWQty_var, (char *)&wdMaxWQty, dim, cur); + else memset(wdMaxWQty, 0, buf_size*dim[1]*sizeof(char)); + if (IS_VALID_NC(wsMaxWQty_var)) get_nc_data(&wsMaxWQty_var, (char *)&wsMaxWQty, dim, cur); + else memset(wsMaxWQty, 0, buf_size*dim[1]*sizeof(char)); + + dim[1] = maxlvl_manLevel; + get_filtered_nc_data_2d(prMan_var, (float *)&prMan[0], dim, cur, "prMan"); + get_filtered_nc_data_2d(htMan_var, (float *)&htMan[0], dim, cur, "htMan"); + get_filtered_nc_data_2d(tpMan_var, (float *)&tpMan[0], dim, cur, "tpMan"); + get_filtered_nc_data_2d(tdMan_var, (float *)&tdMan[0], dim, cur, "tdMan"); + get_filtered_nc_data_2d(wdMan_var, (float *)&wdMan[0], dim, cur, "wdMan"); + get_filtered_nc_data_2d(wsMan_var, (float *)&wsMan[0], dim, cur, "wsMan"); + dim[1] = maxlvl_sigTLevel; + get_filtered_nc_data_2d(prSigT_var, (float *)&prSigT, dim, cur, "prSigT"); + get_filtered_nc_data_2d(tpSigT_var, (float *)&tpSigT, dim, cur, "tpSigT"); + get_filtered_nc_data_2d(tdSigT_var, (float *)&tdSigT, dim, cur, "tdSigT"); + dim[1] = maxlvl_sigWLevel; + get_filtered_nc_data_2d(htSigW_var, (float *)&htSigW, dim, cur, "htSigW"); + get_filtered_nc_data_2d(wdSigW_var, (float *)&wdSigW, dim, cur, "wdSigW"); + get_filtered_nc_data_2d(wsSigW_var, (float *)&wsSigW, dim, cur, "wsSigW"); + dim[1] = maxlvl_sigPresWLevel; + get_filtered_nc_data_2d(prSigW_var , (float *)&prSigW, dim, cur, "prSigW"); + get_filtered_nc_data_2d(wdSigPrW_var, (float *)&wdSigPrW, dim, cur, "wdSigPrW"); + get_filtered_nc_data_2d(wsSigPrW_var, (float *)&wsSigPrW, dim, cur, "wsSigPrW"); + dim[1] = maxlvl_mTropNum; + get_filtered_nc_data_2d(prTrop_var, (float *)&prTrop, dim, cur, "prTrop"); + get_filtered_nc_data_2d(tpTrop_var, (float *)&tpTrop, dim, cur, "tpTrop"); + get_filtered_nc_data_2d(tdTrop_var, (float *)&tdTrop, dim, cur, "tdTrop"); + get_filtered_nc_data_2d(wdTrop_var, (float *)&wdTrop, dim, cur, "wdTrop"); + get_filtered_nc_data_2d(wsTrop_var, (float *)&wsTrop, dim, cur, "wsTrop"); + dim[1] = maxlvl_mWndNum; + get_filtered_nc_data_2d(prMaxW_var, (float *)&prMaxW, dim, cur, "prMaxW"); + get_filtered_nc_data_2d(wdMaxW_var, (float *)&wdMaxW, dim, cur, "wdMaxW"); + get_filtered_nc_data_2d(wsMaxW_var, (float *)&wsMaxW, dim, cur, "wsMaxW"); for (int i_idx=0; i_idx BUFFER_SIZE) nc_buf_size = BUFFER_SIZE; - cur[0] = i_hdr_s; dim[0] = buf_size; get_nc_data(&in_hdr_vld_var, tmp_dbl_arr, buf_size, i_hdr_s); @@ -2211,14 +2196,14 @@ void process_madis_profiler(NcFile *&f_in) { // Wind U obs_arr[4] = uComponent_arr[i_idx][i_lvl]; count += process_obs(33, conversion, obs_arr, uComponentQty_arr[i_idx][i_lvl], - in_uComponent_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_uComponent_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Wind V obs_arr[4] = vComponent_arr[i_idx][i_lvl]; count += process_obs(34, conversion, obs_arr, vComponentQty_arr[i_idx][i_lvl], - in_vComponent_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_vComponent_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); } // end for i_lvl @@ -2357,9 +2342,9 @@ void process_madis_maritime(NcFile *&f_in) { // // Arrays of longs for indexing into NetCDF variables // - long *cur = new long [3]; + long *cur = new long [3]; // NetCDF API handles 2D or 3D cur[0] = cur[1] = cur[2] = 0; - long *dim = new long [3]; + long *dim = new long [3]; // NetCDF API handles 2D or 3D dim[0] = dim[1] = dim[2] = 1; int hdr_idx = 0; @@ -2406,9 +2391,6 @@ void process_madis_maritime(NcFile *&f_in) { char precip18HourQty_arr[buf_size]; char precip24HourQty_arr[buf_size]; - nc_buf_size = buf_size * FIELD_COUNT; - if (nc_buf_size > BUFFER_SIZE) nc_buf_size = BUFFER_SIZE; - cur[0] = i_hdr_s; dim[0] = buf_size; get_nc_data(&in_hdr_vld_var, tmp_dbl_arr, buf_size, i_hdr_s); @@ -2534,73 +2516,73 @@ void process_madis_maritime(NcFile *&f_in) { // Wind Direction obs_arr[4] = windDir_arr[i_idx]; count += process_obs(31, conversion, obs_arr, windDirQty_arr[i_idx], - in_windDir_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_windDir_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Wind Speed obs_arr[4] = windSpeed_arr[i_idx]; count += process_obs(32, conversion, obs_arr, windSpeedQty_arr[i_idx], - in_windSpeed_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_windSpeed_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Temperature obs_arr[4] = temperature_arr[i_idx]; count += process_obs(11, conversion, obs_arr, temperatureQty_arr[i_idx], - in_temperature_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_temperature_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Dew Point temperature obs_arr[4] = dewpoint_arr[i_idx]; count += process_obs(17, conversion, obs_arr, dewpointQty_arr[i_idx], - in_dewpoint_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_dewpoint_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Pressure reduced to MSL obs_arr[4] = seaLevelPress_arr[i_idx]; count += process_obs(2, conversion, obs_arr, seaLevelPressQty_arr[i_idx], - in_seaLevelPress_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_seaLevelPress_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Surface wind gust obs_arr[4] = windGust_arr[i_idx]; count += process_obs(180, conversion, obs_arr, windGustQty_arr[i_idx], - in_windGust_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_windGust_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // APCP_01 obs_arr[2] = 3600; obs_arr[4] = precip1Hour_arr[i_idx]; count += process_obs(61, conversion, obs_arr, precip1HourQty_arr[i_idx], - in_precip1Hour_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_precip1Hour_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // APCP_06 obs_arr[2] = 21600; obs_arr[4] = precip6Hour_arr[i_idx]; count += process_obs(61, conversion, obs_arr, precip6HourQty_arr[i_idx], - in_precip6Hour_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_precip6Hour_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // APCP_12 obs_arr[2] = 43200; obs_arr[4] = precip12Hour_arr[i_idx]; count += process_obs(61, conversion, obs_arr, precip12HourQty_arr[i_idx], - in_precip12Hour_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_precip12Hour_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // APCP_18 obs_arr[2] = 64800; obs_arr[4] = precip18Hour_arr[i_idx]; count += process_obs(61, conversion, obs_arr, precip18HourQty_arr[i_idx], - in_precip18Hour_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_precip18Hour_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // APCP_24 obs_arr[2] = 86400; obs_arr[4] = precip24Hour_arr[i_idx]; count += process_obs(61, conversion, obs_arr, precip24HourQty_arr[i_idx], - in_precip24Hour_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_precip24Hour_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); } @@ -2779,7 +2761,7 @@ void process_madis_mesonet(NcFile *&f_in) { long *cur = new long [2]; cur[0] = cur[1] = 0; long *dim = new long [2]; - dim[0] = 1; + dim[0] = dim[1] = 1; int hdr_idx = 0; @@ -2847,9 +2829,6 @@ void process_madis_mesonet(NcFile *&f_in) { char windDir10Qty_arr[buf_size]; char windSpeed10Qty_arr[buf_size]; - nc_buf_size = buf_size * FIELD_COUNT; - if (nc_buf_size > BUFFER_SIZE) nc_buf_size = BUFFER_SIZE; - cur[0] = i_hdr_s; dim[0] = buf_size; @@ -2994,46 +2973,46 @@ void process_madis_mesonet(NcFile *&f_in) { // Temperature obs_arr[4] = temperature_arr[i_idx]; count += process_obs(11, conversion, obs_arr, temperatureQty_arr[i_idx], - in_temperature_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_temperature_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Dewpoint obs_arr[4] = dewpoint_arr[i_idx]; count += process_obs(17, conversion, obs_arr, dewpointQty_arr[i_idx], - in_dewpoint_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_dewpoint_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Relative Humidity obs_arr[4] = relHumidity_arr[i_idx]; count += process_obs(52, conversion, obs_arr, relHumidityQty_arr[i_idx], - in_relHumidity_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_relHumidity_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Station Pressure obs_arr[4] = stationPressure_arr[i_idx]; count += process_obs(1, conversion, obs_arr, stationPressureQty_arr[i_idx], - in_stationPressure_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_stationPressure_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Sea Level Pressure obs_arr[4] = seaLevelPressure_arr[i_idx]; count += process_obs(2, conversion, obs_arr, seaLevelPressureQty_arr[i_idx], - in_seaLevelPressure_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_seaLevelPressure_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Wind Direction obs_arr[4] = windDir_arr[i_idx]; count += process_obs(31, conversion, obs_arr, windDirQty_arr[i_idx], - in_windDir_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_windDir_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); wdir = obs_arr[4]; // Wind Speed obs_arr[4] = windSpeed_arr[i_idx]; char qty = windSpeedQty_arr[i_idx]; count += process_obs(32, conversion, obs_arr, qty, - in_windSpeed_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_windSpeed_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); wind = obs_arr[4]; // Convert the wind direction and speed into U and V components @@ -3042,105 +3021,105 @@ void process_madis_mesonet(NcFile *&f_in) { // Write U-component of wind obs_arr[4] = ugrd; count += process_obs(33, conversion, obs_arr, qty, in_windSpeed_var, - hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Write V-component of wind obs_arr[4] = vgrd; count += process_obs(34, conversion, obs_arr, qty, in_windSpeed_var, - hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Wind Gust obs_arr[4] = windGust_arr[i_idx]; count += process_obs(180, conversion, obs_arr, windGustQty_arr[i_idx], - in_windGust_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_windGust_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Visibility obs_arr[4] = visibility_arr[i_idx]; count += process_obs(20, conversion, obs_arr, visibilityQty_arr[i_idx], - in_visibility_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_visibility_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Precipitation Rate // Convert input meters/second to output millimeters/second obs_arr[4] = precipRate_arr[i_idx]; count += process_obs(59, 1000.0, obs_arr, precipRateQty_arr[i_idx], - in_precipRate_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_precipRate_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Solar Radiation obs_arr[4] = solarRadiation_arr[i_idx]; count += process_obs(250, conversion, obs_arr, solarRadiationQty_arr[i_idx], - in_solarRadiation_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_solarRadiation_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Sea Surface Temperature obs_arr[4] = seaSurfaceTemp_arr[i_idx]; count += process_obs(80, conversion, obs_arr, seaSurfaceTempQty_arr[i_idx], - in_seaSurfaceTemp_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_seaSurfaceTemp_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Precipitable Water // Convert input cm to output mm obs_arr[4] = totalColumnPWV_arr[i_idx]; count += process_obs(54, 10.0, obs_arr, totalColumnPWVQty_arr[i_idx], - in_totalColumnPWV_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_totalColumnPWV_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Soil Temperature obs_arr[4] = soilTemperature_arr[i_idx]; count += process_obs(85, conversion, obs_arr, soilTemperatureQty_arr[i_idx], - in_soilTemperature_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_soilTemperature_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Minimum Temperature obs_arr[4] = minTemp24Hour_arr[i_idx]; count += process_obs(16, conversion, obs_arr, minTemp24HourQty_arr[i_idx], - in_minTemp24Hour_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_minTemp24Hour_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Maximum Temperature obs_arr[4] = maxTemp24Hour_arr[i_idx]; count += process_obs(15, conversion, obs_arr, maxTemp24HourQty_arr[i_idx], - in_maxTemp24Hour_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_maxTemp24Hour_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Precipitation - 3 Hour obs_arr[2] = 3.0*sec_per_hour; obs_arr[4] = precip3hr_arr[i_idx]; count += process_obs(61, conversion, obs_arr, precip3hrQty_arr[i_idx], - in_precip3hr_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_precip3hr_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Precipitation - 6 Hour obs_arr[2] = 6.0*sec_per_hour; obs_arr[4] = precip6hr_arr[i_idx]; count += process_obs(61, conversion, obs_arr, precip6hrQty_arr[i_idx], - in_precip6hr_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_precip6hr_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Precipitation - 12 Hour obs_arr[2] = 12.0*sec_per_hour; obs_arr[4] = precip12hr_arr[i_idx]; count += process_obs(61, conversion, obs_arr, precip12hrQty_arr[i_idx], - in_precip12hr_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_precip12hr_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Precipitation - 10 minutes obs_arr[2] = 600; obs_arr[4] = precip10min_arr[i_idx]; count += process_obs(61, conversion, obs_arr, precip10minQty_arr[i_idx], - in_precip10min_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_precip10min_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Precipitation - 1 minutes obs_arr[2] = 60; obs_arr[4] = precip1min_arr[i_idx]; count += process_obs(61, conversion, obs_arr, precip1minQty_arr[i_idx], - in_precip1min_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_precip1min_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Set the level to bad data and the height to 10 meters obs_arr[2] = bad_data_float; @@ -3149,16 +3128,16 @@ void process_madis_mesonet(NcFile *&f_in) { // 10m Wind Direction obs_arr[4] = windDir10_arr[i_idx]; count += process_obs(31, conversion, obs_arr, windDir10Qty_arr[i_idx], - in_windDir10_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_windDir10_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); wdir = obs_arr[4]; // 10m Wind Speed qty = windSpeed10Qty_arr[i_idx]; obs_arr[4] = windSpeed10_arr[i_idx]; count += process_obs(32, conversion, obs_arr, qty, in_windSpeed10_var, - hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); wind = obs_arr[4]; // Convert the wind direction and speed into U and V components @@ -3167,8 +3146,8 @@ void process_madis_mesonet(NcFile *&f_in) { // Write U-component of 10m wind obs_arr[4] = ugrd; count += process_obs(33, conversion, obs_arr, qty, in_windSpeed10_var, - hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Write V-component of 10m wind obs_arr[4] = vgrd; @@ -3176,8 +3155,8 @@ void process_madis_mesonet(NcFile *&f_in) { // hdr_typ, hdr_sid, hdr_vld, // hdr_arr[0], hdr_arr[1], hdr_arr[2]); process_obs(34, conversion, obs_arr, qty, in_windSpeed10_var, - hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); } @@ -3272,10 +3251,10 @@ void process_madis_acarsProfiles(NcFile *&f_in) { // // Arrays of longs for indexing into NetCDF variables // - long *cur = new long [3]; - cur[0] = cur[1] = cur[2] = 0; - long *dim = new long [3]; - dim[0] = dim[1] = dim[2] = 1; + long *cur = new long [2]; + cur[0] = cur[1] = 0; + long *dim = new long [2]; + dim[0] = dim[1] = 1; // // Get the number of levels @@ -3348,9 +3327,6 @@ void process_madis_acarsProfiles(NcFile *&f_in) { char windSpeedQty_arr[buf_size][maxLevels]; char altitudeQty_arr[buf_size][maxLevels]; - nc_buf_size = buf_size * FIELD_COUNT; - if (nc_buf_size > BUFFER_SIZE) nc_buf_size = BUFFER_SIZE; - cur[0] = i_hdr_s; dim[0] = buf_size; dim[1] = maxLevels; @@ -3491,28 +3467,28 @@ void process_madis_acarsProfiles(NcFile *&f_in) { // Temperature obs_arr[4] = temperature_arr[i_idx][i_lvl]; count += process_obs(11, conversion, obs_arr, temperatureQty_arr[i_idx][i_lvl], - in_temperature_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_temperature_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Dewpoint obs_arr[4] = dewpoint_arr[i_idx][i_lvl]; count += process_obs(17, conversion, obs_arr, dewpointQty_arr[i_idx][i_lvl], - in_dewpoint_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_dewpoint_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Wind Direction obs_arr[4] = windDir_arr[i_idx][i_lvl]; count += process_obs(31, conversion, obs_arr, windDirQty_arr[i_idx][i_lvl], - in_windDir_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_windDir_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); wdir = obs_arr[4]; // Wind Speed obs_arr[4] = windSpeed_arr[i_idx][i_lvl]; qty = windSpeedQty_arr[i_idx][i_lvl]; count += process_obs(32, conversion, obs_arr, qty, - in_windSpeed_var, hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + in_windSpeed_var, hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); wind = obs_arr[4]; // Convert the wind direction and speed into U and V components @@ -3521,17 +3497,17 @@ void process_madis_acarsProfiles(NcFile *&f_in) { // Write U-component of wind obs_arr[4] = ugrd; count += process_obs(33, conversion, obs_arr, qty, in_windSpeed_var, - hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); // Write V-component of wind obs_arr[4] = vgrd; //count += process_obs(34, conversion, obs_arr, qty, in_windSpeed_var, - // hdr_typ, hdr_sid, hdr_vld, - // hdr_arr[0], hdr_arr[1], hdr_arr[2]); + // hdr_typ, hdr_sid, hdr_vld, + // hdr_arr[0], hdr_arr[1], hdr_arr[2]); process_obs(34, conversion, obs_arr, qty, in_windSpeed_var, - hdr_typ, hdr_sid, hdr_vld, - hdr_arr[0], hdr_arr[1], hdr_arr[2]); + hdr_typ, hdr_sid, hdr_vld, + hdr_arr[0], hdr_arr[1], hdr_arr[2]); } // end for i_lvl } diff --git a/scripts/environment/development.seneca b/scripts/environment/development.seneca new file mode 100644 index 0000000000..d6e13f0543 --- /dev/null +++ b/scripts/environment/development.seneca @@ -0,0 +1,46 @@ +# Define the development environment for NCAR project machine seneca +# Based on settings in /usr/local/src/met/README.snat + +# Top-level MET project directory +MET_PROJ_DIR=/d1/projects/MET + +# Variables required to build MET +export MET_DEVELOPMENT=true +export MET_DST=/usr/local +export MET_NETCDF=${MET_DST}/netcdf-4.7.0/gcc-8.3.0 +export MET_HDF5=${MET_DST}/hdf5-1.8.21 +export MET_HDFINC=${MET_DST}/hdf4-4.2.15/include/hdf +export MET_HDFLIB=${MET_DST}/hdf4-4.2.15/lib +export MET_HDFEOS=${MET_DST}/hdf-eos2-20v1 +export MET_BUFR=${MET_DST} +export MET_GRIB2C=${MET_DST} +export MET_GSL=${MET_PROJ_DIR}/MET_releases/external_libs/gnu_8.3.0 +export MET_CAIROINC=/usr/include/cairo +export MET_CAIROLIB=/usr/lib/x86_64-linux-gnu +export MET_FREETYPEINC=/usr/include/freetype2 +export MET_FREETYPELIB=/usr/lib/x86_64-linux-gnu +export MET_JASPER=${MET_DST}/jasper-1.900.1 + +# For Python 3 in met-9.0 +export MET_PYTHON=/usr/local/met-python3 +export MET_PYTHON_CC="-I${MET_PYTHON}/include/python3.8" +export MET_PYTHON_LD="-L${MET_PYTHON}/lib -lpython3.8 -lcrypt -lpthread -ldl -lutil -lm" + +# -D__64BIT__ is required because we've compiled libgrib2c.a with that flag +export CFLAGS="-DUNDERSCORE -fPIC -D__64BIT__" +export CXXFLAGS=${CFLAGS} + +# Set LDFLAGS to include -rpath settings when compiling MET +export LDFLAGS="-Wl,--disable-new-dtags" +export LDFLAGS="${LDFLAGS} -Wl,-rpath,${MET_DST}/lib:${MET_HDFEOS}/lib:${MET_NETCDF}/lib:${MET_DST}/zlib-1.2.11/lib:${MET_DST}/szip-2.1.1/lib" +export LDFLAGS="${LDFLAGS} -Wl,-rpath,${MET_HDFLIB}:${MET_HDF5}/lib:${MET_GSL}/lib:${MET_PYTHON}/lib:${MET_JASPER}/lib" +export LDFLAGS="${LDFLAGS} -L${MET_JASPER}/lib" + +# Variables required to run MET +export MET_TEST_INPUT=${MET_PROJ_DIR}/MET_test_data/unit_test +export MET_FONT_DIR=${MET_TEST_INPUT}/fonts + +# This is a cron script -- create the shell environment for this job +export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:\ + /usr/bin/X11:/opt/bin:${MET_NETCDF}/bin" + diff --git a/test/hdr/met_10_1.hdr b/test/hdr/met_10_1.hdr index 77d4fa0053..245eac4203 100644 --- a/test/hdr/met_10_1.hdr +++ b/test/hdr/met_10_1.hdr @@ -1,4 +1,4 @@ -CNT : VERSION MODEL DESC FCST_LEAD FCST_VALID_BEG FCST_VALID_END OBS_LEAD OBS_VALID_BEG OBS_VALID_END FCST_VAR FCST_UNITS FCST_LEV OBS_VAR OBS_UNITS OBS_LEV OBTYPE VX_MASK INTERP_MTHD INTERP_PNTS FCST_THRESH OBS_THRESH COV_THRESH ALPHA LINE_TYPE TOTAL FBAR FBAR_NCL FBAR_NCU FBAR_BCL FBAR_BCU FSTDEV FSTDEV_NCL FSTDEV_NCU FSTDEV_BCL FSTDEV_BCU OBAR OBAR_NCL OBAR_NCU OBAR_BCL OBAR_BCU OSTDEV OSTDEV_NCL OSTDEV_NCU OSTDEV_BCL OSTDEV_BCU PR_CORR PR_CORR_NCL PR_CORR_NCU PR_CORR_BCL PR_CORR_BCU SP_CORR KT_CORR RANKS FRANK_TIES ORANK_TIES ME ME_NCL ME_NCU ME_BCL ME_BCU ESTDEV ESTDEV_NCL ESTDEV_NCU ESTDEV_BCL ESTDEV_BCU MBIAS MBIAS_BCL MBIAS_BCU MAE MAE_BCL MAE_BCU MSE MSE_BCL MSE_BCU BCMSE BCMSE_BCL BCMSE_BCU RMSE RMSE_BCL RMSE_BCU E10 E10_BCL E10_BCU E25 E25_BCL E25_BCU E50 E50_BCL E50_BCU E75 E75_BCL E75_BCU E90 E90_BCL E90_BCU EIQR EIQR_BCL EIQR_BCU MAD MAD_BCL MAD_BCU ANOM_CORR ANOM_CORR_NCL ANOM_CORR_NCU ANOM_CORR_BCL ANOM_CORR_BCU ME2 ME2_BCL ME2_BCU MSESS MSESS_BCL MSESS_BCU RMSFA RMSFA_BCL RMSFA_BCU RMSOA RMSOA_BCL RMSOA_BCU ANOM_CORR_UNCNTR ANOM_CORR_UNCNTR_BCL ANOM_CORR_UNCNTR_BCU +CNT : VERSION MODEL DESC FCST_LEAD FCST_VALID_BEG FCST_VALID_END OBS_LEAD OBS_VALID_BEG OBS_VALID_END FCST_VAR FCST_UNITS FCST_LEV OBS_VAR OBS_UNITS OBS_LEV OBTYPE VX_MASK INTERP_MTHD INTERP_PNTS FCST_THRESH OBS_THRESH COV_THRESH ALPHA LINE_TYPE TOTAL FBAR FBAR_NCL FBAR_NCU FBAR_BCL FBAR_BCU FSTDEV FSTDEV_NCL FSTDEV_NCU FSTDEV_BCL FSTDEV_BCU OBAR OBAR_NCL OBAR_NCU OBAR_BCL OBAR_BCU OSTDEV OSTDEV_NCL OSTDEV_NCU OSTDEV_BCL OSTDEV_BCU PR_CORR PR_CORR_NCL PR_CORR_NCU PR_CORR_BCL PR_CORR_BCU SP_CORR KT_CORR RANKS FRANK_TIES ORANK_TIES ME ME_NCL ME_NCU ME_BCL ME_BCU ESTDEV ESTDEV_NCL ESTDEV_NCU ESTDEV_BCL ESTDEV_BCU MBIAS MBIAS_BCL MBIAS_BCU MAE MAE_BCL MAE_BCU MSE MSE_BCL MSE_BCU BCMSE BCMSE_BCL BCMSE_BCU RMSE RMSE_BCL RMSE_BCU E10 E10_BCL E10_BCU E25 E25_BCL E25_BCU E50 E50_BCL E50_BCU E75 E75_BCL E75_BCU E90 E90_BCL E90_BCU EIQR EIQR_BCL EIQR_BCU MAD MAD_BCL MAD_BCU ANOM_CORR ANOM_CORR_NCL ANOM_CORR_NCU ANOM_CORR_BCL ANOM_CORR_BCU ME2 ME2_BCL ME2_BCU MSESS MSESS_BCL MSESS_BCU RMSFA RMSFA_BCL RMSFA_BCU RMSOA RMSOA_BCL RMSOA_BCU ANOM_CORR_UNCNTR ANOM_CORR_UNCNTR_BCL ANOM_CORR_UNCNTR_BCU SI SI_BCL SI_BCU CTC : VERSION MODEL DESC FCST_LEAD FCST_VALID_BEG FCST_VALID_END OBS_LEAD OBS_VALID_BEG OBS_VALID_END FCST_VAR FCST_UNITS FCST_LEV OBS_VAR OBS_UNITS OBS_LEV OBTYPE VX_MASK INTERP_MTHD INTERP_PNTS FCST_THRESH OBS_THRESH COV_THRESH ALPHA LINE_TYPE TOTAL FY_OY FY_ON FN_OY FN_ON CTS : VERSION MODEL DESC FCST_LEAD FCST_VALID_BEG FCST_VALID_END OBS_LEAD OBS_VALID_BEG OBS_VALID_END FCST_VAR FCST_UNITS FCST_LEV OBS_VAR OBS_UNITS OBS_LEV OBTYPE VX_MASK INTERP_MTHD INTERP_PNTS FCST_THRESH OBS_THRESH COV_THRESH ALPHA LINE_TYPE TOTAL BASER BASER_NCL BASER_NCU BASER_BCL BASER_BCU FMEAN FMEAN_NCL FMEAN_NCU FMEAN_BCL FMEAN_BCU ACC ACC_NCL ACC_NCU ACC_BCL ACC_BCU FBIAS FBIAS_BCL FBIAS_BCU PODY PODY_NCL PODY_NCU PODY_BCL PODY_BCU PODN PODN_NCL PODN_NCU PODN_BCL PODN_BCU POFD POFD_NCL POFD_NCU POFD_BCL POFD_BCU FAR FAR_NCL FAR_NCU FAR_BCL FAR_BCU CSI CSI_NCL CSI_NCU CSI_BCL CSI_BCU GSS GSS_BCL GSS_BCU HK HK_NCL HK_NCU HK_BCL HK_BCU HSS HSS_BCL HSS_BCU ODDS ODDS_NCL ODDS_NCU ODDS_BCL ODDS_BCU LODDS LODDS_NCL LODDS_NCU LODDS_BCL LODDS_BCU ORSS ORSS_NCL ORSS_NCU ORSS_BCL ORSS_BCU EDS EDS_NCL EDS_NCU EDS_BCL EDS_BCU SEDS SEDS_NCL SEDS_NCU SEDS_BCL SEDS_BCU EDI EDI_NCL EDI_NCU EDI_BCL EDI_BCU SEDI SEDI_NCL SEDI_NCU SEDI_BCL SEDI_BCU BAGSS BAGSS_BCL BAGSS_BCU FHO : VERSION MODEL DESC FCST_LEAD FCST_VALID_BEG FCST_VALID_END OBS_LEAD OBS_VALID_BEG OBS_VALID_END FCST_VAR FCST_UNITS FCST_LEV OBS_VAR OBS_UNITS OBS_LEV OBTYPE VX_MASK INTERP_MTHD INTERP_PNTS FCST_THRESH OBS_THRESH COV_THRESH ALPHA LINE_TYPE TOTAL F_RATE H_RATE O_RATE