Using 'lat-lon' map projection in WRF, assigns Cassini projection in DART
### Describe the bug
When using WRF-DART while applying WRF 'lat-lon' map projection for land/atmosphere -- DART misinterprets 'lat-lon' map projection as cassini.
Expectation:
When using WRF 'lat-lon', that DART uses the map_latlon and PROJ_LATLON options in model_mod to perform interpolation
What happens instead:
DART uses map_cassini and PROJ_CASSINI instead. This occurs because WRF assign an integer value of '6' for the 'MAP_PROJ' attribute using map_latlon, whereas DART assigns an integer value of '0' for PROJ_latlon. DART incorrectly calls subroutine llij_cassini instead of llij_latlon, which is the incorrect forward operator.
### Which model(s) are you working with? Tested with WRF version 3.9 thru 4.5
### Version of DART
Latest tag
### Have you modified the DART code?
No -- but quick fix would be to reassign the integers within DART such that PROJ_LATLON = 6 and map_latlon = 6. Then assign cassini a different integer, such as PROJ_CASSINI = 106 or map_cassini = 106. See misc_definitions_module and
model_mod.f90 for more details.
All other WRF supported map projections are aligned properly with DART -- including lambert, mercator and polar. No changes required. The WRF-DART tutorial using the lambert map projection.
I thought this integer change for the latlon MAP_PROJ occured between WRF version 3 and more recent versions of WRFv4+, and this change was missed during the WRF-DART version 4 tutorial updates, however, both WRFv3 and v4 versions have this integer mismatch with DART.
Bug, first reported by Rui Sun (UCSD).
### Compiling information Derecho using gfortan
Forgot to mention that DART uses the MAP_PROJ integer attribute from the WRF land/atm files to assign the integer in DART. This is read within read_wrf_file_attributes
what would happen with WRF files that did have 0 as the projection type integer? would those still work?
I don't know if WRF generates MAP_PROJ = 0 anymore. I guess at some point it did, perhaps the 'lat-lon' projection at one point was at '0', but testing version 3.9 for the latest versions 4.5 does not produce MAP_PROJ = 0 for any supported map projection that I can tell.
Currently, if MAP_PROJ = 0, DART interprets as 'lat-lon' which is incorrect. If I implemented suggested changes, a MAP_PROJ = 0 should cause DART to error out.
just for reference, i looked up some older wrfinput_d01 files from CONUS runs and they use map projection 1. so maybe this change wouldn't break anything.
just for reference, i looked up some older wrfinput_d01 files from CONUS runs and they use map projection 1. so maybe this change wouldn't break anything.
What was the WRF version of the wrfinput_d01? As far as I know map projection 1 has always referred to the lambert projection Projection 1 --> lambert Projection 2 --> polar Projection 3 --> mercator Projection 6 --> lat-lon, although at some point was '0' according to DART.
I would need to dig into the WRF code (WPS ) to find all possibilities when I find time
yes - the conus runs i usually saw were using a lambert projection, not straight lat/lon. plotted on a lat/lon grid, the area was a section of a wedge, not a square. that was one of the reasons we used the wrf utils to map from lat/lon to i/j index in the wrf arrays.
@braczka @nancycollins
This comment also needs updated as we are supporting different projections than this now. The following projection codes are parameters in module_map_utils.f90 but are not listed in the supported:
! Projection codes for proj_info structure:
INTEGER, PUBLIC, PARAMETER :: PROJ_PS_WGS84 = 102
INTEGER, PUBLIC, PARAMETER :: PROJ_CYL = 5
INTEGER, PUBLIC, PARAMETER :: PROJ_ALBERS_NAD83 = 105
INTEGER, PUBLIC, PARAMETER :: PROJ_CASSINI = 106
And in the model_mod, we allow for the use of the following projections: (note you can scroll down to see the rest of the lines in this permalink) https://github.com/NCAR/DART/blob/e79746d96bf9eba7846ca23e445407b4193aca94/models/wrf/model_mod.f90#L7432-L7449
So at least we should add PROJ_CASSINI and PROJ_CYL to the list of supported.
But what about the other 2 (PROJ_PS_WGS84 = 102 and PROJ_ALBERS_NAD83 = 105)? Are WRF files able to have these values as the projection type integer? Do we have plans to support these projection codes if so?
Finally, PROJ_GAUSS and PROJ_ROTLL are both listed in the supported projections and are parameters in module_map_utils.f90, but we do not allow for the use of them in the model_mod - so I don't know if we should keep them listed as supported or keep the parameters in module_map_utils.f90
@mjs2369 I agree the comments are confusing. From what I can tell the DART comments are inherited directly from the WRF code documentation and comments -- which are confusing. The WRF-ARW documentation states that 5 projections are supported, but if you go to the WPS geogrid source code which generates the maps, the comments suggest 6 projections are supported. Go a little deeper and source code shows support for 10 projections. It's potentially WRF-ARW, WRF-NMM dependent......
Technically this PR intended to only resolve the Cassini projection bug, but it would be worth identifying what integer WRF currently assigns to all 10 possible projections.
@mjs2369 I agree the comments are confusing. From what I can tell the DART comments are inherited directly from the WRF code documentation and comments -- which are confusing. The WRF-ARW documentation states that 5 projections are supported, but if you go to the WPS geogrid source code which generates the maps, the comments suggest 6 projections are supported. Go a little deeper and source code shows support for 10 projections. It's potentially WRF-ARW, WRF-NMM dependent......
Technically this PR intended to only resolve the Cassini projection bug, but it would be worth identifying what integer WRF currently assigns to all 10 possible projections.
For clarity, it looks like DART supports all possible projections (10 possible) within module_map_utils.f90. The integer mismatch between WRF and DART is at issue. The common projections will match with PR (lambert, lat-lon, mercator, polar,cassini), but will doublecheck others (PS_WGS84, GAUSS, CYL,ALBERS_NAD83, ROTLL).