Skip to content

Conversation

@islas
Copy link
Collaborator

@islas islas commented Feb 27, 2025

No description provided.

coastwx and others added 30 commits March 27, 2024 16:11
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.
islas and others added 21 commits March 10, 2025 13:19
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
@islas islas added Retest and removed Retest labels Apr 25, 2025
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 islas merged commit a52433c into master Apr 25, 2025
1 check was pending
islas added a commit that referenced this pull request Apr 25, 2025
@islas islas mentioned this pull request Apr 25, 2025
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
@islas islas mentioned this pull request Apr 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.