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

20020910: 248NM Reflectivity and using echo tops for masking



Robert,

I added the NDVAL in gdradr to specify what you wanted to
set the "none-detected" value to (instead of -9999.0).

The NET product sets the values past 124nmi to "ND". Unfortunately,
the cloudless areas inside 124nmi are also "ND". So there doesn't
appear to be a way to differentiate the 2 different reasons for ND.

I'm assuming your need for the 248nmi is to get coverage out past
where other radars exist -  where they overlap is somewhet easier.

I could suggest taking the HAXA00 10km grib product which has vip
levels 0-6 for the data, and values of  >6 outside the radar range,
and interpolating this to the heigher resolution. At least it would be a
first cut on masking the values outside the radar range. But,
this probably doesn't help you in the area of NET not reported by
adjacent radars operating in clear air mode.
At any rate, its something to play with maybe. 

Other than that, it sounds like you need NIDS products of range values.

Steve Chiswell
Unidata User Support


>From: "Robert Mullenax" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200209102034.g8AKYf122985

>
>I have created N0Z composites using gdradr, but as is usually
>the case this time of the year down here radars will be in precip
>mode but will have very strong echoes (like 50dBz) where there
>is nothing..so I would like to do the same thing I am doing
>with N0R composites, mask out echoes which are reported with
>tops of 5K or less. The problem here is of course that the 
>NET product is only good out to 124nm.   If I just
>assume that any echoes picked up past 124nm is real
>(maybe not always a good assumption, but good enough
>for just a quick look at data) and try to using the masking
>routine, it takes out all echoes past 124nm as well, presumably
>because my mask says to only keep echoes that have tops
>of greater than 5Kft and the tops past 124nm are -9999.0.
>If I have tried to come up with a way around this but can't
>seem to.  Any ideas?
>
>Thanks,
>Robert
>
>
>
>----- Original Message -----
>Date: Tue  September 10, 2002  02:11 PM
>From: Unidata Support <address@hidden>
>To: Robert Mullenax <address@hidden>
>cc: address@hidden
>Subject: 20020904: nex2gini problems with 248NM Reflectivity  
>
>>From: "Robert Mullenax" <address@hidden>
>>Organization: UCAR/Unidata
>>Keywords: 200209041426.g84EQAZ24669
>
>>Even though the data is of lesser quality I wanted
>>to make composites of the 248NM reflectivity (N0Z)
>>to look further into the Gulf and to look further
>>into data void regions in New Mexico.  When I run nex2gini
>>using gfunc=n0z, it creates the file but at the end says:
>>
>>warning header being truncated to 18 characters
>>
>>and the resulting file can't be viewed in GEMPAK or McIDAS.
>>Is there something intrinsically different about the N0Z
>>product?
>>
>>Thanks,
>>Robert Mullenax
>>
>
>Robert,
>
>I didn't put an entry for N0Z into the $GEMTBL/unidata/nex2gini.tbl file
>(I'll make the code handle that possibility in the new release to generate
>a generic header).
>
>What you need is in the above file is an entry:
>N0Z       25    1 dBZ,0,255,0,75            TICZ99 CHIZ
>
>Then, just define the band in the $GEMTBL/sat/imgtype.tbl file:
>RADAR                N0Z           0    255     11  2**24      1 
>osf_ref16.tbl
>
>Steve Chiswell
>****************************************************************************
>Unidata User Support                                    UCAR Unidata 
>(303)497-8643                                                  P.O. Box 
>address@hidden                                   Boulder, CO 
>----------------------------------------------------------------------------
>Unidata WWW Service                        
>****************************************************************************
>
>