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

conventions for azimuth angle for RHI scans #104

Open
isabels opened this issue Dec 1, 2021 · 4 comments
Open

conventions for azimuth angle for RHI scans #104

isabels opened this issue Dec 1, 2021 · 4 comments
Assignees

Comments

@isabels
Copy link
Collaborator

isabels commented Dec 1, 2021

Using RadxConvert to create cfradial files from Leosphere WLS200s netcdfs, then using HawkEye to plot RHI scans. On all scans, even those that cover a full 180º, HawkEye plots only display the first half of the scan:
lidar WLS200s-181 20200312005030 BETA 117 RHI
This scan covers a full 180º, with the given elevations and azimuths:

   azimuth = 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 

      10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 

      10, 10, 10, 10, 10, 10, 190, 190, 190, 190, 190, 190, 190, 190, 190, 

      190, 190, 190, 190, 189.999, 189.999, 190, 190, 190, 190, 190, 190, 

      190, 190, 190, 189.999, 190, 190, 190, 190, 190, 190, 190, 190, 190, 

      190, 190, 190, 190, 190, 190, 190, 190, 190, 190, 190 ;


   elevation = 11.953, 13.96, 15.956, 17.954, 19.961, 21.955, 23.951, 25.948, 

      27.963, 29.953, 31.958, 33.958, 35.959, 37.956, 39.951, 41.951, 43.948, 

      45.954, 47.951, 49.949, 51.953, 53.955, 55.95, 57.955, 59.948, 61.961, 

      63.959, 65.95, 67.947, 69.948, 71.954, 73.952, 75.958, 77.954, 79.958, 

      81.95, 83.957, 85.948, 87.953, 89.948, 88.05, 86.048, 84.044, 82.044, 

      80.048, 78.047, 76.052, 74.05, 72.053, 70.037, 68.049, 66.04, 64.048, 

      62.052, 60.037, 58.045, 56.045, 54.044, 52.054, 50.044, 48.051, 46.04, 

      44.045, 42.042, 40.05, 38.053, 36.037, 34.045, 32.043, 30.048, 28.043, 

      26.044, 24.039, 22.04, 20.041, 18.051, 16.047, 14.045, 12.041, 10.042, 

      8.04, 6.039, 4.046, 2.053, 0.05 ;

In Leosphere files the azimuth switches by 180º when the elevation passes 90º, which I'm guessing is why HawkEye stops plotting the scan just before 90º elevation. So my question is: is there a convention for how azimuth should be represented on a RHI scan that goes past 90º? Is it incorrect for the azimuth to change when the elevation crosses 90º?

I can do more looking into the code myself, but first I need to know if this is a convention thing that should be fixed in the leosphere input to RadxConvert, or if it's a bug in HawkEye.

Parameter file used:
Hawkeye.rhi.params.txt
Link to netcdf plotted: https://drive.google.com/file/d/1wvjiTl3CQAkxRc_FXxSOfOxm6lgFw_rq/view?usp=sharing

@leavesntwigs
Copy link
Collaborator

The azimuth is mostly a convention thing and it is probably best to
modify the Leosphere data during ingest (LeoCf2RadxFile.cc and LeoRadxFile.cc) to output the expected convention for azimuth. With some code changes, RadxConvert would handle the Leosphere data ingest and output the expected azimuth. Then, HawkEye can display the full RHI data.

@isabels
Copy link
Collaborator Author

isabels commented Dec 27, 2022

That sounds good, thanks Brenda!
@jacquiewitte wrote a python script to do some corrections to elevation and azimuth for plotting. Here's what she did to fix elevations and azimuths:

`
def correct_rhi_az_elev(az_xr, elev_xr):
# Corrects for large variations in azimuth and trunction elevation angles

Parameters
----------
az_xr: xarray of azimuth
elev_xr: xarray of elevation

Returns
-------
az_xr: xarray of azimuth corrected
elev_xr: xarray of elevation corrected 
"""

# initialize to the first azimuth to compare all other angles
az0 = az_xr[0].values

# Loop over the azimuths
for i in np.arange(len(az_xr)):
    az1 = az_xr[i].values
    res = return_anglediff(az0, az1) # calculate the angle difference

    if abs(res) > 5:
        # Angle cases 
        if res >= -92 and res < 0: 
            az_xr[i] = az1 - 90.
        if res >= -180 and res < -175: 
            az_xr[i] = abs(az1 - 180.)
        if res >= 180.: 
            az_xr[i] = print(360. - az1)
        if res >= 90. and res < 100.: 
            az_xr[i] = 270. - az1

        delta = 180. - elev_xr[i]
        elev_xr[i] = delta

return az_xr, elev_xr

`

It seems like adding this logic to RadxConvert would be the best solution for this. Let me know if you want to work on it, or if I should take a look.

@leavesntwigs leavesntwigs self-assigned this Feb 10, 2023
@leavesntwigs
Copy link
Collaborator

Added @jacquiewitte python code (converted to C++ syntax) to RadxVol. Also, added a parameter and command-line arg to RadxConvert (-combine_rhi) to maintain a constant azimuth and keep the elevation angle increasing. With these changes, RadxConvert generates CfRadial files that HawkEye can use to display the full range of RHI rays.

@jacquiewitte
Copy link

@isabels @leavesntwigs
If you haven't found it already, there is silly error in this code. There's an insidious print() function that should be removed in
az_xr[i] = print(360. - az1)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants