initialize lat/lon with zero to fix nested ideal fire runs

[masih-e]

The lat/lon coordinates are initialized with spatial coordinates that create a fatal error when running idealized nested fire cases

TYPE: bug fix

KEYWORDS: idealized fire nested domain simulation

SOURCE: Masih Eghdami (NCAR)

DESCRIPTION OF CHANGES:
Problem:
The lat/lons are initialized with spatial coordinates, this will create a fatal error when the model is run with nested domains. The error is because lat>90.
CALL wrf_error_fatal ( 'Nest over the pole, single input domain, longitudes will be wrong' )

Solution:
Initialize the lat/lon with zeros similar to LES idealized cases.

LIST OF MODIFIED FILES: module_initialize_fire.F

TESTS CONDUCTED:

1. Yes, the model runs without producing the error.

[davegill]

@masih-e
I looked in the registry.fire file. These fields are already assigned to zero:

grep -i fire_lat_init *
registry.fire:rconfig   real    fire_lat_init          namelist,fire         max_domains           0.      -      "fire_lat_init"    "latitude to start fire"           "degrees"
etotheipi:/Users/gill/Desktop/WRF_noahmp/Registry>grep -i fire_lon_init *
registry.fire:rconfig   real    fire_lon_init          namelist,fire         max_domains           0.      -      "fire_lon_init"    "longitude to start fire"          "degrees"

These run-time options are defined in the namelists in the em_real directory:

find . -name namelist\* -exec grep -iw fire_lat_init {} \; -print
!fire_lat_init      =   40.,    ! real   , initial fire latitude (deg)
 fire_lat_init      = 6.75e-3,  ! real   , initial fire latitude (deg)
./em_real/namelist.input.fire

find . -name namelist\* -exec grep -iw fire_lon_init {} \; -print
!fire_lon_init      = -105.,    ! real   , initial fire longitude (deg)
 fire_lon_init      = 6.70e-3,  ! real   , initial fire longitude (deg)
./em_real/namelist.input.fire

Perhaps there is another problem.

[masih-e]

I see. So those lines are fine. It's only the call set_ideal_coord() should be removed which is overwriting the 253 and 254.

[davegill]

@masih-e @janmandel @pedro-jm
Take a look in phys/module_fr_fire_util.F at subroutine set_ideal_coord.

 276                 ! set fake  coordinates, in m
 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

This look to be the cause of the trouble.

I suggest that this PR be closed, and that a new PR that directly addresses your problem be opened. Likely something that modifies the simple assignment. If the results are currently in meters, maybe include a scale factor for the number of meters in a degree of latitude.

I have included two individuals that you should include on the discussions for the other PR.

[masih-e]

Thanks, will do.

[janmandel]

@masih-e @davegill @pedro-jm @Fergui

fxlong and fxlat are needed for ignition. Both fxlong/fxlat and xlong/xlat are needed for visualization in postprocessing but xlong/xlat are used in the fire code only to interpolate to fxlong/fxlat in real runs (fxlong/fxlat used to be set in a modified WPS, Pedro added the call to the interpolation from phys/module_fr_fire_driver.F in e26f21f). As far as I can tell xlong/xlat are not used in the fire code for anything else.

The lines setting xlong/xlat in dyn_em/module_initialize_fire.F were in WRF-Fire submitted to WRF for v3.3 3cdb542, then in WRF from V3.3 cd86778 until they were deleted in 26f21fb33ecdee7ba3 #403, as they are not needed. They came back through hand merge 0c304f6 #792 with our earlier code. This merge was probably me working with Angel, who was driving. We never tested multi-domain ideal cases, is it new?

As far as WRF itself is concerned, the lines setting xlong xlat can be deleted now again.

But it would be really really good to have xlong xlat set to something reasonable even in ideal runs, since they are needed for visualization and diagnostics. We needed xlong/xlat e.g., for VAPOR. Once it is decided what to set them to, the fire code ignition can adapt. This would require changing all ideal test cases at least.

Thanks,
Jan

[pedro-jm]

@janmandel

We can use normalized units of distance within the grid. With this coordinate change the center of the domain would be (0.5, 0.5) for both the atmospheric and the fire grid. Something in this direction:

276 ! set fake coordinates, in normalized distance within the grid
277 do j=jfts,jfte
278 do i=ifts,ifte
279 ! uniform mesh, lower left domain corner is (0, 0) and the upper right corner is (1, 1)
280 fxlong(i,j)=(i - ifds + 0.5) / real (ifde, kind = kind (fxlong))
281 fxlat (i,j)=(j - jfds + 0.5) / real (jfde, kind = kind (fxlat))
282 enddo
283 enddo

Let me know what you think.

[janmandel]

@pedro-jm @adamk0 @Fergui

Good idea. Also the ignition would be much easier to set and it would not have to be redone when the mesh resolution changes.

But, maybe for xlong/xlat? Then fxlong/fxlat can be set by interpolation as in real, no special code for ideal. Besides fxlong/fxlat did not cause the issue.

Also, there should be a two-domain ideal test case in the regression test to make sure this works in future. Actually we do have some, but I do not think they worked, at least not recently: fireflux fireflux_ak

[pedro-jm]

@janmandel
I am trying to understand.
You propose is to fill in the atmospheric lat/lon with the normalized distance and then from this normalized distance in the atmospheric grid calculate the normalized distance in the fire grid.
Is not this the same to calculate the normalized distance in the atmospheric grid and the fire grid independently as it is done now?

[janmandel]

@pedro-jm @adamk0 @Fergui @masih-e @davegill

I had the opportunity to bring it up with my group today and we would actually prefer to fill the xlong xlat variables with valid longitude and latitude in ideal runs, perhaps specify the coordinates of the center of the domain in namelist.input. We had difficulties with VAPOR and artificial coordinates from ideal runs and postprocessing can get complicated. It would be really nice to be able to treat output from ideal runs just like output from real runs.

We have tried nested ideal runs before and could not make them work. It is great to see that there is interest in WRF community now. Could someone point me to a working nested ideal test case to start from, please?

Thanks!

Jan

[pedro-jm]

@janmandel

That should work too. I see two options to allow for nested simulations in the idealized fires.

Option 1) Here we can keep current functionality + allow to run nested fires. This option will allow you to continue doing visualizations with VAPOR with your current format (1 dom runs) + will allow to run nested fire simulations (without solving visualization issues). The fix is quite simple. We just need to fill in the lat/lon of the atmospheric grid only if it is a 1 domain simulation. This is the fix (adding the if statement):

if (grid%max_doms == 1) then
call set_ideal_coord( grid%dx,grid%dy, &
ids,ide,jds,jde, &
ims,ime,jms,jme, &
its,ite,jts,jte, &
grid%xlong,grid%xlat )
end if

Option 2) Filling in the lat/lon of the atmospheric grids in the way you suggested to have real geolocation in the atmospheric grid. This will allow to run nested idealized domains and fix the visualization. You can lead this development in my opinion since I can see the potential.

It would be good to have the idealized nested domains fixed for the upcoming WRF release. Option 1 is easy and we can take care of it. If we do not think option 2 will make it for the next release I would be in favor to implement option 1 now, and then update the model with option 2 in future releases.

Let me know what you think.

[pedro-jm]

@janmandel
We will put the PR for the option 1 above so we can run nested idealized simulations keeping the rest of the model functionality as it is. Hopefully we will make it for the upcoming release. You can upgrade this in a subsequent PR (e.g. having real lats/lons in the idealized runs).