You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
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.
The text was updated successfully, but these errors were encountered: