Sync to SD Mines WRF 2024-10-23#1
Closed
wjcapehart wants to merge 31 commits intowjcapehart:masterfrom
Closed
Conversation
… 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
wjcapehart
commented
Oct 23, 2024
Owner
Author
wjcapehart
left a comment
There was a problem hiding this comment.
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 masterto get formatted list)TESTS CONDUCTED:
RELEASE NOTE: Include a stand-alone message suitable for the inclusion in the minor and annual releases. A publication citation is appropriate.