WRF Known Problems V4.0
(Posted June 8, 2018)
Starting with GNU/6.4.0 and continuing through (at least) GNU/7.2.0, the fast RRTMG scheme is not able to compile when using the "-D" option on the configure command.
./configure -D
Below is the message users will see after the build:
module_ra_rrtmg_swf.f90:5612:0:
use rrsw_kg21_f, only : kao, kbo, selfrefo, forrefo, sfluxrefo, &
internal compiler error: in gfc_trans_use_stmts, at fortran/trans-decl.c:4920
module_ra_rrtmg_swf.f90:5612:0: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951)
Currently, the solution is to remove the offending code (RRTMG fast for longwave and shortwave). After the user constructs the configure.wrf file (after the configure step, and before the compile step), the configure.wrf file is edited. Remove this line:
-DBUILD_RRTMG_FAST=1 \
Then the code may be built as usual. Note that in this condition, the WRF code may not be used to run either of the fast RRTMG schemes.
(Posted April 17, 2019)
Beginning with the original implementation of the hybrid vertical coordinate (v3.9), there are several locations in the small_step routine where the "mu" array with the "t_2" field was incorrectly assigned to full levels. The differences one may see are typical of a small perturbation in an initial condition. The differences do not look unphysical.
In three statements where the half-level t_2 array is used, the half-level c1h and c2h 1d arrays replace the incorrect full-level 1d arrays c1f and c2f to correct the problem. See the GitHub commit here for more explanation, and specifics of the file modifications. You can also download the modified file here: Modified module_small_step_em.F
You will need to place the modified file in your dyn_em/ directory and then recompile the code. There is no need to issue a 'clean -a' or to reconfigure prior to recompiling.
This same functionality of modification for v4.0 would need to go into v3.9, v3.9.1, and
v3.9.1.1.
Upon initialization of WRF, there is an initial error in pressure that is introduced - 3000 Pa. The imbalance quickly decays, but the perturbations are enough to change the larger scale solution, which leads to pressure differences around 3000 Pa.
An if-test is introduced in the dyn_em/start_em.F file. The if-test is based on the namelist option use_theta_m, and tests whether or not to assign the factor qvf as either 1 or ( 1 + Rv/Rd Qv ). For more explicit details and specifics of the code modifications, see the GitHub commit here. You can also download the modified file here: Modified start_em.F
You will need to place the modified file in your dyn_em/ directory and then recompile the code. There is no need to issue a 'clean -a' or to reconfigure prior to recompiling.
When RRTMG is turned on with CAM ozone as input (o3input=2), the variable ozmixm has 13 elements in time dimension, and monthly ozone data is stored in the 2nd to 13th elements, corresponding to 1-12 month. In the subroutine "ozn_time_int", however, the time dimension for "ozmixm" is not specified accordingly. This causes the interpolation to be off by 1 month, giving an incorrect zero-value.
The above problem is corrected in the phys/module_radiation_driver.F file. See the GitHub commit here for additional details and specific code modifications. You can also download the corrected file here: Modified module_radiation_driver.F
You will need to place the modified file in your phys/ directory and then recompile the code. There is no need to issue a 'clean -a' or to reconfigure prior to recompiling.
When running real.exe with some datasets (seen often with ERA-interim, but has also been seen with CFSR and GFS), along with the default namelist.input option "surface_input_source = 3", users see the fatal error:
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: LINE: 2963
mismatch_landmask_ivgtyp
-------------------------------------------
This was a problem that began in V3.8 when the default for surface_input_source was changed from 1 to 3. The file dyn_em/module_initialize_real.F was modified to fix the problem. For detailed information on the problem, fix, and for the specifics of the modified code, see the GitHub commit here. Users can download the corrected file here: Modified module_initialize_real.F
You will need to place the modified file in your dyn_em/ directory and then recompile the code. There is no need to issue a 'clean -a' or to reconfigure prior to recompiling.
When running Noah-MP with no urban scheme (bulk method), the roughness length in urban areas used a bare soil value. This resulted in a high temperature, high wind speed, and low sensible heat flux over cities.
A correction is made to the phys/module_sf_noahmplsm.F file to use z0 from the Noah-MP look-up table. See the GitHub commit here for additional details and specifics on the code modification. Users can download the corrected file here:Modified module_sf_noahmplsm.F
You will need to place the modified file in your dyn_em/ directory and then recompile the code. There is no need to issue a 'clean -a' or to reconfigure prior to recompiling.
If a user tried to start a simulation after the last LBC valid period, the WRF model would get into an infinite loop and print out repeated statements:
THIS TIME 2000-01-24_18:00:00, NEXT TIME 2000-01-25_00:00:00
d01 2000-01-25_06:00:00 Input data is acceptable to use: wrfbdy_d01
2 input_wrf: wrf_get_next_time current_date: 2000-01-24_18:00:00 Status = -4
d01 2000-01-25_06:00:00 ---- ERROR: Ran out of valid boundary conditions in file wrfbdy_d01
The file share/input_wrf.F has been modified to resolve the problem. See the GitHub PR for additional details and specifics on the code modification. Users can download the corrected file here:Modified input_wrf.F
You will need to place the modified file in your share/ directory and then recompile the code. There is no need to issue a 'clean -a' or to reconfigure prior to recompiling.