There are some things you might want to know before running WACCM, regarding known problems and modifications to recommended settings. These are listed below, organized by CESM version.
This post focuses on issues that have been of particular interest to WACCM users. For more comprehensive information on CESM 1.0.6 and later, see the bug reporting forums, especially the WACCM, CAM, and scripts sections:
The old known problems pages can be found at the links below:
For CESM 1.2.X: http://www.cesm.ucar.edu/models/cesm1.2/tags/cesm1_2/knownproblems.html
For CESM 1.1.2: http://www.cesm.ucar.edu/models/cesm1.1/tags/cesm1_1_2/knownproblems.html
For CESM 1.0.X: http://www.cesm.ucar.edu/models/cesm1.0/tags/
To get started on running the model, you can try tutorials from previous years:
CESM 1.1.X and 1.2.X: http://www.cesm.ucar.edu/events/tutorials/081213/day1-practical1-santos.pdf
Which version of CESM should you run?
- At the time of this writing, two incremental updates are planned for late spring and early summer of 2014. These are CESM 1.0.6 and CESM 1.2.2. At that point, all users setting up new runs should use one of these two versions, especially for specified chemistry cases.
- These new releases contain bug fixes preventing data loss, model crashes, and namelist configuration problems.
- In the case of SC-WACCM, there are many fixes involving the default namelist settings and forcing files, including five new SC-WACCM fully coupled compsets.
- For runs that must be comparable to CMIP5 configurations, you should run the most recent version of CESM 1.0.x.
- Because the CESM 1.0.x series will be supported through at least 2018, longer-term research projects may prefer to use CESM 1.0.x.
- However, use of the 1.0.x series is highly discouraged for projects that must make major modifications to CESM code.
- Users who want to experiment with recent model development should use the highest released version number (as of this writing, CESM 1.2.x).
- If you want to run a configuration that has been designated as "scientifically supported", you can look here for a list of configurations that are supported for each model version:
- Collaborators involved with model development may contact the co-chair of the appropriate working group to request access to pre-release versions of CESM.
For All Released Versions:
- DO NOT run diagnostic scripts that create files or directories in a short term archive, if the model is still running at the same time.
- In versions of CESM before CESM 1.2.x, there is a rare but serious bug that can cause the loss of all data in the short term archive, potentially affecting centuries of data.
- In CESM 1.2.x, the data loss is prevented, but the data may appear to be lost because it is in a hidden directory in the short term archive.
- CESM 1.0.6 also has this safeguard, but earlier versions of CESM 1.0.x, such as 1.0.5, do not.
CESM 1.2.2 (upcoming):
- WACCM-SE can crash if threading is enabled, particularly with DEBUG set to TRUE on with the Intel compiler. The problem is very similar to the problem with WACCM-X that was present in CESM 1.1.1.
- WACCM-SE also uses a frontogenesis function about 14x too large, triggering frontal gravity waves too often and in the tropics. This is due to a unit conversion error between CAM's physics (using Pa) and the SE dycore (using hPa). A workaround is to use SourceMods to change models/atm/cam/src/dynamics/se/gravity_waves_sources.F90, and divide psurf_ref by 100._r8 when it is set from hypi.
- The WACCM/CARMA nuclear winter compset is replaced with a generic WACCM/CARMA black carbon compset in this version of the code. The default initial conditions will yield a climate equivalent to a control run for the nuclear winter case in previous CESM 1.2.x versions.
- All issues listed above for CESM 1.2.2 also apply to this tag, except that there is a different nuclear winter compset issue, mentioned below.
- The QBO forcing module requires the FV dycore to be used, and the namelist option do_circulation_diags to be .true.
- This is the default for all WACCM-FV runs.
- A run with do_circulation_diags = .false. and qbo_use_forcing = .true. will produce invalid results!
- The WACCM5 B1850 compset has a wrong use_case. Fix this by using "./xmlchange CAM_NML_USE_CASE=waccm_1850_cam5" in your case directory.
- WACCM5 experiences occasional crashes (for some cases, as frequently as every few years) in eddy_diff and RRTMG. This is due to these parameterizations making assumptions that become invalid near the WACCM5 model top.
- The WACCM/CARMA nuclear winter compset, BNUKE_C4WBC_L40CN, starts from the wrong refcase (RUN_REFCASE in env_run.xml).
- The corrected refcase is "b40.rcp4_5.2deg.wcm.carma.bc0tg.002". With this change, the compset should produce a control run without a nuclear winter scenario. To get a nuclear winter, you should additionally change the initial conditions file, by setting "ncdata" to point to the file "b40.rcp4_5.2deg.wcm.carma.bc5tg.IndPak.002.cam2.i.2013-01-01-00000.nc". This file is present in inputdata in the directory "ccsm4_init/b40.rcp4_5.2deg.wcm.carma.bc0tg.002/2013-01-01/"
- WACCM doesn't build properly on pleiades due to a bug involving invalid XML. There is a simple fix for this.
CESM 1.0.6 (upcoming):
- There may be an issue with POP2 restarts on some machines. We have not been able to reproduce this.
- All issues listed for CESM 1.0.6 also apply to this version.
- The QBO forcing module requires the FV dycore to be used and the namelist option do_circulation_diags to be .true. (this is the default for all WACCM-FV runs). A run with do_circulation_diags = .false. and qbo_use_forcing = .true. will produce invalid results!
- In rare cases, WACCM will crash due to a numerical instability in the FV dycore. A workaround is to set the namelist variable "nspltvrm" to 2.
- Specified chemistry cases (SC-WACCM) have an incorrect ozone input file (only 26 levels, from CAM4). Use these namelist settings to correct this issue:
- prescribed_ozone_file = "waccm_ozone_c121126.nc"
- prescribed_ozone_cycle_yr = 0
- Turbulent mountain stress (TMS) is not turned on by default for SC and SD compsets in this release. Users may wish to turn TMS on as specified here.
- Specified chemistry cases may experience an out-of-bounds memory access issue. At the least this will cause DEBUG cases to fail on compilers with bounds checking (e.g. PGI), if not more serious issues. The only fix is to use SourceMods to fix upper_bc.F90. The solution used in CESM 1.1 is the following change:
- Find the line "if ( any( z_top(:ncol) < 150.0_r8 ) ) then"
- Replace the number "150" with "180" in this line.
- WACCM-X can crash with a floating point error if threading is enabled. This is known to happen when DEBUG is TRUE on yellowstone; theoretically it could affect cases with DEBUG set to FALSE. The solution is to run without threading.
Sean Patrick Santos
CESM Software Engineering Group
NCAR Mesa Lab, Room 320A