Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RadxConvert bug in apply georefs #123

Open
mike-dixon opened this issue Apr 25, 2023 · 0 comments
Open

RadxConvert bug in apply georefs #123

mike-dixon opened this issue Apr 25, 2023 · 0 comments
Labels

Comments

@mike-dixon
Copy link
Collaborator

Reported by Alex DeRosiers

I encountered a specific problem twice now when helping others troubleshoot airborne radar issues with SAMURAI. When converting either raw or dorade files to cfradial without the apply_georefs argument results in a poor geolocation of radar echoes in SAMURAI.

The two ways I have seen this happen are:

  • A student at U Albany converted raw sigmet TDR files to cfradial with default params and encountered the issue.
  • Brad Klotz converted dorade files I supplied (which had already had navigation corrections applied) to cfradial with the attached param file.

In both cases, the original conversion resulted in the 1km v wind field analysis slice I have attached. The examples here come from Brad's more recent case. The problem is that the echoes seem to be highly localized to the flight track and do not appropriately reflect the range of the TDR. However, in both cases, when the apply_georefs argument is used, the issue is remedied and the analysis spans the domain more like the "expected" image attached. This raises a few key questions. The first being, if navigation corrections were applied to a dorade file in Solo II, will converting it with the apply georefs argument cause this to happen again and overcorrect? The second, and more important question, is there is a bug in RadxConvert? Even a basic conversion should still allow for the radar file to appropriately span the domain in SAMURAI. Looking at the two different plots it appears that the coverage is about an order of magnitude different. This leads me to believe that RadxConvert may have a unit conversion bug when converting airborne data to cfradial with default param options. I believe the apply_georefs argument may trigger a different subroutine which circumvents the bug. I may be incorrect on the source of the problem, but wanted to bring it to your attention in case there is something that needs repairing. I am CC'ing Brenda, Jen, and Brad as well because it is relevant to the ongoing meetings about navigation corrections in HawkEdit.

@mike-dixon mike-dixon added the bug label Apr 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant