Skip to content

Sync to SD Mines WRF 2024-10-23#1

Closed
wjcapehart wants to merge 31 commits intowjcapehart:masterfrom
wrf-model:master
Closed

Sync to SD Mines WRF 2024-10-23#1
wjcapehart wants to merge 31 commits intowjcapehart:masterfrom
wrf-model:master

Conversation

@wjcapehart
Copy link
Owner

Sync to SD Mines WRF 2024-10-23

TYPE: choose one of [bug fix]

KEYWORDS: 5 to 10 Updating SD Mines WRF for wrfmodel updates on 2024-10-23

SOURCE: Either "Bill Capehart SDMiners"

DESCRIPTION OF CHANGES:
Problem:
Adding Jimy, Wei et als changes in to my fork

Solution:
What was down algorithmically and in the source code to address the problem?

ISSUE: For use when this PR closes an issue.
Fixes wrf-model#123

LIST OF MODIFIED FILES: list of changed files (use git diff --name-status master to get formatted list)

TESTS CONDUCTED:

  1. Do mods fix problem? How can that be demonstrated, and was that test conducted?
  2. Are the Jenkins tests all passing?

RELEASE NOTE: Include a stand-alone message suitable for the inclusion in the minor and annual releases. A publication citation is appropriate.

mos3r3n and others added 30 commits August 1, 2024 17:36
… 2 (#2078)

TYPE: bug fix

KEYWORDS: radar DA

DESCRIPTION OF CHANGES:
Problem:
Duplicated allocation of avg_qws when choosing radar_rhv_opt = 2.
da_free_unit instead of da_get_unit for closing a file when radar_rhv_opt is equal to 2.

ISSUE: #2077 

LIST OF MODIFIED FILES:
var/da/da_radar/da_get_innov_vector_radar.inc
TYPE: text only

KEYWORDS: namelists, corrections

SOURCE: JiriRichter and internal

DESCRIPTION OF CHANGES:
The description of a few namelists are updated. io_style_emiss is removed from this file since it is for WRF-Chem, and not specifiable under &time_control. Namelist ntiedtke_dx_opt was also removed, since it is not implemented.

ISSUE: For use when this PR closes an issue.
Fixes #2071, #2072, #2073

LIST OF MODIFIED FILES:
run/README.namelist

RELEASE NOTE: The documentation of a few namelists is updated in this PR.
…2032)

TYPE: Bug fix

KEYWORDS: LECH stability functions, Latent heat flux, Sensible heat flux, SL Urban Canpy Model

SOURCE: Parag Joshi (Brookhaven National Lab), Katia Lamer (Brookhaven National Lab)

DESCRIPTION OF CHANGES:
Problem:
The stability functions originally proposed by Lech Lobocki which are used in calculating the exchange coefficients between surface layer and roof, building wall, Green roof, and ground are implemented incorrectly. The error surfaced while comparing the formulation suggested in Lobocki 1992 with the equations in commands/lines 3056 and 3062 (WRF-v4.5.2).

Solution:
The code has been corrected by referring to the equations 48 and 49 of the article "A procedure for the derivation of surface layer bulk relationships from simplified second-order closure models" by Lobocki 1992 (Journal of Applied Meteorology).

LIST OF MODIFIED FILES: 
M    phys/module_sf_urban.F

TESTS CONDUCTED: 
1. The significance of the corrections can be highlighted by comparing a test run with the corrected module and current version of the WRF model. 
2. The fix will correct the evaluation of the exchange coefficients between the ground, roof, green roof etc and air. 
3. The Jenkins tests are all passing.

