.. role:: underline :class: underline :orphan: .. _Back to top: =============================================== Known Problems and Solutions for WRF Versions 4 =============================================== | .. note:: This page only displays known problems with WRFv4+. For problems in version 3, `see Known Problems and Solutions for WRF Versions 3 <./older_wrf/wrfv3_known_problems.html>`_ | | | .. _KP WRFV4.4: WRFV4.4 ======= | | :underline:`The following applications are known to be problematic and may not run to completion` * Lightning Option 3 * SSiB LSM (when using restart option) **Solution:** There is currently no solution. | | :underline:`The following applications are known to NOT give bit for bit identical answers with a restart` * Lightning Option 11 * WRF-Solar EPS **Solution:** There is currently no solution. | | .. rst-class:: horizbuttons-next-m * :ref:`Back to top ` | | | | | .. _KP WRFV4.3: WRFV4.3 ======= | :underline:`The following applications are known to be problematic and may not run to completion` * Lightning Option 3 * SSiB LSM (when using restart option) * NSSL option 22 microphysics * Obs Nudging **Solution:** There is currently no solution. | | :underline:`The following applications are known to NOT give bit for bit identical answers with a restart` * SKEBS * adaptive time-stepping (when using nested feedback) * Eta-Ferrier microphysics * SBM Full microphysics * GFDL Radiation * Lightning Options 1 and 2 * LCZ Wudapt with Urban option 3 **Solution:** There is currently no solution. | | .. rst-class:: horizbuttons-next-m * :ref:`Back to top ` | | | | | .. _KP WRFV4.2: WRFV4.2 ======= | :underline:`Restarts not bit-for-bit identical when starting from a non-boundary time` **Problem:** For at least the last several major release versions there has been a problem with restart runs if they are not restarted at a boundary time. The simulation completes without errors, but if one were to compare output files for the original simulation and the restart run at identical times, there would be minor differences in the file. **Solution:** There is no solution at this time. It is recommended to try to restart at boundary times. | | :underline:`Restarts not bit-for-bit identical with lightning options 1, 2, and 11` **Problem:** When using lightning_option = 1, 2, or 11, and running a restart, simulation results will not be bit-for-bit identical when comparing output for the same time for the original simulation and the restart simulation unless cudt is set to 0. **Solution:** For now, it is recommended to set cudt = 0 for all domains when using the lightning option and restarts. | | :underline:`Lightning option 3 segmentation fault` **Problem:** If using lightning_option = 3, the run will seg-fault soon after the simulation begins. This behavior has been seen with both GNU and Intel compilers (but is likely a problem with others too). **Solution:** There is currently no solution. Users will not be able to use lightning_option = 3 at this time. This has been a problem for several versions now. | | :underline:`Restarts not bit-for-bit identical with other options` * adaptive time-stepping * Eta/Ferrier microphysics * SBM (full) microphysics * GFDL radiation * SSIB LSM **Problem:** When using any of the options use_adaptive_time_step=.true. (for multiple domains), mp_physics=5, mp_physics=32, ra_lw_physics=99 & ra_sw_physics=99, or sf_surface_physics=8 and running a restart, simulation results will not be bit-for-bit identical when comparing output for the same time for the original simulation and the restart simulation. **Solution:** There is currently no solution to this problem. The restart simulation will complete and results should likely be reasonable, regardless of the minor differences. | | .. rst-class:: horizbuttons-next-m * :ref:`Back to top ` | | | | | .. _KP WRFV4.1: WRFV4.1 ======= | :underline:`Recurring issues from previous version(s)` **"Ran out of valid boundary conditions in file wrfbdy_d01" infinite loop** |br| If a user starts a simulation after the last LBC valid period, the WRF model goes into an infinite loop and prints out the following repeated statements: .. code-block:: 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 | *See the solution in :ref:`KP WRFV4.0`.* | | :underline:`Newer GNU Internal Compiler Error with Bounds Checking` **Problem:** Starting with GNU/6.4.1 and continuing through (at least) GNU/7.3.0, the fast RRTMG scheme is not able to compile when using the "-d" or "-D" options on the configure command. Starting with GNU/8.1.0, the code is able to build with the debug options. .. code-block:: ./configure -D | Below is the message after the build: .. code-block:: 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) | **Solution:** 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: .. code-block:: -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. | | .. rst-class:: horizbuttons-next-m * :ref:`Back to top ` | | | | | .. _KP WRFV4.0: WRFV4.0 ======= | :underline:`Newer GNU Internal Compiler Error with Bounds Checking` **Problem:** 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``), and the following message appears in the compile log. .. code-block:: 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) | **Solution:** Currently, the solution is to remove the offending code (RRTMG fast for longwave and shortwave). After *configure.wrf* is created (by the configure step, and before the compile step), it should be edited. Remove the following line and the code should be able to build as usual. *Note that in this condition, the WRF code may not be used to run either of the fast RRTMG schemes*. .. code-block:: -DBUILD_RRTMG_FAST=1 \ | | :underline:`Problem with half versus full 1d coefficients for hybrid vertical coordinate` **Problem:** 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. **Solution:** 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 `_ for more explanation, and specifics of the file modifications, or `download the modified module_small_step_em.F file `_. Place the modified file in the 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. | | :underline:`Problem with pressure field when 'use_theta_m' is turned on (or set to '1,' which is the default)` **Problem:** Upon initialization of WRF, a pressure error 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. **Solution:** 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 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 use_theta_m GitHub commit `_, or `download the modified start_em.F file `_. Place the modified file in the dyn_em/ directory and then recompile the code. There is no need to issue a 'clean -a' or to reconfigure prior to recompiling. | | :underline:`Bug in RRTMG with o3input=2 option` **Problem:** 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. **Solution:** The above problem is corrected in the phys/module_radiation_driver.F file. `See the GitHub commit `_ for additional details and specific code modifications, or `download the corrected module_radiation_driver.F file `_. Place the modified file in the phys/ directory and then recompile the code. There is no need to issue a 'clean -a' or to reconfigure prior to recompiling. | | :underline:`mismatch_landmask_ivgtyp Error` **Problem:** 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: .. code-block:: -------------- FATAL CALLED --------------- FATAL CALLED FROM FILE: LINE: 2963 mismatch_landmask_ivgtyp ------------------------------------------- | **Solution:** This problem 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 mismatch_landmask_ivgtyp GitHub commit `_ or `download the corrected module_initialize_real.F file `_. 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. | | :underline:`Problem with Noah-MP with no urban option turned on` **Problem:** 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. **Solution:** 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 `_ for additional details and specifics on the code modification, or `download the corrected module_sf_noahmplsm.F file `. 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. | | :underline:`"Ran out of valid boundary conditions in file wrfbdy_d01" infinite loop` **Problem:** 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: .. code-block:: 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 | **Solution:** The file share/input_wrf.F has been modified to resolve the problem. `See the GitHub commit `_ for additional details and specifics on the code modification, or `download the corrected input_wrf.F file `_. 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. | | .. rst-class:: horizbuttons-next-m * :ref:`Back to top ` | | | | |