Region Based algorithm dealiasing large areas of no aliasing with a blanket Vn

[CGLiesker]

The region-based dealiasing algorithm has worked well for our S-Band radar (we are specifically looking at event days with mesocyclones present), however, I have noticed on various timesteps for various case dates the following occurs where the algorithm provide a blanket velocity value (which appears to be the Nyquist value of 39.19 m/s) for echoes that do not have any dealiasing issues.
Here is an example of this issue:

I ran the algorithm with the following settings:
dealias_data = pyart.correct.dealias_region_based(
radar, interval_splits=4, skip_between_rays=5, skip_along_rays=5,
gatefilter=gatefilter,
rays_wrap_around=True, keep_original=True, vel_field="V")

Originally I used the default skip_between_rays/along_rays but reducing it to 5 each made a difference for some elevations and timesteps but did not fix all Some cases at least reduced the neighbouring echoes that were also initially affected). Decreasing it below 5 resulted in additional issues and did not fix for example the timestep provided above. I also tried increasing this value to for example 10, and the above example was no longer an issue however, the previous timestep then had this issue (at a different elevation) for a similar area (see below).

I have tried changing the intervals splits and various other parameters in the dealiasing function (including providing the Vn directly) but nothing seems to solve this issue. Any suggestions? Could there be a bug in the code or perhaps an issue with the data files themselves that could be causing this?

[CGLiesker]

I have looked further into this. I realized that in fact it was not that it was using a blanket value but rather dealiasing the values and correcting by adding/subtracting 2Vn. Below is another example with the last 10 gates in the 120° radial indicating the following between the uncorrected and corrected values:
uncorrected corrected
18.91 -59.48
19.83 -58.56
17.99 -60.40
17.37 -61.02
17.06 -61.33
17.06 -61.33
17.37 -61.02
17.68 -60.71

The Nyquist at this elevation is 39.195 m/s.

I assume it is an issue with the algorithm dealiasing this echo. Any suggestions to avoid this issue? In the bigger picture it should not be a major challenge when implementing for example a mesocyclone detection algorithm but would be interested if there is an explanation for this and how to avoid the issue to improve the quality of my data.

[zssherman]

@CGLiesker Hello, apologies a few of us are out for the holiday, so might be a bit til we can take a look, but can once folks are back.

Cheers!

[CGLiesker]

Thanks that would be appreciated. It's not a major issue and the region based outperformed both the 4DD and UNRAVEL on our data but would be nice to try determine why it is doing this and if it is avoidable at all.

[zssherman]

@CGLiesker I was discussing with a colleague @rcjackson, there has been an issue with the region based dealiasing that it could be "off" by a nyquist interval. More filtering could mitigate it to an extent such as using a filter with velocity texture similar to the example here:
https://github.com/ARM-DOE/pyart/blob/main/examples/correct/plot_dealias_rhi.py#L87

Its on our to do list, just sadly haven't been able to take a look at it yet.

[CGLiesker]

Ah ok, thanks for the feedback. They are very isolated instances in my data and unlikely to be a major issue when I apply for example the mesocyclone detection algorithm I am using, as it includes multiple levels in the analysis and also time continuity. I was just curious what would be causing it. In all other aspects the algorithm has done really well for my data (S-band data) and actually outperformed some of the other open source algorithms I tested. Also did not have issues inside my mesocyclones so that was also good to see as I have seen others comment on the algorithm doing this to their data.