[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IDV #CMQ-531543]: More IDV funny stuff



This is in the nightly build of the IDV and we are testing for a release this week.

Don

Robb Kambic wrote:
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/
===============================================================================

--
*************************************************************
Don Murray                               UCAR Unidata Program
address@hidden                        P.O. Box 3000
(303) 497-8628                              Boulder, CO 80307
http://www.unidata.ucar.edu/staff/donm
*************************************************************