0 values within FXLONG and FXLAT in wrf-fire output

[pearse]

In the wrf-fire datasets I've worked with, the FXLONG and FXLAT coordinate variables contain 0's at the spatial domain's boundary. Since they also have no _FillValue attribute, some post-processing software package like Vapor have trouble reading the contained 2D variables.

Is there a good place that I can make a feature request to change this? I don't know if there may be a good reason to keep it.

Example `ncdump -v FXLAT` on wrf-fire output:

...
40.19511, 40.19512, 40.19511, 40.19511, 40.19511, 40.19511, 40.19511,
40.19511, 40.19511, 40.19511, 40.19511, 40.19511, 40.19511, 40.1951,
40.1951, 40.1951, 40.1951, 40.1951, 40.19509, 40.19509, 40.19509,
40.19508, 0, _, _, _, _,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
...

 

[Ming Chen]

Hi,
I suppose this is an ideal WRF-FIRE run. Please let em know if I am wrong.
fxlong and flat are 'fake' coordinate with unit of 'meter'. They are specified in the code phys/module_fr_fire_util.F. Please look at the following piece of code and modify if necessary:

277 do j=jfts,jfte

278 do i=ifts,ifte

279 ! uniform mesh, lower left domain corner is (0,0)

280 fxlong(i,j)=(i-ifds+0.5)*dxf

281 fxlat (i,j)=(j-jfds+0.5)*dyf

282 enddo

283 enddo

An alternative way is to directly modify these variables in your wrfout. NCL and Python both can be applied to do so. Please see the website here for the NCL example to modify data:

https://www.ncl.ucar.edu/Applications/change_netCDF.shtml:

 

[pearse]

Hi Ming, thanks for the tips. I'm actually trying to make a request that this gets implemented in the main code repository so that there is no need for post-processing in the future.

Is there a github repository or some place similar that I can make this request? I've made similar requests for models like CM-1 that have made our users' lives much easier.

 

[Ming Chen]

Please issue a PR in GitHub. here is the website for WRF repository:

GitHub - wrf-model/WRF: The official repository for the Weather Research and Forecasting (WRF) model

The official repository for the Weather Research and Forecasting (WRF) model - GitHub - wrf-model/WRF: The official repository for the Weather Research and Forecasting (WRF) model

github.com

 

[frediani]

If I understand this correctly, these zeros appear in the last row/column of the domain and may require extrapolation of the coordinates beyond the unstaggered grid coordinates. Scott's coordinates are not for an ideal case, the lat values are 40.xxx.

In the meantime, for plotting purposes, the fire points in the array on the last column/row can be ignored.
I know this doesn't solve the issue in Vapor, but here's a suggestion that works in Python:

nc = Dataset(filename, 'r')
nx = nc.getncattr('WEST-EAST_GRID_DIMENSION')
ny = nc.getncattr('SOUTH-NORTH_GRID_DIMENSION')
# Calculate the refinement ratio - assumes the same ratio in x and y
sr = nc.dimensions['south_north_subgrid'].size / ny # refinement ratio

# Fire variables valid values are within nx-1, ny-1
nrx = int((nx-1) * sr) +1
nry = int((ny-1) * sr) +1

# In the fire domain, rows and cols at domain edge don't exist, so crop them out
fxlon = np.squeeze(nc.variables['FXLONG'][:])[:nry,:nrx]
fxlat = np.squeeze(nc.variables['FXLAT'][:])[:nry,:nrx]
fire_area = np.squeeze(nc.variables['FIRE_AREA'][:])[:nry,:nrx]