Release v4.7.0 #2172
Open
Release v4.7.0 #2172
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
Pleim-Xiu LSM MODIS LCZ Compatibility & Surface Evaporation Update TYPE: bug fix & physics refinement KEYWORDS: MODIS, LCZ, P-X LSM, Latent Heat Flux SOURCE: Robert Gilliam & Jon Pleim, US EPA DESCRIPTION OF CHANGES: Problem: User indicated that the P-X LSM errored for MODIS LCZ 61 NUM_LAND_CAT configuration. Currently, we account for evaporation from transpiration, soil in both vegetated and non-veg parts, and wet leaves. But we only account for the latent heat effects on Tg from transpiration and evaporation from non-veg soil. This fix adds latent heat effects on Tg from soil in vegetated parts and from wet leaves. Fix for rare case where GRDFLX goes NaN because of a divide by zero based on a soil parameter when a water cell turns to sea ice. Solution: Logic checks in module_physics_init.F and module_sf_pxlsm.F were adjusted for 61 category inputs. P-X LSM data table, module_sf_pxlsm_data.F was updated for MODIS 61 categories. Default for LCZ 51-61 was set to MODIS urban class. We also added updates for the evaporation from vegetation and wet canopy. ISSUE: Fixes: #1965 LIST OF MODIFIED FILES: M phys/module_physics_init.F M phys/module_sf_pxlsm.F M phys/module_sf_pxlsm_data.F - Tested 61 class LCZ with PX LSM for a 1 day simulation with updated codes. Ran base MODIS 21 class scheme with same code before and after LCZ update. The results were identical after a 24 hour simulation. This confirms updates do not impact other MODIS settings in the P-X LSM. The MODIS 21 was by nature not identical to the MODIS 61, but similar enough and differences follow underlying differences in MODIS datasets. - The Jenkins tests are all passing. RELEASE NOTE: Pleim-Xiu LSM is now compatible with 61 category MODIS LCZ landuse dataset. A mode of latent heat effects on Tg from vegetated parts and from wet leaves is added to Pleim-Xiu LSM.
) TYPE: bug fix KEYWORDS: WRF-Chem, GOCART, optical properties, dust, sea salt, AOD SOURCE: KAUST DESCRIPTION OF CHANGES: Problem: It was found that WRF-Chem with GOCART aerosol scheme disregards the radiative effect of the largest dust and sea salt particles (5th and 4th bins). Solution: Mass redistribution between GOCART dust/sea salt and MOZAIC bins now accounts for the 5th dust and 4th sea salt bins. The number of MOZAIC bins was changed from 8 to 9 and MOZAIC max size range was increased from 10 to 20 um. This PR is an addition to #667 and #677 PR. LIST OF MODIFIED FILES: M chem/module_optical_averaging.F M chem/optical_driver.F TESTS CONDUCTED: - 7-day WRF-Chem run over the Middle East with the GOCART aerosol scheme was conducted without the changes and with changes. As expected, AOD increased by 3% on average. Over dust source regions the AOD increase is more pronounced - 5% on average. See PR itself for details. - The Jenkins tests are all passing. RELEASE NOTE: Bug fix in the calculation of optical properties. Mass redistribution between GOCART dust/sea salt and MOZAIC bins was corrected. It slightly increased (by 3-5%) the aerosol optical depth (AOD).
TYPE: bug fix KEYWORDS: grav_setting, LCZ SOURCE: Adam Dury (WeatherQuest) DESCRIPTION OF CHANGES: Problem: WRF crashes when grav_settling is greater than 0 and wudapt_lcz = 1 due to the historical code using hard coded values for land categories to detect which land use type is being used. This isn't the case now so needed to update to use a variable with actual land use category type so the grav_settling code would work when wudapt_lcz was turned on and the nlcat wasnt the same for each land use type. Solution: Changed the if statements to use mminlu rather than nlcat so that the grav_settling option knows what land use dataset is being used. Corrected the error message to go into rsl.error files rather than rsl.out files LIST OF MODIFIED FILES: phys/module_sf_fogdes.f phys/module_surface_driver.f TESTS CONDUCTED: 1. Tested with wudapt_lcz on and off with all option of grav_settling. 2. The Jenkins tests are all passing. RELEASE NOTE: Updated grav_settling code to better recognize the land use type so it doesn't crash. Also update the error message if it does crash to go into the rsl.error files rather than rsl.out files.
TYPE: enhancement KEYWORDS: cmake, configuration SOURCE: internal DESCRIPTION OF CHANGES: Problem: The configuration checks done by the CMake build use language-specific calls between various functions. This has lead to a rather complex signature that is also limited in scope. Solution: Simplify the `wrf_conf_check` calls to make use of CMake's built-in `try_compile()` and `try_run()` functions, forwarding argument to those as necessary. Aside from minor adjustments to the `wrf_conf_check` calls this should appear as a drop-in replacement that provides the same results as before, i.e. no change to the system configuration options detected.
TYPE: bug fix KEYWORDS: netcdf, cmake SOURCE: internal DESCRIPTION OF CHANGES: Problem: Certain versions of netCDF with particular configurations return a blank when queried with `nc-config`. To prevent a null argument expansion in CMake we should check for variable emptiness and if empty assume the queried feature is not present. There is a typo copied from the FindnetCDF-Fortran.cmake module causing this check to never get exercised leading to failed configuration due to syntax errors. Solution: Correct the typo to reference the netCDF variables rather than the netCDF-Fortran ones. TESTS CONDUCTED: 1. Tested against netCDF 4.7.2 without szlib (`--has-szlib -> `) RELEASE NOTE: Bug fix in CMake FindnetCDF.cmake for empty --has-* nc-config fields
TYPE: bug fix KEYWORDS: compilation, cmake SOURCE: internal DESCRIPTION OF CHANGES: Problem: With the addition of #2088, `ARCH_LOCAL` from the stanza is now being fed into compilation with potential `-D` defines. On versions of CMake <3.26 leading `-D` on defines is not removed from certain function calls like `add_compile_definitions()`. This will pass the configuration stage but will fail to compile when using the defined minimum CMake version of the project. Solution: To simplify the logic, all defines fed into the `wrf_config.cmake` file for the configuration step will be sanitized of leading `-D`. This follows the original design intent where stanza sanitization happens before being fed into CMake, thus allowing the CMake code to focus on configuration of options rather than translation of stanza into usable values. TESTS CONDUCTED: 1. Tested configuration and compilation on CMake version v3.20.6 RELEASE NOTE: Remove leading -D on defines during stanza reading to allow older versions of CMake to configure properly.
TYPE: bug fix KEYWORDS: compilation, cmake SOURCE: internal DESCRIPTION OF CHANGES: Problem: As noted in #2124, prior to CMake 3.23, when defining custom properties the `BRIEF_DOCS` and `FULL_DOCS` are non-optional arguments. Solution: Add proper documentation to the custom properties to allow minimum CMake version requirements of the project to remain the same. ISSUE: Addresses #2124 TESTS CONDUCTED: 1. Tested on CMake v3.20.6 RELEASE NOTE: Add documentation to custom properties in CMake to fix compatibility with older versions.
#2125) This change fixes the warning appearing when calling `configure_new` with newer versions of Cmake. TYPE: bug fix KEYWORDS: cmake, configure SOURCE: Jakub Lewandowski (University of Leeds) DESCRIPTION OF CHANGES: Problem: When calling `configure_new` script with newer versions of Cmake (3.30.5 in my case) warning appears: ``` CMake Warning (dev) at CMakeLists.txt:5 (enable_language): project() should be called prior to this enable_language() call. This warning is for project developers. Use -Wno-dev to suppress it. ``` Solution: This is easily fixable by calling `project()` before `enable_language()` as the warning suggests. ISSUE: For use when this PR closes an issue. n/a LIST OF MODIFIED FILES: CmakeLists.txt TESTS CONDUCTED: 1. Do mods fix problem? How can that be demonstrated, and was that test conducted? 2. Are the Jenkins tests all passing? I tested the change on my machine and it solved the issue. As the change is very minor it should not cause issues for others. RELEASE NOTE: Fixed CMake dev warning `project() should be called prior to this enable_language() call` appearing when using `configure_new` script with some newer versions of Cmake.
TYPE: bug fix KEYWORDS: autogeneration, compilation, cmake SOURCE: internal DESCRIPTION OF CHANGES: Problem: Currently the CMake build system minimum version is limited by the automated scoping of generated property on certain source files. This in combination of `CMP0118` requires usage of CMake >3.20 Solution: Set the generated property at the correct scope for source file usage. Lower the minimum required version to reflect this change. Note that CMake 3.18.6 is not used as there are features from 3.19 in use that, while could be implemented by hand, would take more effort to remove than the gained benefit. TESTS CONDUCTED: 1. Combined with #2125, #2130, and #2131 this was tested on the latest patch of each unique minor release of CMake since v3.19.8. The full list of tested versions is as follows: v3.19.8 v3.20.6 v3.21.7 v3.22.6 v3.23.5 v3.24.4 v3.25.3 v3.26.6 v3.27.9 v3.28.6 v3.29.8 v3.30.5 v3.31.0 RELEASE NOTE: Set the generated property on autogen source code explicitly in CMake and allow for lowered minimum CMake version of v3.19
TYPE: bug fix KEYWORDS: cmake, flags, optimization SOURCE: internal DESCRIPTION OF CHANGES: Problem: To feed initial flags into the cmake build, a toolchain file is used. However, for particular build configurations, namely release and debug, despite the configuration being "Release" and "Debug", respectively, the corresponding `CMAKE_<LANG>_FLAGS_<CONFIG>_INIT` has the configuration name capitalized. Additionally, these initial flags supplement the starting flags and do not override any inherited flags that CMake automatically appends. This can cause issues with certain compilers where subsequent flags that normally should supersede previously listed options are ignored. As an example, using nvfortran/pgi the following will cause forced optimization, which is not viable for some files within WRF : https://forums.developer.nvidia.com/t/nvfortran-reducing-optimation-level-by-multiple-on-does-not-work/191825 https://forums.developer.nvidia.com/t/how-to-override-pgccs-optimization-flag/136275 Finally, certain files do not have optimization overridden even if it were to work correctly Solution: Ensure correct variable name in toolchain file to provide initial starting flags, and wipe CMake-injected release flags to avoid significant deviation from provided optimization flags. Add proper directory scope to files that need these reduced optimizations. TESTS CONDUCTED: 1. Tested with CMake build on Derecho selecting nvhpc/pgi compiler stanzas RELEASE NOTE: Override CMake-injected optimization flags in favor of the flags set by the build system and provided stanza information.
TYPE: enhancement KEYWORDS: cmake, wrfplus SOURCE: internal DESCRIPTION OF CHANGES: Problem: The current CMake build does not build the WRF PLUS core configuration Solution: Add the necessary source files to compile WRF PLUS. WRF binary will still be created, but a symlink to `wrfplus.exe` will also be created for backward compatibility
TYPE: enhancement, no impact KEYWORDS: manage_externals, some physics for tropical suite SOURCE: internal DESCRIPTION OF CHANGES: Add the use of manage_externals tool to access physics in [MMM-physics](https://github.com/NCAR/MMM-physics) repository. The physics we access are part of the 'tropical' suite: YSU PBL, revised MM5 surface layer, WSM6 microphysics, and new Tiedtke scheme. It also accesses GWDO option 1 routine. These modules have been residing in phys/physics_mmm/ in 4.6. Instead of copied files in this directory, we now use manage_externals to access these modules from MMM-physics repository. Will need to update the tags specified in Externals.cfg before final release. LIST OF MODIFIED FILES: A arch/Externals.cfg M phys/Makefile D phys/physics_mmm/bl_gwdo.F90 D phys/physics_mmm/bl_ysu.F90 D phys/physics_mmm/cu_ntiedtke.F90 D phys/physics_mmm/module_libmassv.F90 D phys/physics_mmm/mp_radar.F90 D phys/physics_mmm/mp_wsm6.F90 D phys/physics_mmm/mp_wsm6_effectRad.F90 D phys/physics_mmm/sf_sfclayrev.F90 A tools/manage_externals/ TESTS CONDUCTED: 1. Successfully compiled the code on Derecho. 2. Are the Jenkins tests all passing? RELEASE NOTE: Add manage_externals tool to access physics modules in MMM-physics git repository.
TYPE: bug fix KEYWORDS: cmake, mpi, compilation SOURCE: internal DESCRIPTION OF CHANGES: Problem: The `arch/configure_reader.py` does the job of parsing, organizing, and sanitizing input from configuration stanzas into a CMake toolchain file which can then be used to inform the build about which compilers, flags, and options to use. Occasionally, stanzas fields inject flags into a compiler or other command field (like `DM_FC`) so that the actual command is a command + flags. Part of the `arch/configure_reader.py` organization is breaking these up into separable sections automatically. With the example of `DM_FC = mpif90 -f90=gfortran` (`$(SFC)` already expanded) this _should_ be broken into `DM_FC = mpif90` and `DM_FC_FLAGS = -f90=gfortran`. Currently, the `*_FLAGS` field when split out for certain keys in a stanza is not populated due to using the wrong index from the Python `str.partition()` call. Secondly, when these fields are actually provided to CMake compilation breaks for MPI specifically. Since the MPI "compilers" are wrappers, they are then interrogated for the underlying flags and options meaning further adding the flags back into compilation results in things like `gfortran <all the other flags> -f90=gfortran`. This is incorrect, and instead the flags should be provided to the MPI flags used during wrapper interrogation on a per-language basis. Furthermore, for certain MPI implementations supplying any flags renders the query command (e.g. `-show`, `-showme`, or `-compileinfo`) useless. For instance, OpenMPI `mpif90 -f90=gfortran -show` only outputs `gfortran -f90=gfortran` which is also wrong. Solution: 1. The Python call to split the fields should take the actual values 2. MPI flags per language should be supplied to the interrogation flags `MPI_<LANG>_COMPILER_FLAGS` if needed 3. The `FindMPI` module already feeds in the underlying compiler specification for wrappers that support it so flags like `-f90=$(SFC)` should be filtered out from `DM_*_FLAGS` before being written to the `wrf_config.cmake` toolchain file TESTS CONDUCTED: 1. Flags in specific command fields are now split and appearing in the `wrf_config.cmake` file 2. MPI compilation works with compiler specification filtered out but correct underlying compiler still selected even when multiple compilers are in the same environment (note: this was the original behavior but now is deliberate)
TYPE: bug fix
KEYWORDS: double precision, configuration, make, cmake
SOURCE: internal
DESCRIPTION OF CHANGES:
Problem:
Currently, the source code has multiple preprocessor definitions for
controlling double precision usage (1). Likewise, there are multiple
parameter definitions in the IO code for the `WRF_REAL` value (2).
Examples of (1) :
```
#if ( RWORDSIZE == 8 )
#if ( RWORDSIZE == DWORDSIZE )
#if ( DWORDSIZE == 8 && RWORDSIZE == 8 )
```
Because there is no definitive define for querying double precision, it
has been left as an exercise to the contributor to formulate an adequate
conditional. While the above and other such forms work, they are not
consistent and can be confusing as to the intent.
Examples of (2) in a directory with option `-r8` :
```bash
grep -RiE "WRF_REAL.*=.*[0-9]+" | sort -u
# original version
external/ioapi_share/wrf_io_flags.h: integer, parameter :: WRF_REAL = 104
external/io_grib1/io_grib1.f90: integer, parameter :: WRF_REAL = 104
external/io_grib_share/io_grib_share.f90: integer, parameter :: WRF_REAL = 104
external/io_int/diffwrf.f: integer, parameter :: WRF_REAL = 104
external/io_int/io_int.f: integer, parameter :: WRF_REAL = 105
external/io_netcdf/wrf_io.f: integer, parameter :: WRF_REAL = 104
frame/module_io.f90: integer, parameter :: WRF_REAL = 105
frame/module_quilt_outbuf_ops.f90: integer, parameter :: WRF_REAL = 105
# modified version
# inc/wrf_io_flags.h: integer, parameter :: WRF_REAL = 105
main/real_em.f90: integer, parameter :: WRF_REAL = 105
share/input_wrf.f90: integer, parameter :: WRF_REAL = 105
share/mediation_integrate.f90: integer, parameter :: WRF_REAL = 105
share/output_wrf.f90: integer, parameter :: WRF_REAL = 105
share/track_input.f90: integer, parameter :: WRF_REAL = 105
share/wrf_bdyin.f90: integer, parameter :: WRF_REAL = 105
share/wrf_bdyout.f90: integer, parameter :: WRF_REAL = 105
share/wrf_tsin.f90: integer, parameter :: WRF_REAL = 105
var/da/da_main/da_update_firstguess.inc: wrf_real=104
```
Across many different preprocessed files, there appears to be two values
of `WRF_REAL` which could lead to undesired behavior when interfacing
between different sections of code. This issue arises from the `sed`
command in `external/ioapi_share/makefile` where `wrf_io_flags.h` is
changed in the `inc/` folder _only_, and thus anything including
`external/ioapi_share` first has one definition whilst anything
including `inc/` has the changed value.
While (2) may seem like an entirely separate problem from (1) they are
interrelated. `wrf_io_flags.h` already partially contains the necessary
logic to control whether to use `104` or `105` when double precision
promotion is requested. The current logic is not being used correctly
fully as it uses a totally different (and undefined) form of double
precision query :
```fortran
#ifdef PROMOTE_FLOAT
integer, parameter :: WRF_FLOAT = WRF_DOUBLE
#else
integer, parameter :: WRF_FLOAT = WRF_REAL
#endif
```
The end result will always be `WRF_FLOAT = WRF_REAL` regardless of `-r8`
option since `PROMOTE_FLOAT` is not defined anywhere in the
configuration / compilation logic. However, `WRF_FLOAT` _happens to be
used correctly_ since the `sed` rewrite has changed `WRF_REAL` to `105`
(effectively the same as `WRF_FLOAT = WRF_DOUBLE`). This only works
because `WRF_FLOAT` is exclusively used only in files that access the
`inc/wrf_io_flags.h` rewritten file and not the
`external/ioapi_share/wrf_io_flags.h` one. Furthermore, aside from
`io_int.F`, no code that contains the `105` value utilizes `WRF_REAL`
```bash
# Looking for any incorrect usage of WRF_FLOAT in files with 104 value
# we're really only concerned with unique statements of computational code
grep -RiEl "WRF_REAL.*=.*104" | sort -u | xargs -i grep -iH WRF_FLOAT {} | sort -u
external/ioapi_share/wrf_io_flags.h: integer, parameter :: WRF_FLOAT=WRF_DOUBLE
external/io_grib1/io_grib1.f90: integer, parameter :: WRF_FLOAT=WRF_REAL
external/io_grib_share/io_grib_share.f90: integer, parameter :: WRF_FLOAT=WRF_REAL
external/io_int/diffwrf.f: integer, parameter :: WRF_FLOAT=WRF_REAL
external/io_netcdf/wrf_io.f: integer, parameter :: WRF_FLOAT=WRF_REAL
# No usage of bad value, only the include declaration shows up
```
```bash
# Look for usage of WRF_REAL where its value has been changed to 105 thus
# leading to ambiguous definitions
# Exclude declarations for brevity
grep -RiEl "WRF_REAL.*=.*105" | sort -u | xargs -i grep -iH WRF_REAL {} | sort -u | grep -vE "integer, parameter[ ]*:: WRF_"
external/io_int/io_int.f: CALL wrf_message('io_int.F90: ext_int_read_field: types other than WRF_REAL not supported yet')
external/io_int/io_int.f: IF ( FieldType .EQ. WRF_REAL .OR. FieldType .EQ. WRF_DOUBLE) THEN
external/io_int/io_int.f: IF ( FieldType .EQ. WRF_REAL ) THEN
external/io_int/io_int.f: IF ( FieldType .EQ. WRF_REAL ) THEN
# These are character strings
main/real_em.f90: IF ( config_flags%auxinput1_inname(1:8) .NE. 'wrf_real' ) THEN
share/input_wrf.f90: ( config_flags%auxinput1_inname(1:8) .EQ. 'wrf_real' ) ) ) THEN
```
Solution:
To reduce the overall complexity of various define constructs _and_ IO
inconsistencies a singular define `DOUBLE_PRECISION` can be introduced
specifically meant to inform sections of code whether double precision
promotion has been requested.
Adding "one more define" may not sound appealing at first, but it does
carry some benefits :
* Firstly, it does not require the user to hard code values of `4` or
`8` for single or double precision, respectively, where those are
already defined by `NATIVE_RWORDSIZE` and `DWORDSIZE`.
* Furthermore, rather than use `#if (RWORDSIZE == DWORDSIZE)` logic can
be simplified to a more coherent statement of `#ifdef DOUBLE_PRECISION`
which is more readable and better understood in intent.
* Finally, reducing duplication of defines to do the same thing is good
practice _and_ limiting defines to control one thing only avoiding
co-opting for multiple roles is *also* good practice. The first part
sounds counter to a new define but `RWORDSIZE` and `DOUBLE_PRECISION`
serve two different functions - the former to tell us the numeric size
of real data in bytes and the latter to tell us if alternate logic
should be used. An alternative solution to only use a single define
would be to have `DOUBLE_PRECISION` control an `rkind` setting
`RWORDSIZE` much like `kind_phys` for ccpp
For areas where `WRF_REAL` was used with a value of `105` when `-r8` is
used (`io_int.F`), to maintain previous behavior the value should be
changed to `WRF_FLOAT`. Instead of using `sed` to rewrite the file,
`#ifdef PROMOTE_FLOAT` will use the valid `DOUBLE_PRECISION` define to
switch control of `WRF_FLOAT` to `WRF_DOUBLE` if defined, or `WRF_REAL`
if not.
For the CMake build, `DOUBLE_PRECISION` needs to be added to the
defines. No other changes necessary.
To reduce the complexity of these changes, `wrf_io_flags.h` is still
copied out to `inc/`, this may be addressed separately.
TESTS CONDUCTED:
1. Single and double precision builds should compile without issue and
have effectively the same logic as before
TYPE: new feature, enhancement
KEYWORDS: hydro, reservoir, reach lakes, namelist style guide
SOURCE: Soren Rasmussen and Ryan Cabell, NSF NCAR, internal
DESCRIPTION OF CHANGES:
* Add lake_opt to namelist, reservoirs to own nlist
- Add (integer) to &hydro_nlist: 0 [lakes off], 1 [level pool], or 2
[passthrough], or 3 [reservoir DA]
- turning lakes off (lake_option=0) will disable lakes even if
route_lake_f is supplied, or outlake is turned on.
- Reservoir DA will not be used unless lake_option=3, even if all
other required namelist options are present
- Reset lake_opt from 3 to 1 after setting DA flag
* Reservoir options have been moved from &hydro_nlist to
&reservoir_nlist
- This will make it easier to isolate / compose namelist files
- If lake_option is not equal to 3, &reservoir_nlist won't be read,
meaning it can be completely removed for applications that don't
need it
- Use reasonable lake_option default when not specified
- Update testing namelists
* Forcing variables names that have been added to namelist.hrldas
* Reach Lakes: support for lakes (reservoirs) in non-UDMP reach-based
routing, restoring functionality that was in WRF-Hydro version 5.1.1
* Style guide cleanup
- Remove unneeded return statements
- Remove file header
- Tabs to spaces
- Trailing whitespace cleanup
- MPI Capitalization
Problem: WRF-Hydro developments need to be ported over for future
release
LIST OF MODIFIED FILES:
```
M hydro/CPL/WRF_cpl/module_wrf_HYDRO.F90
M hydro/CPL/WRF_cpl/module_wrf_HYDRO_downscale.F90
M hydro/CPL/WRF_cpl/wrf_drv_HYDRO.F90
M hydro/Data_Rec/module_RT_data.F90
M hydro/Data_Rec/module_gw_gw2d_data.F90
M hydro/Data_Rec/module_namelist.F90
M hydro/HYDRO_drv/module_HYDRO_drv.F90
M hydro/IO/netcdf_layer.F90
M hydro/MPP/CPL_WRF.F90
M hydro/MPP/module_mpp_GWBUCKET.F90
M hydro/MPP/module_mpp_ReachLS.F90
M hydro/MPP/mpp_land.F90
M hydro/OrchestratorLayer/config.F90
M hydro/Routing/Noah_distr_routing.F90
M hydro/Routing/Reservoirs/Level_Pool/module_levelpool.F90
M hydro/Routing/Reservoirs/Level_Pool/module_levelpool_properties.F90
M hydro/Routing/Reservoirs/Persistence_Level_Pool_Hybrid/module_persistence_levelpool_hybrid.F90
M hydro/Routing/Reservoirs/RFC_Forecasts/module_rfc_forecasts.F90
M hydro/Routing/module_GW_baseflow.F90
M hydro/Routing/module_HYDRO_io.F90
M hydro/Routing/module_HYDRO_utils.F90
M hydro/Routing/module_NWM_io.F90
M hydro/Routing/module_RT.F90
M hydro/Routing/module_UDMAP.F90
M hydro/Routing/module_channel_routing.F90
M hydro/Routing/module_date_utilities_rt.F90
M hydro/Routing/module_gw_gw2d.F90
M hydro/Routing/module_lsm_forcing.F90
M hydro/Routing/module_reservoir_routing.F90
M hydro/nudging/module_date_utils_nudging.F90
M hydro/nudging/module_nudging_io.F90
M hydro/nudging/module_nudging_utils.F90
M hydro/nudging/module_stream_nudging.F90
M hydro/template/HYDRO/hydro.namelist
M hydro/template/NoahMP/namelist.hrldas
M hydro/utils/module_hydro_stop.F90
```
TESTS CONDUCTED:
1. Currently testing hydro's WRF testcase on new CMake and old Makefile
build systems. **PR will be draft until fully tested.**
2. Are the Jenkins tests all passing? Yes
```
Test Type | Expected | Received | Failed
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Number of Tests : 23 24
Number of Builds : 60 57
Number of Simulations : 158 150 0
Number of Comparisons : 95 86 0
Failed Simulations are:
None
Which comparisons are not bit-for-bit:
None
```
RELEASE NOTE:
hydro updates: In `hydro.namelist` adding lake_opt to namelist,
reservoirs to own namelist. Support for lakes (reservoirs) in non-UDMP
reach-based routing added and some style guide cleanup completed.
…SGS urban category. (#2153) TYPE: bug fix KEYWORDS: LCZ, USGS SOURCE: Lukas Pilz (Heidelberg University) DESCRIPTION OF CHANGES: Problem: As shown in #2152, for USGS data the wrfinput LU_INDEX field has major differences to the met_em LU_INDEX field. Cells in LU_INDEX which have LCZ categories (>30) were overwritten with the default USGS urban category (1) where FRC_URB2D > 0.5. Solution: Add a check similar to the MODIS case above. ISSUE: Fixes #2152 LIST OF MODIFIED FILES: M dyn_em/module_initialize_real.F TESTS CONDUCTED: 1. Did local tests, the only differences between wrfinput and met_em which remain are changing LU_INDEX 28 to 16, which is a water body redesignation as to my knowledge. 2. Jenkins tests have passed. RELEASE NOTE: Bug fix for wrfinput where LCZ urban cells in LU_INDEX were overwritten with default USGS urban category.
TYPE: new feature KEYWORDS: microphysics, physics, rainfall, warm rain, cloud water SOURCE: Robert Conrick (U. of Washington); [email protected] DESCRIPTION OF CHANGES: This is the release of the RCON microphysics scheme, the intent of which is to improve warm rain representation within the Thompson-Eidhammer scheme. LIST OF MODIFIED FILES: modified: Registry/Registry.EM_COMMON modified: Registry/registry.var modified: dyn_em/solve_em.F modified: phys/Makefile modified: phys/module_microphysics_driver.F new file: phys/module_mp_rcon.F modified: phys/module_physics_init.F The code has passed the regression tests. RELEASE NOTE: Release of the RCON Microphysics package into WRF, which improves upon the warm rain representation of the Thompson-Eidhammer scheme. RCON is based heavily on the Thompson-Eidhammer scheme with a couple significant changes that improve upon the code in module_mp_rcon.F to generate more realistic rainfall during warm rain events with additional benefits for cold rain, especially warm processes during cold rain events. Among the most significant changes for rain productions are 1) the use of a wider cloud water DSD of lognormal shape instead of the gamma DSD used by the Thompson-Eidhammer parameterization and 2) enhancement of the cloud-to-rain autoconversion parameterization to accommodate the new shape. The changes here also allow for sedimentation of cloud water within the lowest model layer, which effectively creates a drizzle mode in the scheme. Accompanying published reference: Conrick, R., C. F. Mass, and L. McMurdie, 2023: Improving Simulations of Warm Rain in a Bulk Microphysics Scheme. Mon. Wea. Rev., 152, 169-185, https://doi.org/10.1175/MWR-D-23-0035.1.
TYPE: text only KEYWORDS: README.namelist, adaptive time step SOURCE: internal DESCRIPTION OF CHANGES: Problem: Definitions for a few adaptive time step-relative variables in README.namelist weren't comprehensible. Solution: Modified the wording to make more sense LIST OF MODIFIED FILES: M run/README.namelist
TYPE: enhancement KEYWORDS: cmake, chem, kpp SOURCE: internal DESCRIPTION OF CHANGES: Problem: Current CMake build does not build chem or chem+kpp configurations Solution: Build kpp and associated tools, and cmake commands to facilitate simplified logic of the `configure_wkc` and `compile_wkc` scripts. As with all CMake builds, all auto-generated source code is placed in the out-of-source build directory. Notable differences to make build : * Use of Bison instead of Yacc as it is more easily accessible for install and usage as well as backward compatible * Allow `-j N` parallel jobs to generate KPP sources up to a limit * Use KPP-generated source file original names (not renamed to `module_kpp_*` * Pass `tuv_kpp` a directory to locate where include file is to be generated, and allow control of file IO mode* * Allow integration decomp rewrite to specify file locations rather than hard-coded* * `registry` uses `-DWRF_CHEM` and `-DWRF_KPP` defines passed at command line instead of `getenv()` to match all other options* *Affects make build in subtle ways but do not change user instructions LIST OF MODIFIED FILES: M CMakeLists.txt M chem/CMakeLists.txt A chem/KPP/CMakeLists.txt M chem/KPP/compile_wkc A chem/KPP/kpp/kpp-2.1/CMakeLists.txt A chem/KPP/util/wkc/CMakeLists.txt M chem/KPP/util/wkc/gen_kpp.c M chem/KPP/util/wkc/protos_kpp.h M chem/KPP/util/wkc/tuv_kpp.c A chem/KPP/util/write_decomp/CMakeLists.txt M chem/KPP/util/write_decomp/Makefile M chem/KPP/util/write_decomp/integr_edit.c M chem/chem_driver.F M tools/CMakeLists.txt M tools/data.h M tools/registry.c TESTS CONDUCTED: 1. Reproduction of chem and chem+kpp regtests with cmake is possible now RELEASE NOTE: CMake Chem and Chem+KPP Build
TYPE: bug fix KEYWORDS: snow albedo, soil timestep, glacier heat capacity SOURCE: Cenlin He (NCAR) DESCRIPTION OF CHANGES: Bug fixes for the following three parts: 1. allow BATS snow albedo scheme for nighttime snow aging: NCAR/ccpp-physics#1091 2. fix the potential leakage caused by calculate_soil variable during parallelization: NCAR/noahmp#136 3. fix the missing of HCPCT output for glacier points: NCAR/noahmp#141 LIST OF MODIFIED FILES: only Noah-MP source code is changed in Noah-MP GitHub. phys/noahmp TESTS: The changes have passed the regression tests. RELEASE NOTE: Noah-MP bug fixes for (1) allowing BATS snow albedo scheme for nighttime snow aging, (2) the potential leakage caused by calculate_soil variable during parallelized run, (3) the missing of HCPCT output for glacier points.
This replaces the original (non submodule) MYNN with the public-facing MYNN-EDMF submodule, which will the central point of development for the MYNN-EDMF in WRF, MPAS, and CCPP. TYPE: bug fix, enhancement, and new feature KEYWORDS: refactored, submodule, MYNN-EDMF SOURCE: Joseph Olson (NOAA/GSL) DESCRIPTION OF CHANGES: 1. Submodule implementation pointing to https://github.com/NCAR/MYNN-EDMF/ 2. This is a refactored scheme (now k-only) which is called from a new driver derived heavily from the MPAS driver. 3. The module names changed from *_mynn_* to *_mynnedmf_* to resolve a version conflict in MPAS. 4. This version carries many modification that originated in FV3-related development for RRFSv1, but it has since been tuned to better perform in MPAS and WRF, unlike previous versions of the MYNN. The list of modifications are fairly extensive but the most dycore-sensitive parts of the MYNN are related to the subgrid clouds. From now on, all minor commits are captured in the public-facing submodule repository and the submodule will be updated in WRF at a lower frequency (probably every 6 months or so). LIST OF MODIFIED FILES: M .gitmodules M Makefile M Registry/Registry.EM_COMMON M clean M dyn_em/module_first_rk_step_part1.F M main/depend.common A phys/MYNN-EDMF M phys/Makefile D phys/module_bl_mynn.F D phys/module_bl_mynn_common.F D phys/module_bl_mynn_wrapper.F M phys/module_pbl_driver.F M phys/module_physics_init.F TESTS CONDUCTED: 1. The submodule itself has been tested in both WRF and MPAS for several months now in NOAA-GSL realtime systems and case study tests, passing all of our newly designed regression tests. 2. Has been compiled and run with intel and gnu compilers on Jet and Hera. 3. Are the Jenkins tests all passing? RELEASE NOTE: Submodule implementation of the MYNN-EDMF (https://github.com/NCAR/MYNN-EDMF). The module names changed from *_mynn_* to *_mynnedmf_* to resolve a version conflict in MPAS. This version was originally developed within FV3/CCPP for RRFSv1, but has been refactored (to a k-only scheme) resulting in a speed-up of about 10-15% and it has since been tuned to better perform in MPAS and WRF compared to previous versions which were primarily developed for use in FV3.
…2120) TYPE: bug fix KEYWORDS: tke-epsilon-tpe, PBL, stability functions SOURCE: Andrea Zonato, Royal Netherlands Meteorological Institute (KNMI) DESCRIPTION OF CHANGES: Problem: The stability functions at the surface (phim,phieps) for calculating the boundary values of tke and its dissipation rate in the tke-epsilon-tpe PBL scheme [Zonato et al., 2022](https://doi.org/10.1175/MWR-D-21-0299.1) does not include the correction by z0. Solution: Pass the correct stability functions, calculated in module_sf_sfclayrev.F LIST OF MODIFIED FILES: phys/module_bl_keps.F phys/module_pbl_driver.F TESTS CONDUCTED: The Jenkins tests are all passing. RELEASE NOTE: The similarity stability functions phim and phieps, necessary for calculating the surface values of tke and dissipation rate in the tke-epsilon-tpe PBL scheme [Zonato et al., 2022](https://doi.org/10.1175/MWR-D-21-0299.1) have been updated considering the correction term accounting for the roughness length z0. No relevant differences are found in temperature, wind speed, and humidity. Regarding turbulence variables, the stable case has just negligible differences, while the unstable case shows higher values of TKE and dissipation rate and lower values of temperature variance.
TYPE: new feature KEYWORDS: data assimilation, incremental analysis update SOURCE: Min Chen of IUM/CMA and internal DESCRIPTION OF CHANGES: Add incremental analysis update capability. In the DA code, code is added to write out analysis increments for all variables in WRF netCDF format using auxiliary history output stream #5. In the model, analysis increments are divided by the number of time steps in a specified time window and added to the model similar to physics tendencies. The input stream for the model is 15. The capability is turned on by adding iau = 1 and iau_time_window_sec in &time_control. For example: ``` auxinput15_inname = "wrfiauinp_d01" io_form_auxinput15 = 2 auxinput15_interval = 360, iau = 1 iau_time_window_sec = 3600. ``` LIST OF MODIFIED FILES: M Registry/Registry.EM_COMMON.var M Registry/Registry.wrfvar M Registry/registry.em_shared_collection A Registry/registry.iau M dyn_em/module_em.F M dyn_em/module_first_rk_step_part2.F M phys/module_physics_addtendc.F M var/build/da.make M var/build/depend.txt M var/da/da_main/da_solve.inc M var/da/da_main/da_wrfvar_io.f90 M var/da/da_main/da_wrfvar_top.f90 A var/da/da_main/da_write_anaincrements.inc M var/da/da_transfer_model/da_transfer_xatowrf.inc TESTS CONDUCTED: The Jenkins tests have passed. RELEASE NOTE: This PR adds an incremental analysis update capability. In the DA code, code is added to write out analysis increments for all variables in WRF netCDF format using auxiliary history output stream #5. In the model, analysis increments are divided by the number of time steps in a specified time window and added to the model similar to physics tendencies. The input stream for the model is 15. The capability is turned on by adding iau = 1 and iau_time_window_sec in &time_control. The way the increments are added to the model is similar to what described by the paper by Chen et al. (https://doi-org.cuucar.idm.oclc.org/10.1175/WAF-D-22-0127.1).
TYPE: bug fix KEYWORDS: cmake, compilation SOURCE: internal DESCRIPTION OF CHANGES: Problem: PR #2144 added a new microphysics file `phys/module_mp_rcon.F` which only added it to the make build Solution: Add new RCON file to CMake build TESTS CONDUCTED: 1. Develop branch at merge of #2144 fails to build CMake build. These changes fix the build issues
TYPE: bug fix KEYWORDS: Memory Leaks SOURCE: Charlie Li - Software developer from lakes environmental Canada DESCRIPTION OF CHANGES: Problem: Memory leaks are detected in wrf_timeseries.F and start_em.F when use PGI option: -g -O0 -traceback -Mchkptr -Mbounds -Ktrap=fp -Msave -tp=px It will failed for: "0: ALLOCATE: array already allocated" 1. In dyn_em/start_em.F, dz8w is allocated, but not deallocated. 2. In share/wrf_timeseries.F, two arrays, earth_u_profile and earth_v_profile, are allocated without being deallocated when time series is not computed. Solution: Calls to deallocate the array dz8w is added in start_em.F, and move the return statement before array allocation in wrf_timeseries.F. LIST OF MODIFIED FILES: M share/wrf_timeseries.F M dyn_em/start_em.F TESTS CONDUCTED: The Jenkins tests are all passing. RELEASE NOTE: This PR fixed memory leaks related to arrays being allocated without being deallocated in start_em and time series calculation subroutines.
TYPE: bug fix KEYWORDS: crash, access violation error SOURCE: Charlie Li, software developer from lakes environmental, Canada DESCRIPTION OF CHANGES: Problem: WRF crashed for access violation frequently, due to the change made in PR #1991 when namelist.input has sf_urban_physics = 0 and bl_pbl_physics = 1. Because those arrays from urban models are always available, but their memories are not available if the urban option is not turned on. This causes the access violation in module_bl_ysu.F Solution: The fix is actually using v4.5 logic to check on the flag 'flag_bep' before using the arrays. LIST OF MODIFIED FILES: phys/module_bl_ysu.F TESTS CONDUCTED: The Jenkins tests are all passing. RELEASE NOTE: This PR fixes a access violation error when a PGI compiler is used with urban variables in module_bl_ysu.F when urban option is turned off and the memories of those arrays are not available.
… displacements overflow. (Fix for #2156) (#2157) Determine MPI Data Types in col_on_comm() & dst_on_comm() to prevent displacements overflow. TYPE: bug fix KEYWORDS: prevent displacements overflow in MPI_Gatherv() and MPI_Scatterv() operations SOURCE: Benjamin Kirk & Negin Sobhani (NSF NCAR / CISL) DESCRIPTION OF CHANGES: Problem: The MPI_Gatherv() and MPI_Scatterv() operations require integer displacements into the communications buffers. Historically everything is passed as an MPI_CHAR, causing these displacements to be larger than otherwise necessary. For large domain sizes this can cause the displace[] offsets to exceed the maximum int, wrapping to negative values. Solution: This change introduces additional error checking and then uses the function MPI_Type_match_size() (available since MPI-2.0) to determine a suitable MPI_Datatype given the input *typesize. The result then is that the displace[] offsets are in terms of data type extents, rather than bytes, and less likely to overflow. ISSUE: Fixes #2156 LIST OF MODIFIED FILES: M frame/collect_on_comm.c TESTS CONDUCTED: Failed cases run now. RELEASE NOTE: Determine MPI Data Types in col_on_comm() & dst_on_comm() to prevent displacements overflow.
…2133) TYPE: bug fix/enhancement KEYWORDS: wrf, wrfv4, restart, output streams SOURCE: James Ruppert (University of Oklahoma) DESCRIPTION OF CHANGES: Problem: When running WRF from as a restart, the option write_hist_at_0h_rst would only apply to the default history stream. Now, when this option is set to true, it will also apply to special user-defined streams. This is required to maintain a consistent number of output time steps per file with multiple time steps writing to a single file, which is often preferred for multiple-day runs. Solution: Added an additional loop over history streams with CALL med_hist_out when the following condition is met: IF ( (config_flags%restart) .AND. ( currTime .EQ. startTime ) .AND. (config_flags%write_hist_at_0h_rst )) LIST OF MODIFIED FILES: share/mediation_integrate.F TESTS CONDUCTED: 1. Verified that this change works: when option is set to true, history write-out at first time step of a restart now applies to both the default history stream and a user-defined stream (tested with stream 7). 2. The Jenkins tests are all passing. RELEASE NOTE: When the namelist option write_hist_at_0h_rst is set to .true. under &time_control, history write-out will now be conducted for the first time step for both the 0th stream (wrfout* files) and any special user-defined streams being implemented.
TYPE: new feature KEYWORDS: UFS Double Moment Microphysics scheme (UDM) SOURCE: Songyou Hong via internal DESCRIPTION OF CHANGES: The new microphysics option is based on 7-class WDM7 with revision and improvements and will be mp_physics=27. LIST OF MODIFIED FILES: M Registry/Registry.EM_COMMON M phys/Makefile M phys/module_microphysics_driver.F M phys/module_physics_init.F M phys/module_mp_udm.F TESTS CONDUCTED: 1. Compilation on derecho Cray Intel (ftn) seems to need -O2. 2. squall2d_x test case runs OK. 3. The Jenkins tests are all passing. RELEASE NOTE: An new microphysics, UFS Double Moment (UDM), 7-class microphysics from Songyou Hong is added (mp_physics=27). UDM mp largely adopts microphysical processes in WDM7, but with bug fixes or revisions based on literature and accumulated realism. UDM mp utilizes the in-cloud microphysics concept (Kim and Hong 2018), with the addition of water-friendly aerosols for CCN initialization. Semi-lagrangian sedimentation of Juang and Hong (2010) is also re-configured for computational efficiency and numerical accuracy. All production terms are optimized by introducing a cloud-top definition for hydrometeors.
…2063) TYPE: bug fix KEYWORDS: precipitation, tipping bucket, nudging, spectral nudging, analysis nudging, grid nudging, regional climate, dynamical downscaling, downscaling SOURCE: Tanya Spero (U.S. EPA) DESCRIPTION OF CHANGES: Problem: Several processes in WRF are currently triggered at periodic intervals (such as reading/writing files and managing certain bookkeeping processes). Some of those processes had been coded to identify those time triggers by referencing a variable that contains the time elapsed since the model simulation was initialized. That variable, XTIME, is a Fortran single-precision real variable that counts the number of elapsed minutes since initialization. However, single-precision real numbers become imprecise (i.e., cannot accurately resolve "whole" numbers) after they exceed 2^24, which is 16,777,216. In long simulations, that occurs just before 32 years of simulation period. Solution: Two new variables are introduced based on existing variable CURR_SECS2: CURR_SECS2_R8, and double precision version of CURR_SECS2, to address bucket tipping and CURR_MINS2, based on CURR_SECS2_R8, to address issues in nudging code. LIST OF MODIFIED FILES: M phys/module_diag_misc.F M dyn_em/module_first_rk_step_part1.F M dyn_em/solve_em.F, M phys/module_fdda_psufddagd.F M phys/module_fdda_spnudging.F, M phys/module_fddagd_driver.F M wrftladj/wrftladj/solve_em_ad.F TESTS CONDUCTED: 1. Modified code has been tested extensively using a long simulation (using a restart at more than 31 years into the simulation) with WRFv4.5.1 and with shorter (3-day) simulations using WRFv4.6. 2. The Jenkins tests are all passing. RELEASE NOTE: Corrected algorithms in the tipping bucket for precipitation and in the nudging routines to adjust for imprecision in single-precision real numbers exceeding the resolvable values in long (>23-year) continuous simulations.
TYPE: enhancement, no impact, text only KEYWORDS: vertical coordinate, namelist SOURCE: internal DESCRIPTION OF CHANGES: Problem: The current namelist.input file only has dzstretch_s. To properly use the auto_levels_opt, dzstretch_u and dzbot should be considered. Solution: Add dzstretch_u and dzbot in the namelist. Parameters based on UG. LIST OF MODIFIED FILES: M test/em_real/namelist.input TESTS CONDUCTED: The Jenkins tests have passed. RELEASE NOTE: Add dzstretch_u and dzbot in namelist.input. Users are advised to check UG for other parameters to use.
TYPE: bug fix KEYWORDS: cmake, compilation SOURCE: internal DESCRIPTION OF CHANGES: Problem: PR #2147 added a new file that was not added to the CMake build Solution: Add the corresponding file to the respective CMakeLists.txt
|
Please use this PR to note any relevant updates, progress, testing, or bugs for this release. |
kkeene44
approved these changes
Feb 28, 2025
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.
No description provided.