ARM-DOE / pyart

The Python-ARM Radar Toolkit. A data model driven interactive toolkit for working with weather radar data.
https://arm-doe.github.io/pyart/
Other
513 stars 266 forks source link

NEXRAD SAILS sweep selection issues with cfradial from Radx #649

Closed swnesbitt closed 7 years ago

swnesbitt commented 7 years ago

All,

Using the devel branch of pyart - having the issue where pyart is able to correctly count and select sweeps from L2 file from S3 using read_nexrad_archive, but when I convert the file using RadxConvert to cfradial, it loads in the entire file, and the elevation data is different, but when counting sweeps with radar.nsweeps or using the radar.get_* methods, it finds fewer sweeps than I would expect.

For example:

>>> radar=pyart.io.read_nexrad_archive('/Users/snesbitt/data/nexrad/KDGX20170430_142255_V06')
>>> plt.plot(radar.elevation['data'],'.r')

image

>>> for i in np.arange(radar.nsweeps):
>>>          print(i,radar.get_elevation(i).mean(),radar.get_nyquist_vel(i))
0 0.538994 8.40999984741211
1 0.527344 33.5
2 0.880337 8.40999984741211
3 0.878906 33.5
4 1.33428 8.40999984741211
5 1.35377 33.5
6 0.479263 8.40999984741211
7 0.502602 33.5
8 1.79398 33.5
9 2.41649 33.5
10 3.16589 33.5
11 3.98895 33.5
12 5.14631 33.5
13 0.474407 8.40999984741211
14 0.515068 33.5
15 6.48042 33.5
16 8.03027 28.610000610351562
17 10.0651 30.860000610351562
18 12.5261 33.5
19 15.6505 33.5
20 19.5112 33.5

while the cfradial file, which has different elevation angles, biffs:

>>> radar=pyart.io.read_cfradial('/Users/snesbitt/data/nexrad/20170430/cfrad.20170430_142349.506_to_20170430_142827.703_KDGX_Surveillance_SUR.nc')
>>> plt.plot(radar.elevation['data'],'.r')

image

>>> for i in np.arange(radar.nsweeps):
>>>          print(i,radar.get_elevation(i).mean(),radar.get_nyquist_vel(i))
0 0.878906 33.5
1 1.35377 33.5
2 1.79398 33.5
3 2.41649 33.5
4 3.16589 33.5
5 3.98895 33.5
6 5.14631 33.5
7 0.515068 33.5
8 6.48042 33.5
9 8.03027 28.610000610351562
10 10.0651 30.860000610351562
11 12.5261 33.5
12 15.6505 33.5
13 19.511 33.5

I don't think Radx is reading the files correctly either, but that is another story for another day...

scollis commented 7 years ago

Thanks @swnesbitt Hopefully some one can look into this. We are short staffed at the moment so this will be on the back burner for a bit.

swnesbitt commented 7 years ago

I think I may have found the solution, this is a Radx issue -- by default it removes the long range and split cuts from NEXRAD data. By setting the following in a RadxConvert params file, I was able to fix the issue:

///////////// preserve_sweeps /////////////////////////
//
// Preserve sweeps just as they are in the file.
//
// Applies generally to NEXRAD data. If true, the sweep details are
//   preserved. If false, we consolidate sweeps from split cuts into a
//   single sweep.
//
//
// Type: boolean
//

preserve_sweeps = TRUE;

///////////// remove_long_range_rays //////////////////
//
// Option to remove long range rays.
//
// Applies to NEXRAD data. If true, data from the non-Doppler long-range
//   sweeps will be removed.
//
//
// Type: boolean
//

remove_long_range_rays = FALSE;

Then run RadxConvert as such:

RadxConvert -f KDGX20170430_142255_V06 -outdir . -v -params RadxConvert.params
nguy commented 7 years ago

This was a conscious decision on Radx part when I spoke with Mike D a while back.

swnesbitt commented 7 years ago

Ok, makes sense.