pyart
pyart copied to clipboard
ARM-DOE
Method for storing a volume in which the range gate differ between rays.
Many radars collect volume such that the location of the range gates changes between rays most often between different sweeps. For example some NEXRAD file change to a different gate spacing at high elevation. Currently the CfRadial convention on which the Radar class is based has not manner for expressing a radar volume in which the gate locations vary by ray. A method for expressing and storing such data should be developed and implemented in Py-ART. This should be done in such a manner that the method can be included in or as an extension to the CfRadial format.
As a note, I will be working with NCAR in coming months on CF2.0. This will be one issue I will raise
On 3/12/15 2:00 PM, Jonathan J. Helmus wrote:
Many radars collect volume such that the location of the range gates changes between rays most often between different sweeps. For example some NEXRAD file change to a different gate spacing at high elevation. Currently the CfRadial convention on which the Radar class is based has not manner for expressing a radar volume in which the gate locations vary by ray. A method for expressing and storing such data should be developed and implemented in Py-ART. This should be done in such a manner that the method can be included in or as an extension to the CfRadial format.
— Reply to this email directly or view it on GitHub https://github.com/ARM-DOE/pyart/issues/252.
Hi, I propose a quick fix for this one: The data fields would still be a 2D-array of ray-range with the range length being defined by the ray that has the maximum number of gates. The range Attribute data would become a 2D-array of ray-range (not a 1D-array of range as it is now )where the actual range of each gate at each ray would be specified. The Attribute ngates would not be an integer but a 1D-array of length nrays. If we want to save some memory and keep some level of backwards compatibility we could make nrays either and int or a 1D-array. If it is an int is business as usual while if it is an array it means it is an irregular grid. For most applications it would not change anything at all. I hope there is some action on this issue soon because I have a volume scan with varying prf and it is hard to know where the data is finishing.
Hey @kmuehlbauer and @meteoswiss-mdr ! I will ping @josephhardinee on CF2.0... he keeps up with that more than me.. I like your proposal @meteoswiss-mdr .. I would suggest the best way to proceed is not to touch the existing core.radar object but to add a new core.vradar object. Also note we have a desire to add core.spectraradar as well..
@scollis I would prefer not to create a new radar object. I handle many different types of radars and to have two different types of objects doing essentially the same would make my pyrad (https://github.com/meteoswiss-mdr/pyrad) processing framework more difficult to mantain. If my proposal is accepted and we allow ngates and range to have a varying type, for the current user will make absolutely no difference but we will have the flexibility that we lack right now.
So a CF/Radial 2.0 proposal is out and can be found on Github. There is also a CF/Radial 1.5 as well being maintained in parallel (Which I believe should be out at some point). 1.5 looks a lot like 1.4 with improvements to things like naming and some edge cases that were not handled before. 2.0 looks more like the gamic files in that it uses groups to separate sweeps and allows changes of metadata per sweep. This wouldn't necessarily fix your gates problem, just moves it to the sweep level rather than the file level. 1.4 actually allows for a 1D variable ray_n_gates that stores number of saved gates in each ray. I'm not 100% sure why this was dropped in 2.0.
PyART could just implement the ray_n_gates solution (Which I think is what you meant by the 1d nrays part). I assume your actual sampling rate is not changing during a sweep, just the number of gates and possibly initial offset?
Actually I read some of Jonathon's comments about Nexrad and that would require a 2d array of range, or the CF 2.0 route of splitting up by sweep. I'm not sure there is going to be a purely CF/Radial compliant way of implementing this. I'll bring it up with Mike though and see what can be done. I think adding ray_n_gates to 2.0 goes part of the way towards helping.
Supporting CF/Radial 2.0 will require some larger changes to PyART most likely to support the group mechanism.
Yep. Making Py-ART work with CF 2.0 is doable but is a big change.. And there are plenty of other things we want to tackle.. 1.5 will be our target. We are cutting a release this week (1.9 Picasso) , lets aim to get @meteoswiss-mdr 's proposal moving for Py-ART 1.20, Dali
