Page 1 of 1

Strange result when converting WRF output to ARL format

Posted: October 4th, 2017, 3:57 pm
by John.Johansson
I have run WRF on two nested domains and converted the output for each of the domains using arw2arl. The outer domain has a lat-lon grid with 0.5 degrees resolution and the inner domain has a lat-lon grid with 0.16667 degrees resolution (parent_grid_ratio = 3). The conversion for the outer domain seems to work fine, but for the inner domain the resolution of the grid seems to be 0.2 degrees in the ARL format file (lat-lon seems to be correct in the middle of the grid, but magnified towards the edges). Here is the lat-lon grid taken from one of the WRF output netCDF files for the inner domain:

Code: Select all

XLAT = [43.08333206,  43.25      ,  43.41666794,  43.58333206,  43.75      ,  43.91666794,  44.08333206,  44.25      ,
        44.41666794,  44.58333206,  44.75      ,  44.91666794,  45.08333206,  45.25      ,  45.41666794,  45.58333206,
        45.75      ,  45.91666794,  46.08333206,  46.25      ,  46.41666794,  46.58333206,  46.75      ,  46.91666794,
        47.08333206,  47.25      ,  47.41666794,  47.58333206,  47.75      ,  47.91666794,  48.08333206,  48.25      ,
        48.41666794,  48.58333206,  48.75      ,  48.91666794,  49.08333206,  49.25      ,  49.41666794,  49.58333206,
        49.75      ,  49.91666794,  50.08333206,  50.25      ,  50.41666794,  50.58333206,  50.75      ,  50.91666794,
        51.08333206,  51.25      ,  51.41666794,  51.58333206,  51.75      ,  51.91666794,  52.08333206,  52.25      ,
        52.41666794,  52.58333206,  52.75      ,  52.91666794,  53.08333206,  53.25      ,  53.41666794,  53.58333206,
        53.75      ,  53.91666794,  54.08333206,  54.25      ,  54.41666794,  54.58333206,  54.75      ,  54.91666794,
        55.08333206,  55.25      ,  55.41666794,  55.58333206,  55.75      ,  55.91666794,  56.08333206,  56.25      ,
        56.41666794,  56.58333206,  56.75      ,  56.91666794,  57.08333206,  57.25      ,  57.41666794,  57.58333206,
        57.75      ,  57.91666794,  58.08333206,  58.25      ,  58.41666794,  58.58333206,  58.75      ,  58.91666794,
        59.08333206,  59.25      ,  59.41666794]

XLONG = [ -8.41665649,  -8.25      ,  -8.08331299,  -7.91665649,  -7.75      ,  -7.58331299,  -7.41665649,  -7.25      ,
        -7.08331299,  -6.91665649,  -6.75      ,  -6.58331299,  -6.41665649,  -6.25      ,  -6.08331299,  -5.91665649,
        -5.75      ,  -5.58331299,  -5.41665649,  -5.25      ,  -5.08331299,  -4.91665649,  -4.75      ,  -4.58331299,
        -4.41665649,  -4.25      ,  -4.08331299,  -3.91665649,  -3.75      ,  -3.58331299,  -3.41665649,  -3.25      ,
        -3.08331299,  -2.91665649,  -2.75      ,  -2.58331299,  -2.41665649,  -2.25      ,  -2.08331299,  -1.91665649,
        -1.75      ,  -1.58331299,  -1.41665649,  -1.25      ,  -1.08331299,  -0.91665649,  -0.75      ,  -0.58331299,
        -0.41665649,  -0.25      ,  -0.08331299,   0.08334351,   0.25      ,   0.41668701,   0.58334351,   0.75      ,
         0.91668701,   1.08334351,   1.25      ,   1.41668701,  1.58334351,   1.75      ,   1.91668701,   2.08334351,
         2.25      ,   2.41668701,   2.58334351,   2.75      ,  2.91668701,   3.08334351,   3.25      ,   3.41668701,
         3.58334351,   3.75      ,   3.91668701,   4.08334351,  4.25      ,   4.41668701,   4.58334351,   4.75      ,
         4.91668701,   5.08334351,   5.25      ,   5.41668701,  5.58334351,   5.75      ,   5.91668701,   6.08334351,
         6.25      ,   6.41668701,   6.58334351,   6.75      ,  6.91668701,   7.08334351,   7.25      ,   7.41668701,
         7.58334351,   7.75      ,   7.91668701,   8.08333302,  8.25      ,   8.41666698,   8.58333302,   8.75      ,
         8.91666698,   9.08333302,   9.25      ,   9.41666698,  9.58333302,   9.75      ,   9.91666698,  10.08333397,
        10.25      ,  10.41666698,  10.58333397,  10.75      ,  10.91666698,  11.08333397,  11.25      ,  11.41666698,
        11.58333397,  11.75      ,  11.91666698,  12.08333397,  12.25      ,  12.41666698,  12.58333397,  12.75      ,
        12.91666698,  13.08333397,  13.25      ,  13.41666698,  13.58333397,  13.75      ,  13.91666698,  14.08333397,
        14.25      ,  14.41666698,  14.58333397,  14.75      ,  14.91666698,  15.08333397,  15.25      ,  15.41666698,
        15.58333397,  15.75      ,  15.91666698,  16.08333397,  16.25      ,  16.41666794,  16.58333397,  16.75      ,
        16.91666794,  17.08333397,  17.25      ,  17.41666794,  17.58333397,  17.75      ,  17.91666794,  18.08333397,
        18.25      ,  18.41666794,  18.58333397,  18.75      ,  18.91666794,  19.08333397,  19.25      ,  19.41666794,
        19.58333397,  19.75      ,  19.91666794,  20.08333397,  20.25      ,  20.41666794,  20.58333397,  20.75      ,
        20.91666794,  21.08333397,  21.25      ,  21.41666794,  21.58333397,  21.75      ,  21.91666794,  22.08333397,
        22.25      ,  22.41666794,  22.58333397,  22.75      ,  22.91666794,  23.08333397,  23.25      ,  23.41666794,
        23.58333397,  23.75      ,  23.91666794,  24.08333397,  24.25      ,  24.41666794]
