GR2 vs Py-ART velocity values

[vc17b]

Hi all,

I'm currently doing my master's research on supercells where I'm writing the mesocyclone vrot, diameter, and altitude at which these occur. I am looking at NEXRAD radar files. I was doing it in GR2 but felt this process was a time-sink and subjective way to do my research. Since then, I've created a code using Py-ART to grid my radar object on a 500m x 500m x 500m grid using the Barnes2 weighting function and 'dist_beam' ROI.

The problem I'm having is that my vrots for all my storms tend to be 2-6 m/s lower than that on GR2. For example, from one volume scan, GR2 Vrot values I get are:

11.28865979 m/s at an avg beam height of  719 m
11.03092784 m/s at an avg beam height of  1132 m
10.51546392 m/s at an avg beam height of 1583 m

These are the Vrot values I get from Py-ART with no gatefilter exclusions and used the region-based dealiasing function (I found that the gatefilter made the discrepancies worse):

8.5 m/s at a grid altitude of 500 m
8 m/s at a grid altitude of 1000 m
7 m/s at a grid altitude of 1500 m

I found these values by: 1) subtracting the SMV (found from GR2) from the base velocity radar field by the formula SMV = (translational_motion)*np.cos(np.deg2rad((azimuth_2d-SMVangle)%360)), then subtracting this from the dealiased velocity srv=base_vel-SMV; 2) plotting them at altitude = j using contourf and finding the appropriate polygons through lots of loops I will not post here; 3) calculated vrot using the formula vrot = np.abs(outbound_max-inbound_max)/2. 4) do this for every other subsequent altitude until couplet is no more (I use input a lot as well - I'm not a coder/algorithm-maker, but it works well otherwise).

I wanted to pick your brains and see why they are considerably lower than GR2, whether that is just the nature of gridding a radar (especially mapping the gates to the grid - I tried mapping it to the grid and it took 30+ mins), or if dealiasing could also be a problem. I also wanted to see if anyone had any suggestions on how to correct this or if you've also had this problem.

Difference between my Py-ART plot and GR2 screen-cap below. My plot is at 500 m altitude, and the bottom GR2 photo is the 0.5° tilt, with both showing SRV with the SMV applied to both. I find it matches very well, yet can't get over the discrepancy. I also wonder if the contours are smoothing over the individual pixels like seen in GR2.

[mgrover1]

@vc17b are you using the same dataset in both applications?

Can you try using Level3 Storm Relative Motion data for the Py-ART workflow you running, instead of using the Level2 data?

Also, I think it could be combination of differing dealiasing methods, as well as gridding. Gridding smooths out some of those higher magnitude velocity fields (see Trapp and Doswell 2000).

My recommendation would be to try stay in the same data-space (radial coordinates), and use the Level3 data where possible if you are doing a 1:1 comparison between the two. Otherwise, go through and look at your dealiased velocity fields and make sure they look alright.

[mgrover1]

We also have an open issue (#1262 ) for adding a storm-relative motion calculation in Py-ART. We would be happy to work with you on adding this new feature, and would be a great contribution to the toolkit!

[vc17b]

I've read the paper and applied a constant ROI function to my grid, and my numbers now match MUCH better! Average difference between the two Vrot now lies a little more than 1 m/s (GR2 being larger) and std is 1 m/s. Originally, with a "dist-beam" ROI function, the average was ~3.9 m/s and std was 1.3 m/s.

I still plan to try with Level 3 data but thought I would update with this. Thank you for your help and insight!

[mgrover1]

Yay! Glad you are getting some closer values... would you be interested in putting together a blog post on this? Starting with a notebook? This would be another way to contribute/help other users with this problem :)

[vc17b]

I would be interested, but I'm kind of a newbie in the coding world. Like a Jupyter notebook? I've never used it before.

[mgrover1]

I would start here! https://foundations.projectpythia.org/foundations/jupyterlab.html it walks through how to get started with Jupyter notebooks, especially in the Jupyter lab environment. We can set up a time to chat about the process here if you'd like.

[vc17b]

That's fine with me. One more thing I'm having with this code - it only seems to work for this storm. The rest of my storms have their fields fully masked after the gridding completes. This does not happen with either the "dist" or "dist-beam" ROI functions. Any idea what's happening? I have been separating the SAILS scans, have no gatefilter activated, and only use the region-based dealiasing. Nothing different between all of them for code runs.

[vc17b]

This is occurring with most of my other storms when using a constant ROI, but especially ones that are past 100 km away from the radar site. I've tried increasing resolution in all directions to 1000 m (originally 500 m), but that leaves more white-space at each level. Do you believe that is just the nature of this interpolation/ROI scheme?

[mgrover1]

@vc17b when you are that far away from the radar, you will likely to struggle to have adequate low level velocity data for the level due to both the height of the lowest tilt (your lowest measured heigh above ground there is likely above 1-2 km), and your maximum unambiguous range.) which limits how far away from the radar you are able to measure radial velocity. You can try different interpolation schemes, but you will likely still struggle with these two issues.

[vc17b]

Ah, I figured. Rats, that's a bummer for my dataset. Nonetheless, I appreciate your help throughout this and would still be interested in writing a blog post if that's still an option.

[mgrover1]

Yeah! I would start by making a notebook with this example and we can go from there.