RELEASE NOTE: Lech's stability functions are corrected following the original formulation in the single layer urban canopy model.
…nt. (#2049)

TYPE: Bug fix

KEYWORDS: PV panels, Correlations, Upward heat flow, BEM (Building Energy Model). 

SOURCE: Parag Joshi (Brookhaven National Laboratory) 

DESCRIPTION OF CHANGES:
Problem:
A typographical mistake was identified within the correlations that evaluate heat transfer coefficient for the upward heat flow over PV panels in the Building Energy Model (BEM). 

Solution:
The parameters have been modified following the correlation expressions provided in the literature. Please refer to the equation J.2.2a on page number 79 of the document below:
https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nbsir83-2655.pdf

LIST OF MODIFIED FILES: 
M     phys/module_sf_bem.F

TESTS CONDUCTED: 
1. No test has been conducted as the parameters seems to have very small or insignificant impact on the results. However, the tests can be performed with and without correcting the parameters to quantify the role. 
2. The Jenkins tests are all passing.

RELEASE NOTE: Bug fixes for parameters associated with the heat transfer coefficient for the upward heat flow over PV panels.
…urban model (#2038)

TYPE: Bug fix

KEYWORDS: Stability function, Urban canopy model, surface energy balance, Green roof temperature. 

SOURCE: Parag Joshi (Brookhaven National Laboratory), Katia Lamer (Brookhaven National Laboratory)

DESCRIPTION OF CHANGES:
Problem: The calculations for PSIM in the mos subroutine of module-sf_urban.F has been corrected. The earlier equations has a typo where X (= (1-16\zeta)^1/4) is mentioned instead of X0. In addition, following the formulation of surface energy balance of OSU1DPBL scheme by Ek and Mahrt 1991, it appears that when the following definition is used $\sigma * \theta_s^4 = \sigma T_0^4 (1 + 4((\theta_s - T_0)/T_0)))$ is used, the temperature in the calculations of net flux at the surface should use T_0 (temperature at first atmospheric level). However, in the module TGRP (temperature of the green roof surface at previous time step is used)is used instead of T_0 (please refer to the attached screenshots of the formulation).

Solution:
Following the formulation, the temperature variable has been updated according. Moreover, the mos subroutine is also corrected by replacing X by X0 where X0 is =X*z0/(z+z0) (as per the WRF/phys/module_sf_urban.F).

LIST OF MODIFIED FILES: 
M     phys/module_sf_urban.F

TESTS CONDUCTED: 
1. No tests are conducted. A test case could be run to compare the impact of changes in the TGR and stability parameter value as well as CD, US, and ALPHA. 
2. The Jenkins tests are all passing.

RELEASE NOTE: Fixes for the calculations for PSIM in the mos subroutine and the temperature used in surface energy balance for the green roof. The later follows the OSU1DPBL document located at:  
[https://ftp.emc.ncep.noaa.gov/mmb/gcp/ldas/nceplsm/OSU1DPBL/OSU1DPBL-userguide.pdf]
…RF-CMAQ (#2044)

TYPE: bug fix

KEYWORDS: metadata, global attributes, auxiliary output, auxiliary history, WRF-CMAQ

SOURCE: Tanya Spero and Jeff Willison (U.S. EPA)

DESCRIPTION OF CHANGES:
Problem:
The suite of global attributes is incomplete in auxiliary history files. Notably, the precipitation tipping bucket is among the fields not included. Separately, there is no metadata in the header to indicate when WRF-CMAQ is used.

Solution:
Changes are introduced in share/output_wrf.F to expand the use cases to write the full suite of global attributes to the metadata of auxiliary output files. In addition, two global attributes are added to the output only when the WRF-CMAQ model is invoked (WRF_CMAQ_OPTION and DIRECT_SW_FEEDBACK).

ISSUE: Fixes #1476 

LIST OF MODIFIED FILES: share/output_wrf.F

TESTS CONDUCTED: 
1. Tests were conducted using the WRF model both with and without compiling with CMAQ. The base code was pulled from the branch "release-v4.6.0" on 8 May 2024. In both sets of tests on the EPA supercomputing system, an auxiliary output file was created in auxhist7. The global attributes were properly expanded to include the full suite of attributes in the auxiliary output file. The two new WRF-CMAQ coupled model attributes appeared when the WRF-CMAQ model was invoked.
2. The Jenkins tests are all passing.

RELEASE NOTE: Expanded global attributes to the full suite for auxiliary history files. Also added two global attributes when the WRF-CMAQ model is invoked (WRF_CMAQ_OPTION and DIRECT_SW_FEEDBACK).
TYPE: bug fix

KEYWORDS: radar reflectivity, WSM6

SOURCE: reported by Gabriel Cassol of Sigma Meteorologia, Brazil, internal

DESCRIPTION OF CHANGES:
Problem:
When moving WSM6 to MMM shared physics directory, the calculation of radar reflectivity was left out.

Solution:
The calculation of radar reflectivity is added back in the WSM6 scheme.

ISSUE: For use when this PR closes an issue.
Fixes #2096

LIST OF MODIFIED FILES:
M phys/module_mp_wsm6.F

TESTS CONDUCTED:

1. The reflectivity is computed now when namelist do_radar_ref is set to 1.
2. The Jenkins tests are all passing.

RELEASE NOTE: Fixed the bug of missing radar reflectivity in WSM6 scheme when do_radar_ref is set to 1. This bug was introduced when WSM6 scheme was moved to physics_mmm/ directory, and shared with other MMM models in v4.6.
TYPE: bug fix

KEYWORDS: intel, compilation, oneapi

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
The `-auto` flag is not supported by the Intel C compilers. See https://www.intel.com/content/www/us/en/docs/cpp-compiler/developer-guide-reference/2021-10/alphabetical-option-list.html for full list of supported icx flags.

Solution:
Remove the flag, no output changes should happen as the flag was previously being ignored if it didn't cause an error.
…2060)

TYPE: bug fix

KEYWORDS: syntax, compilation

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
dyn_em/module_big_step_utilities_em.F contains nonstandard line continuation symbols that are most likely being ignored by the make build system by the in situ file preprocessing steps. The cmake build does not use sed or standard.exe to preprocess files, so these lines get fed directly to compilers. Fortran compilers that do not support C-style line continuation then fail (nvhpc as an example).

Solution:
Change line continuation characters to standard Fortran.
TYPE: bug fix

KEYWORDS: sfclayrev, fix possible undefined

SOURCE:  internal reported by Xin-Zhong Liang

DESCRIPTION OF CHANGES:
Problem:
zol(i) can be left undefined in rare case of br(i) = 0.

Solution:
add line to initialize zol(i)=0.

LIST OF MODIFIED FILES: 
M       phys/physics_mmm/sf_sfclayrev.F90

TESTS CONDUCTED: 
1. Only compile tested.
2. The Jenkins tests are all passing.

RELEASE NOTE: Fix for rare undefined zol in sfclayrev.
TYPE: bug fix

KEYWORDS: compilation, nonstandard

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
PR #1944 introduced a nonstandard function call `isnan()` which breaks
compilation for compilers which don't support this extension.

Solution:
A potential alternative is to use the `ieee_is_nan()` call from
`ieee_arithmetic`. As there is conditional compilation of this module
which requires Fortran 2003 standard, an easier alternative is just to
check the input values before calling `acos()`
TYPE: bug fix

KEYWORDS: gcc14, compilation, c99

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
From #2047 :
Compilation of WRF v4.6.0 fails with GCC 14 due to new standard changes

> Type checking on pointer types (-Werror=incompatible-pointer-types)
> GCC no longer allows implicitly casting all pointer types to all other
pointer types. This behavior is now restricted to the void * type and
its qualified variations.
> 
> To fix compilation errors resulting from that, you can add the
appropriate casts, and maybe consider using void * in more places
(particularly for old programs that predate the introduction of void *
into the C language).
> 
> Programs that do not carefully track pointer types are likely to
contain aliasing violations, so consider building with
-fno-strict-aliasing. (Whether casts are written manually or performed
by GCC automatically does not make a difference in terms of strict
aliasing violations.)
> 
> A frequent source of incompatible function pointer types involves
callback functions that have more specific argument types (or less
specific return types) than the function pointer they are assigned to.
For example, old code which attempts to sort an array of strings might
look like this:
```
#include <stddef.h>
#include <stdlib.h>
#include <string.h>

int
compare (char **a, char **b)
{
  return strcmp (*a, *b);
}

void
sort (char **array, size_t length)
{
  qsort (array, length, sizeof (*array), compare);
}
```
Example of failure : 
```
/home/aislas/wrf-model/wrf/external/RSL_LITE/c_code.c: In function ‘rsl_lite_pack_’:
/home/aislas/wrf-model/wrf/external/RSL_LITE/c_code.c:487:27: error: passing argument 1 of ‘f_pack_lint_’ from incompatible pointer type [-Wincompatible-pointer-types]
  487 |             F_PACK_LINT ( buf, p+yp_curs, imemord, &js, &je, &ks, &ke, &is, &ie,
      |                           ^~~
      |                           |
      |                           char *
In file included from /home/aislas/wrf-model/wrf/external/RSL_LITE/c_code.c:31:
/home/aislas/wrf-model/wrf/external/RSL_LITE/rsl_lite.h:200:25: note: expected ‘long int *’ but argument is of type ‘char *’
  200 | void F_PACK_LINT (long *inbuf, long *outbuf, int* memorder, int* js, int* je, int* ks, int* ke, int* is, int* ie, int* jms, int* jme, int* kms, int* kme, int* ims, int* ime, int* curs);
      |                   ~~~~~~^~~~~
/home/aislas/wrf-model/wrf/external/RSL_LITE/c_code.c:487:33: error: passing argument 2 of ‘f_pack_lint_’ from incompatible pointer type [-Wincompatible-pointer-types]
  487 |             F_PACK_LINT ( buf, p+yp_curs, imemord, &js, &je, &ks, &ke, &is, &ie,
      |                                ~^~~~~~~~
      |                                 |
      |                                 char *
/home/aislas/wrf-model/wrf/external/RSL_LITE/rsl_lite.h:200:38: note: expected ‘long int *’ but argument is of type ‘char *’
  200 | void F_PACK_LINT (long *inbuf, long *outbuf, int* memorder, int* js, int* je, int* ks, int* ke, int* is, int* ie, int* jms, int* jme, int* kms, int* kme, int* ims, int* ime, int* curs);
      |                                ~~~~~~^~~~~~
/home/aislas/wrf-model/wrf/external/RSL_LITE/c_code.c:492:26: error: passing argument 1 of ‘f_pack_int_’ from incompatible pointer type [-Wincompatible-pointer-types]
  492 |             F_PACK_INT ( buf, p+yp_curs, imemord, &js, &je, &ks, &ke, &is, &ie,
      |                          ^~~
      |                          |
      |                          char *
/home/aislas/wrf-model/wrf/external/RSL_LITE/rsl_lite.h:201:23: note: expected ‘int *’ but argument is of type ‘char *’
  201 | void F_PACK_INT (int *inbuf, int *outbuf, int* memorder, int* js, int* je, int* ks, int* ke, int* is, int* ie, int* jms, int* jme, int* kms, int* kme, int* ims, int* ime, int* curs);
      |                  ~~~~~^~~~~
```

Error was reproduced AlmaLinux release 9.4 with GCC 14.1.0

Solution:
Use explicit type casting

ISSUE: 
Fixes #2047 

TESTS CONDUCTED: 
1. Tested on GCC 14.1.0
TYPE: bug fix

KEYWORDS: mixing ratio, interpolation, pressure level, height level, missing value

SOURCE: Jesus Fernandez, Andrés Simón-Moral and Josipa Milovac (Instituto de Física de Cantabria, CSIC-Universidad de Cantabria, Spain)

DESCRIPTION OF CHANGES:
Problem: The mixing ratio field is not being initialized in the interpolation routine. This leads to no missing values below ground and values from previous time steps filling these areas.

Solution:
The mixing ratio has been initialized to missing values, as for the rest of variables.

LIST OF MODIFIED FILES:
```
M       phys/module_diag_pld.F
M       phys/module_diag_zld.F
```

TESTS CONDUCTED: 
The Jenkins tests are all passing.

RELEASE NOTE: Fix non-initialized 3D moisture field in pressure- and height-level diagnostic interpolation.
TYPE: enhancement

KEYWORDS: testing, regression, test framework

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
The current regression suite code is complex, requires maintenance of
multiple alternate repositories, and takes involved effort to add a new
test making community contribution limited at best. Likewise, the
complexity of the system reduces the likelihood of independent local
testing of changes, leading to a development cycle of one-off commits
done to reinvoke testing to see if meaningful commits fix the issues.

Solution:
This new proposed regression suite addresses these shortcomings in a
number of discrete ways:
1. Modularize the testing framework to an generalized independent repo
usable by any repo seeking to set up tests that can run locally, on HPC
systems, and within any CI/CD framework
2. Write WRF-specific test scripts _inside_ the WRF repo and in a manner
that does not rely on specific layouts/hardware/etc. so long as WRF can
compile and run on intended system (i.e. able to be run locally)
3. Write CI/CD tests in a simple and generally CI/CD framework-agnostic
method where definitions of these also reside _within the WRF repo_
4. Utilize HPC resources in a safe manner to increase breadth of testing
to allow testing of many more compilers and on similar hardware to the
general use case of WRF

As a first pass at demonstrating this solution, this PR implements a
simple set of compilation tests using GNU x86 configurations testing
serial, sm, dm, and sm+dm selections. The CI/CD portion is done via
GitHub workflow actions on a specific trigger event. The values and
trigger methods are configurable, but this initial implementation will
use the `labeled` trigger, which will initiate tests when
`compile-tests` or `all-tests` is added as a label to a pull request.

TESTS CONDUCTED:
1. Testing of this github workflow was done in a separate fork also
testing on Derecho. Both positive and negative tests were used to
demonstrate respective output usefulness.

RELEASE NOTE:
Introduce a modularized testing framework that allows testing locally
and natively on HPC systems that lives within the WRF repository
TYPE: enhancement

KEYWORDS: intel, compilation, llvm, memory

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
The Intel oneAPI compilers (and others like nvhpc) struggle with some of
the larger (15k+ lines of code) files within WRF. This causes intense
memory usage that is not often available to the average user not in a
resource-rich environment. This often limits compilation to single
threaded if even possible or to a dedicated environment with enough
memory if available. If neither of those is available to a user, they
will be unable to use these configurations entirely.

Solution:
This PR focuses on the `module_alloc_space*` sections of code to reduce
their individual file size to manageable levels. They are instead broken
out into many smaller files as external subroutines, not requiring a
wrapper module to house the subroutine call. The files are now fully
generated source code from the registry, with the calls to the
subroutines also being generated as well. This also makes it relatively
easy to change the number of files generated from a source code
perspective. Build rules would need to be modified accordingly as seen
in these changes.

TESTS CONDUCTED: 
Attached to this PR are plots of the respective effects of theses
changes. Changes were tested with intel and gcc compilers, but only
intel memory usage is shown as it exacerbates the memory usage issue.
TYPE: enhancement

KEYWORDS: intel, compilation, llvm, memory

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
The Intel oneAPI compilers (and others like nvhpc) struggle with some of
the larger (15k+ lines of code) files within WRF. This causes intense
memory usage that is not often available to the average user not in a
resource-rich environment. This often limits compilation to single
threaded if even possible or to a dedicated environment with enough
memory if available. If neither of those is available to a user, they
will be unable to use these configurations entirely.

Solution:
This PR focuses on the `module_dm` sections of code to reduce its
individual file size to manageable levels. This and its helper
subroutines are instead broken out into many smaller files.

TESTS CONDUCTED: 
Attached to this PR are plots of the respective effects of theses
changes. Changes were tested with intel and gcc compilers, but only
intel memory usage is shown as it exacerbates the memory usage issue.
The .F90 source files in physics_mmm need to be compiled directly to .o
on case-insensitive file systems (like MacOS standard FS). This PR
avoids the creation of a .f90 temporary, which will clobber the .F90
version.

TYPE: [bug fix]

KEYWORDS: case-insensitive filesystem

SOURCE:  "Ted Mansell (NOAA/NSSL)"

DESCRIPTION OF CHANGES:
Problem:
1. On case-insensitive file systems (like MacOS standard FS), the
creation of .f90 temporary files from .F90 source will clobber the
source files.
2. The configure.defaults has an unrecognized option for Apple clang

Solution:
1. In postamble: Removed the .F90.f90 rule and compacted the .F90.o rule
to use only the fortran compiler to do any necessary preprocessing. It
is convention among fortran compilers that .F90 will be preprocessed.
2. In configure.defaults: For Darwin compile with ifort+clang, removed
the -qopenmp from OMPCC (Apple clang does not support OpenMP)

ISSUE: Addresses .F90.f90 issue raised in
#1989

LIST OF MODIFIED FILES: 
arch/postamble
arch/configure.defaults

TESTS CONDUCTED: 
1. Compiles correctly on MacOS (Intel CPU with ifort + clang) and Linux
2. Are the Jenkins tests all passing? Yes.

RELEASE NOTE: Fixed a compile problem with .F90 source files on
case-insensitive file systems.
TYPE: bug fix

KEYWORDS: cmake, compilation

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
The use of generator expressions in the defines compacts the logic
neatly but removes the ability to evaluate these conditionals at
configuration time. As such, assumptions must either be made or defines
wholly dropped when adding configure-time commands like C preprocessing,
both of which are wrong.

Solution:
Switch the logic to a more verbose `if()`-style that guarantees defines
that can be known at configure time are resolved.

LIST OF MODIFIED FILES: 
M       CMakeLists.txt
M       cmake/c_preproc.cmake

RELEASE NOTE: CMake build no longer uses generator expressions in
defines
TYPE: no impact directly in the run

KEYWORDS: namelist, end_date, b_wave

SOURCE: Jeronimo Bande (IDING SAS)

DESCRIPTION OF CHANGES:
Problem: Wrong end date in namelist. Not good for example.
Solution: Correct  end date of the simulation.

LIST OF MODIFIED FILES: 
test/em_b_wave/namelist.input

TESTS CONDUCTED: 
Jenkins tests are all passing.
TYPE: enhancement

KEYWORDS: intel, compilation, llvm, memory

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
The Intel oneAPI compilers (and others like nvhpc) struggle with some of
the larger (15k+ lines of code) files within WRF. This causes intense
memory usage that is not often available to the average user not in a
resource-rich environment. This often limits compilation to single
threaded if even possible or to a dedicated environment with enough
memory if available. If neither of those is available to a user, they
will be unable to use these configurations entirely.

Solution:
This PR focuses on the `deallocs.inc` sections of code used in
`module_domain` to reduce the include size to manageable levels. The
include is instead broken out into many smaller files as external
subroutines. The files are fully generated source code from the
registry, with the calls to the subroutines also being generated as
well. This also makes it relatively easy to change the number of files
generated from a source code perspective. Build rules would need to be
modified accordingly as seen in these changes.

TESTS CONDUCTED: 
Attached to this PR are plots of the respective effects of theses
changes. Changes were tested with intel and gcc compilers, but only
intel memory usage is shown as it exacerbates the memory usage issue.
)

TYPE: enhancement

KEYWORDS: cmake, flags, compilation

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
The current iteration of the cmake build places all configuration flags
in the global properties of the project. While this works when just
building WRF, integration with other projects' cmake builds if placed
under WRF pollutes their respective build flags.

Solution:
Adjust the layout of the flags to instead carry them in a variable, and
prefer using `target_*` calls for flag usage.

LIST OF MODIFIED FILES: 
M       CMakeLists.txt
M       chem/CMakeLists.txt
M       external/CMakeLists.txt
M       external/io_adios2/CMakeLists.txt
M       external/io_netcdf/CMakeLists.txt
M       external/io_netcdfpar/CMakeLists.txt
M       external/io_pnetcdf/CMakeLists.txt
M       frame/CMakeLists.txt
M       main/CMakeLists.txt
M       phys/CMakeLists.txt
M       tools/CMakeLists.txt

RELEASE NOTE: 
Change internal flag organization in CMake build to not be global
TYPE: enhancement

KEYWORDS: cmake, wrfplus, da

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
The current CMake build only works with the em core / ARW in mind and
presents a non-intuitive selection when attempting other cores. While
these cores are not yet supported in the CMake build, remove these
selections sets up the configuration script to be able to present a
familiar set of options.

Solution:
Remove normally unselectable options from `configure_new` after
selecting non-ARW cores. Put in place stand-in values for these
unselected variables.
TYPE: enhancement

KEYWORDS: netCDF, cmake, compilation

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
The current iteration of the cmake build uses the old-style of finding
modules. This limits the usability of transitive properties as well as
the native netCDF cmake build which provide imported targets.

See
https://cmake.org/cmake/help/latest/manual/cmake-developer.7.html#find-modules
for more information on module writing.

Solution:
Augment the output of the provided find module to supply an imported
target that fully describes the netCDF library. Additionally, in
rewriting how targets in WRF reference netCDF remove unnecessary linking
to the library. Ensure the provided import target and flags of the find
module matches the netCDF[-Fortran].cmake.in outputs verbatim thus
emulating the native netCDF build for additional robustness.

LIST OF MODIFIED FILES: 
M       CMakeLists.txt
M       cmake/modules/FindnetCDF-Fortran.cmake
M       cmake/modules/FindnetCDF.cmake
M       external/CMakeLists.txt
M       external/RSL_LITE/CMakeLists.txt
M       external/atm_ocn/CMakeLists.txt
M       external/esmf_time_f90/CMakeLists.txt
M       external/fftpack/fftpack5/CMakeLists.txt
M       external/io_adios2/CMakeLists.txt
M       external/io_esmf/CMakeLists.txt
M       external/io_grib1/CMakeLists.txt
M       external/io_grib1/MEL_grib1/CMakeLists.txt
M       external/io_grib1/WGRIB/CMakeLists.txt
M       external/io_grib1/grib1_util/CMakeLists.txt
M       external/io_grib2/bacio-1.3/CMakeLists.txt
M       external/io_grib2/g2lib/CMakeLists.txt
M       external/io_grib_share/CMakeLists.txt
M       external/io_netcdf/CMakeLists.txt
M       external/io_netcdfpar/CMakeLists.txt


RELEASE NOTE: 
Restructure netCDF find modules to use modern import target
TYPE: bug fix

KEYWORDS: fseek, compilation, cmake

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
The fseek test lacks correct syntax causing false negative reports of
feature not existing when newer compiler standards disallow this.

Solution:
Add `int` to the main program in the fseek test. Also to add further
robustness in detecting this feature, use the `-D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE=1` generally *nix standard defines.

LIST OF MODIFIED FILES: 
M       CMakeLists.txt
M       confcheck/CMakeLists.txt
M       tools/fseek_test.c

RELEASE NOTE: Fix fseek test
TYPE: enhancement

KEYWORDS: cmake, configuration

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
In preparation for alternate core compilation, there is need for
additional information from the stanzas. Some of these fields include
extraneous information to cmake that must be filtered out. The previous
version manually listed fields and values to sanitize, but this is
brittle when accounting for all stanza types and configurations.

Solution:
Rather than hard-coding the sanitization of stanza fields to be consumed
by cmake, a generalized approach is used to allow full use of stanza
fields down the line.
TYPE: enhancement

KEYWORDS: cmake, compilation, flags

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
In preparation for alternative core selection, there is a broader range
of flags that must be set and controlled throughout the project. This
includes being able to set flags on a per-source basis to override
certain flags that are normally applied wholly to all source within a
CMake target. An example of this is disabling double precision on an
individual file when that option is being used.

Solution:
Categorizing the flags first allows for easy application and selection
of particular sets of flags for the multiple libraries and binaries
created. Second, for the core library, using pseudo-inherited CMake
properties between targets and source files allows for granular control
of these flag categories.
TYPE: enhancement

KEYWORDS: testing, compilation

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
The testing frameworks (github actions nor Jenkins) don't run a wide
array of compilation tests per compiler family commonly available.

Solution:
Use the github actions / hpc-workflows testing framework to run serial,
sm, dm, and dm+sm for GNU, Intel Classic & OneAPI, and PGI/nvhpc on
Derecho. Tests will run collectively in one node in parallel to maximize
core hour allocations.

TESTS CONDUCTED: 
1. Tests can be run locally on Derecho by using the .ci/hpc-workflows
runner.py to launch all tests as separate jobs, but this is inefficient
and not exactly as the tests run. To emulate the tests as done in the
github actions workflow use the additional `args` set in the respective
testSet of .github/workflows/.ci.yml and provide alternate directories
from which to compile. This can be facilitated via :
* clone WRF branch that features these changes into `<dir>`
* list names of tests you want space-delimited in variable, e.g. `export
tests="make-gnu-serial make-gnu-dm"`
* create copy test dirs with something like `printf "%s\n" $tests |
xargs -i -P 4 cp -Rp <dir> {}`
* Create alt dirs run locations from test definitions. In this case one
directory up from each, this can be done with `export altDirs=$( printf
"../%s/.ci " $tests )` (note the extra space!)
* launch tests using runner and join args along with `-alt $altDirs`
* Final command should look like 
```
<dir>/.ci/hpc-workflows/.ci/runner.py <dir>/.ci/wrf_compilation_tests-make.json -t $tests -a <account> -p <num parallel> -tp 1 -j='{"node_select":{"-l ":{"select":1}}}' -jn <job name> -alt $altDirs
```
…diffuse radiation reflection from the wall terms. (#2101)

TYPE: Bug fix

KEYWORDS: Shortwave radiation balance, reflected radiation, shadowing effect, single-layer urban canopy model (SLUCM), direct and diffuse radiation.

SOURCE: Parag Joshi, Katia Lamer (Brookhaven National Laboratory)

DESCRIPTION OF CHANGES:

Problem:
The single-layer urban canopy model missed a couple of terms that represent the direct and diffuse radiation reaching at a wall reflected from the other wall. It leads to an inaccurate calculation of the shortwave radiation at the walls.

Solution:
Mathematical formulation by Kusaka et. al. (2001) was followed to verify the equations used in the SLUCM module in WRF. The equations are corrected.

More details can be found in this
[attachment](https://github.com/user-attachments/files/16800936/Shortwave.radiation_Single.Layer.pdf).

LIST OF MODIFIED FILES: module_sf_urban.F

TESTS CONDUCTED:
1. It compiles.
2. It passes the Jenkins tests.

RELEASE NOTE: 
This PR corrects the shortwave radiation balance at the wall, particularly the reflected direct and diffuse radiation reaching the wall which leads to underestimation of SW radiation at the wall.
TYPE: bug fix

KEYWORDS: compilation, cmake, netcdf

SOURCE: internal

DESCRIPTION OF CHANGES:
Problem:
PR #2054 changes the netCDF target linking for WRF targets generated
through CMake. When used with any other software relying on the package
config generated from `cmake/template/WRFConfig.cmake`, there must be a
way to find non-CMake supported packages like netCDF. WRF provides these
find modules in `<install dir>/share` but does not use them within its
own package config. WPS also has a FindnetCDF.cmake and
FindnetCDF-Fortran.cmake, but these use the classic variable approach
instead of an import target.

Thus, when building WPS referencing WRF with the changes of #2054, it
will use the WPS netCDF find modules instead of WRF's. This will result
in an error like:
```
CMake Error at /home/aislas/wrf-model/wrf/install/lib/cmake/WRF/WRFTargets.cmake:111 (set_target_properties):
  The link interface of target "WRF::io_netcdf" contains:

    netCDF::netcdff
```

Solution:
Adjust the generated package config file to use WRF's find modules and
give them precedence over WPS for WRF's imported targets specifically.
Additionally, move imported target inclusion to after dependencies have
been resolved so that WRF package finding precedence is used.

TESTS CONDUCTED: 
1. Tested with gcc/OpenMPI to build WRF and WPS (v4.6.0) together
TYPE: text only

KEYWORDS: v4.6.1, release, version_decl, README

SOURCE: internal

DESCRIPTION OF CHANGES:
Updated the top-level README and inc/version_decl files to reflect
V4.6.1, in preparation for the v4.6.1 release

LIST OF MODIFIED FILES:
M README
M inc/version_decl

TESTS CONDUCTED:

No tests necessary - text only
Copy link
Owner Author

@wjcapehart wjcapehart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bugfix for duplicated allocation and file closing for radar_rhv_opt =…
… 2 (wrf-model#2078)

TYPE: bug fix

KEYWORDS: radar DA

DESCRIPTION OF CHANGES:
Problem:
Duplicated allocation of avg_qws when choosing radar_rhv_opt = 2.
da_free_unit instead of da_get_unit for closing a file when radar_rhv_opt is equal to 2.

ISSUE: wrf-model#2077

LIST OF MODIFIED FILES:
var/da/da_radar/da_get_innov_vector_radar.inc

@wjcapehart wjcapehart closed this Oct 24, 2024
@wjcapehart wjcapehart reopened this Oct 24, 2024
@wjcapehart wjcapehart closed this Oct 24, 2024
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.

10 participants