Merge 4.1.4 #44
Merged
Merge 4.1.4 #44
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
TYPE: bug fix KEYWORDS: deng, shcu, check-a-mundo, MYJ, MYNN SOURCE: Internal DESCRIPTION OF CHANGES: When using the Deng shcu scheme, one must use either the MYJ or MYNN PBL scheme. There was a check in module_check_a_mundo.F for this, but the logic was incorrect, meaning that a user would always get a fatal error when using the Deng scheme. Modified logic to correct this. LIST OF MODIFIED FILES: M share/module_check_a_mundo.F TESTS CONDUCTED: none RELEASE NOTE: Bug fix for Deng shallow cumulus scheme (the scheme and the bug were introduced in release-v4.1). If using the Deng scheme, it is mandatory to use either the MYJ or MYNN PBL scheme. However, even when using one of these required PBL schemes, users would receive a fatal error due to incorrect logic in the check. This check has been corrected.
…umber of processors (wrf-model#896) TYPE: bug fix KEYWORDS: WRFDA, hybrid_dual_res, adjoint, MPI SOURCE: Jamie Bresch (NCAR) DESCRIPTION OF CHANGES: With hybrid_dual_res, different number of processors give significant different analysis results. The differences show up as early as in the initial gradient values. The fix to sum up adjoint contribution among processors. With one processor, the results are identical before and after the fix. ISSUE: Fixes wrf-model#894 LIST OF MODIFIED FILES: M var/build/depend.txt M var/da/da_vtox_transforms/da_calc_flow_dependence_xa_adj_dual_res.inc A var/da/da_vtox_transforms/da_dual_res_c2n_ad.inc M var/da/da_vtox_transforms/da_vtox_transforms.f90 TESTS CONDUCTED: Before fix: 1 processor Starting cost function: 1.633993070036564D+04, Gradient= 4.419673919180535D+02 4 processors Starting cost function: 1.633993070036564D+04, Gradient= 4.377463103586127D+02 diffwrf p1/wrfvar_output.orig p4/wrfvar_output.orig ``` Diffing p1/wrfvar_output.orig p4/wrfvar_output.orig Next Time 2008-09-12_00:00:00 Field Ndifs Dims RMS (1) RMS (2) DIGITS RMSE pntwise max U 1578230 3 0.1043087455E+02 0.1043180479E+02 4 0.2696E-01 0.1242E-01 V 1577552 3 0.7075759011E+01 0.7076467776E+01 3 0.2906E-01 0.1308E-01 PH 1569168 3 0.8413483114E+04 0.8413571470E+04 4 0.1639E+01 0.8408E-03 T 1569522 3 0.7443338460E+02 0.7443351883E+02 5 0.1630E-01 0.2400E-02 MU 35685 2 0.5945061610E+03 0.5947561706E+03 3 0.3395E+01 0.6578E-02 P 1570122 3 0.4821838892E+03 0.4821134969E+03 3 0.2021E+01 0.7966E-02 PSFC 35627 2 0.9975677947E+05 0.9975628309E+05 5 0.3381E+01 0.2665E-03 QVAPOR 1509148 3 0.8848210238E-02 0.8848087363E-02 4 0.4800E-05 0.5903E-02 ``` After fix: 1 processor Starting cost function: 1.633993070036564D+04, Gradient= 4.419673919180535D+02 4 processors Starting cost function: 1.633993070036564D+04, Gradient= 4.419673919180562D+02 diffwrf p1/wrfvar_output.fix p4/wrfvar_output.fix ``` Diffing p1/wrfvar_output.fix p4/wrfvar_output.fix Next Time 2008-09-12_00:00:00 Field Ndifs Dims RMS (1) RMS (2) DIGITS RMSE pntwise max U 698146 3 0.1043087455E+02 0.1043087459E+02 8 0.2220E-04 0.2432E-04 V 828685 3 0.7075759011E+01 0.7075758876E+01 7 0.2597E-04 0.3500E-04 PH 864783 3 0.8413483114E+04 0.8413480134E+04 6 0.1035E-01 0.5664E-05 T 1109573 3 0.7443338460E+02 0.7443339278E+02 6 0.6154E-04 0.5457E-05 MU 34973 2 0.5945061610E+03 0.5944788699E+03 4 0.6649E-01 0.6984E-04 P 1519958 3 0.4821838892E+03 0.4821680178E+03 4 0.3995E-01 0.8473E-04 PSFC 20228 2 0.9975677947E+05 0.9975675966E+05 6 0.6681E-01 0.2855E-05 QVAPOR 372470 3 0.8848210238E-02 0.8848210299E-02 8 0.1076E-07 0.3149E-04 ``` RELEASE NOTE: Fix DA dual-res hybrid significant different results with different number of processors.
TYPE: bug fix KEYWORDS: diff_6th_opt, specified SOURCE: Robert Rozumalski (COMET) DESCRIPTION OF CHANGES: When a restart problem was fixed in 4.0.3 (Dec 18, 2018), an error was introduced. It used a logical variable 'specified' in subroutine sixth_order_diffusion, but it was not defined before it was used. This caused model failure in the case reported by Rob. This PR fixes the problem. ISSUE: Fixes wrf-model#895 "module_big_step_utilities_em.F - logical variable "specified" not assigned" LIST OF MODIFIED FILES: M dyn_em/module_big_step_utilities_em.F TESTS CONDUCTED: Compiled and verified it fixed the user's problem. RELEASE NOTE: Fixed a bug associated with option diff_6th_opt. When a restart problem was fixed in 4.0.3 (Dec 18, 2018), an error was introduced. It used a logical variable 'specified' in subroutine sixth_order_diffusion, but it was not defined before it was used. This caused model failure in a user's case.
TYPE: text only KEYWORDS: missing "," LANDUSE.TBL SOURCE: Rob Gilliam (EPA) DESCRIPTION OF CHANGES: There are two commas ',' missing from LANDUSE.TBL. As was verified this does not affect model results at all. Also, this is not an error that a different compiler would find. This is not an error. This is a cosmetic fix to make the text-based file self-consistent. So we consider this as a 'text change' only. ISSUE: Fixes wrf-model#830 "Typo in LANDUSE.TBL" LIST OF MODIFIED FILES: M run/LANDUSE.TBL TESTS CONDUCTED: Substantial testing was conducted with the reported issue. An extracted subroutine read both the original and new files. No change in results. The following is taken from the issues page: There should be no impact of the missing comma. Since this is list directed input, either white space or a comma would be suitable for parsing the individual fields. D. pulled out the read portion of the routine that handles this file to verify this assertion and ran the code for both MODIS and MODIFIED_IGBP_MODIS_NOAH, and with the original run/LANDUSE.TBL and a corrected file. No diffs in the printed standard out.
…chastic processing TYPE: bug fix KEYWORDS: stochastic, random, pattern, spread, error, seed, dimension SOURCE: problem found by and solution proposed by Judith Berner (NCAR) DESCRIPTION OF CHANGES: The assignment of seeds for random numbers is complicated by the fact that the standard does not provide a fixed number of required seeds. What is provided is a function that returns the necessary dimension of a random seed. Two currently used compilers (Intel and GNU) have the dimensions for the seeds as 2 and 33, respectively. Problem: When multiple ensembles were run with stochastic processing, there was error but no spread. Solution: Judith Berner found that the DO loop for the assignment of value for the random seeds was not being entered, due to the loop bounds. An IF test now checks if a sufficiently large enough seed dimension is available to use a preferred loop. If the seed dimension is too small, then another DO loop is now provided. LIST OF MODIFIED FILES: M dyn_em/module_stoch.F TESTS CONDUCTED: 1. Without the mod, the real-time HRRR cases had zero spread (intel compiler). 2. After the mod, their ensemble results look as expected. 3. Results with this mod are verified by Judith Berner.
…ds floating exception (wrf-model#879) TYPE: bug fix KEYWORDS: effective radius, radiation, exception SOURCE: internal DESCRIPTION OF CHANGES: Problem: This subroutine computes an effective radius given the mass and the number for the cloud, snow, and graupel. 1. When a denominator is zero (in the first time step), this gives a divide-by-0 situation. 2. After a time step, (cloud number / cloud mass < 0) is a problem when using a real exponent. 3. The sum of snow and graupel is used as a denominator. Both can be zero. Solution: Use MAX function to make sure that positive definite values are >= zero, and make sure that denominators are >= a pre-defined small value. 1. Both the cloud mass and the cloud number now use a MAX function with a previously existing value (r1 = 1.e-12). The `rqcmps` variable is local, so it is changed directly. The `nc` variable is INTENT(IN), so the MAX function surrounds this variable (is used in-line) twice. 2. The sum of qs and qg now has a minimum allowable value (r1 = 1.e-12). In the same loop, set the minimum allowable value for each qs and qg (both used in the numerator) to be 0. LIST OF MODIFIED FILES: M module_ra_effective_radius.F TESTS CONDUCTED: - [x] Without mod, code failed in first time step, at (i,j) = (1,1). - [x] With mod, code runs through effective radius calculation OK. - [x] With mod, code completes the regression simulation (10 time steps) with full debugging. MMM Classroom regtest; em_real, nmm, em_chem; GNU only
… data (wrf-model#875) TYPE: bug fix KEYWORDS: LBC, valid time SOURCE: identified by Michael Duda (NCAR/MMM), fixed internally DESCRIPTION OF CHANGES: Problem: 1. If a user tried to start a simulation _after_ the last LBC valid period, the WRF model would get into a nearly 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 ``` 2. If a user tries to extend the model simulation beyond that valid times of the LBC, the code behavior is not controlled (nearly infinite loops on some machines, or runtime errors with a backtrace on other machines). Solution: In another routine, the lateral boundary condition is read to get to the correct time. Once inside of share/input_wrf.F, we should be at the correct time. There is no need to try to get to the next time. In this particular case, the effort to get to the next time fails, but we try again (and again and again). This solution fixes both problems identified above. ISSUE: Fixes wrf-model#769 "WRF doesn't halt when beginning LBC time is not in wrfbdy_d01 file" LIST OF MODIFIED FILES: M share/input_wrf.F TESTS CONDUCTED: 1. Without fix, start the model after the last valid time of the LBC file => lots of repeated messages ``` 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 ``` 2. With this fix, when LBC stops at 2000 01 25 00, and WRF starts at 2000 01 25 06 ``` d01 2000-01-25_06:00:00 Input data is acceptable to use: wrfbdy_d01 THIS TIME 2000-01-24_12:00:00, NEXT TIME 2000-01-24_18:00:00 d01 2000-01-25_06:00:00 Input data is acceptable to use: wrfbdy_d01 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 -------------- FATAL CALLED --------------- FATAL CALLED FROM FILE: <stdin> LINE: 1134 ---- ERROR: Ran out of valid boundary conditions in file wrfbdy_d01 ------------------------------------------- ``` 3. Without this fix, if we try to extend the module simulation beyond the valid lateral boundary times ``` Timing for main: time 2000-01-24_23:54:00 on domain 1: 0.53782 elapsed seconds Timing for main: time 2000-01-24_23:57:00 on domain 1: 0.51111 elapsed seconds Timing for main: time 2000-01-25_00:00:00 on domain 1: 0.54507 elapsed seconds Timing for Writing wrfout_d01_2000-01-25_00:00:00 for domain 1: 0.03793 elapsed seconds d01 2000-01-25_00:00:00 Input data is acceptable to use: wrfbdy_d01 2 input_wrf: wrf_get_next_time current_date: 2000-01-25_00:00:00 Status = -4 d01 2000-01-25_00:00:00 ---- ERROR: Ran out of valid boundary conditions in file wrfbdy_d01 At line 777 of file module_date_time.f90 Fortran runtime error: Bad value during integer read Error termination. Backtrace: #0 0x10e67c36c #1 0x10e67d075 #2 0x10e67d7e9 ``` 4. With this fix, if we try to extend the module simulation beyond the valid lateral boundary times ``` Timing for main: time 2000-01-24_23:54:00 on domain 1: 0.60755 elapsed seconds Timing for main: time 2000-01-24_23:57:00 on domain 1: 0.57641 elapsed seconds Timing for main: time 2000-01-25_00:00:00 on domain 1: 0.60817 elapsed seconds Timing for Writing wrfout_d01_2000-01-25_00:00:00 for domain 1: 0.04499 elapsed seconds d01 2000-01-25_00:00:00 Input data is acceptable to use: wrfbdy_d01 2 input_wrf: wrf_get_next_time current_date: 2000-01-25_00:00:00 Status = -4 -------------- FATAL CALLED --------------- FATAL CALLED FROM FILE: <stdin> LINE: 1134 ---- ERROR: Ran out of valid boundary conditions in file wrfbdy_d01 ------------------------------------------- ``` MMM Classroom regtest; em_real, nmm, em_chem; GNU only
…-model#899) TYPE: enhancement KEYWORDS: WRFDA, EnVar, ep SOURCE: Jamie Bresch (NCAR) DESCRIPTION OF CHANGES: Avoid unused ep allocation in alloc_and_configure_domain for EnVar applications. ep is allocated in subroutine da_solve_init (var/da/da_main/da_solve_init.inc) or subroutine reallocate_analysis_grid (var/da/da_main/da_solve_dual_res_init.inc) with desired dimensions. The 4th dimension of ep should be ensdim_alpha*num_fgat_time instead of just ensdim_alpha as defined in registry. For dual-res EnVar, the ep is re-allocated with coarse intermediate grid dimensions. Depending on domain/ensemble sizes, the memory reduction with the fix can allow the job to run on regular nodes instead of large-memory nodes on NCAR/cheyenne. LIST OF MODIFIED FILES: modified: Registry/registry.var modified: var/da/da_main/da_wrfvar_init2.inc TESTS CONDUCTED: A dual-resolution EnVar case, before the fix: alloc_space_field: domain 1 , 2088567208 bytes allocated alloc_space_field: domain 2 , 47306336 bytes allocated alloc_space_field: domain 2 , 2601652648 bytes allocated A dual-resolution EnVar case, after the fix: alloc_space_field: domain 1 , 1281764008 bytes allocated alloc_space_field: domain 2 , 47306336 bytes allocated alloc_space_field: domain 2 , 1594559848 bytes allocated An EnVar case, on proc 0, before the fix: alloc_space_field: domain 1 , 1705984056 bytes allocated An EnVar case, on proc 0, after the fix: alloc_space_field: domain 1 , 689084856 bytes allocated Note that the total memory allocated for single resolution EnVar is reduced by approximately 20% including the later allocations in da_solve_init. RELEASE NOTE: Fix DA EnVar unnecessary allocation to reduce memory requirement.
TYPE: enhancement KEYWORDS: CODEOWNERS SOURCE: internal DESCRIPTION OF CHANGES: Add in a few more active developers for schemes: Fire, RUC, MYNN, PX, ACM LIST OF MODIFIED FILES: M .github/CODEOWNERS TESTS CONDUCTED: MMM Classroom regtest; em_real, nmm, em_chem; GNU only
TYPE: bug fix KEYWORDS: WRFDA, BCAST, DMPAR, mpi, 4DVAR SOURCE: Internal, JJ Guerrette DESCRIPTION OF CHANGES: Fix dependencies on wrf_dm_bcast_integer/real/string/bytes … A missing use statement for da_wrf_interfaces in da_obs_io.f90 was causing the following compile-time error for a 4D-Var build: ``` catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error. compilation aborted for da_obs_io.f (code 1) real 0m19.553s user 0m18.652s sys 0m0.668s da.make:421: recipe for target 'da_obs_io.o' failed make[1]: [da_obs_io.o] Error 1 (ignored) ``` The interfaces are updated in da_wrf_interfaces, including assumed-size array behavior similar to that originally defined in module_dm.f90. All known missing use statements related to wrf_dm_bcast_* calls are corrected. In some cases, scalar variables were changed to array variables with dimension(1), because the wrf_dm_bcast_* subroutines have an assumed-size array dummy argument that requires an array as an input. The error arose for intel/17.0.1 and mpt/2.19 on cheyenne. Of note is that the compile error has not been noticed previously. An alternative solution could be to notify intel, as the error message suggests. It seemed more logical to put a non-ambiguous fix in place that references specific subroutine interfaces. LIST OF MODIFIED FILES: M var/build/depend.txt M var/da/da_gpseph/da_gpseph.f90 M var/da/da_obs_io/da_obs_io.f90 M var/da/da_par_util/da_par_util.f90 M var/da/da_physics/da_physics.f90 M var/da/da_radiance/da_radiance.f90 M var/da/da_radiance/da_radiance1.f90 M var/da/da_setup_structures/da_scale_background_errors_cv3.inc M var/da/da_setup_structures/da_setup_structures.f90 M var/da/da_test/da_test.f90 M var/da/da_tools/da_wrf_interfaces.f90 M var/da/da_transfer_model/da_transfer_model.f90 M var/da/da_transfer_model/da_transfer_wrftoxb.inc TESTS CONDUCTED: Compile works now. Have not conducted WRFDA REGTEST. Only affects 4D-Var builds.
TYPE: bug fix KEYWORDS: bufr, conventional obs, wrfda, missing value SOURCE: Internal, JJ Guerrette DESCRIPTION OF CHANGES: This error only arises in a debug build of WRFDA. nint is applied to QM (quality marker) and PC (program code) values that are sometimes equal to 1e+11 in RAP/HRRR bufr files. Those large values can not be represented with a 4-byte integer. The solution is to check if the obs values are missing (> 9e+8) before using nint. In a non-debug build, these same observations would normally be filtered out a few lines after the call to nint due to the missing values. Now the missing value check is performed before the error can arise. This fix allows a debug build to be used to check other types of errors outside the bufr reading. ISSUE: none LIST OF MODIFIED FILES: M var/da/da_obs_io/da_read_obs_bufr.inc TESTS CONDUCTED: The modifications prevent the errors from occurring in the debug build. No WRFDA REGTEST has been run.
…ailures on wrfout metadata (wrf-model#874) TYPE: bug fix KEYWORDS: missing files, input_wrf SOURCE: identified by Michael Duda (NCAR/MMM), fixed internally DESCRIPTION OF CHANGES: Problem: The user was given an incorrect diagnostic print when an auxiliary file was missing (such as for SST update or FDDA). The user was ALWAYS told that the WRF model could not read the metadata from the wrfout file. ``` d01 2000-01-24_12:00:00 Error trying to read metadata d01 2000-01-24_12:00:00 File name that is causing troubles = wrfout_d01_2000-01-24_12:00:00 d01 2000-01-24_12:00:00 wrfout_d01_2000-01-24_12:00:00 d01 2000-01-24_12:00:00 Error trying to read metadata d01 2000-01-24_12:00:00 You can try 1) ensure that the input file was created with WRF v4 pre-processors, or d01 2000-01-24_12:00:00 2) use force_use_old_data=T in the time_control record of the namelist.input file -------------- FATAL CALLED --------------- FATAL CALLED FROM FILE: <stdin> LINE: 324 ---- ERROR: The input file appears to be from a pre-v4 version of WRF initialization routines ------------------------------------------- -------------- FATAL CALLED --------------- FATAL CALLED FROM FILE: <stdin> LINE: 324 ---- ERROR: The input file appears to be from a pre-v4 version of WRF initialization routines ------------------------------------------- ``` Solution: If the _filestate_ is either "unopened" or "open for write", we flag the attempt to read the file as a fatal error. If the file is "unopened", then the file name was wrong or missing. If the _filestate_ is "open for write", then the WRF I/O is using the old data from the previous write of the WRF model. In either case, a print out is issued that maps the _switch_ (stream number) to a more recognizable WRF namelist identifier (for example, stream 30 is mapped to auxinput4). ISSUE: Fixes wrf-model#770 "Misleading error message when wrflowinp_d01 file is missing" LIST OF MODIFIED FILES: M share/input_wrf.F TESTS CONDUCTED: 1. With no missing files, and with FDDA and SST update, bit-wise identical results with a restart. 2. With sst_update activated, and no wrflowinp file ``` -------------- FATAL CALLED --------------- FATAL CALLED FROM FILE: <stdin> LINE: 315 Possibly missing file for = auxinput4 ------------------------------------------- -------------- FATAL CALLED --------------- FATAL CALLED FROM FILE: <stdin> LINE: 315 Possibly missing file for = auxinput4 ------------------------------------------- ``` 3. With fdda active, and no wrffdda file ``` -------------- FATAL CALLED --------------- FATAL CALLED FROM FILE: <stdin> LINE: 315 Possibly missing file for = auxinput10 ------------------------------------------- -------------- FATAL CALLED --------------- FATAL CALLED FROM FILE: <stdin> LINE: 315 Possibly missing file for = auxinput10 ------------------------------------------- ``` 4. For the standard WRF Chem case, things behave as expected: ``` Timing for Writing wrfout_d01_2006-04-06_00:00:00 for domain 1: 0.21654 elapsed seconds d01 2006-04-06_00:00:00 Yes, this special data is acceptable to use: OUTPUT FROM EMISSIONS V1.0 PREPROCESSOR for WRF version 2.03.1 d01 2006-04-06_00:00:00 Input data is acceptable to use: wrfchemi_d01_2006-04-06_00:00:00 **WARNING** Time in input file not being checked **WARNING** d01 2006-04-06_00:00:00 Input data processed for aux input 5 for domain 1 d01 2006-04-06_00:00:00 Input data is acceptable to use: wrfbdy_d01 Timing for processing lateral boundary for domain 1: 0.05871 elapsed seconds Tile Strategy is not specified. Assuming 1D-Y WRF TILE 1 IS 1 IE 40 JS 1 JE 40 WRF NUMBER OF TILES = 1 Timing for main: time 2006-04-06_00:04:00 on domain 1: 1.42039 elapsed seconds Timing for main: time 2006-04-06_00:08:00 on domain 1: 0.45995 elapsed seconds ``` 5. For the Chem case, when we remove a file `wrfchemi_d01_2006-04-06_00:00:00`: ``` -------------- FATAL CALLED --------------- FATAL CALLED FROM FILE: <stdin> LINE: 314 Possibly missing file for = auxinput5 ------------------------------------------- ``` Then you look in the namelist to find: ``` &time_control auxinput5_inname = "wrfchemi_d<domain>_<date>" / ``` MMM Classroom regtest; em_real, nmm, em_chem; GNU only
…dard schemes (wrf-model#906) TYPE: bug fix KEYWORDS: IEEE, GNU SOURCE: reported by Maik Reichert, fixed internally DESCRIPTION OF CHANGES: Problem: With the introduction of the Goddard MP and radiation schemes in release-v4.1, there are locations where the IEEE capability for Fortran 2003 is unconditionally used. With the default GNU compiler on Linux, the WRF code will not build. Updating the compiler, while free, does require that the user then rebuild libraries from scratch. Solution: The WRF code has had tests for using IEEE for a number of years (with the svn releases, starting with v3.6). Since that release, during the `configure` step, if a small test code fails to build or run successfully, the `configure.wrf` file sets a cpp compile-time flag. This ifdef infrastructure is now added to the new Goddard-related files that were recently included in the WRF repository (b60a5b9). ISSUE: Fixes wrf-model#905 "ieee_arithmetic usage" LIST OF MODIFIED FILES: M ./configure M ./phys/module_checkerror.F M ./phys/module_gocart_coupling.F M ./phys/module_mp_gsfcgce_4ice_nuwrf.F M ./phys/module_ra_goddard.F TESTS CONDUCTED: 1. No harm - the code performs as expected with newer GNU compilers. 2. Code builds with an older GNU compiler (4.9.2), with this warning during the `configure` step: ``` ************************** W A R N I N G ************************************ There are some IEEE Fortran 2003 features in WRF that your compiler does not recognize. The IEEE function calls have been removed. ***************************************************************************** ``` RELEASE NOTE: The WRF code added unprotected IEEE functions in the source code with release-v4.1. Using existing infrastructure, those declarations and functions are now ifdef'ed out automatically when they the IEEE functions are detected to not be supported by the compiler. Note that this does remove some default error checking in the Goddard MP and Goddard radiation schemes.
…compiler flag confusion (wrf-model#907) TYPE: bug fix KEYWORDS: Goddard, Intel, CHUNK SOURCE: RCarpenter DESCRIPTION OF CHANGES: Inside of frame/module_dm.F, there is an optimization effort for the Intel compiler: ``` #ifdef INTEL_ALIGN64 ! align on 64 byte boundaries if -align array64byte ims = ips-CHUNK ime = ime + (CHUNK-mod(ime-ims+1,CHUNK)) #endif ``` This `CHUNK` variable is defined through a cpp directive in a couple of WRF build stanzas for Intel: `Xeon Phi (MIC architecture)` and `Xeon (SNB with AVX mods)`, using the Intel compiler. For example: ``` ARCH_LOCAL = -DNONSTANDARD_SYSTEM_FUNC -DCHUNK=16 -DXEON_OPTIMIZED_WSM5 ``` and ``` ARCH_LOCAL = -DNONSTANDARD_SYSTEM_FUNC -DCHUNK=64 -DXEON_OPTIMIZED_WSM5 ``` [The switch `INTEL_ALIGN64` does not actually appear in any supported WRF build file.] Therefore, for some selections of Intel compiler stanza in the `configure` step, there is a performance flag, `CHUNK`, that is automatically set that modifies Fortran files. Problem: Unfortunately, `CHUNK` is the same name that was used by the Goddard MP and radiation schemes (coincidentally, also for performance gains). Original: ``` INTEGER, PARAMETER, PRIVATE:: CHUNK = 16 ``` The pre-processor (from `ARCH_LOCAL`) turns an OK line of Fortran into a syntactically incorrect line: ``` INTEGER, PARAMETER, PRIVATE:: 64 = 16 ``` Solution: As proposed on the WRF forum, https://forum.mmm.ucar.edu/phpBB3/viewtopic.php?f=37&t=5324, since both of these `CHUNK` modifications are based on cpp directives, changing the case of `CHUNK` in the newly added Goddard schemes is sufficient to avoid multiple meanings for the same variable name. LIST OF MODIFIED FILES: modified: phys/module_mp_gsfcgce_4ice_nuwrf.F modified: phys/module_ra_goddard.F TESTS CONDUCTED: 1. For users on forum with this trouble, this was a good fix. 2. Since Fortran is case insensitive, there are no side effects to changing a variable's case. 3. Using Linux Intel build option 18 (AVX) on cheyenne, without this mod the code fails. 4. Using Linux Intel build option 18 (AVX) on cheyenne, with this mod, the code builds.
TYPE: bug fix KEYWORDS: include, cpp, quotes, angle brackets, ", > SOURCE: Jamie Bresch (NCAR/MMM) DESCRIPTION OF CHANGES: Problem: When using CPP \#include, to access local include files, the correct syntax is to use quotes to surround the filename. Using angle brackets makes the search look in standard system directories. Solution: Swap the single location of WRF-manufactured include file: `<filename.inc>` for `"filename.inc"`. LIST OF MODIFIED FILES: modified: frame/module_alloc_space.h TESTS CONDUCTED: 1. The code builds just fine. 2. The Jan 2000 test case looks as expected at 12-h.
TYPE: bug fix KEYWORDS: Ishmael, DFI, package SOURCE: internal DESCRIPTION OF CHANGES: The list of variables in the Ishmael MP for DFI mistakenly had a character in the wrong place. LIST OF MODIFIED FILES: M Registry/Registry.EM_COMMON TESTS CONDUCTED: 1. Before mod, there was a complaint from the Registry program. ``` Packages in gen_scalar_indices1 WARNING: qdfi_v is not a member of 4D array dfi_moist ``` 2. After the mod, there is no Registry program complaint.
TYPE: bug fix KEYWORDS: do_trad_fields, diag_nwp2, traditional fields SOURCE: internal DESCRIPTION OF CHANGES: Problem: The variable theta is not a state variable, but it was incorrectly used as a variable in the package for "do_trad_fields". Solution: This PR removes theta from the package list, and replaces theta with the correct variable potential_t. LIST OF MODIFIED FILES: Registry/registry.trad_fields TESTS CONDUCTED: A single case with the option diag_nwp2=1 (the option to output the traditional fields) is conducted. The model runs fine and the results are reasonable.
TYPE: text only KEYWORDS: README.namelist, NMM SOURCE: internal DESCRIPTION OF CHANGES: A few physics options are declared as "NMM only" in README.namelist, whereas they actually work for both ARW and NMM. Surface Layer: NCEP GFS (sf_sfclay_physics=3) PBL: Hybrid EDMF GFS (bl_pbl_physics=3) This PR corrects the information. LIST OF MODIFIED FILES: M run/README.namelist TESTS CONDUCTED: A single ARW case is successfully done with the options of sf_sfclay_physics=3 and bl_pbl_physics=3. Results look fine.
TYPE: text only KEYWORDS: README, release SOURCE: internal DESCRIPTION OF CHANGES: Update the top-level README file, and the inc/version_decl file with the correct version. Now using a string which in no longer a fixed length. LIST OF MODIFIED FILES: M README M inc/version_decl TESTS CONDUCTED: A test case is run with the correct printout taskid: 0 hostname: r5i2n23 Quilting with 1 groups of 0 I/O tasks. Ntasks in X 12 , ntasks in Y 12 WRF V4.1.1 MODEL ************************************* Parent domain ids,ide,jds,jde 1 401 1 261 ims,ime,jms,jme -4 41 -4 29 ips,ipe,jps,jpe 1 34 1 22 *************************************
TYPE: bug fix KEYWORDS: hybrid vertical coordinate, vertical refinement SOURCE: Katie Lundquist (LLNL) and internal DESCRIPTION OF CHANGES: Problem: Since the formal introduction of the hybrid vertical coordinate option in WRF (with version v4.0), the vertical refinement option (also referred to as vertical nesting) has been broken for both of the options when vert_refine_method = 1 or 2 (ndown or WRF, respectively). The symptomology is that model dies in the first time step, whether in the dynamics, physics, or initialization. Solution: Katie discovered that the 1d arrays (c1, c2, c3, c4 which are used to construct the pressure level of the vertical levels) were never set for vertical refinement. Editor's note: These values were set for traditional nests. Since the number of vertical levels in the parent and child domains were the same, the already existing code was sufficient: ``` nest%c1h(1:parent%e_vert) = parent%c1h(1:parent%e_vert) nest%c2h(1:parent%e_vert) = parent%c2h(1:parent%e_vert) nest%c3h(1:parent%e_vert) = parent%c3h(1:parent%e_vert) nest%c4h(1:parent%e_vert) = parent%c4h(1:parent%e_vert) nest%c1f(1:parent%e_vert) = parent%c1f(1:parent%e_vert) nest%c2f(1:parent%e_vert) = parent%c2f(1:parent%e_vert) nest%c3f(1:parent%e_vert) = parent%c3f(1:parent%e_vert) nest%c4f(1:parent%e_vert) = parent%c4f(1:parent%e_vert) ``` However, when the two domains have a different number of vertical levels these assignments are incorrect. When there is no input for the second domain, there is no opportunity inside of the WRF model to correct these wrong assignments by overwriting the nest values of the 1d arrays with a subsequent _read_. The source code that is required to compute the vertical 1d arrays already exists. For the real program, the computation of the 1d arrays is handled in the `dyn_em/module_initialize_real.F` file. The entirety of those computations are now removed from the `module_initialize_real.F` subroutine and placed in `dyn_em/nest_init_utils.F`, as a new subroutine. This refactoring does two things: 1. The computations necessary for the vertical refinement are available and consistent with the existing computations done elsewhere in the real program. 2. A single shared routine is in place instead of duplicated software. Due to the existing makefile dependencies, locating the new subroutine inside of the `nest_init_utils.F` file required no mods to the makefiles or `depend.common` for the case of the (online) vertical refinement. For the ndown (offline vertical refinement), the `depend.common` file is updated to include the files `nest_init_utils.o` (where the new 1d array computing routine is located) and `module_model_constants.o` (where the constants are located for R, CP, etc. Lastly, a previously required test in `check_a_mundo.F` is now able to be removed. That test did not allow users to use vertical nesting with the hybrid coordinate. As it turns outs, that test was insufficient. Any use of the vertical refinement with `input_from_file=.true.,.false.` would fail. LIST OF MODIFIED FILES: modified: dyn_em/module_initialize_real.F modified: dyn_em/nest_init_utils.F modified: main/depend.common modified: main/ndown_em.F modified: share/module_check_a_mundo.F ISSUE: Fixes wrf-model#917 "NDOWN v4.1: vertical refinement is broken" TESTS CONDUCTED: - [x] With the original code, the WRF model dies in the first time step. - [x] With the mods, the model runs a successful 12-h simulation Here are the pieces to make the code fail for online vertical refinement (within WRF): 1. A nested domain, but only a single input file. The 1d arrays must be internally computed. ``` &time_control input_from_file = .true.,.false., / ``` 2. The vertical refinement option must be active, with different values of `e_vert` on each domain. Whether the nested value of `vert_refine_method` is 1 or 2 does not matter - fail city. ``` &domains max_dom = 2, e_vert = 35, 45, feedback = 0, vert_refine_method = 0, 2, / ``` 3. Nothing special, other than radiation LW and SW must be 1 - just a friendly reminder. ``` &physics ra_lw_physics = 1, 1, ra_sw_physics = 1, 1, / ``` 4. Importantly, the setting of the hybrid option does not matter. The original code will fail with either: ``` &dynamics hybrid_opt = 0 / ``` or ``` &dynamics hybrid_opt = 2 / ``` 5. With this mod, using hybrid_opt=0 and use_theta_m=0, I was able to get bit-wise identical results with wrf-model#891 "fix for vertical nesting without the hybrid coordinate - fix for use". I used a test case provided by Katie Lundquist: ``` curl -O ftp:https://ftp.llnl.gov/outgoing/lundquist3/vertnesting_example.tgz ``` Per Katie: > I ran two cases in v3.9.1.1 (unchanged) and 4.1 (my vert. nesting fix, not your nice refactoring) and they look the same. MU certainly has noticeable effects at the edges from vertical nesting. Effects are much more muted on the other prognostic variables, such as velocity. The causes of this are documented in the Daniels et al (2016) paper in MWR. Some of it is unavoidable and I think some could be fixed by modifying the smoothing behavior between nested domains. This commit should return the vertical nesting functionality to that before v4.0 when the hybrid coordinate was set as the default. I have only looked at the solutions for hybrid_opt = 0, not 2. 6. I ran Katie's case with the hybrid vertical coordinate with metgrid data that was provided: ``` curl -O ftp:https://ftp.llnl.gov/outgoing/lundquist3/vertnesting_example_input.tgz ``` This namelist snippet is used: ``` &time_control run_seconds = 60, input_from_file = .true., .false., .false., .false., history_interval_s = 20, 20, 10, 10, / &domains time_step = 20, e_we = 196, 100, 100, 100, e_sn = 196, 100, 100, 100, e_vert = 88, 89, 90, 91, vert_refine_method = 0, 2, 2, 2, dx = 27000, 3000, 333, 37, dy = 27000, 3000, 333, 37, grid_id = 1, 2, 3, 4, parent_id = 1, 1, 2, 3, parent_grid_ratio = 1, 9, 9, 9, parent_time_step_ratio = 1, 5, 4, 4, feedback = 0, rebalance = 1, / &dynamics use_theta_m = 0, hybrid_opt = 2, / ``` The figure shows domain 4, after 1 hour (240 d04 time steps), MU field LEFT - differences between terrain following and hybrid vertical coordinate CENTER - MU field terrain following coordinate (considered an exemplar) RIGHT - MU field hybrid coordinate  Here are the pieces to make the code fail (for the original code) for offline vertical refinement (using ndown): 1. A nested domain, requesting the same number of vertical levels, and turning on the hybrid option. ``` &domains vert_refine_fact = 2 e_vert = 45, 45, 33, feedback = 0, / ``` ``` &dynamics hybrid_opt = 2, / ``` For ndown, cross section plots of geopotential perturbation of the generated wrfbdy_d02 file (the ranges are not the same, to show detail of the figures). Left: new mods Center: original code Right: difference  This error condition and fix are consistent with the required modification to fill in the 1d vertical coordinate arrays. Those arrays became mandatory with v4.0 (when the vertical refinement option was first broken). Those 1d arrays are mandatory for both the hybrid and terrain-following vertical coordinates. RELEASE NOTE: From version 4.0 through 4.1, both vertical refinement options were broken. For online vertical refinement (within the WRF model) with only a single input domain, the incorrect WRF code had uninitialized arrays that defined the vertical coordinate in the child domain. However, any users with vertical refinement activated AND with input_from_file = t,t were never impacted. For offline vertical refinement (using ndown with vert_refine_fact), the initial conditions also only had the lower portion of the 1d arrays initialized (and those were initialized incorrectly). Modifications were introduced to fix both refinement options, and the modifications support both the hybrid and the terrain-following vertical coordinate. The WRF code now provides results similar to v3.9.1.1 (hybrid_opt = 0) for both vertical refinement capabilities. Additionally, the v4.1.1 WRF code gives similar results when using the hybrid vertical coordinate or the terrain-following vertical coordinate.
…odel#927) TYPE: bug fix KEYWORDS: WRFDA, serial, compile SOURCE: Jamie Bresch (NCAR) DESCRIPTION OF CHANGES: The error message of serial build: ``` da_vtox_transforms.f:44:26: use da_par_util, only : true_mpi_real, mpi_sum, comm 1 Error: Symbol 'true_mpi_real' referenced at (1) not found in module 'da_par_util' da_vtox_transforms.f:44:41: use da_par_util, only : true_mpi_real, mpi_sum, comm 1 Error: Symbol 'mpi_sum' referenced at (1) not found in module 'da_par_util' ``` The fix is to move the line of code use da_par_util, only : true_mpi_real, mpi_sum, comm inside #ifdef DM_PARALLEL. ISSUE: Fixes wrf-model#923 LIST OF MODIFIED FILES: modified: var/da/da_vtox_transforms/da_vtox_transforms.f90 TESTS CONDUCTED: WRFDA builds for serial mode after the fix. RELEASE NOTE: Fix WRFDA V4.1.1 serial compilation failure.
TYPE: bug fix KEYWORDS: WRFDA, radar, memory, deallocation, allocation SOURCE: Han Lung (Fujitsu America, Inc.), Jamie Bresch (NCAR) DESCRIPTION OF CHANGES: 1. da_allocate_y.inc is used to allocate y_type variables (re, y, jo_grad_y, ob) in various places in WRFDA. Some allocated arrays for radar are not deallocated. The un-allocated memory grows with minimization iterations. The fix is to add deallocation of allocated arrays in da_deallocate_y.inc. 2. Changes are also made to allocate arrays when they are actually needed. 3. Initialize pointers as null to make da_deallocate_y/da_deallocate_observations work. 4. Add deallocation to some iv%radar arrays. LIST OF MODIFIED FILES: M var/da/da_define_structures/da_allocate_y.inc M var/da/da_define_structures/da_allocate_y_radar.inc M var/da/da_define_structures/da_deallocate_observations.inc M var/da/da_define_structures/da_deallocate_y.inc M var/da/da_define_structures/da_define_structures.f90 M var/da/da_radar/da_transform_xtoy_radar_adj.inc TESTS CONDUCTED: A radar radial velocity 4DVAR case. RELEASE NOTE: Fix Radar DA memory leak.
TYPE: bug fix KEYWORDS: WRFDA, 4DVAR, compile SOURCE: Jamie Bresch (NCAR) DESCRIPTION OF CHANGES: Following commit 56d4bef, the new function name (check_which_switch) needs to be added in da_name_space.pl to avoid name conflict for 4DVAR build. The error message: ``` duplicate symbol _check_which_switch_ in: /Volumes/sysdisk1/hclin/WRFV4/wrfplus/main/libwrflib.a(input_wrf.o) ./libwrfvar.a(input_wrf.o) ld: 1 duplicate symbol for architecture x86_64 collect2: error: ld returned 1 exit status ``` LIST OF MODIFIED FILES: M var/build/da_name_space.pl TESTS CONDUCTED: WRFDA 4DVAR builds after the fix. RELEASE NOTE: Fix WRFDA 4DVAR V4.1.1 compilation failure.
…elist.input TYPE: bug fix KEYWORDS: WRFDA, mp_physics, package, QVAPOR, physics_suite SOURCE: Jamie Bresch (NCAR) DESCRIPTION OF CHANGES: Add back the packaging for mp_physics=-1 (added in commit 93a1791, but dropped unintentionally in commit 81ca2ff) to allow WRFDA to allocate qv in the cases when (1) physics_suite is set and mp_physics is not set, (2) both physics_suite and mp_physics are not set. Commit 7427eac contains some information about physics_suite in WRFDA. When mp_physics is not set in the namelist.input, its default -1 leads to no moist variable (even qv) being allocated. Even if the user is able to identify the incorrect QVAPOR analysis, it is almost impossible for the user to figure out why and how to solve the problem. The problem can be avoided by setting proper mp_physics. For dual-resolution EnVar, my_physics in both column 1 and column 2 must be set. NOTE that this PR handles qv only. More other consideration and tests are needed for cloud variables. LIST OF MODIFIED FILES: M Registry/registry.var TESTS CONDUCTED: (1) with missing mp_physics setting, the fixed code gets proper QVAPOR analysis for one simple test case. RELEASE NOTE: Fix to allow proper QVAPOR analysis when mp_physics is not set in namelist.input.
…moisture from DRY theta perturbation (wrf-model#942) TYPE: bug fix KEYWORDS: diagnostics, temperature, moist theta SOURCE: Nicolas Baldeck (OpenMeteoData), internal DESCRIPTION OF CHANGES: In the traditional fields diagnostics option, the moisture is removed from the (already) dry theta perturbation. The `trad_fields` is called in two locations. From the diagnostics driver, the input to the scheme is: ``` CALL trad_fields ( & ! Input data for computing U=grid%u_2 & ,V=grid%v_2 & ,W=grid%w_2 & ,t=grid%th_phy_m_t0 & ``` From `start_em`, the call incorrectly and inconsistently uses `grid%t_2`, which is fixed in this PR to `grid%th_phy_m_t0`. The name `th_phy_m_t0` means "theta from physics, minus t0", so this is a dry potential temperature perturbation. Therefore, since the input is dry potential temperature perturbation, attempting to remove the moisture results in a cooler temperature, as much as 8-10 K in locations near the surface with tropical moisture. This is how the error was spotted. ISSUE: Closes wrf-model#935 "Bad Wind and Temperature values with diag_nwp2=1" (only the "temperature" portion) LIST OF MODIFIED FILES: modified: dyn_em/start_em.F modified: physics/module_diag_trad_fields.F TESTS CONDUCTED: - [x] With the new mods, the potential temperature fields are correct: The `T` field from WRF is dry potential temperature perturbation. The `POTENTIAL_T` field from the diagnostics output is the total dry potential temperature. The difference of these fields should be a constant 300 K (and, it is).  - [x] With the new mods, the temperature fields are correct: The `T2` field from WRF is 2m temperature. The `TEMPERATURE` field from the diagnostics output is the temperature. At the initial time, these fields should be _similar_. They do not show the pre-mod large 6-10 K offset.  RELEASE NOTE: Also, the traditional fields diagnostics incorrectly removed the impact of moisture, but from an already dry potential temperature perturbation. Re-removing the moisture results in a cooler temperature, possibly 8-10 K at the surface in locations with tropical levels of moisture.
…l#941) TYPE: bug fix KEYWORDS: diagnostics SOURCE: Nicolas Baldeck (OpenMeteoData), internal DESCRIPTION OF CHANGES: When computing the earth-relative winds from the model's projection-relative winds, the resulting values of umet and vmet are correctly placed in the cell center. However, the averaging to the cell center from the momentum cell faces is missing a "divide by 2". ISSUE: Closes wrf-model#935 "Bad Wind and Temperature values with diag_nwp2=1" (only the "wind" portion) LIST OF MODIFIED FILES: modified: module_diag_trad_fields.F TESTS CONDUCTED: - [x] Verified results for a single point ``` +----- vt -----+ +--------------+ | | | | | | | | | | | | ul ua,va ur | um,vm | | | | | | | | | | | | | +----- vb -----+ +--------------+ ``` The `ul`, `ur`, `vb`, `vt` points are the cell-faced, WRF-projection values for U and V. The `ul` and `ur` points are averaged to `ua` The `vb` and `vt` points are averaged to `va` ``` ul 9.646521 ur 9.88719 vb 5.692195 vt 6.119572 ua 9.7668555 va 5.9058835 ``` The `um` and `vm` points are the mass-centered, earth-relative values for U and V. ``` um 11.25222 vm 1.912724 ``` The speed computed with `ua` and `va` is `sa`. The speed computed with `um` and `vm` is `sm`. ``` sa 11.41362897037802346311 sm 11.41363079955611670914 ``` - [x] With the old code, the results show a 2x factor in the earth-relative values of u, v, and speed. ``` ul 9.646521 ur 9.88719 vb 5.692195 vt 6.119572 ua 9.7668555 va 5.9058835 sa 11.41362897037802346311 um 22.50444 vm 3.825448 sm 22.82726159911223341829 ``` RELEASE NOTE: One of the diagnostic options in WRF is called "traditional fields". Two of the available fields are the earth-relative components of the horizontal wind. Those values were too large by a factor of two (due to averaging to the cell center, but neglecting to divide by 2).
…rf-model#931) TYPE: bug fix KEYWORDS: topographic shading, radiation, restart runs, nested domains SOURCE: Emily Collier (FAU Erlangen-Nürnberg) DESCRIPTION OF CHANGES: 1. Added ht_shad to the restart files Restart runs aren't reproducible in nested domains when topographic shading is turned on, because ht_shad is not initialised in grid points adjacent to the lateral boundary of the nest. Zero values for ht_shad at affected grid points (all located one grid point away from the eastern boundary in the same patch) lead to different values of shadowmask and swnorm. Here is a diff of swnorm in D2 in the first affected time step for a restart at 04 UTC:   Here is swdown for reference:  Adding ht_shad to the restart files makes restart runs reproducible for all domains when topo_shading is used. ISSUE: Closes wrf-model#922 "Restart runs not reproducible in nest when topo_shading is turned on" LIST OF MODIFIED FILES: M Registry/Registry.EM_COMMON TESTS CONDUCTED: WRF 3.9.1.1 and 4.1 for two different configurations and study areas. RELEASE: A small modification to Registry.EM_COMMON now allows all domains to generate reproducible results on a restart when running the topo_shading option.
…ned values; nucleation limit (wrf-model#925) TYPE: bug fixes KEYWORDS: code changes/bug fixes SOURCE: Anders A. Jensen (NCAR-RAL) DESCRIPTION OF CHANGES: 1) Added allocation for single-precision lookup tables which are defined from the double-precision ones. Without this, certain versions of PGI throw an error. 2) Moved the calculation of the inherent growth ratio to prevent if from being undefined in certain instances. 3) Storing dsold (old deltastr value, or shape parameter), use it to diagnose shape during nucleation and aggregation (transfer between ice categories), and ensure that this value stays in bounds. This prevents the updated shape from going out of bounds in certain instances. 4) Moved the mass check for aggregation to occur to around the aggregation subroutine call to prevent the aggregate diagnostics, calculated just above, from being undefined. 5) Added a fix to ensure that nucleation won't turn planar particles into columnar ones by limiting this shape to spherical (deltastr(cc)=1). 6) Set a low limit on nucleation size to 2 microns. LIST OF MODIFIED FILES: M phys/module_mp_jensen_ishmael.F TESTS CONDUCTED: Tested serial intel, gnu, pgi. Builds and runs correctly dmpar (ifort), and I get the same answer on a restart. 🎉
…rmat (wrf-model#940) TYPE: bug fix KEYWORDS: compile, version_decl SOURCE: internal DESCRIPTION OF CHANGES: The `compile` script has a line to inform users of the version of WRF that is being built, purely for informational purposes: ``` cat inc/version_decl | cut -c 45-54 ``` While this could have been more general, it worked OK with the original syntax of the original `inc/version_decl` file. With the inclusion of modification 18c66c7 in PR wrf-model#918 "Prepare for WRF-v4.1.1 release", the string in the `inc/version_decl` file is no longer a fixed length, so the original `cut` syntax (grabbing characters 45 through 54) no longer returns a valid version ID. A modification to the `compile` script handles retrieving this information in a more robust fashion from the `inc/version_decl` file. The old `version_decl` file: ``` CHARACTER (LEN=10) :: release_version = 'V4.1 ' ``` The new `version_decl` file: ``` CHARACTER (LEN=*), PARAMETER :: release_version = 'V4.1.1' ``` Basically, we modify the `compile` script to get the characters between the single quotes: ``` cat inc/version_decl | cut -d"'" -f2 ``` which gives the correct string, regardless of the style selected for the assignment: ``` V4.1.1 ``` ISSUE: Closes issue wrf-model#938 "version_decl modification causes incorrect info in compile log" LIST OF MODIFIED FILES: M compile TESTS CONDUCTED: - [x] Without this mod, the top of the compile log has ``` ersion = ' Compiling: WRF_EM_CORE ``` - [x] With this mod, the top of the compile log says ``` V4.1.1 Compiling: WRF_EM_CORE ``` RELEASE NOTE: A modification was added to the compile script to print out the correct version number of the WRF model in the compile log.
TYPE: enhancement KEYWORDS: ESMF, FFTPACK, LICENSE SOURCE: fomented by Michael Kavulich (NCAR/DTC), internal DESCRIPTION OF CHANGES: 1. For ESMF and FFTPACK directories, remove individual licenses from files. 2. Replace with a single `LICENSE` file in each directory. 3. `LICENSE` file is taken from FFTPACK homepage or ESMF source tree. 4. Remove all references to MCEL in WRF system. Specific commit messages: 1. Remove unnecessary files from WRF source These files were used to split a large file into multiple pieces. We do not use this capability. deleted: external/fftpack/f90split.f90 deleted: external/fftpack/f90split.sh 2. Remove GPL license from FFTPACK, replace with a single LICENSE file. The original license change for FFTPACK in WRF in 2009 was ok'd by CISL (the distributor of the library). With the replacement of the library in 2014 (via svn), the original licenses were accidentally returned. Replaced GPL from every *.F with newer NCAR CISL license, and locate it in a single file: https://www2.cisl.ucar.edu/resources/legacy/fft5/license 3. Remove individual license statement from F90 and inc files for ESMF Grabbed license from LICENSE file from ESMF source: git clone https://git.code.sf.net/p/esmf/esmf modified: ESMF_Alarm.F90 modified: ESMF_AlarmClock.F90 modified: ESMF_Base.F90 modified: ESMF_BaseTime.F90 modified: ESMF_Calendar.F90 modified: ESMF_Clock.F90 modified: ESMF_Fraction.F90 modified: ESMF_Time.F90 modified: ESMF_TimeInterval.F90 modified: ESMF_Macros.inc modified: ESMF_TimeMgr.inc new file: LICENSE 4. MCEL is not used, not supported, and not being developed. Removal of all MCEL references gets rid of a GPL file. modified: ./Registry/Registry.CONVERT modified: ./Registry/Registry.EM_COMMON modified: ./Registry/Registry.NMM modified: ./dyn_em/start_em.F modified: ./external/Makefile modified: ./frame/module_io.F deleted: ./external/io_mcel/configure.wrf.example deleted: ./external/io_mcel/ext_mcel_open_for_read.F90 deleted: ./external/io_mcel/ext_mcel_open_for_write.F90 deleted: ./external/io_mcel/ext_mcel_read_field.F90 deleted: ./external/io_mcel/ext_mcel_write_field.F90 deleted: ./external/io_mcel/io_mcel.F90 deleted: ./external/io_mcel/makefile deleted: ./external/io_mcel/timeconvert.c LIST OF MODIFIED FILES: Registry/Registry.CONVERT Registry/Registry.EM_COMMON Registry/Registry.NMM dyn_em/start_em.F external/Makefile external/esmf_time_f90/ESMF_Alarm.F90 external/esmf_time_f90/ESMF_AlarmClock.F90 external/esmf_time_f90/ESMF_Base.F90 external/esmf_time_f90/ESMF_BaseTime.F90 external/esmf_time_f90/ESMF_Calendar.F90 external/esmf_time_f90/ESMF_Clock.F90 external/esmf_time_f90/ESMF_Fraction.F90 external/esmf_time_f90/ESMF_Macros.inc external/esmf_time_f90/ESMF_Time.F90 external/esmf_time_f90/ESMF_TimeInterval.F90 external/esmf_time_f90/ESMF_TimeMgr.inc external/esmf_time_f90/LICENSE external/fftpack/f90split.f90 external/fftpack/f90split.sh external/fftpack/fftpack5/LICENSE external/fftpack/fftpack5/c1f2kb.F external/fftpack/fftpack5/c1f2kf.F external/fftpack/fftpack5/c1f3kb.F external/fftpack/fftpack5/c1f3kf.F external/fftpack/fftpack5/c1f4kb.F external/fftpack/fftpack5/c1f4kf.F external/fftpack/fftpack5/c1f5kb.F external/fftpack/fftpack5/c1f5kf.F external/fftpack/fftpack5/c1fgkb.F external/fftpack/fftpack5/c1fgkf.F external/fftpack/fftpack5/c1fm1b.F external/fftpack/fftpack5/c1fm1f.F external/fftpack/fftpack5/cfft1b.F external/fftpack/fftpack5/cfft1f.F external/fftpack/fftpack5/cfft1i.F external/fftpack/fftpack5/cfft2b.F external/fftpack/fftpack5/cfft2f.F external/fftpack/fftpack5/cfft2i.F external/fftpack/fftpack5/cfftmb.F external/fftpack/fftpack5/cfftmf.F external/fftpack/fftpack5/cfftmi.F external/fftpack/fftpack5/cmf2kb.F external/fftpack/fftpack5/cmf2kf.F external/fftpack/fftpack5/cmf3kb.F external/fftpack/fftpack5/cmf3kf.F external/fftpack/fftpack5/cmf4kb.F external/fftpack/fftpack5/cmf4kf.F external/fftpack/fftpack5/cmf5kb.F external/fftpack/fftpack5/cmf5kf.F external/fftpack/fftpack5/cmfgkb.F external/fftpack/fftpack5/cmfgkf.F external/fftpack/fftpack5/cmfm1b.F external/fftpack/fftpack5/cmfm1f.F external/fftpack/fftpack5/cosq1b.F external/fftpack/fftpack5/cosq1f.F external/fftpack/fftpack5/cosq1i.F external/fftpack/fftpack5/cosqb1.F external/fftpack/fftpack5/cosqf1.F external/fftpack/fftpack5/cosqmb.F external/fftpack/fftpack5/cosqmf.F external/fftpack/fftpack5/cosqmi.F external/fftpack/fftpack5/cost1b.F external/fftpack/fftpack5/cost1f.F external/fftpack/fftpack5/cost1i.F external/fftpack/fftpack5/costb1.F external/fftpack/fftpack5/costf1.F external/fftpack/fftpack5/costmb.F external/fftpack/fftpack5/costmf.F external/fftpack/fftpack5/costmi.F external/fftpack/fftpack5/d1f2kb.F external/fftpack/fftpack5/d1f2kf.F external/fftpack/fftpack5/d1f3kb.F external/fftpack/fftpack5/d1f3kf.F external/fftpack/fftpack5/d1f4kb.F external/fftpack/fftpack5/d1f4kf.F external/fftpack/fftpack5/d1f5kb.F external/fftpack/fftpack5/d1f5kf.F external/fftpack/fftpack5/d1fgkb.F external/fftpack/fftpack5/d1fgkf.F external/fftpack/fftpack5/dcosq1b.F external/fftpack/fftpack5/dcosq1f.F external/fftpack/fftpack5/dcosq1i.F external/fftpack/fftpack5/dcosqb1.F external/fftpack/fftpack5/dcosqf1.F external/fftpack/fftpack5/dcost1b.F external/fftpack/fftpack5/dcost1f.F external/fftpack/fftpack5/dcost1i.F external/fftpack/fftpack5/dcostb1.F external/fftpack/fftpack5/dcostf1.F external/fftpack/fftpack5/dfft1b.F external/fftpack/fftpack5/dfft1f.F external/fftpack/fftpack5/dfft1i.F external/fftpack/fftpack5/dfftb1.F external/fftpack/fftpack5/dfftf1.F external/fftpack/fftpack5/dffti1.F external/fftpack/fftpack5/dsint1b.F external/fftpack/fftpack5/dsint1f.F external/fftpack/fftpack5/dsint1i.F external/fftpack/fftpack5/dsintb1.F external/fftpack/fftpack5/dsintf1.F external/fftpack/fftpack5/mcsqb1.F external/fftpack/fftpack5/mcsqf1.F external/fftpack/fftpack5/mcstb1.F external/fftpack/fftpack5/mcstf1.F external/fftpack/fftpack5/mradb2.F external/fftpack/fftpack5/mradb3.F external/fftpack/fftpack5/mradb4.F external/fftpack/fftpack5/mradb5.F external/fftpack/fftpack5/mradbg.F external/fftpack/fftpack5/mradf2.F external/fftpack/fftpack5/mradf3.F external/fftpack/fftpack5/mradf4.F external/fftpack/fftpack5/mradf5.F external/fftpack/fftpack5/mradfg.F external/fftpack/fftpack5/mrftb1.F external/fftpack/fftpack5/mrftf1.F external/fftpack/fftpack5/mrfti1.F external/fftpack/fftpack5/msntb1.F external/fftpack/fftpack5/msntf1.F external/fftpack/fftpack5/r1f2kb.F external/fftpack/fftpack5/r1f2kf.F external/fftpack/fftpack5/r1f3kb.F external/fftpack/fftpack5/r1f3kf.F external/fftpack/fftpack5/r1f4kb.F external/fftpack/fftpack5/r1f4kf.F external/fftpack/fftpack5/r1f5kb.F external/fftpack/fftpack5/r1f5kf.F external/fftpack/fftpack5/r1fgkb.F external/fftpack/fftpack5/r1fgkf.F external/fftpack/fftpack5/r4_factor.F external/fftpack/fftpack5/r4_mcfti1.F external/fftpack/fftpack5/r4_tables.F external/fftpack/fftpack5/r8_factor.F external/fftpack/fftpack5/r8_mcfti1.F external/fftpack/fftpack5/r8_tables.F external/fftpack/fftpack5/rfft1b.F external/fftpack/fftpack5/rfft1f.F external/fftpack/fftpack5/rfft1i.F external/fftpack/fftpack5/rfft2b.F external/fftpack/fftpack5/rfft2f.F external/fftpack/fftpack5/rfft2i.F external/fftpack/fftpack5/rfftb1.F external/fftpack/fftpack5/rfftf1.F external/fftpack/fftpack5/rffti1.F external/fftpack/fftpack5/rfftmb.F external/fftpack/fftpack5/rfftmf.F external/fftpack/fftpack5/rfftmi.F external/fftpack/fftpack5/sinq1b.F external/fftpack/fftpack5/sinq1f.F external/fftpack/fftpack5/sinq1i.F external/fftpack/fftpack5/sinqmb.F external/fftpack/fftpack5/sinqmf.F external/fftpack/fftpack5/sinqmi.F external/fftpack/fftpack5/sint1b.F external/fftpack/fftpack5/sint1f.F external/fftpack/fftpack5/sint1i.F external/fftpack/fftpack5/sintb1.F external/fftpack/fftpack5/sintf1.F external/fftpack/fftpack5/sintmb.F external/fftpack/fftpack5/sintmf.F external/fftpack/fftpack5/sintmi.F external/fftpack/fftpack5/xercon.F external/fftpack/fftpack5/xerfft.F external/fftpack/fftpack5/z1f2kb.F external/fftpack/fftpack5/z1f2kf.F external/fftpack/fftpack5/z1f3kb.F external/fftpack/fftpack5/z1f3kf.F external/fftpack/fftpack5/z1f4kb.F external/fftpack/fftpack5/z1f4kf.F external/fftpack/fftpack5/z1f5kb.F external/fftpack/fftpack5/z1f5kf.F external/fftpack/fftpack5/z1fgkb.F external/fftpack/fftpack5/z1fgkf.F external/fftpack/fftpack5/z1fm1b.F external/fftpack/fftpack5/z1fm1f.F external/fftpack/fftpack5/zfft1b.F external/fftpack/fftpack5/zfft1f.F external/fftpack/fftpack5/zfft1i.F external/fftpack/fftpack5/zfft2b.F external/fftpack/fftpack5/zfft2f.F external/fftpack/fftpack5/zfft2i.F external/fftpack/fftpack5/zfftmb.F external/fftpack/fftpack5/zfftmf.F external/fftpack/fftpack5/zfftmi.F external/fftpack/fftpack5/zmf2kb.F external/fftpack/fftpack5/zmf2kf.F external/fftpack/fftpack5/zmf3kb.F external/fftpack/fftpack5/zmf3kf.F external/fftpack/fftpack5/zmf4kb.F external/fftpack/fftpack5/zmf4kf.F external/fftpack/fftpack5/zmf5kb.F external/fftpack/fftpack5/zmf5kf.F external/fftpack/fftpack5/zmfgkb.F external/fftpack/fftpack5/zmfgkf.F external/fftpack/fftpack5/zmfm1b.F external/fftpack/fftpack5/zmfm1f.F external/io_mcel/configure.wrf.example external/io_mcel/ext_mcel_open_for_read.F90 external/io_mcel/ext_mcel_open_for_write.F90 external/io_mcel/ext_mcel_read_field.F90 external/io_mcel/ext_mcel_write_field.F90 external/io_mcel/io_mcel.F90 external/io_mcel/makefile external/io_mcel/timeconvert.c frame/module_io.F TESTS CONDUCTED: - [x] For FFTPACK and ESMF modifications, text only, so no testing required. - [x] For MCEL, code still builds without option, and no "unsatisfied externals".
TYPE: bug fix KEYWORDS: observation nudging, diagnostic prints, obs_prt_max SOURCE: Brian Reen (Army Research Lab) DESCRIPTION OF CHANGES: The observation nudging diagnostic prints controlled by obs_prt_max were sometimes incorrect. Information from different observations were sometimes mixed together and sometimes missing values were printed when it tried to print observations that were not available for printing. This bug did not influence the nudging itself, only the diagnostic prints regarding the nudging. Observation nudging stores some information to be printed about the obs in arrays specifically for diagnostic prints. However, some fields printed do not have diagnostic-print specific variables. When old obs are removed from non-diagnostic-print variables and the placement of obs in the array shifts to fill in the portion of the array left blank by the removal of old obs, previously the diagnostic print code was not aware of this. This resulted in it using the correct index to pull data from diagnostic-specific variables but the wrong index to pull data from non-diagnostic-specific variables. Now, the diagnostic-print variable indicating the index of the corresponding non-diagnostic-print variable is updated to account for the shifts in the placement of data within the arrays. When obs are determined to be too early when first read in, previously it would decrement the obs counter by one. However, for multi-level obs the check occurs at the end of the ob and thus all but the final level in the ob would be initially retained. Now, it decrements the ob counter by the number of levels in the current ob. Each obs in the array of obs to be printed is printed if it is not marked as missing. Previously, the headers for the obs prints were printed only if the first ob to be printed was not marked as missing, whereas now the headers are printed if any of the obs to be printed are not marked as missing. When obs are read in from the file, previously it would mark any obs prior to twice the length of the obs nudging window in the past as too early but then later (correctly) additionally mark any obs prior to once the length of the obs nudging window in the past for removal for being too early. After the changes described in the preceding paragraphs were made, while the obs printed had their information correctly printed, the number of obs printed could be much fewer than the user-specified maximum number of observations to print (obs_prt_max). This was because obs that met the first time criteria but not the second time criteria were included in the array of obs to print, and thus took up entries in this array, but were ultimately not printed because they were too early. Now, the first time criteria is changed to the correct time criteria, and thus the obs that are too early are not included in the list of obs to print and the number of obs printed can be more consistent with obs_prt_max. LIST OF MODIFIED FILES: M phys/module_fddaobs_rtfdda.F M share/wrf_fddaobs_in.F TESTS CONDUCTED: Tested with obs nudging enabled and found diagnostic prints are corrected by the changes but wrfout* files are unchanged as expected. RELEASE NOTE: Fixed a problem with observation nudging diagnostic prints (Thanks to Brian Reen of Army Research Lab).
TYPE: bug fix KEYWORDS: spelling in comment SOURCE: Piotr Kasprzyk (CIRI - self employed)" DESCRIPTION OF CHANGES: Change misspelled DIMENSION - it has no "E" letter by mistake LIST OF MODIFIED FILES: share/input_wrf.F TESTS CONDUCTED: Jenkins regression test
TYPE: bug fix KEYWORDS: max_ts_level SOURCE: Pedro Jimenez Munoz (RAL/MMM), internal DESCRIPTION OF CHANGES: The value of `max_ts_level` should be set less than or equal to the number of half levels. If `max_ts_level` is accidentally set to a larger value, the wrf_timeseries.F would try to access the vertical velocity (`w_2`) and other variables that are defined on full levels with an index outside of the variables' extent. A check is added to check_a_mundo to ensure that if `max_ts_level` is set up to a number larger than the number of half layers, then it is reset to the number of half layers. ISSUE: Fixes wrf-model#976 "Need check_a_mundo test: max_ts_level must be <= number of znu half layers" LIST OF MODIFIED FILES: M share/module_check_a_mundo.F M run/README.tslist TESTS CONDUCTED: 1. A single test is run to ensure the check works as expected. Below is the output: ``` Quilting with 1 groups of 0 I/O tasks. Ntasks in X 6 , ntasks in Y 6 max_ts_level must be <= number of znu half layers max_ts_level is reset to the number of znu half layers ```
…oud; terminal velocity for rimed snow (wrf-model#957) TYPE: bug fix KEYWORDS: MP, Thompson, xDs, vts_boost SOURCE: Greg Thompson (NCAR-RAL) DESCRIPTION OF CHANGES: Some relatively minor bug fixes and safety checks 1. xDs (mass-weighted mean size snow) was only set if both cloud water and snow coexist in grid box, so its calculation was moved out of IF-test to be calculated at any grid box with any reasonable amount of snow. 2. couple small safety checks to avoid exceeding max amount of possible snow, graupel, or cloud water in a few places (e.g., prs_scw, prr_sml, tmg_gacs) 3. vts_boost should always default 1.0, not 1.5. vts_boost is the factor applied to snow terminal fallspeed due to riming of snow (up to 50% faster). 4. ensure snow moment variables get initialized to zero in calc_refl10cm 5. density calculation moved up (out of IF-test) in preparation for additional future changes where it is always needed. 6. permitting larger max value of ice crystal concentration (999 per Liter) 7. small constant change related to rimed snow boost terminal velocity LIST OF MODIFIED FILES: M phys/module_mp_thompson.F TESTS CONDUCTED: 1. After these mods, the code compiles and produces indistinguishable changes in final WRF runs. There were such small changes that nothing can be easily found in any real model simulation results to see any impacts.
TYPE: bug fix KEYWORDS: fire, bounds check, vertical index SOURCE: Internal DESCRIPTION OF CHANGES: A bounds check indicated a half-level variable was accessed with the vertical index at the top full-level. Only a single array is in the DO loop. The vertical index is reduced by one. LIST OF MODIFIED FILES: modified: phys/module_fr_fire_util.F TESTS CONDUCTED: - [x] Without mod, the WRF Fire code built with bounds checking activated throws an error. - [x] With mod, the WRF Fire code built with bounds checking activated completes the simulation without any troubles.
TYPE: text only KEYWORDS: WSM7, WDM7, README SOURCE: internal DESCRIPTION OF CHANGES: Microphysics options WSM7 and WDM7 were introduced in 4.1, but not added to README.namelist file. This PR adds them. LIST OF MODIFIED FILES: M run/README.namelist TESTS CONDUCTED: No test needed.
TYPE: bug fix KEYWORDS: GOCART, WRF-Chem, dust gravitational settling flux. SOURCE: Alexander Ukhov, KAUST DESCRIPTION OF CHANGES: I introduced a typo in wrf-model#714. This typo affected only the diagnostic variables (GRASET_1,...,5). Dust mixing ratios were not affected. The derivation of the dust gravitational flux in the surface grid-cell is attached below. Multiplication by RHO_air is done in strings 158-162. LIST OF MODIFIED FILES: chem/module_gocart_settling.F TESTS CONDUCTED: After the changes model runs and outputs corrected dust flux. RELEASE NOTE: Corrected a typo in diagnostic dust gravitational settling flux (Thanks to Alexander Ukhov, KAUST).
…l#1019) TYPE: text only KEYWORDS: release, version_decl, README, v4.1.3 SOURCE: internal DESCRIPTION OF CHANGES: Updated the top-level README file, and the inc/version_decl file to version 4.1.3. LIST OF MODIFIED FILES: M README M inc/version_decl TESTS CONDUCTED: Reg-test passed.
…-model#952) TYPE: bug fix KEYWORDS: Linux, Darwin, nc-config, configure SOURCE: Yago Riveiro (Air Quality and Odor Management - AQOM), internal DESCRIPTION OF CHANGES: This pull fixes the incorrect use of `whereis` when we try to locate `nc-config` command. - Only the `which` command is valid. - The return code is used, not the value of the `which nc-config` command. - There is no need to determine the OS with this fix. LIST OF MODIFIED FILES: M configure TESTS CONDUCTED: - [x] Re-run configure script, the warning disappears - [x] Still works on Darwin (netcdf/3.6.3 and netcdf/4.5.0) - [x] Still works on Linux desktop Centos 7.6 (netcdf/4.7.0) - [x] Still works on Linux NCAR supercomputer SUSE 12 SP4 (netcdf/4.6.3)
…rf-model#1027) TYPE: bug fix KEYWORDS: effective radius, lamda calculation SOURCE: Yali Wu (NCAR) DESCRIPTION OF CHANGES: Subroutine `da_cld_eff_radius` uses exponential distribution for calculating the effective radius of different hydrometeor particles. Slope parameters should be calculated following: ``` sqrt(sqrt(piover6*rho_x*n0_x/(rho*qx))) ``` but this was incorrectly typed, so that rho is in the numerator: ``` sqrt(sqrt(piover6*rho_x*n0_x*rho/qx))) ``` where, x denotes rain, snow, and graupel. LIST OF MODIFIED FILES: M var/da/da_radiance/da_cld_eff_radius.inc TESTS CONDUCTED: Conducted tests before and after bugfix on Cheyenne. The model simulated MW radiances were slightly improved for a typhoon case, while the simulated IR radiances seemed to have no difference.
TYPE: bug fix KEYWORDS: sfclayrev scheme, divide by zero SOURCE: internal (reported by CH Liu) DESCRIPTION OF CHANGES: During iterative solution for z/L there are rare cases where the same bit-for-bit value is returned for slightly different inputs to function zolri2 resulting in a divide by zero. This appears to be rare. Fix is to return when these are found equal because solution is converged already. LIST OF MODIFIED FILES: phys/module_sf_sfclayrev.F TESTS CONDUCTED: Fix works for case that stopped. Test on standard June case is bit-for-bit as expected Jenkins passed RELEASE NOTE: Fix for occasional divide-by-zero error in sfclayrev option. Thanks Changhai Liu.
TYPE: text only
KEYWORDS: hybrid comments
SOURCE: Found by Kezhen Chong (Georgia Institute of Technology), fixed internally
DESCRIPTION OF CHANGES:
Modify the comments in registry.hyb_coord to correctly define c4f and c4h. Originally, the value
of the pressure at the model lid (ptop) was included in the description of the computation of
the C4F and C4H 1d arrays as an added term. Following is the source code showing no such term.
```
! c4 is a function of c3 and eta.
DO k=1, kde
c4f(k) = ( znw(k) - c3f(k) ) * ( p1000mb - p_top )
ENDDO
! Now on half levels, just add up and divide by 2 (for c3h). Use (eta-c3)*(p00-pt) for c4 on half levels.
DO k=1, kde-1
c4h(k) = ( znu(k) - c3h(k) ) * ( p1000mb - p_top )
ENDDO
```
ISSUE:
Fixes wrf-model#1050
LIST OF MODIFIED FILES:
modified: Registry/registry.hyb_coord
TESTS CONDUCTED:
- [x] Text only in comment in a registry file, no tests required.
…rf-model#1049) TYPE: bug fix KEYWORDS: HWRF, build, run SOURCE: internal DESCRIPTION OF CHANGES: To get the HWRF code to build and run the regression test cases, two changes are required: ### Build There is a replicated symbol in subroutine feedback_domain_nmm_part2: SMOOTHER. This named symbol cannot be both a LABEL and the name of a called SUBROUTINE within a single subprogram unit (subroutine or function). Just a quick misspelling of SMOOTHR works wonders. ### Run Link in (ln -sf) all of the look-up tables to the test/nmm_real directory in the last step of the build process. Most of the run-time-required links to physics data files were not originally in place. LIST OF MODIFIED FILES: modified: Makefile modified: external/RSL_LITE/module_dm.F TESTS CONDUCTED: - [x] Without build mod (replicated symbol), code does not build with GNU - [x] Without run mod (linked-in look-up tables), the code does not run regression tests - [x] With both mods, the code builds and runs. - [x] Regression test is now in place for HWRF.
TYPE:bug fix KEYWORDS: fire, pop, push, communicator SOURCE: internal DESCRIPTION OF CHANGES: Problem: WRF gets into a state where the code tries to pop or push a stack of communicators. This should not happen when doing a Serial or OpenMP build. Here is the example error message we get with a push on OpenMP: ``` -------------- FATAL CALLED --------------- FATAL CALLED FROM FILE: <stdin> LINE: 5489 pop_communicators_for_domain on empty stack ------------------------------------------- ``` And here is the example error message with a pop with OpenMP: ``` -------------- FATAL CALLED --------------- FATAL CALLED FROM FILE: <stdin> LINE: 5464 push_communicators_for_domain would excede stacksize ------------------------------------------- ``` Solution: This problem only occurs with Serial or OpenMP builds. The communicators are only required for distributed memory MPI jobs. Therefore, put an ifdef around the routine that handles pops and pushes of the the communicator stack. LIST OF MODIFIED FILES: modified: external/RSL_LITE/module_dm.F TESTS CONDUCTED: - [x] Auto regression is HAPPY!
TYPE: bug fix KEYWORDS: eta, levels SOURCE: internal DESCRIPTION OF CHANGES: Problem: The real program fails when the number of vertical levels is more than a thousand. Solution: There is a single PARAMETER in the frame directory that is used to allocate space for the namelist read and the eta computation in the real program. We absolutely need a parameter for allocating space for the namelist variables. The original value for the maximum number of eta levels was 1001. The 10x increase in size (from 1001 to 10001) impacts only a couple of 1d arrays, so the WRF memory footprint is not dramatically increased. The mods to the real program are for a stand-alone program buried in the source, and therefore do not impact the traditional processing of either the real program or the WRF model. LIST OF MODIFIED FILES: modified: dyn_em/module_initialize_real.F modified: frame/module_driver_constants.F TESTS CONDUCTED: - [x] Original version with 1100 eta levels fails with bound check on Mac. - [x] New mods, real on Mac with 1100 eta levels works OK. ``` Full level index = 1 Height = 0.0 m Full level index = 2 Height = 50.0 m Thickness = 50.0 m Full level index = 3 Height = 73.0 m Thickness = 23.1 m Full level index = 4 Height = 96.1 m Thickness = 23.1 m Full level index = 5 Height = 119.2 m Thickness = 23.1 m Full level index = 6 Height = 142.2 m Thickness = 23.0 m Full level index = 7 Height = 165.2 m Thickness = 23.0 m Full level index = 8 Height = 188.3 m Thickness = 23.0 m Full level index = 9 Height = 211.3 m Thickness = 23.0 m Full level index = 10 Height = 234.3 m Thickness = 23.0 m Full level index = 1090 Height = 19738.8 m Thickness = 15.9 m Full level index = 1091 Height = 19754.7 m Thickness = 15.9 m Full level index = 1092 Height = 19770.7 m Thickness = 15.9 m Full level index = 1093 Height = 19786.6 m Thickness = 15.9 m Full level index = 1094 Height = 19802.5 m Thickness = 15.9 m Full level index = 1095 Height = 19818.4 m Thickness = 15.9 m Full level index = 1096 Height = 19834.4 m Thickness = 15.9 m Full level index = 1097 Height = 19850.3 m Thickness = 15.9 m Full level index = 1098 Height = 19866.2 m Thickness = 15.9 m Full level index = 1099 Height = 19882.2 m Thickness = 15.9 m Full level index = 1100 Height = 19898.3 m Thickness = 16.1 m d01 2000-01-25_12:00:00 real_em: SUCCESS COMPLETE REAL_EM INIT ``` RELEASE NOTE: The number of vertical levels for the WRF model was increased from 1001 to 10001. Certainly 10000 vertical levels is very large. However, 3 domains with increasing numbers of eta levels (from vertical refinement) of 250, 350, 450 eta levels would previously have exceed the 1001 maximum value.
…odel#1043) TYPE: bug fix KEYWORDS: Deng shallow, radiation-driver clouds SOURCE: internal and Pedro Jimenez DESCRIPTION OF CHANGES: Line qc_save = qc must be removed from Deng shallow section of radiation driver because it may save qc that is already updated by other physics that have radiation feedback, e.g. icloud, cu or bl. Leads to error when combining Deng shallow with such options (already not recommended with cumulus scheme). qc_save was already set for all options earlier. LIST OF MODIFIED FILES: phys/module_radiation_driver.F TESTS CONDUCTED: This fix has been tested by Pedro in WRF-Solar. No regtests yet. Test shows impact when Deng shcu is run with sub-grid clouds from MYNN icloud_bl=1. Left fixed, right old. Higher cloud fraction which leads to reduced surface shortwave compared to corrected code. [Note that a later bug fix will not allow this combination, but fix applies to Deng shcu with sub-grid clouds from cumulus schemes and icloud=3 too]. Screen Shot 2019-12-18 at 1 39 55 PM RELEASE NOTE: Deng shallow scheme fix for when combined with other sub-grid cloud schemes (e.g. non-microphysics options that have radiation feedback). This would have added these clouds to microphysics at each step instead of removing them after radiation. (provided by Pedro Jimenez).
TYPE: bug fix KEYWORDS: WDM5, WDM6, WDM7 SOURCE: Kyo-Sun Lim (Kyungpook National University) and Sooya Bae (KIAPS). DESCRIPTION OF CHANGES: Error correction based on Lei et al. (JGR, 2020) Melting of snow/graupel : -Problem: melting processes of snow/graupel mass and number concentration do not occur at the same time. -Correction: melting of snow/graupel changes the snow/graupel/rain mass and rain number concentration at the same time. -Effect: Generation of rain number concentrations would decrease. Regeneration of CCN number concentration due to the cloud water evaporation: -Problem: Cloud water number concentration does not add into the CCN number concentration. -Correction: Adding the cloud water number concentration into the CCN number concentration. Effect: CCN number concentration would increase. ISSUE: none LIST OF MODIFIED FILES: module_mp_wdm5.F module_mp_wdm6.F module_mp_wdm7.F TESTS CONDUCTED: Passed Jenkins WDM6 tested versus master. Diffs small for surface fields including rainfall after 12 hrs of June 2001 test case (shown). Screen Shot 2020-02-04 at 12 39 13 PM RELEASE NOTE: Melting of snow/graupel now changes the snow/graupel/rain mass and rain number concentration at the same time in all WDM schemes provided by Kyo-Sun Lim (Kyungpook National University, South Korea).
TYPE: no impact KEYWORDS: README update for release SOURCE: internal DESCRIPTION OF CHANGES: update the top-level README file, and the inc/version_decl file with the correct version LIST OF MODIFIED FILES: M README M inc/version_decl TESTS CONDUCTED: not necessary
Finalize WRFv4.1.4 by merging bug foxes from release-v4.1.4 branch to master. See the Annotation of the v4.1.4 tag for full releae notes (git show v4.1.4).
c7bccf4
to
9592080
Compare
|
Plots look fine, same as paper reference. Will merge this.
|
76c1369
to
3962bb3
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Update WRF to 4.1.4.