and here is the first index record from the corresponding ARL format file:

Code: Select all

13 8 1 099 099INDX   0 0.0000000E+00 0.0000000E+00
AWRF168 061.0500387.600.200000.200000.000000.000000.0000001.000001.0000041.4500348.200.000000198 99 22 115561.000012
As I understand it .200000 and .20000 are the lat-lon grid spacings and 41.4500 and 348.200 are the lat-lon coordinates of the lower left grid corner cell. Any idea what causes this?

Re: Strange result when converting WRF output to ARL format

Posted: October 5th, 2017, 4:51 pm
by Fantine
In the arw2arl package, when the setmap.f subroutine deals with a lat-lon projection, the parameters are rounded up to an integer and then divided by 10.0 that becomes 0.2 deg in your case (shown below). So, the "NINT" should be removed.

! defines a latitude-longitude grid (use 0->360)
ELSEIF(iproj.EQ.6)THEN
! kilometers per degree latitude (radius earth = 6370 km)
! define only to the nearest 0.1 degree
! note HYSPLIT assumes earth = 6371.2 km
KMPDEG=2.0*3.14159265*6370.0/360.0
GRIDS(3)=NINT(10.0*dykm/kmpdeg)/10.0
GRIDS(4)=NINT(10.0*dxkm/kmpdeg)/10.0

Would you please provide a sample WRF file in lat-lon project that we can test the code? Thanks!

Re: Strange result when converting WRF output to ARL format

Posted: October 6th, 2017, 5:35 am
by John.Johansson
Yes, this seems like it would explain the results I got. Any idea what the purpose of rounding the numbers might have been?

You can download one of the WRF output files for the inner domain from here:
https://chalmersuniversity.box.com/s/1 ... sv0rphg43e

Unfortunately it is quite large (~800 MB). I hope that is okay.

Thank you!

Re: Strange result when converting WRF output to ARL format

Posted: October 6th, 2017, 4:35 pm
by christopher.loughner
This bug is now corrected. Please copy the attached files (setmap.f.fix.txt and cfgrec.f.fix.txt) into your data2arl/arw2arl/ directory, rename them setmap.f and cfgrec.f, and recompile. This bug fix corrects the rounding issue of the reference lat and lon, corrects the sync lat and lon calculation, and allows for more decimal places to be written out to the ARLDATA.CFG file, which in turn improves the precision of the header variables in the ARL formatted file. We will get this update uploaded to the HYSPLIT respository. Thanks.

Re: Strange result when converting WRF output to ARL format

Posted: October 17th, 2017, 1:21 pm
by John.Johansson
Thank you fixing this problem so quickly!

I have now downloaded the fixed source code, recompiled and tested it. The output grid from arw2arl now seems to be correct for my use case. I also checked the output for my outer domain files with 0.5 degrees resolution and compared to the old output. This made me realize that the old code gave an incorrect output grid for this domain too. For instance, the first and last latitude for the WRF grid was 31.25 and 72.75, but in the old arw2arl output file they were instead 31.0 and 72.5. The longitudes were also rounded down to the nearest multiple of 0.5. The output from the updated code seems to have fixed this problem too though.