-
Notifications
You must be signed in to change notification settings - Fork 797
Release v4.7.0 #2172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Release v4.7.0 #2172
Conversation
This file contains hidden or 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: bug fix KEYWORDS: cmake, typo SOURCE: internal DESCRIPTION OF CHANGES: Problem: There is a typo in the confcheck for arguments that are forwarded to `try_compile()` and `try_run()` functions Solution: Fix the typo TESTS CONDUCTED: 1. Tested on Derecho with ifx / oneAPI compilers
TYPE: enhancement updates, optimization fix KEYWORDS: microphysics constants and process update SOURCE: Songyou Hong via internal DESCRIPTION OF CHANGES: Problem: Previous code did not compile with intel -O3. Also changes to constants and process which are updates. Solution: Minor change allows optimized compile. New code performs more as expected and is cleaned up. LIST OF MODIFIED FILES: M dyn_em/solve_em.F M phys/module_microphysics_driver.F M phys/module_mp_udm.F M phys/module_physics_init.F M wrftladj/solve_em_ad.F TESTS CONDUCTED: 1. compiles with -O3 using ifort 2. tested with 2d squall line case 3. passed regression tests.
…PR#808 (#2182) TYPE: bugfix KEYWORDS: hydro, bugfix, lake_option, reservoir DA SOURCE: Soren Rasmussen, internal hydro group DESCRIPTION OF CHANGES: Problem: If lake_option was set to 3 (Reservoir DA) but no Reservoir DA flags were set to .true. the internal lake_option was not set to [levelpool/off/passthrough] and a cryptic error resulted. Solution: NCAR/wrf_hydro_nwm_public#808 This fix now prints an error message and reverts the value to Level Pool if no DA option is selected. LIST OF MODIFIED FILES: ``` M hydro/OrchestratorLayer/config.F90 ``` TESTS CONDUCTED: 1. Do mods fix problem? Yes, tested in the WRF-Hydro model. WRF builds with GNU 3. Are the Jenkins tests all passing? Yes RELEASE NOTE: Hydro reservoir drainage area (DA) lake option bugfix
TYPE: enhancement KEYWORDS: default_soiltype, namelist, landuse and soil type matching SOURCE: Mathieu Landreau (Centrale Nantes) DESCRIPTION OF CHANGES: Problem: When running real.exe, in the land cells where no soiltype is defined in the soil dataset (which happens when soil types with lower resolution input do not match the land mask defined by landuse data), the type is set to 8=silty clay loam. For high-resolution coastal area simulation, this can represent a certain amount of cells, which may not be representative of the area. Solution: A namelist option named default_soiltype is added. It is checked (in module_check_a_mundo) that the user-defined value is between 1 and 19 and is not water (19) LIST OF MODIFIED FILES: Registry/Registry.EM_COMMON dyn_em/module_initialize_real.F run/README.namelist share/module_check_a_mundo.F TESTS CONDUCTED: - It has passed the regression tests. RELEASE NOTE: A namelist option, default_soiltype, is added to define filled-in land category along water/land boundaries where soil data may be missing in program real.
…an (#2171) TYPE: bug fix KEYWORDS: TUV, distance to the sun, 1 January, Julian day SOURCE: Sergey Osipov (KAUST) DESCRIPTION OF CHANGES: Problem: TUV and FTUV fail to initialize the distance to the Sun properly if the simulation starts on 1 Jan. The multiplication factor remains uninitialized at 0, which zeros out photolysis rate calculations (see line 745 @ module_phot_tuv.F. On the next day, the distance is recalculated normally and photolysis rates are calculated properly. Solution: Given that the calculation of sun distance is trivial, the if check was disabled. LIST OF MODIFIED FILES: chem/module_phot_tuv.F chem/module_ftuv_driver.F TESTS CONDUCTED: The Jenkins tests are all passing. RELEASE NOTE: This PR fixed a bug where TUV and FTUV fail to initialize the distance to the Sun properly if the simulation starts on 1 Jan.
TYPE: enhancement KEYWORDS: NSSL microphysics scheme; rain breakup SOURCE: Ted Mansell (NOAA/NSSL) (@MicroTed ) DESCRIPTION OF CHANGES: - More accurate saturation mixing ratio calculation (iqvsopt=1) - Changed default droplet renucleation to irenuc=5, which allows extra nucleation at high supersaturation - A default explicit rain breakup for 3-moment rain (irainbreak=2) has been added to reduce excessive median drop diameters in rain cores, which in turn increases evaporation and cool pool temperature deficits (were too warm). - Imposed reflectivity conservation in graupel->hail conversion (ihlcnh=3) and Bigg freezing (both 2- and 3-moment) - Two optional diagnostic outputs for supersaturation (wrt liquid/ice) - Changed nssl_hail_on from max_dom array to singe value, because it can't be different for different domains, anyway. LIST OF MODIFIED FILES: Registry/Registry.EM_COMMON doc/README.NSSLmp dyn_em/solve_em.F phys/module_microphysics_driver.F phys/module_mp_nssl_2mom.F phys/module_physics_init.F TESTS CONDUCTED: 2. Are the Jenkins tests all passing? Yes. RELEASE NOTE: NSSL microphysics scheme updates include 1. An explicit rain breakup for 3-moment rain (addresses issue of cold pools being too warm and drops being too large in rain cores), 2. Improved reflectivity conservation for graupel->hail conversion and drop freezing, 3. More accurate saturation mixing ratio calculation, 4. New default droplet nucleation that controls excess supersaturation much better than previously (and default is to always predict the number of activated CCN). The update has been submitted to CCPP repository as well.
TYPE: bug fix KEYWORDS: make, verbose SOURCE: internal DESCRIPTION OF CHANGES: Problem: The MYNN-EDMF checkout status check commands in the make build were being output all the time regardless of status causing the `echo` error line to be verbosely printed out along with the actual status. Solution: Suppress the verbose output of the subshell command using the make command prefix `@` TESTS CONDUCTED: 1. Recompilation with the change no longer produces unwanted output
TYPE: bug fix KEYWORDS: NSSL microphysics scheme SOURCE: Ted Mansell (NOAA/NSSL) (@MicroTed ) DESCRIPTION OF CHANGES: Problem: Other updates resulted in the old droplet nucleation scheme (irenuc=2) producing too few cloud droplets. This option is no longer the default, but ought to work the same as it did before in case anybody wanted to use it. Solution: Restored use of background value for this particular option. LIST OF MODIFIED FILES: phys/module_mp_nssl_2mom.F TESTS CONDUCTED: The Jenkins tests are all passing.
TYPE: text only KEYWORDS: namelist, readme SOURCE: internal DESCRIPTION OF CHANGES: Add (max_dom) for frames_per_auxhist3 and 9, and UDM microphysics (mp_physics = 27). LIST OF MODIFIED FILES: M run/README.namelist
TYPE: bug fix KEYWORDS: module_sf_bep_bem.F, loop index, debugging-crash SOURCE: L. Fita (UBA/CIMA/IFAECI) DESCRIPTION OF CHANGES: Problem: The loop index in line 1600 of subroutine module_sf_bep_bem.F should be up to `nzu`, instead of `nz_um`. Solution: This PR fixes the index. ISSUE: For use when this PR closes an issue. Fixes #2194 LIST OF MODIFIED FILES: M phys/module_sf_bep_bem.F TESTS CONDUCTED: 1. Code was modified and recompiled in serial debug mode and it did not crashed 2. The Jenkins tests are all passing. RELEASE NOTE: This PR fixed a loop index error in bep_bem urban code.
TYPE: bug fix KEYWORDS: landuse SOURCE: internal DESCRIPTION OF CHANGES: Problem: The `GET_LANDUSE()` function in landread.c when enabled had an implicit return for a non-void function, i.e. it should return an integer to denote status. This results in undefined behavior with an uninitialized return value left to the discretion of the compiler optimization, if it even does auto-initialize returns to some known value. Solution: Add a return statement of value `0` to denote success at the very end of the function. TESTS CONDUCTED: 1. Originally exposed with option 78 (Intel OneAPI ifx/icx) on derecho. Tested with 1 MPI rank and 36 MPI ranks to ensure landread did not fail where not expected to with these modifications. RELEASE NOTE: Bug fix in landread.c to address undefined behavior by adding an explicit return statement in `GET_LANDUSE()` function
TYPE: bug fix
KEYWORDS: ghg_input, idealized, no radiation
SOURCE: internal
DESCRIPTION OF CHANGES:
Problem:
Most idealized cases have radiation options turned off, which causes the following error message to inaccurately print to the rsl files when ideal.exe is run:
ERROR: ghg_input available only for these radiation schemes: CAM, RRTM,
RRTMG, RRTMG_fast
And the LW and SW schemes must be reasonably paired together:
OK = CAM LW with CAM SW
OK = RRTM, RRTMG LW or SW, RRTMG_fast LW or SW may be mixed
Solution:
In share/module_check_a_mundo.F, add code to ensure that when radiation is turned off, not only does the message not print, but the namelist value for ghg_input is set to 0, as well.
LIST OF MODIFIED FILES:
M share/module_check_a_mundo.F
TESTS CONDUCTED:
1. Code compiles okay and no longer prints the message for idealized cases (tested with em_quarter_ss).
2. The Jenkins tests are all passing.
RELEASE NOTE: This PR fixes an erroneous print for using ghg_input when no radiation option is selected, mostly from idealized cases.
TYPE: bug-fix KEYWORDS: UDM microphysics SOURCE: internal from Songyou Hong DESCRIPTION OF CHANGES: Problem: Some test cases were failing Solution: tests for divide by zero were added and some of the in-cloud physics was taken out ISSUE: none LIST OF MODIFIED FILES: modified: phys/module_mp_radar.F modified: phys/module_mp_udm.F TESTS CONDUCTED: 1. yes this code passes test suite 2. code passes regression tests.
TYPE: bug fix KEYWORDS: netcdfpar, configure, make SOURCE: internal DESCRIPTION OF CHANGES: Problem: Control of whether the external/io_netcdfpar folder is controlled via the presence of `NETCDFPAR_BUILD = CONFIGURE_NETCDFPAR_BUILD` which is replaced by a substitution in arch/Config.pl. However, currently this relies on all stanzas to include this value verbatim, otherwise that stanza will be unable to skip building the netCDF parallel IO code. Solution: Since this is required regardless of stanza selected this should be isolated from the arch/configure.defaults and relocated to a common location for all stanzas to automatically use. Following current substitution variable layout, this is placed in arch/postamble. TESTS CONDUCTED: 1. Tested to ensure CMake and make builds of common stanzas are unaffected. RELEASE NOTE: Fix uncontrollable building of external/io_netcdfpar folder for all stanzas
TYPE: bug fix KEYWORDS: make, grib2 SOURCE: internal, reported by Dmitri Chubarov DESCRIPTION OF CHANGES: Problem: Commit 3a0478e removed `wrf_io_flags.h` from `./external/io_grib_share` in order to reduced duplicate code. However, the grib2 Makefile was not updated to point to `./external/ioapi_share` for the consolidated version of this file. Solution: Include `ioapi_share` in the search paths when building grib2 io. ISSUE: For use when this PR closes an issue. Fixes #2184 TESTS CONDUCTED: 1. Confirmed that with the include path changes, compilation is successful of the grib2 io when explicitly requested
TYPE: bug fix KEYWORDS: Urban, Noah-MP, LCZ SOURCE: Martilli, Alberto (CIEMAT) DESCRIPTION OF CHANGES: Problem: If one uses Noah-MP and LCZ data, all the LCZ_1, LCZ_2, etc. are zero because they are not defined correctly for Noah-MP. Solution: This PR fixes the issue by using LCZ_*_TABLE instead so that LCZ are correctly defined in Noah-MP. LIST OF MODIFIED FILES: M phys/module_surface_driver.F TESTS CONDUCTED: 1. A one-month simulation was conducted for February 2018 over Atlanta to verify the change. 2. The Jenkins tests are all passing. RELEASE NOTE: This PR fixes an error associated with using LCZ categories in NoahMP. Prior to this fix, the LCZs were not correctly referenced, hence ignored in the NoahMP code.
TYPE: bug fix KEYWORDS: cmake, hydro SOURCE: internal DESCRIPTION OF CHANGES: Problem: Some dependencies were not being fully satisfied and were implicit / partially fulfilled by subsequent compilation. In compilers that could tolerate these situations the hydro folder would compile successfully. However, for compilers where dependencies are enforced (i.e. symbols resloved at compile time even within Fortran submodules), compilation would fail. Solution: To account for situations where compilers require all module dependencies be resolved, dependencies between the hydro libraries and the transitive link properties were reworked to propagate dependencies up the chain correctly. TESTS CONDUCTED: 1. Tested building hydro with Intel oneAPI ifx 2024.2.1 RELEASE NOTE: Fixed failed compilation with Intel oneAPI by reworking the dependency linking of hydro CMake compilation
TYPE: bug fix KEYWORDS: make, compilation, dm SOURCE: internal DESCRIPTION OF CHANGES: Problem: When a DM (distributed memory) configuration is selected, the configuration phase of the make build will extract the corresponding stanza from `arch/configure.defaults` and modify various variable lines with substitutions or comment removals. Of particular note is the normally defined `DMPARALLEL = # 1` which is changed to `DMPARALLEL = 1` when DM configurations are selected. This definition is then used to inform the make build about which pieces of code to compile for DM capabilities. The `Linux aarch64, GCC` stanza does not have this comment (`# 1`) and so the variable ends up blank when DM is selected causing compilation failure. This issue possibly also exists for the `Linux aarch64, armclang` stanza, however no bug report has been noted for this at the time of this PR. Solution: Add `# 1` to the `DMPARALLEL =` line in the `Linux aarch64, GCC` stanza definition. Likewise, perform the same change in the `Linux aarch64, armclang` stanza definition as well. TESTS CONDUCTED: 1. Confirmed with user on forum that this resolved their build issues for the `Linux aarch64, GCC` stanza.
TYPE: bug fix KEYWORDS: NoahMP, version update SOURCE: Cenlin He @cenlinhe and Tzu-Shun Lin (NCAR) DESCRIPTION OF CHANGES: Update NoahMP code with bug fixes for the following: (1) Corrected LECH's stability functions in WRF/Noah-MP. This is a bug fix for the LECH's surface function in Chen et al. 1997 surface resistance module calculations. This bug has been fixed in v5.0 but not in v4.7 (non-refactored code), so this PR fixes this missing issue. NCAR/noahmp#182 (2) Corrected Noahmp irrigation init, the code generalize the initialization of the irrigation matrices in order to avoid NaN values when it is not properly initializated. This error was detected in debug compilation mode. NCAR/noahmp#183 LIST OF MODIFIED FILES: M phys/noahmp/ TESTS: The Jenkins tests are all passing. RELEASE NOTE: Noah-MP code tag is updated to corresponding to WRFV4.7 release.
TYPE: text only KEYWORDS: cmake, documentation SOURCE: internal DESCRIPTION OF CHANGES: Problem: Typos in cmake documentation Solution: Fix of some typos and grammatical errors in the cmake README documentation
TYPE: text only KEYWORDS: cmake, documentation SOURCE: internal DESCRIPTION OF CHANGES: Problem: There has been some confusion on what variables are available within the CMake build to control where dependencies can be found. This has been noted a few times within the forum where users want fine tuned control on the location of these dependencies. The current build support this through native CMake support, however the current documentation left it as an exercise to the reader to construct the variables necessary for these features. Solution: Add explicit documentation of dependency search variables and how a user would make use of them. Additionally point to the exact external documentation to reference for the CMake `find_package()` call
TYPE: text only KEYWORDS: v4.7.0, release, version_decl, README SOURCE: internal DESCRIPTION OF CHANGES: Updated the top-level README and inc/version_decl files to reflect the v4.7.0 release
islas
added a commit
that referenced
this pull request
Apr 25, 2025
Reverts #2172 This was a bad squash merge which collapsed the relevant history
Merged
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.