# PyART and cfradial **URL:** \ **Category:** General\ **Tags:** py-art, xarray, data\ **Created:** [October 18, 2022, 7:15pm UTC](https://openradar.discourse.group/t/pyart-and-cfradial/63 "2022-10-18T19:15:17Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![nick.guy](https://avatars.discourse-cdn.com/v4/letter/n/6de8d8/32.png) [@nick.guy](https://openradar.discourse.group/u/nick.guy)\ **Post date:** [October 18, 2022, 7:15pm UTC](https://openradar.discourse.group/t/pyart-and-cfradial/63/1 "2022-10-18T19:15:17Z")
It’s been a couple of years since I really looked into the latest cfradial formats. From looking at the documentation the cfradial1.4 format was a 1D varying gates storage. The cfradial2.0 is a 2-D (time, range) storage definition? And the followup if that is correct is: Does Py-ART follow only the cfradial2.0 standard (that’s what it looks like is output from write\_cfradial function? ---
**Author:** ![mgrover1](https://yyz2.discourse-cdn.com/free1/user_avatar/openradar.discourse.group/mgrover1/32/7_2.png) [@mgrover1](https://openradar.discourse.group/u/mgrover1)\ **Post date:** [October 18, 2022, 7:40pm UTC](https://openradar.discourse.group/t/pyart-and-cfradial/63/2 "2022-10-18T19:40:40Z")
Py-ART’s [`write_cfradial`](https://arm-doe.github.io/pyart/API/generated/pyart.io.write_cfradial.html) function returns a cfradial 1.x standard file. This poster from Mike Dixon in 2016 outlines the difference between cfradial1 and cfradial2 pretty well, where cfradial1 can uses both time and range as the dimensions, with **`swee_start_ray_index`** **`sweep_end_ray_index`** values within the dataset indicating where one sweep starts and ends. > Cfradial2, on the other hand, makes use of netCDF4 groups, storing a hierarchal dataset where each sweep is an individual branch in the tree. For more information on the cfradial2 standard, check out Mark Curtis’s presentation from the European Weather Radar Conference (use the link below to download the poster, `NET.P3.Curtis.pdf`) > **[ENACSHARE-Download : ERAD\_Posters](https://enacshare.epfl.ch/dUQ4fCXGYPh3RbcKWFpwL#:~:text=May.%2025%2C%202023-,NET.P3_Curtis.pdf,-299.9KB)** > > ENAC-IT ENACSHARE - Service d'échange de fichiers Figure 3 is probably the best illustration of this idea… where the volume is a file, with multiple groups (sweeps) inside. ![Screen Shot 2022-10-18 at 2.40.01 PM](https://global.discourse-cdn.com/free1/uploads/openradar/original/1X/ed7dd99eaffeb56fac0a3e387197e322517c1231.png) We (Py-ART + wradlib developers) are working on moving to a shared IO package, xradar, which will conform to this new cfradial2 standard, where the data model is explained [here](https://docs.openradarscience.org/projects/xradar/en/latest/datamodel.html). > **[xradar — xradar 0.0.9.dev2+g28ab806 documentation](https://docs.openradarscience.org/projects/xradar/en/latest/)** > > Top-level documentation for xradar, with links to the rest of the site. I encourage you (and others) to check out this new package! This will be compatible with the rest of the Py-ART functionality in the near future. ---
**Author:** ![nick.guy](https://avatars.discourse-cdn.com/v4/letter/n/6de8d8/32.png) [@nick.guy](https://openradar.discourse.group/u/nick.guy)\ **Post date:** [October 18, 2022, 9:23pm UTC](https://openradar.discourse.group/t/pyart-and-cfradial/63/3 "2022-10-18T21:23:58Z")
Thanks for this explanation, this is a great overview. I’ll definitely look into xradar package! ---
**Author:** ![cgrasmick](https://avatars.discourse-cdn.com/v4/letter/c/9de053/32.png) [@cgrasmick](https://openradar.discourse.group/u/cgrasmick)\ **Post date:** [October 21, 2022, 2:32pm UTC](https://openradar.discourse.group/t/pyart-and-cfradial/63/4 "2022-10-21T14:32:28Z")
The University of Wyoming’s airborne radars are also transitioning to Cfradial2, although with a slightly different application of a sweep do to the nature of the measurements. Each sweep will still store data for a constant pointing angle (relative to the aircraft) but this is because each sweep will contain data fields for an individual antenna. This means that the different sweeps (sweep\_up, sweep\_down, etc.) have the same time variable and are simultaneous rather than sequential. ---
**Author:** ![mgrover1](https://yyz2.discourse-cdn.com/free1/user_avatar/openradar.discourse.group/mgrover1/32/7_2.png) [@mgrover1](https://openradar.discourse.group/u/mgrover1)\ **Post date:** [October 21, 2022, 3:11pm UTC](https://openradar.discourse.group/t/pyart-and-cfradial/63/5 "2022-10-21T15:11:12Z")
Is this still using netCDF groups in the files? ---
**Author:** ![cgrasmick](https://avatars.discourse-cdn.com/v4/letter/c/9de053/32.png) [@cgrasmick](https://openradar.discourse.group/u/cgrasmick)\ **Post date:** [October 21, 2022, 3:29pm UTC](https://openradar.discourse.group/t/pyart-and-cfradial/63/6 "2022-10-21T15:29:03Z")
Yes. Each file has the top-level root variables, followed by second-level sweep (antenna) groups for however many antennas were active. These contain additional monitoring/georeference groups. ---
**Author:** ![mgrover1](https://yyz2.discourse-cdn.com/free1/user_avatar/openradar.discourse.group/mgrover1/32/7_2.png) [@mgrover1](https://openradar.discourse.group/u/mgrover1)\ **Post date:** [October 21, 2022, 6:03pm UTC](https://openradar.discourse.group/t/pyart-and-cfradial/63/7 "2022-10-21T18:03:06Z")
Great!! Very exciting - thanks for sharing this here! ---
**Author:** ![kmuehlbauer](https://yyz2.discourse-cdn.com/free1/user_avatar/openradar.discourse.group/kmuehlbauer/32/439_2.png) [@kmuehlbauer](https://openradar.discourse.group/u/kmuehlbauer)\ **Post date:** [October 21, 2022, 6:40pm UTC](https://openradar.discourse.group/t/pyart-and-cfradial/63/8 "2022-10-21T18:40:05Z")
Yes, that sounds it will still fit into the model. Would be great if @cgrasmick could provide one example file for our testsuite, when available.