Hi Ian,
I made a typeo in my previous email - I meant Pressure_reduced_to_MSL_msl, not MSLP. I'm curious, where are you getting the variable names like "MSLMA_P0_L101_GLC0"? Are those coming from NCL? We construct a similar string and put it in a variable attribute called Grib_Variable_Id. For GRIB2, the structure of that string is
VAR_%d-%d-%d[_error][_L%d][_layer][_I%s_S%d][_D%d][_Prob_%s]
where:
VAR_%d-%d-%d = discipline-category-paramNo
L%d = level type code
I%s = time interval name (eg "12_hour" or "mixed")
S%d = statistical type code if applicable
D%d = derived type code if applicable
Prob_%s = probability name if applicable
The only variable I see with Level 101 has a variable name of "VAR0-3-198_FROM_59-0--1_msl", which means we do not have it defined in a GRIB table, like we do for variable names that are human readable. We'll need to update our copy of the grib2 tables from NCEP to fix that, but for now, that's probably the variable you are looking for.
By the way, here is how we come up with a variable name:
%paramName[_error][_%level][_layer][_%interval][_%statName][_%ensDerivedType][_probability_%probName]
%paramName = parameter name from GRIB-2 table 4.2 (cleaned up); if unknown, use
VAR_%d-%d-%d_FROM%d-%d = VAR_discipline-category-paramNo_FROM_center-subcenter
%level = short form of level name from GRIB-2 table 4.5, if defined.
_layer = added if its a vertical layer (literal)
%timeInterval = time interval name (eg "12_hour" or "mixed")
%statName = name of statistical type if applicable, from GRIB-2 table 4.10
%ensDerivedType = name of ensemble derived type if applicable, from GRIB-2 table 4.7
%probName = name of probability type if applicable
For the 3km HRRR, you will want the mixed interval accumulation variable, as it contains the various different intervals of accumulations. If you look at the metadata for the precip variable, you will see that the time variable it is associated with is called time4. The variable time4 has an attribute called "bounds", whose value is time4_bounds. The variable time4_bounds contains the information about the beginning and end of the interval over which the interval occurs. Although a bit confusing, here are the values of time4 and time4_bounds in plain text:
For example, the dimensions of Time4_bounds are of length reftime, time4, 2. Here are the first 4 values, for the first reftime (i.e. the first four forecast hours of the first model run in the collection):
Time4_bounds[65][95][2]
[0][0], 0.0, 1.0
[0][1], 0.0, 2.0
[0][2], 1.0, 2.0
[0][3], 0.0, 3.0
The first entry indicates a 1 hour interval, the second a 2 hour, the third a 1 hour interval, and the fourth a 3 hour interval. There is a lot of duplication here, but that's how the grids are sent out.
The issue here is that GRIB messages are individual 2D slices of data valid at a single time. netCDF-Java, and thus the TDS, tries to look at all the grids holistically and assemble them into time varying n-dimensional variables. The interval variables can be tricky. We could assemble them into individual 1_hour, 2_hour, 3_hour, ..., 48_hour, etc. interval grids, but then the collection could have possibly hundreds of variable associated with a single field. Then, when we aggregate over multiple runs, that could lead to even bigger numbers of variables to describe a single field. No fun.
Cheers,
Sean
