pyart
pyart copied to clipboard
ARM-DOE
Composite Z bugs (issue and fix)
In my original composite reflectivity code, I neglected that different sweeps can have different PRFs, which change the sensitivity and range. This created some odd artifacts like here:
To get around this, I have adjusted the composite reflectivity code to include a quick np.where call to find all the sweeps with the same nyquist as the lowest sweep. This gets rid of the hard artifacts:
I have added a bool flag to turn this on/off (not sure why someone would want to turn this off, but its there if people do).
I would guess in the future i should build it so you can select the specific nyquist, but for now this fix works.
I have the code into the codebase locally, but need to run. I will try to get this pushed up next week.
I feel like dropping ALL tilts that don't match the lowest Nyquist is going to be pretty hit or miss and affect vertical extent. For instance, this is for KFCX 2024-04-15 20:32Z (tilt num, angle, Nyquist):
VCP: 212
1 0.53 8.51
2 0.53 31.3
3 0.93 8.51
4 0.92 31.3
5 1.38 9.25
6 1.36 31.3
7 0.52 8.51
8 0.53 31.3
9 1.82 31.3
10 2.43 31.3
11 3.10 31.3
12 3.99 31.3
13 5.10 31.3
14 6.41 31.3
This is why xradar will really help Py-ART deal with all the issues we face with non-“rectangle” radar files. From: Ryan May ***@***.***>Date: Monday, April 15, 2024 at 15:43To: ARM-DOE/pyart ***@***.***>Cc: Subscribed ***@***.***>Subject: Re: [ARM-DOE/pyart] Composite Z bugs (issue and fix) (Issue #1559)I feel like dropping ALL tilts that don't match the lowest Nyquist is going to be pretty hit or miss and affect vertical extent. For instance, this is for KFCX 2024-04-15 20:32Z (tilt num, angle, Nyquist):VCP: 2121 0.53 8.512 0.53 31.33 0.93 8.514 0.92 31.35 1.38 9.256 1.36 31.37 0.52 8.518 0.53 31.39 1.82 31.310 2.43 31.311 3.10 31.312 3.99 31.313 5.10 31.314 6.41 31.3—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
@dopplershift I agree, its a bit strong. But clearly from this case, things are getting weird in that doppler scan.
Should the default have the same_nyquist=False then if folks notice weird artifacts they have the power to turn it off?
Or should we apply some default gatefilter that cleans up the ugly data?
I'm curious to look at the sweeps and see just what's going on there...
Ok, so it looks like the SZ-2 phase coding for the range ambiguity resolution on the velocity cuts results in some kind of power bias. I'm rusty on my phase coding, but I don't remember that being a problem, but, it's clearly there, whatever.
The problem with your approach is that, for instance on this volume, it's only going to use the 0.5 and 0.9 cuts, nothing else:
1: 0.53 8.4
2: 0.53 30.92
3: 0.88 8.4
4: 0.88 30.92
5: 1.27 9.14
6: 1.32 30.92
7: 1.80 30.92
8: 2.42 30.92
9: 3.12 30.92
10: 0.53 8.4
11: 0.53 30.92
12: 3.96 30.92
13: 5.05 30.92
14: 6.37 30.92
15: 7.95 28.64
16: 9.98 30.92
17: 12.37 33.56
18: 15.47 33.56
19: 19.34 33.56
To me that's not a great composite Z product. There's also a general "issue" that needs to be dealt with (not sure if it is here) where SAILS can put another 0.5 cut in the volume--not sure whether that should be included.
Options I can think of:
- Look at the VCP information in the file and ignore sweeps that come from the "Doppler" sweeps on the SZ-2 phase coded split cuts
- Use some smart thresholding to only include a single sweep at a particular elevation angle from a volume, picking the lowest Nyquist to keep.
- Just live with the suboptimal behavior with the flag turned on.
@dopplerchase - if the nyquist velocity is in the instrument parameters, it will work! The method is implemented at the Radar object level, so it will across the readers.
https://github.com/ARM-DOE/pyart/blob/db95df72c3c59e90f35e772ccbf5ff30f0746be4/pyart/core/radar.py#L609
