Merged
Conversation
TYPE: bug fix KEYWORDS: chem, KPP SOURCE: Michael Newman (Woodard & Curran) DESCRIPTION OF CHANGES: Fixed typo "Makfile_org" to "Makefile_org" in chem/KPP/clean_kpp. Expected behavior: After copying "Makefile_org" to "Makefile", the script is expecting to delete "Makefile_org" to clean up. LIST OF MODIFIED FILES: M chem/KPP/clean_kpp TESTS CONDUCTED: 1. Ran clean_kpp to confirm expected behavior. 2. Searched code base to confirm no additional references to the typo "Makfile_org". 3. Jenkins tests all PASS. RELEASE NOTE: Fixed typo "Makfile_org" to "Makefile_org" in chem/KPP/clean_kpp.
TYPE: new feature KEYWORDS: issue template SOURCE: internal DESCRIPTION OF CHANGES: A first cut at setting up a bug-fix template for issues. LIST OF MODIFIED FILES: .github/ISSUE_TEMPLATE/bug_report.md TESTS CONDUCTED: 1. Does not impact the build or run of the WRF model, no test required.
TYPE: bug fix KEYWORDS: Variational Bias Correction, num_fgat_time>1, 4DVar, FGAT SOURCE: Yali Wu (NCAR) DESCRIPTION OF CHANGES: This is bug fixes for VarBC in 4DVar or FGAT model. The innovations were incorrect for time>1, because the ordering of the VarBC and radiance quality control processes were inconsistent. The issue is resolved by moving forward operator of VarBC and radiance QC routine to a higher level subroutine da_get_innov_vector.inc. The general procedure for doing VarBC in WRFDA is: 1. calculate bias predictors (da_varbc_pred) 2. call da_varbc_coldstart 3. apply forward operator of bias correction to radiance innovation (da_varbc_direct) 4. radiance da_qc procedures 5. calculate covariance matrix b/w bias predictors for VarBC preconditioning (da_varbc_precond). Previously, VarBC worked correctly for cases when num_fgat_time=1. However, when num_fgat_time > 1, there are two bugs that need to be fixed. * First, bias is applied to innovations before cold_varbc is calculated in cases of time slot >1. * Second, the order of conducting varbc and da_qc is unclear: for the first time slot, varbc is done before da_qc, but for other time slots when num_fgat_time>1, da_qc is done before VarBC. This PR fixed the issues mentioned above and worked properly in 4DVAR experiments. LIST OF MODIFIED FILES: M var/da/da_minimisation/da_get_innov_vector.inc M var/da/da_minimisation/da_minimisation.f90 M var/da/da_radiance/da_get_innov_vector_radiance.inc TESTS CONDUCTED: 1. WRF DA regression tests conducted on Cheyenne. 2. Jenkins testing all PASS. RELEASE NOTES: Previously, VarBC worked correctly for cases when num_fgat_time=1 (i.e., 3DVar or hybrid-3DEnVar mode). However, when num_fgat_time > 1, there were two bugs. First, bias was applied to innovations before cold_varbc was calculated in case of number of time slots >1. Second, the order of conducting VarBC and radiance QC was not consistent: for the first time slot, VarBC was done before da_qc, but for other time slots when num_fgat_time>1, radiance QC was done before VarBC. These two issues have been addressed.
TYPE: bug fix KEYWORDS: PGI, compile, mp_SBM_polar_radar, phys, erf, derf SOURCE: Bart Brashers (Ramboll) DESCRIPTION OF CHANGES: A fortran function (DErF) was being used in the module_mp_SBM_polar_radar file. This was causing a compiling fail for PGI (tested with versions 19.10.0 on user's machine and 19.3 on Cheyenne). According to this article: https://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/DErF-Intrinsic.html the DErF function is archaic. Modifying this function to ErF corrects the problem and allows the PGI compiler to build the WRF executable from source. LIST OF MODIFIED FILES: M phys/module_mp_SBM_polar_radar.F TESTS CONDUCTED: Verified that code does not compile in original state, but does with the modified code when using the PGI compiler. Reggie should be OK. RELEASE NOTE: A minor modification has been introduced into the SBM Polar Radar microphysics code to allow the WRF code to build with PGI compilers. The nonstandard derf() intrinsic has been replaced by the 2008 standard compliant erf() intrinsic.
…he namelist (#1190) TYPE: bug fix KEYWORDS: aer_opt = 2, Goddard SW, single scattering albedo, asymmetry factor, prescribed aerosol optical properties from namelist.input SOURCE: Pedro A. Jimenez and Ju Hye Kim (NCAR/RAL), and J. Dudhia (NCAR/MMM) DESCRIPTION OF CHANGES: Fill in aerssa2d and aerasy2d arrays if aer_opt = 2 and sw = 5 (Goddard shortwave parameterization) with the values imposed in the namelist via aer_ssa_opt = 1 and/or aer_asy_opt = 1 options. The variables aerssa2d and aerasy2d are always present for ARW so there is no concern with memory packaging. The filling of the variables is properly handled by RRTMG but not by the Goddard SW parameterization. Similarly to the RRTMG implementation, no special treatment for HWRF (e.g. ifdef) is necessary to fill in the variables. If the variables are not filled in, FARMS will not use the values specified in the namelist. Instead, FARMS will use zero values for the single scattering albedo (SSA) and the asymmetry factor (g) leading to an incorrect irradiance parameterization. LIST OF MODIFIED FILES: M phys/module_ra_aerosol.F TESTS CONDUCTED: Before the fix, aerssa2d and aerasy2d were zero. After the fix these arrays have the values specified in the namelist. Jenkins test is all PASS RELEASE NOTE: Bug fix for aer_opt =2 and Goddard SW radiation to fill in the 2D arrays with the aerosol optical properties (SSA and g) from namelist.input. The bug affects the FARMS output which will not properly account for either SSA or g (both values will be zero).
TYPE: bug fix KEYWORDS: clWRF, maximum, minimum, time, diagnostics SOURCE: Christopher Thomas (Climate Change Research Centre, UNSW Australia) DESCRIPTION OF CHANGES: TT2MAX and TT2MIN are the times at which T2MAX and T2MIN, the max and min values of T2 within a diagnostic period, are achieved. This bug caused the incorrect computation of TT2MAX and TT2MIN for cases in which T2MAX or T2MIN occurred at the beginning of the diagnostic period under consideration. At the beginning of each diagnostic period the working values of T2MAX and T2MIN are reinitialized with the current value of T2, however the working values of TT2MAX and TT2MIN were not reinitialized with the current time value. Thus if the max or min actually occurred at the beginning of the diagnostic period, then TT2MAX or TT2MIN would contain the value assigned to it in the previous period. The bug fix corrects this by re-initializing TT2MAX and TT2MIN at the beginning of each diagnostic period. The same initialization of the time of occurrence for the max/min of the 2-m temperature was applied to these variables: tt2clmin, tt2clmax, tq2clmin, tq2clmax, tspduv10clmax, traincclmax, trainncclmax, tskintempclmin, tskintempclmax. ISSUE: Closes #1193 LIST OF MODIFIED FILES: M phys/module_diag_cl.F TESTS CONDUCTED: Tested on the WRF simulation set up for which the problem was first encountered. The fix changes the TT2MAX and TT2MIN values only for those points/periods for which they were incorrect, leaving all others unchanged. The values of TT2MAX and TT2MIN produced by the fix are in agreement with those computed by outputting T2 for all times steps and calculating TT2MAX and TT2MIN directly (using R). The tests were made using v4.1.2 but the file in question (module_diag_cl.F) has not changed in v4.2. Here the diagnostic period for the min/max output is 24 hrs. Screenshot shows second 24 hr period of simulation. Left-hand panel = before fix Right-hand panel = after fix Values for TT2MAX should range between 1440 and 2880 Note speckling in region south of Australia, also isolated instances elsewhere. In this instance nothing seems to occur over land but it clearly could. Bug only manifests if the extreme value occurs at the beginning of the diagnostic period. before_after_clwrf_fix Jenkins testing is OK. RELEASE NOTE: The calculation of the times of minimum and maximum of fields within the clWRF diagnostics module was occasionally incorrect. At the beginning of each diagnostic period the working values of diagnostic was correctly reinitialized with the current value; however the working values of occurrence of the time of the max/min values of the diagnostics were not reinitialized with the current time value. Thus if the max or min actually occurred at the beginning of the diagnostic period, then the reported time would incorrectly contain the value assigned during the previous output period.
TYPE: bug fix KEYWORDS: nesting, configure -r8, integer SOURCE: Yulong Ma (University of Delaware) DESCRIPTION OF CHANGES: Problem: A segmentation fault occurs when running nesting with "./configure -r8" and using the urban scheme. This was traced to incorrect interpolation (Registry d option) and feedback (Registry u option) subroutines that are assigned in a Registry file. The interp_fcnm is a masked interpolation for real variables. For integers, the interpolation should use the only available option: interp_fcni. Solution: In Registry/Registry.EM_COMMON, an example of the incorrect subroutine is: state integer UTYPE_URB2D ij misc 1 - rd=(interp_fcnm)u=(copy_fcnm) "UTYPE_URB" "URBAN TYPE" "dimensionless" The Registry line should be: state integer UTYPE_URB2D ij misc 1 - rd=(interp_fcni)u=(copy_fcni) "UTYPE_URB" "URBAN TYPE" "dimensionless" LIST OF MODIFIED FILES: Registry/Registry.EM_COMMON: fields changed= UTYPE_URB2D, mosaic_cat_index Registry/registry.clm: fields changed= NUMC, NUMP, SNL Registry/registry.noahmp: fields changed= isnowxy TESTS CONDUCTED: Without mod, code seg faults during first time step. With mod, code runs to completion. Fields look OK Jenkins testing all PASS. RELEASE NOTE: Using real*8, nesting, and urban caused a segmentation fault, which has been fixed. The problem was traced to a default assignment to the wrong horizontal interpolation and feedback routines.
TYPE: bug fix KEYWORDS: shin hong, divide by zero SOURCE: Matthias Göbel (University of Innsbruck) DESCRIPTION OF CHANGES: When using the Shin-Hong PBL with initially zero wind, divisions by zero can occur. This bug fix includes if-statements to avoid a crash of the model. All limit values that are used instead of the divisions by zero should be mathematically correct, except for the third change where I guessed the appropriate limit value. LIST OF MODIFIED FILES: phys/module_bl_shinhong.F RELEASE NOTE: fixed divide by zero in Shin-Hong PBL
…. See WRF Issue #1206. (#1221) TYPE: bug fix KEYWORDS: macros, compiler, llvm, clang SOURCE: Isaac Rowe (University of Kentucky) DESCRIPTION OF CHANGES: Problem: Some versions of LLVM clang cannot parse spaces near parentheses in cpp macros. For example: DM_BCAST_MACRO_R16 ( FAF1 ) This bug has been discussed on the LLVM site: https://bugs.llvm.org/show_bug.cgi?id=18011. Solution: The surrounding spaces around the parentheses from the macros with parameters in phys/module_mp_fast_sbm.F were removed. DM_BCAST_MACRO_R16(FAF1) Only a single file uses this "nonstandard" spacing for the cpp macros. ISSUE: Fixes #1206 (Usage of macros is incompatible with clang cpp -traditional-cpp). LIST OF MODIFIED FILES: phys/module_mp_fast_sbm.F TESTS CONDUCTED: Now builds with LLVM cpp (Apple clang version 11.0.3 (clang-1103.0.32.62)). Previously received Unclassifiable statement error at module_mp_fast_sbm.f90:6065:4 during next step in compilation. Jenkins test all PASS. RELEASE NOTES: A fix was provided to support building the WRF system with LLVM clang. Some versions of LLVM clang cannot correctly parse spaces near parentheses in cpp macros, and those spaces have been removed.
TYPE: bug fix KEYWORDS: subroutine, end SOURCE: Ted Mansell (NSSL), issue reported by Manuel Luis Aznar (University of La Laguna) DESCRIPTION OF CHANGES: Compilation error generated by a subroutine which has an "end" statement but does not have an "end subroutine X" statement. Platform: Macos High Sierra (10.13) Compilers: Fortran: ifort Version 13.0.3.198 Build 20130606; cc: clang-1000.11.45.5 MPI: Openmpi 2.1.2 ISSUE: Fixes issue #1215 (Error in compiling WRF v4.2) LIST OF MODIFIED FILES: phys/module_fr_fire_phys.F TESTS CONDUCTED: Previously, the compiler complained about the syntax: time mpif90 -f90=ifort -o module_fr_fire_phys.o -c -O3 -fp-model precise -w -ftz -align all -fno-alias -fno-common -FR -convert big_endian [etc.] module_fr_fire_phys.f90 module_fr_fire_phys.f90(755): error #6378: SUBROUTINE must be present on the end-subroutine-stmt of an internal or module subroutine end ^ compilation aborted for module_fr_fire_phys.f90 (code 1) Addition of "subroutine read_namelist_fire" resolved the error. Jenkins test passed. RELEASE NOTE: A compiler error was raised by ifort 13 for a fire module routine due to omission of the keyword "SUBROUTINE" in the "END SUBROUTINE" statement. This has been addressed.
TYPE: bug fix KEYWORDS: process_time_series, solar, segfault SOURCE: Franciano Puhales (Federal University of Santa Maria, Brazil) and internal DESCRIPTION OF CHANGES: When using time series with the solar diagnostic option activated, the model segfaults. This was traced to missing fields in the package for tseries_add_solar: ts_p_profile and ts_w_profile. ISSUE: Fixes #1227 (time series + solar diagnostics = seg fault) LIST OF MODIFIED FILES: modified: Registry.EM_COMMON TESTS CONDUCTED: OP reports this fixes the issue. Jenkins is all PASS. RELEASE NOTE: When using time series with the solar diagnostic option activated, the model segfaulted. This problem was traced to missing fields in the package for tseries_add_solar: ts_p_profile and ts_w_profile. The missing fields have been added to the package list, allowing the proper functioning of time series with solar diagnostics.
TYPE: bug fix KEYWORDS: advection, TKE, wind turbine SOURCE: Cristina L. Archer, Sicheng Wu, and Yulong Ma (University of Delaware, CReW), and Pedro A. Jimenez (NCAR/RAL) DESCRIPTION OF CHANGES: The TKE generated by wind turbines is not advected when the user instructs MYNN to advected the TKE. The present PR fixes this issue. Our research (Archer et al. 2020) indicates that after fixing this issue the production of TKE by wind turbines is too large and we have reduced the TKE coefficient (correction factor = 0.25) based on extensive comparison with LES results. The figure bellow summarizes this choice: ALL_TKE_profiles_LES_PR_figc ISSUE: N/A LIST OF MODIFIED FILES: M phys/module_pbl_driver.F M phys/module_wind_fitch.F M Registry/Registry.EM_COMMON M run/README.namelist M Registry/Registry.NMM TESTS CONDUCTED: We have conducted simulations with and without the fix to ensure WRF is properly advecting the TKE generated by the wind turbines. The jenkins tests are OK RELEASE NOTE: Bug fix to advect the TKE generated by the wind turbines if the user instructs MYNN to advect the TKE. There is also an empirical reduction of the wind turbines' TKE coefficient based on LES results (Archer et al. 2020). Archer, C.L., S. Wu, Y. Ma, and P.A. Jimenez, 2020: Turbulent kinetic energy generated by wind farms is treated incorrectly in the WRF model. Mon. Wea. Rev. (Under review).
TYPE: bug fix KEYWORDS: advection, program, 1d SOURCE: internal DESCRIPTION OF CHANGES: There were two types of problems. First the original cpp commands were broken. The cpp command was commented out, but it is used to build the source code, with cut and paste). The second problem is caused by the modification of the advection interface with the release of v4.0. First Problem and Solution: Original suggested using cpp -traditional. This is an incorrect cpp option. The flag is supposed to be cpp -traditional-cpp. Original suggested using cpp -C -P. The -C flag puts these GNU comments in the code (which is OK if you are writing in the C language). /* Copyright (C) 1991-2012 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. The GNU C Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with the GNU C Library; if not, see <http://www.gnu.org/licenses/>. */ Second Problem: The existing advection testing program had not been updated to assume the existence of the hybrid vertical coordinate. That meant a few variables in the calls to the scalar advection routines (c1 and c2) were missing. The advection testing tool would not compile. Second Solution: Initialize the 1d arrays c1 and c2 to terrain-following coordinate settings (c1=1, c2=0), and pass those args into the WRF scalar advection drivers. The simplified settings are not important since this is just for a 1d advection. LIST OF MODIFIED FILES: modified: dyn_em/module_advection_em.F TESTS CONDUCTED: All of the changes are inside of ifdefs, so there is no impact to the compilable WRF code. The advection main program had the interfaces updated to match the current advection drivers. Previously, the advection testing code did not compile. Now the tester program builds and runs. Here are the results after 0, 1200, 1400, 1600, 1800, and 2000 full time steps (each full time step is constructed of three small time steps). Results from the advection schemes scalar_adv_opt = 0 (standard scalar advection), 1 (positive definite), 2 (monotonic), 3 (WENO), and 4 (WENO PD) are shown. Every 200 full steps, the square wave should be back in the original location. Screen Shot 2020-07-09 at 12 45 43 PM Screen Shot 2020-07-09 at 12 47 18 PM Screen Shot 2020-07-09 at 12 42 29 PM Screen Shot 2020-07-09 at 12 49 10 PM Screen Shot 2020-07-09 at 12 52 12 PM RELEASE NOTE: I don't want to support this, so no release information.
…itions (#1217) TYPE: enhancement KEYWORDS: slope, periodic boundary conditions SOURCE: Matthias Göbel (University of Innsbruck) DESCRIPTION OF CHANGES: In the current WRF version the slope angle on the lateral boundaries of the domain is calculated differently than in the interior of the domain. For the former, forward or backward final differences are used, for the latter central finite differences. This can lead to different shortwave fluxes for equivalent locations in mountainous terrain. For periodic boundary conditions, the terrain outside of the domain is known and set right before. This enhancement implements central differences also for the domain boundary to get the same shortwave flux for equivalent locations. ISSUE: Fixes #1008 LIST OF MODIFIED FILES: dyn_em/start_em.F TESTS CONDUCTED: RELEASE NOTE: for periodic boundary conditions the slope calculation for the lateral boundaries is made equivalent to the calculation for the interior of the domain
TYPE: text only KEYWORDS: PR, commit message, template SOURCE: internal DESCRIPTION OF CHANGES: Problem: The older commit templates referred to WTF and had some singleton three quotes in a row (without a closing set of quotes). There was ambiguity in the requests for what tests were to be conducted, and there was no reference to the jenkins results. Solution: Small text tweaks, just update and clarify expectations from contributors. The text for the two templates is now consistent. LIST OF MODIFIED FILES: modified: .github/PULL_REQUEST_TEMPLATE modified: tools/commit_form.txt TESTS CONDUCTED: 1. No source changes, but jenkins ran OK.
TYPE: bug fix KEYWORDS: floating point exception, log, gamma SOURCE: Ted Mansell (NSSL) DESCRIPTION OF CHANGES: 1. A previous change to a lookup table caused a log(0) floating point exception. There was no practical impact unless compiling with debug checks for FPEs. The problem was when the incomplete gamma function was called with a second argument of zero. It now correctly returns the complete gamma. 2. Since the gamxinflu lookup table is double precision, calculated values for it are now DP instead of single precision. Very slight differences will result. 3. The lookup table is also slightly expanded for the next update -- no impact here. LIST OF MODIFIED FILES: phys/module_mp_nssl_2mom.F ISSUE: Fixes #1207 "Bug: log(0) in module_mp_nssl_2mom.F" TESTS CONDUCTED: 1. Ideal simulation to confirm no substantial difference in result. 2. Jenkins status all PASS. RELEASE NOTE: For NSSL Microphysics, fixed a floating point log(0) and minor change to lookup table.
TYPE: text only KEYWORDS: readme, rinblw, max_dom SOURCE: Peng Zimu (Peking University) and internal DESCRIPTION OF CHANGES: One of the FDDA capabilities for blending observations with the gridded simulation relies on the appropriate observation density within a specified radius of influence, which is controlled by the option rinblw (km). To allow for different observations on different nests, this option is defined in the Registry as a max_domains namelist entry. Therefore this option should be specified for each individual domain. This PR: 1. adds (max_dom) to rinblw in test/em_real/README.grid_fdda 2. adds multiple columns for rinblw in test/em_real/examples.namelist. For users with nested domains, before this mod, the WRF code returned: ``` Error in rinblw, please specify a reasonable value *** ``` This update to the documentation helps users to _a priori_ correctly set rinblw for nested domains. LIST OF MODIFIED FILES: M test/em_real/examples.namelist M test/em_real/README.grid_fdda TESTS CONDUCTED: 1. After setting rinblw for nested domains, the WRF with surface-analysis nudging can run successfully. 2. Only README files changed, no tests required. RELEASE NOTES: A modification to a couple of the README files, which helps users to correctly set rinblw when surface-analysis nudging is applied to nested domains. Previously, the rinblw was not consistently identified as a max_dom variable.
TYPE: bug KEYWORDS: photolysis scheme, TUV, diagnostics, debug_level SOURCE: Xin Zhang (NUIST) DESCRIPTION OF CHANGES: Problem: When using WRF-Chem with the new Photolysis option (phot_opt = 4) activated, the model spends too much time writing the TUV.diags. These diagnostics should only used for debugging photolysis rates. The diagnostics should be enabled only for an explicitly requested debug value. Solution: Enable TUV diagnostics only when debug_level >= 100. ISSUE: Fixes #1242 Speed up writing the TUV.diags file LIST OF MODIFIED FILES: M chem/rxn.F TESTS CONDUCTED: TUV init is much quicker and the WRF-Chem one domain simulation test is successful. The time is the time of the diagnostics call. Here's the table if debug_level = 0: Before Commit After Commit 24 cores 1s skip 120 cores 10 min skip If I change debug_level to 100, this is the result: Before Commit After Commit 24 cores 1s 1s 120 cores 10 min 10 min Jenkins test is successful. RELEASE NOTE: When using WRF-Chem with the new Photolysis option (phot_opt = 4) activated, the model spent too much time on looping and writing the TUV.diags which is only used for debugging photolysis rates. The diagnostics are now enabled only for debug_level >=100.
TYPE: bug fix KEYWORDS: m_opt, momentum flux SOURCE: Matthias Göbel (University of Innsbruck) DESCRIPTION OF CHANGES: When outputting SGS momentum fluxes using the option m_opt, the units of the fluxes should be m2 s-2 according to registry.les. The fluxes above the surface are divided by the density and thus have the correct units. The surface fluxes, however, still contain the density. This bug fix divides the surface fluxes by the density to obtain the correct units. This change only affects the output of the SGS fluxes (nba_mij). The tendencies and thus the results are not changed. LIST OF MODIFIED FILES: dyn_em/module_diffusion_em.F TESTS CONDUCTED: Jenkins OK RELEASE NOTE: Fixed units of surface momentum flux in dyn_em/module_diffusion_em.F when using m_opt. This bug fix divides the surface fluxes by the density to obtain the correct units. This change only affects the output of the SGS fluxes (nba_mij). The tendencies and thus the results are not changed.
… of subroutine 'rad_rrtmg_driver'. (#1257) TYPE: bug fix KEYWORDS: module_ra_rrtmg_swk.F, RRTMK, RRTMG SOURCE: James Ruppert, Penn State University DESCRIPTION OF CHANGES: Longwave (RTHRATENLW) and shortwave (RTHRATENSW) radiative tendencies were in reversed order at start of subroutine rad_rrtmg_driver in module_ra_rrtmg_swk.F (driver for RRTMK radiation scheme). These reverse-ordered tendencies feed directly up to module_radiation_driver.F. While this bug leads to the output shortwave and longwave tendencies being in swapped positions, this bug does not affect the sum of shortwave and longwave heat tendency (RTHRATEN), so it does not affect model results. LIST OF MODIFIED FILES: M phys/module_ra_rrtmg_swk.F TESTS CONDUCTED: Verified that this bug fix places the correct fields into the variables RTHRATENLW (aka RTHRATLW) and RTHRATENSW (aka RTHRATSW) as viewed through model output. Also verified that all other model output variables are not changed due to this fix in a test case by MMM. RELEASE NOTE: A bug is fixed for the long- and short-wave radiative tendencies from RRTMK scheme. The current longwave tendency (RTHRATLW), if output from the model, is actually the shortwave tendency, and vise versa. However the sum of the two, RTHRATEN, is correct, and hence this bug only affect separate radiative tendencies, but not model results. (Thanks to James Ruppert of Penn State University.)
…#1253) TYPE: New feature KEYWORDS: Static analysis, regression testing SOURCE: John Collins (SimCon / Edge Hill University) CHANGES: The WRF code has a large number of nonstandard constructs that have been in the code for a while. Part of the capability of the FPT static analysis tool is to discover noncompliant Fortran syntax and usage. 1. A few issues in the existing WRF code preclude the FPT utility from running on WRF, including outright Fortran bugs. The bugs are removed. 2. Additionally, the temporary files in the frame directory associated with the automatic code generation of namelist configuration processing are no longer removed by the Makefile. This was not a bug, but the static analyzer needsthe cpp manufactured code to continue to exist. This PR represents an initial step. Once the WRF code is suitable for automatic use by FPT, then a second PR will introduce the required exemplar files for comparison. That step, which insures no additional nonstandard Fortran constructs or usages are introduced, will eventually be part of the jenkins testing. MODIFIED FILES: dyn_em/module_first_rk_step_part1.F * Inserted missing continuation * The leading "&" character in column 6 on the following line was sufficient for GNU, Intel, PGI external/io_grib2/bacio-1.3/bacio.F * Inserted missing "::" delimiters * A declaration with an assignment requires the "::" delimeters frame/Makefile * Commented-out deletion of xx*.f90 and yy*.f90. * These are needed for the regression test and are deleted by the `clean` script phys/module_bl_mynn.F * Additional + sign deleted at line 3030 TESTS CONDUCTED: 1. fpt regression tests 2. Jenkins is all PASS. RELEASE NOTE: Changes required to implement a static analysis regression of WRF are being introduced. This is an initial phase, with the static analysis to implementation to follow. Please see: http://simconglobal.com/WRF_Workshop_June_2011_Poster_Automatic_Detection_of_Software_Errors_in_WRF.pdf http://simconglobal.com/WRF_Workshop_June_2012_Poster_QA_Analysis_of_the_WRF_Program.pdf http://simconglobal.com/collins_et_al_2013_automated_quality_assurance_analysis_wrf_a_case_study.pdf
TYPE: no impact KEYWORDS: version_decl, README SOURCE: internal DESCRIPTION OF CHANGES: Update the version number of this release to v4.2.1 LIST OF MODIFIED FILES: README inc/version_decl TESTS CONDUCTED: 1. Regression test all PASS (of course).
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
16 participants
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.
Use this template to give a detailed message describing the change you want to make to the code.
If you are unclear on what should be written here, see https://github.com/wrf-model/WRF/wiki/Making-a-good-pull-request-message for more guidance
The title of this pull request should be a brief "purpose" for this change.
--- Delete this line and those above before hitting "Create pull request" ---
TYPE: choose one of [bug fix, enhancement, new feature, feature removed, no impact, text only]
KEYWORDS: approximately 3 to 6 words (more is always better) related to your commit, separated by commas
SOURCE: Either "developer's name (affiliation)" .XOR. "internal" for a WRF Dev committee member
DESCRIPTION OF CHANGES: One or more paragraphs describing problem, solution, and required changes.
ISSUE: For use when this PR closes an issue. For example, if this PR closes issue number 123
Fixes wrf-model#123
LIST OF MODIFIED FILES: list of changed files (use
git diff --name-status masterto get formatted list)TESTS CONDUCTED: Explicitly state if a WTF and or other tests were run, or are pending. For more complicated changes please be explicit!
RELEASE NOTE: Include a stand-alone message suitable for the inclusion in the minor and annual releases. A publication citation is appropriate.