Jim,
I don't know if anyone got back to you about this problem, so here's the
status. As you probably know, Convective Precipitation is an
accumulation type parameter but it wasn't treated as one in the grib
library. It's now treated as a accumulation parameter. The result is
that there are now
float Convective_precipitation_0hours @ surface time3,y,x
float Convective_precipitation_1hours @ surface time4,y,x
float Convective_precipitation_2hours @ surface time5,y,x
float Convective_precipitation_3hours @ surface time1,y,x
The _xhours is the accumulation period.
The 0hour parameter doesn't make sense to me but that's what in the data
and the data values are all missing values. The other parameters have
the accumulation periods times and valid values.
for example:
float Convective_precipitation_1hours_surface(time4=8, y=225, x=301);
:long_name = "Convective_precipitation_1hours @ surface";
:cell_methods = "time4: sum";
:units = "kg m-2";
:missing_value = NaNf; // float
:grid_mapping = "Lambert_Conformal";
:GRIB_param_discipline = "Meteorological_products";
:GRIB_param_category = "Moisture";
:GRIB_param_name = "Convective_precipitation";
:GRIB_param_id = 2, 0, 1, 10; // int
:GRIB_product_definition_type = "Average, accumulation, extreme
values or other statistically processed value at a horizontal level";
:GRIB_level_type = 1; // int
:GRIB_VectorComponentFlag = "gridRelative";
The IDV folks are incorporating this in the latest release.
RObb...
On Mon, 3 May 2010, Jim Steenburgh wrote:
There can be some wierd stuff in these accumulated precipitation
fields. It should be zero at hour 0. After that, it's possible that
it resets every 3 hours (for example). I have no idea why NCEP sends
out stuff like this, but c'est la vie. What was strange about what I
was seeing was that the precip didn't make sense. If, however,
convective precip is being reset, but the grid-scale precip is hourly,
then perhaps it does. Wonderfully consistent eh?
Jim
Unidata netCDF Java Support wrote:
Hi all:
I looked at Convective Precipitation a bit. My guess is that 1) its
always 0 at forecast time = 0. and 2) its some kind of accumulation
that gets reset every few hours. Im also guessing that these kinds of
fields cant be naively served up in this way. Im cc'ing Jeff W, in
case he can verify those guesses. Im cc'ing Robb because i dont think
we are exposing the time interval metadata correctly.
Hey Jim-
Full Name: Jim Steenburgh
Email Address: address@hidden
Organization: University of Utah
Package Version: 2.9a1 build date:2010-04-30 20:54 UTC
Operating System: Mac OS X
Hardware: Java: home:
/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
version: 1.6.0_15 j3d:1.5.2 fcs (build4)
Description of problem: Don et al.:
Sorry to continue to bombard you with IDV stuff. I get these
periods where I can work on it and thus uncover alot of stuff in a
short period of time.
No problem, at least for the next month. ;-)
I'm hoping this will send you my current state as a bundle. If so,
and you pull it up, it should pull up a 25 frame RUC2 loop derived
from the "best time series" option on the motherlode TDS. I have
set it up using the reverse times options so that it should grab
the most recent run plus prior analyses. Thus, there should be 7
or so frames of analyses followed by 18 forecast frames. Plotted
from left to right are convective precipitation, large-scale
precipitation, and the sum of the two.
Note how the fields blink in and out. This makes little sense to
me. Sometimes the precipitation stored in model output files is
cumulative since a certain time and resets now and then, so you see
jumpiness, but this doesn't apper to be the case here. I'm not
sure what is going on unless there is something with the time
matching of files or different RUC2 forecasts from different
initialization times are getting mixed up.
I'm not sure what the problem is here, but I suspect it's in they
way that the
accumulation time is being calculated. I'm going to pass this over
to the netCDF-Java
folks so they can take a look.
If you need more info, let me know.
Okay. John and crew might have more questions.
Don
Ticket Details
===================
Ticket ID: CMQ-531543
Department: Support netCDF Java
Priority: Normal
Status: Open
===============================================================================
Robb Kambic Unidata Program Center
Software Engineer III Univ. Corp for Atmospheric Research
address@hidden WWW: http://www.unidata.ucar.edu/
===============================================================================