search

tjturnage / cloud-radar-server

Radar server in the cloud for NOAA computing project
MIT License
2 stars 2 forks source link

PyART fails to dealias certain radar files in hodo_plots.py #48

Closed lcarlaw closed 2 months ago

lcarlaw commented 2 months ago

Certain radar files result in an exception thrown by PyART due to inconsistent nyquist intervals within the radar file (see output screenshot below). A reproducible set of radar files is available here. In this case, the radar was operating in VCP 12, so it's possible the PRFs were sectorized (as this is the only VCP for which different PRFs can be specified). However, looking at the radar data in GR, it's not immediately clear this is the case.

For ease of use with the monitor function which outputs script status, it'd be best if the hodo plot script would produce a blank image, perhaps with text warning the user there were issues dealiasing the data. Honestly, this seems to be more of an issue with how PyART handles radar files.

error

lcarlaw commented 2 months ago

A possible solution/workaround to this issue is shown in this commit.

It allows plots to continue to generate (which is good from a script-monitoring perspective), but adds warning text to the top of the hodograph plots that there were issues dealiasing the radar data. Would it be better to even state that NO dealiasing was performed instead?

scottthomaswx commented 2 months ago

Lee, this is an issue I've never run into as most offices I've seen use VCP212 which would be consistent on Nyquist Velocities. I di suspect you're right. The version of the code designed for TDWRs (ID starts with T) removes de-aliasing which would fix that issue. I think what you have in the commit is great. Switching the wording to no dealiasing would be more accurate but that's small potatoes. Is there anything you need me to look at? Otherwise what you have looks good.

lcarlaw commented 2 months ago

Thanks Scott! I realize I didn't share the radar files, but did so in the event you want to take a look at them. We do utilize VCP12 here for its faster volume scans, and I know southern region offices do so as well. What's odd is it doesn't actually look like the PRFs were sectorized in those radar files based on where the 1st trip RF area was. I did not take a look at the actual output via pyart though.

Either way, this patch should cover us and I've made the wording alteration you mentioned above. Ultimately, seems like an issue with the post-processing step via Pyart itself. Thank!