bug fix: initialize lat/lon with zeros only for nested fire runs

[masih-e]

TYPE: bug fix

KEYWORDS: idealized fire nested domain simulation

SOURCE: Found by Masih Eghdami (NCAR), Pedro Jimenez (NCAR)

DESCRIPTION OF CHANGES:
Problem:
The atmospheric coordinates (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 in share/interp_fcn.F:

CALL wrf_error_fatal ( 'Nest over the pole, single input domain, longitudes will be wrong' )

Solution:
The lat/lon are initialized with zeros similar to LES idealized cases only if the model has 2 domains to prevent the error. If the model is run with 1 domain, the lat/lon are written with spatial coordinates allowing easier post-processing.

ISSUE: This PR addresses the discussion in #1412 with @pedro-jm and @janmandel.

LIST OF MODIFIED FILES:
module_initialize_fire.F

TESTS CONDUCTED:

1. Yes, the nested idealized fire case runs without the error described above.
2. They are passing.

[dudhia]

changes confined to fire code

[davegill]

@masih-e @dudhia @janmandel @pedro-jm
Is it still not the case that a domain with 100 grid cells in the north-south direction would fail, whether it is a nest or the coarse grid?

[masih-e]

The number of grid cells is not causing the error. It is the value of XLAT exceeding 85 that triggers the error. The error is called in an interpolation subroutine only for nested domains. Therefore, a single domain run should be fine regardless. I hope that answers the question @davegill

The base branch was changed.

[davegill]

@masih-e @janmandel @pedro-jm
If the code is disabled for nested simulations (and things run OK), then why have the lat/lon assignments required for the single domain runs?

Basically, I am just bothered by the half-way solution.

1. If no lat/lon assignment is required (which it does not seem to be), then we can just completely remove the coordinate setting step. Is that right?
2. If a lat/lon assignment is a good idea, then do not leave the answer in meters. The center lat/lon of the domain is available. Assuming a really high resolution domain, a cartesian coordinate assumption is reasonable. Just set the center of the domain to be (cen lon, cen lat), and scale the rest of the values based on the grid distance.

[pedro-jm]

@davegill

1. You are correct. We can remove the coordinate setup and the code would run fine. The coordinate set up is useful for visualization.
2. Note that the fix only affects idealized runs and for these runs there is no geolocation available for the fire case at this moment.
   Pedro.

[davegill]

@pedro-jm @janmandel @masih-e
Folks,
This is an idealized initialization for WRF Fire. As Jimy said, this is entirely "in" WRF Fire. I defer to your preferences in this matter.

[davegill]

@pedro-jm @janmandel @dudhia @weiwangncar @masih-e
Folks,

1. The initialization is not required for the model.
2. The initialization is used for visualization.
   Therefore we can leave the PR as it is.

Later, should anyone want to fix this, the projection information is defined in module_initialize_fire.F:

    CALL nl_set_iswater(1,0)
    CALL nl_set_cen_lat(1,40.)
    CALL nl_set_cen_lon(1,-105.)
    CALL nl_set_truelat1(1,0.)
    CALL nl_set_truelat2(1,0.)
    CALL nl_set_moad_cen_lat (1,0.)
    CALL nl_set_stand_lon (1,0.)
    CALL nl_set_pole_lon (1,0.)
    CALL nl_set_pole_lat (1,90.)
    CALL nl_set_map_proj(1,0)

This current routine would make a great way to initialize the lat lons for many of the 3d idealized cases.