Scheduled Downtime
On Tuesday 24 October 2023 @ 5pm MT the forums will be in read only mode in preparation for the downtime. On Wednesday 25 October 2023 @ 5am MT, this website will be down for maintenance and expected to return online later in the morning.
Normal Operations
The forums are back online with normal operations. If you notice any issues or errors related to the forums, please reach out to help@ucar.edu
There are some things you might want to know before running WACCM, regarding known problems and modifications to recommended settings. This post is updated regularly. The most recent update was on: 2014/11/07Known problems are listed below, organized by CESM version. This document refers to "series" of CESM, or version numbers like "1.2.z". These terms refer to groups of CESM versions that all have the same first two version numbers, and have generally the same scientific features (e.g. same climate). For example, the terms "CESM 1.1.z" and "CESM 1.1 series" mean the same thing, and include model versions 1.1.0, 1.1.1, and 1.1.2.This post focuses on issues that have been of particular interest to WACCM users. For more comprehensive information on CESM 1.0.6 and all later versions, see the bug reporting forums, especially the WACCM, CAM, and scripts sections:http://bb.cgd.ucar.edu/forums/bug-reportingThe old known problems pages can be found at the links below:For CESM 1.2.z: 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.z: 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.0.z: http://www.cesm.ucar.edu/models/cesm1.0/cesm/cesm1_tutorial.pdfCESM 1.1.z and 1.2.z: http://www.cesm.ucar.edu/events/tutorials/081213/day1-practical1-santos.pdfWhich version of CESM should you run?
Two incremental updates have been released in 2014, CESM 1.0.6 and CESM 1.2.2. 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.z.
Because the CESM 1.0 series will be supported through at least 2018, longer-term research projects may prefer to use CESM 1.0.z.
However, use of the 1.0 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.z).
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.z, 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.z, 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.z, such as 1.0.5, do not.
When running with the FV dycore on yellowstone, we recommend removing the setting of MP_EAGER_LIMIT, which allows the system setting to be used instead. This can be done by removing the relevant lines from env_mach_specific in your case directory, or from the env_mach_specific for yellowstone in the source code in Machines. (There are actually two lines setting it, and the second in particular should be removed or commented out.) See here for more.
CESM 1.2.2:
Molecular diffusion of heat was accidentally disabled when WACCM-X was added, causing the temperature profile in the mesosphere to become jagged. This problem can be fixed by using SourceMods to add the appropriate file from the main bug post.
RESUBMIT, timing files, and long-term archiving have a bug when short-term archiving is on. A simple fix can be found here, but the fix must be added to each case's run script.
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.z versions.
Running SC-WACCM in DEBUG mode on the XLF compiler will crash at the beginning of the run, due to uninitialized flags being used. Details and a workaround here.
Molecular diffusion of heat was accidentally disabled when WACCM-X was added, causing the temperature profile in the mesosphere to become jagged. This problem can be fixed by using SourceMods to add the appropriate file from the main bug post.
Running SC-WACCM in DEBUG mode on the XLF compiler will crash at the beginning of the run, due to uninitialized flags being used. Details and a workaround here.
Releases that are no longer supported This post contains information pertaining to releases that are no longer officially supported. It may or may not be fully up-to-date; the bug reporting forums may have more information.The official CESM Support Policy is located here:http://www.cesm.ucar.edu/models/cesmsupportpolicy.htmlBelow is an unofficial summary of that document's implications.Unsupported versions fall into three categories:
Some series may no longer be supported at all. In this case, no further versions will be released, and CSEG may not be able to answer questions about these versions. CCSM3 and earlier versions fall into this category, as does the CESM 1.1 series.
Other series may be supported, but they have specific versions listed below that are out-of-date. CSEG will generally respond to questions about these versions, but many problems cannot be addressed without upgrading to an updated version that provides the same functionality. For instance, we cannot address many of the issues with early versions of CESM 1.0.z, but the newest versions of CESM 1.0.z are supported and have the same scientific features.
Some code bases are not official releases of the model at all, but are supplied for reference purposes, because of the importance of individual experiments that used them. Since they are not official CESM releases, they have limited or no support from CSEG.
Some special cases:
CCSM4 is treated as an old CESM 1.0 version for support purposes; CSEG maintains the capabilities of CCSM4 within the CESM 1.0 code base.
The code used for CCMI WACCM runs done in 2013 is not supported at all, neither by CSEG, nor WAWG, nor CCWG. The scientific features of this tag are slated for a future supported CESM release, but the details are not yet determined.
The code used for the 2013 large ensemble runs is supported only by maintaining a functional version of the code on yellowstone.
CESM 1.2.1:
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 history file output "kp" is actually the value that "ap" should have. The value "ap" is never set. A workaround can be found here.
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-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.
WACCM doesn't build properly on pleiades due to a bug involving invalid XML. There is a simple fix for this.
CESM 1.2.0:
Same list as CESM 1.2.1, except that the build on pleiades works in 1.2.0.
Large Ensemble and 2013 CCMI code bases:
These releases are similar to CESM 1.1.1, which they are based upon.
CESM 1.1.1/1.1.2:
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!
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 (NTHRDS_ATM set to 1).
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
An experimental version of WACCM5 was present in this release, but a number of bugs make it unsuitable for scientific use. (Generally, the model will crash within a few years.)
The chemistry preprocessor may cause an error on some machines' batch nodes (including Yellowstone), which prevents the namelists from being updated at the beginning of each job. If you are using a custom (non-standard) chemistry, run the "preview_namelists" script after the first batch job, but before any restarts. In this case you should also run preview_namelists each time you change the namelist after building. This bug can trigger a POP error.
Changing one file in the source code will unnecessarily cause builds to recompile the entire model unless you copy this Makefile into the Tools directory of your case.
Cases will not build on pleiades unless you copy the script "ccsm_utils/Tools/taskmaker.pl" from scripts4_121129 or later. A usable version is attached to this post. This file should be placed in your copy of the scripts or in the "Tools" directory of each CESM 1.1.1 case.
CESM 1.1.0 (formerly CESM 1.1):Do not use this version. It has a significant bug that affects climate, and it was replaced by CESM 1.1.1.
All issues listed for CESM 1.1.1 also apply to this release.
Yellowstone support in this version was incomplete.
Will not build on pleiades at all without an update to the Machines tag.
CESM 1.0.5:
All issues listed for CESM 1.0.6 also apply to this version, except that the FWSC compset runs out of the box (but it is configured incorrectly; see 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!
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.0.6 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.
CESM 1.0.4 and older (and CCSM4):
CESM 1.0.4 is more or less equivalent to CESM 1.0.5. The main differences have to do with machine support.
CESM 1.0.3 and older do not have WACCM-X. WACCM-X was introduced in CESM 1.0.4.
Releases that are no longer supported This post contains information pertaining to releases that are no longer officially supported. It may or may not be fully up-to-date; the bug reporting forums may have more information.The official CESM Support Policy is located here:http://www.cesm.ucar.edu/models/cesmsupportpolicy.htmlBelow is an unofficial summary of that document's implications.Unsupported versions fall into three categories:
Some series may no longer be supported at all. In this case, no further versions will be released, and CSEG may not be able to answer questions about these versions. CCSM3 and earlier versions fall into this category, as does the CESM 1.1 series.
Other series may be supported, but they have specific versions listed below that are out-of-date. CSEG will generally respond to questions about these versions, but many problems cannot be addressed without upgrading to an updated version that provides the same functionality. For instance, we cannot address many of the issues with early versions of CESM 1.0.z, but the newest versions of CESM 1.0.z are supported and have the same scientific features.
Some code bases are not official releases of the model at all, but are supplied for reference purposes, because of the importance of individual experiments that used them. Since they are not official CESM releases, they have limited or no support from CSEG.
Some special cases:
CCSM4 is treated as an old CESM 1.0 version for support purposes; CSEG maintains the capabilities of CCSM4 within the CESM 1.0 code base.
The code used for CCMI WACCM runs done in 2013 is not supported at all, neither by CSEG, nor WAWG, nor CCWG. The scientific features of this tag are slated for a future supported CESM release, but the details are not yet determined.
The code used for the 2013 large ensemble runs is supported only by maintaining a functional version of the code on yellowstone.
CESM 1.2.1:
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 history file output "kp" is actually the value that "ap" should have. The value "ap" is never set. A workaround can be found here.
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-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.
WACCM doesn't build properly on pleiades due to a bug involving invalid XML. There is a simple fix for this.
CESM 1.2.0:
Same list as CESM 1.2.1, except that the build on pleiades works in 1.2.0.
Large Ensemble and 2013 CCMI code bases:
These releases are similar to CESM 1.1.1, which they are based upon.
CESM 1.1.1/1.1.2:
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!
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 (NTHRDS_ATM set to 1).
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
An experimental version of WACCM5 was present in this release, but a number of bugs make it unsuitable for scientific use. (Generally, the model will crash within a few years.)
The chemistry preprocessor may cause an error on some machines' batch nodes (including Yellowstone), which prevents the namelists from being updated at the beginning of each job. If you are using a custom (non-standard) chemistry, run the "preview_namelists" script after the first batch job, but before any restarts. In this case you should also run preview_namelists each time you change the namelist after building. This bug can trigger a POP error.
Changing one file in the source code will unnecessarily cause builds to recompile the entire model unless you copy this Makefile into the Tools directory of your case.
Cases will not build on pleiades unless you copy the script "ccsm_utils/Tools/taskmaker.pl" from scripts4_121129 or later. A usable version is attached to this post. This file should be placed in your copy of the scripts or in the "Tools" directory of each CESM 1.1.1 case.
CESM 1.1.0 (formerly CESM 1.1):Do not use this version. It has a significant bug that affects climate, and it was replaced by CESM 1.1.1.
All issues listed for CESM 1.1.1 also apply to this release.
Yellowstone support in this version was incomplete.
Will not build on pleiades at all without an update to the Machines tag.
CESM 1.0.5:
All issues listed for CESM 1.0.6 also apply to this version, except that the FWSC compset runs out of the box (but it is configured incorrectly; see 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!
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.0.6 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.
CESM 1.0.4 and older (and CCSM4):
CESM 1.0.4 is more or less equivalent to CESM 1.0.5. The main differences have to do with machine support.
CESM 1.0.3 and older do not have WACCM-X. WACCM-X was introduced in CESM 1.0.4.
Releases that are no longer supported This post contains information pertaining to releases that are no longer officially supported. It may or may not be fully up-to-date; the bug reporting forums may have more information.The official CESM Support Policy is located here:http://www.cesm.ucar.edu/models/cesmsupportpolicy.htmlBelow is an unofficial summary of that document's implications.Unsupported versions fall into three categories:
Some series may no longer be supported at all. In this case, no further versions will be released, and CSEG may not be able to answer questions about these versions. CCSM3 and earlier versions fall into this category, as does the CESM 1.1 series.
Other series may be supported, but they have specific versions listed below that are out-of-date. CSEG will generally respond to questions about these versions, but many problems cannot be addressed without upgrading to an updated version that provides the same functionality. For instance, we cannot address many of the issues with early versions of CESM 1.0.z, but the newest versions of CESM 1.0.z are supported and have the same scientific features.
Some code bases are not official releases of the model at all, but are supplied for reference purposes, because of the importance of individual experiments that used them. Since they are not official CESM releases, they have limited or no support from CSEG.
Some special cases:
CCSM4 is treated as an old CESM 1.0 version for support purposes; CSEG maintains the capabilities of CCSM4 within the CESM 1.0 code base.
The code used for CCMI WACCM runs done in 2013 is not supported at all, neither by CSEG, nor WAWG, nor CCWG. The scientific features of this tag are slated for a future supported CESM release, but the details are not yet determined.
The code used for the 2013 large ensemble runs is supported only by maintaining a functional version of the code on yellowstone.
CESM 1.2.1:
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 history file output "kp" is actually the value that "ap" should have. The value "ap" is never set. A workaround can be found here.
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-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.
WACCM doesn't build properly on pleiades due to a bug involving invalid XML. There is a simple fix for this.
CESM 1.2.0:
Same list as CESM 1.2.1, except that the build on pleiades works in 1.2.0.
Large Ensemble and 2013 CCMI code bases:
These releases are similar to CESM 1.1.1, which they are based upon.
CESM 1.1.1/1.1.2:
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!
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 (NTHRDS_ATM set to 1).
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
An experimental version of WACCM5 was present in this release, but a number of bugs make it unsuitable for scientific use. (Generally, the model will crash within a few years.)
The chemistry preprocessor may cause an error on some machines' batch nodes (including Yellowstone), which prevents the namelists from being updated at the beginning of each job. If you are using a custom (non-standard) chemistry, run the "preview_namelists" script after the first batch job, but before any restarts. In this case you should also run preview_namelists each time you change the namelist after building. This bug can trigger a POP error.
Changing one file in the source code will unnecessarily cause builds to recompile the entire model unless you copy this Makefile into the Tools directory of your case.
Cases will not build on pleiades unless you copy the script "ccsm_utils/Tools/taskmaker.pl" from scripts4_121129 or later. A usable version is attached to this post. This file should be placed in your copy of the scripts or in the "Tools" directory of each CESM 1.1.1 case.
CESM 1.1.0 (formerly CESM 1.1):Do not use this version. It has a significant bug that affects climate, and it was replaced by CESM 1.1.1.
All issues listed for CESM 1.1.1 also apply to this release.
Yellowstone support in this version was incomplete.
Will not build on pleiades at all without an update to the Machines tag.
CESM 1.0.5:
All issues listed for CESM 1.0.6 also apply to this version, except that the FWSC compset runs out of the box (but it is configured incorrectly; see 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!
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.0.6 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.
CESM 1.0.4 and older (and CCSM4):
CESM 1.0.4 is more or less equivalent to CESM 1.0.5. The main differences have to do with machine support.
CESM 1.0.3 and older do not have WACCM-X. WACCM-X was introduced in CESM 1.0.4.
Releases that are no longer supported This post contains information pertaining to releases that are no longer officially supported. It may or may not be fully up-to-date; the bug reporting forums may have more information.The official CESM Support Policy is located here:http://www.cesm.ucar.edu/models/cesmsupportpolicy.htmlBelow is an unofficial summary of that document's implications.Unsupported versions fall into three categories:
Some series may no longer be supported at all. In this case, no further versions will be released, and CSEG may not be able to answer questions about these versions. CCSM3 and earlier versions fall into this category, as does the CESM 1.1 series.
Other series may be supported, but they have specific versions listed below that are out-of-date. CSEG will generally respond to questions about these versions, but many problems cannot be addressed without upgrading to an updated version that provides the same functionality. For instance, we cannot address many of the issues with early versions of CESM 1.0.z, but the newest versions of CESM 1.0.z are supported and have the same scientific features.
Some code bases are not official releases of the model at all, but are supplied for reference purposes, because of the importance of individual experiments that used them. Since they are not official CESM releases, they have limited or no support from CSEG.
Some special cases:
CCSM4 is treated as an old CESM 1.0 version for support purposes; CSEG maintains the capabilities of CCSM4 within the CESM 1.0 code base.
The code used for CCMI WACCM runs done in 2013 is not supported at all, neither by CSEG, nor WAWG, nor CCWG. The scientific features of this tag are slated for a future supported CESM release, but the details are not yet determined.
The code used for the 2013 large ensemble runs is supported only by maintaining a functional version of the code on yellowstone.
CESM 1.2.1:
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 history file output "kp" is actually the value that "ap" should have. The value "ap" is never set. A workaround can be found here.
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-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.
WACCM doesn't build properly on pleiades due to a bug involving invalid XML. There is a simple fix for this.
CESM 1.2.0:
Same list as CESM 1.2.1, except that the build on pleiades works in 1.2.0.
Large Ensemble and 2013 CCMI code bases:
These releases are similar to CESM 1.1.1, which they are based upon.
CESM 1.1.1/1.1.2:
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!
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 (NTHRDS_ATM set to 1).
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
An experimental version of WACCM5 was present in this release, but a number of bugs make it unsuitable for scientific use. (Generally, the model will crash within a few years.)
The chemistry preprocessor may cause an error on some machines' batch nodes (including Yellowstone), which prevents the namelists from being updated at the beginning of each job. If you are using a custom (non-standard) chemistry, run the "preview_namelists" script after the first batch job, but before any restarts. In this case you should also run preview_namelists each time you change the namelist after building. This bug can trigger a POP error.
Changing one file in the source code will unnecessarily cause builds to recompile the entire model unless you copy this Makefile into the Tools directory of your case.
Cases will not build on pleiades unless you copy the script "ccsm_utils/Tools/taskmaker.pl" from scripts4_121129 or later. A usable version is attached to this post. This file should be placed in your copy of the scripts or in the "Tools" directory of each CESM 1.1.1 case.
CESM 1.1.0 (formerly CESM 1.1):Do not use this version. It has a significant bug that affects climate, and it was replaced by CESM 1.1.1.
All issues listed for CESM 1.1.1 also apply to this release.
Yellowstone support in this version was incomplete.
Will not build on pleiades at all without an update to the Machines tag.
CESM 1.0.5:
All issues listed for CESM 1.0.6 also apply to this version, except that the FWSC compset runs out of the box (but it is configured incorrectly; see 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!
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.0.6 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.
CESM 1.0.4 and older (and CCSM4):
CESM 1.0.4 is more or less equivalent to CESM 1.0.5. The main differences have to do with machine support.
CESM 1.0.3 and older do not have WACCM-X. WACCM-X was introduced in CESM 1.0.4.
Releases that are no longer supported This post contains information pertaining to releases that are no longer officially supported. It may or may not be fully up-to-date; the bug reporting forums may have more information.The official CESM Support Policy is located here:http://www.cesm.ucar.edu/models/cesmsupportpolicy.htmlBelow is an unofficial summary of that document's implications.Unsupported versions fall into three categories:
Some series may no longer be supported at all. In this case, no further versions will be released, and CSEG may not be able to answer questions about these versions. CCSM3 and earlier versions fall into this category, as does the CESM 1.1 series.
Other series may be supported, but they have specific versions listed below that are out-of-date. CSEG will generally respond to questions about these versions, but many problems cannot be addressed without upgrading to an updated version that provides the same functionality. For instance, we cannot address many of the issues with early versions of CESM 1.0.z, but the newest versions of CESM 1.0.z are supported and have the same scientific features.
Some code bases are not official releases of the model at all, but are supplied for reference purposes, because of the importance of individual experiments that used them. Since they are not official CESM releases, they have limited or no support from CSEG.
Some special cases:
CCSM4 is treated as an old CESM 1.0 version for support purposes; CSEG maintains the capabilities of CCSM4 within the CESM 1.0 code base.
The code used for CCMI WACCM runs done in 2013 is not supported at all, neither by CSEG, nor WAWG, nor CCWG. The scientific features of this tag are slated for a future supported CESM release, but the details are not yet determined.
The code used for the 2013 large ensemble runs is supported only by maintaining a functional version of the code on yellowstone.
CESM 1.2.1:
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 history file output "kp" is actually the value that "ap" should have. The value "ap" is never set. A workaround can be found here.
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-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.
WACCM doesn't build properly on pleiades due to a bug involving invalid XML. There is a simple fix for this.
CESM 1.2.0:
Same list as CESM 1.2.1, except that the build on pleiades works in 1.2.0.
Large Ensemble and 2013 CCMI code bases:
These releases are similar to CESM 1.1.1, which they are based upon.
CESM 1.1.1/1.1.2:
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!
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 (NTHRDS_ATM set to 1).
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
An experimental version of WACCM5 was present in this release, but a number of bugs make it unsuitable for scientific use. (Generally, the model will crash within a few years.)
The chemistry preprocessor may cause an error on some machines' batch nodes (including Yellowstone), which prevents the namelists from being updated at the beginning of each job. If you are using a custom (non-standard) chemistry, run the "preview_namelists" script after the first batch job, but before any restarts. In this case you should also run preview_namelists each time you change the namelist after building. This bug can trigger a POP error.
Changing one file in the source code will unnecessarily cause builds to recompile the entire model unless you copy this Makefile into the Tools directory of your case.
Cases will not build on pleiades unless you copy the script "ccsm_utils/Tools/taskmaker.pl" from scripts4_121129 or later. A usable version is attached to this post. This file should be placed in your copy of the scripts or in the "Tools" directory of each CESM 1.1.1 case.
CESM 1.1.0 (formerly CESM 1.1):Do not use this version. It has a significant bug that affects climate, and it was replaced by CESM 1.1.1.
All issues listed for CESM 1.1.1 also apply to this release.
Yellowstone support in this version was incomplete.
Will not build on pleiades at all without an update to the Machines tag.
CESM 1.0.5:
All issues listed for CESM 1.0.6 also apply to this version, except that the FWSC compset runs out of the box (but it is configured incorrectly; see 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!
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.0.6 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.
CESM 1.0.4 and older (and CCSM4):
CESM 1.0.4 is more or less equivalent to CESM 1.0.5. The main differences have to do with machine support.
CESM 1.0.3 and older do not have WACCM-X. WACCM-X was introduced in CESM 1.0.4.
Releases that are no longer supported This post contains information pertaining to releases that are no longer officially supported. It may or may not be fully up-to-date; the bug reporting forums may have more information.The official CESM Support Policy is located here:http://www.cesm.ucar.edu/models/cesmsupportpolicy.htmlBelow is an unofficial summary of that document's implications.Unsupported versions fall into three categories:
Some series may no longer be supported at all. In this case, no further versions will be released, and CSEG may not be able to answer questions about these versions. CCSM3 and earlier versions fall into this category, as does the CESM 1.1 series.
Other series may be supported, but they have specific versions listed below that are out-of-date. CSEG will generally respond to questions about these versions, but many problems cannot be addressed without upgrading to an updated version that provides the same functionality. For instance, we cannot address many of the issues with early versions of CESM 1.0.z, but the newest versions of CESM 1.0.z are supported and have the same scientific features.
Some code bases are not official releases of the model at all, but are supplied for reference purposes, because of the importance of individual experiments that used them. Since they are not official CESM releases, they have limited or no support from CSEG.
Some special cases:
CCSM4 is treated as an old CESM 1.0 version for support purposes; CSEG maintains the capabilities of CCSM4 within the CESM 1.0 code base.
The code used for CCMI WACCM runs done in 2013 is not supported at all, neither by CSEG, nor WAWG, nor CCWG. The scientific features of this tag are slated for a future supported CESM release, but the details are not yet determined.
The code used for the 2013 large ensemble runs is supported only by maintaining a functional version of the code on yellowstone.
CESM 1.2.1:
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 history file output "kp" is actually the value that "ap" should have. The value "ap" is never set. A workaround can be found here.
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-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.
WACCM doesn't build properly on pleiades due to a bug involving invalid XML. There is a simple fix for this.
CESM 1.2.0:
Same list as CESM 1.2.1, except that the build on pleiades works in 1.2.0.
Large Ensemble and 2013 CCMI code bases:
These releases are similar to CESM 1.1.1, which they are based upon.
CESM 1.1.1/1.1.2:
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!
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 (NTHRDS_ATM set to 1).
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
An experimental version of WACCM5 was present in this release, but a number of bugs make it unsuitable for scientific use. (Generally, the model will crash within a few years.)
The chemistry preprocessor may cause an error on some machines' batch nodes (including Yellowstone), which prevents the namelists from being updated at the beginning of each job. If you are using a custom (non-standard) chemistry, run the "preview_namelists" script after the first batch job, but before any restarts. In this case you should also run preview_namelists each time you change the namelist after building. This bug can trigger a POP error.
Changing one file in the source code will unnecessarily cause builds to recompile the entire model unless you copy this Makefile into the Tools directory of your case.
Cases will not build on pleiades unless you copy the script "ccsm_utils/Tools/taskmaker.pl" from scripts4_121129 or later. A usable version is attached to this post. This file should be placed in your copy of the scripts or in the "Tools" directory of each CESM 1.1.1 case.
CESM 1.1.0 (formerly CESM 1.1):Do not use this version. It has a significant bug that affects climate, and it was replaced by CESM 1.1.1.
All issues listed for CESM 1.1.1 also apply to this release.
Yellowstone support in this version was incomplete.
Will not build on pleiades at all without an update to the Machines tag.
CESM 1.0.5:
All issues listed for CESM 1.0.6 also apply to this version, except that the FWSC compset runs out of the box (but it is configured incorrectly; see 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!
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.0.6 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.
CESM 1.0.4 and older (and CCSM4):
CESM 1.0.4 is more or less equivalent to CESM 1.0.5. The main differences have to do with machine support.
CESM 1.0.3 and older do not have WACCM-X. WACCM-X was introduced in CESM 1.0.4.
Releases that are no longer supported This post contains information pertaining to releases that are no longer officially supported. It may or may not be fully up-to-date; the bug reporting forums may have more information.The official CESM Support Policy is located here:http://www.cesm.ucar.edu/models/cesmsupportpolicy.htmlBelow is an unofficial summary of that document's implications.Unsupported versions fall into three categories:
Some series may no longer be supported at all. In this case, no further versions will be released, and CSEG may not be able to answer questions about these versions. CCSM3 and earlier versions fall into this category, as does the CESM 1.1 series.
Other series may be supported, but they have specific versions listed below that are out-of-date. CSEG will generally respond to questions about these versions, but many problems cannot be addressed without upgrading to an updated version that provides the same functionality. For instance, we cannot address many of the issues with early versions of CESM 1.0.z, but the newest versions of CESM 1.0.z are supported and have the same scientific features.
Some code bases are not official releases of the model at all, but are supplied for reference purposes, because of the importance of individual experiments that used them. Since they are not official CESM releases, they have limited or no support from CSEG.
Some special cases:
CCSM4 is treated as an old CESM 1.0 version for support purposes; CSEG maintains the capabilities of CCSM4 within the CESM 1.0 code base.
The code used for CCMI WACCM runs done in 2013 is not supported at all, neither by CSEG, nor WAWG, nor CCWG. The scientific features of this tag are slated for a future supported CESM release, but the details are not yet determined.
The code used for the 2013 large ensemble runs is supported only by maintaining a functional version of the code on yellowstone.
CESM 1.2.1:
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 history file output "kp" is actually the value that "ap" should have. The value "ap" is never set. A workaround can be found here.
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-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.
WACCM doesn't build properly on pleiades due to a bug involving invalid XML. There is a simple fix for this.
CESM 1.2.0:
Same list as CESM 1.2.1, except that the build on pleiades works in 1.2.0.
Large Ensemble and 2013 CCMI code bases:
These releases are similar to CESM 1.1.1, which they are based upon.
CESM 1.1.1/1.1.2:
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!
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 (NTHRDS_ATM set to 1).
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
An experimental version of WACCM5 was present in this release, but a number of bugs make it unsuitable for scientific use. (Generally, the model will crash within a few years.)
The chemistry preprocessor may cause an error on some machines' batch nodes (including Yellowstone), which prevents the namelists from being updated at the beginning of each job. If you are using a custom (non-standard) chemistry, run the "preview_namelists" script after the first batch job, but before any restarts. In this case you should also run preview_namelists each time you change the namelist after building. This bug can trigger a POP error.
Changing one file in the source code will unnecessarily cause builds to recompile the entire model unless you copy this Makefile into the Tools directory of your case.
Cases will not build on pleiades unless you copy the script "ccsm_utils/Tools/taskmaker.pl" from scripts4_121129 or later. A usable version is attached to this post. This file should be placed in your copy of the scripts or in the "Tools" directory of each CESM 1.1.1 case.
CESM 1.1.0 (formerly CESM 1.1):Do not use this version. It has a significant bug that affects climate, and it was replaced by CESM 1.1.1.
All issues listed for CESM 1.1.1 also apply to this release.
Yellowstone support in this version was incomplete.
Will not build on pleiades at all without an update to the Machines tag.
CESM 1.0.5:
All issues listed for CESM 1.0.6 also apply to this version, except that the FWSC compset runs out of the box (but it is configured incorrectly; see 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!
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.0.6 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.
CESM 1.0.4 and older (and CCSM4):
CESM 1.0.4 is more or less equivalent to CESM 1.0.5. The main differences have to do with machine support.
CESM 1.0.3 and older do not have WACCM-X. WACCM-X was introduced in CESM 1.0.4.
Releases that are no longer supported This post contains information pertaining to releases that are no longer officially supported. It may or may not be fully up-to-date; the bug reporting forums may have more information.The official CESM Support Policy is located here:http://www.cesm.ucar.edu/models/cesmsupportpolicy.htmlBelow is an unofficial summary of that document's implications.Unsupported versions fall into three categories:
Some series may no longer be supported at all. In this case, no further versions will be released, and CSEG may not be able to answer questions about these versions. CCSM3 and earlier versions fall into this category, as does the CESM 1.1 series.
Other series may be supported, but they have specific versions listed below that are out-of-date. CSEG will generally respond to questions about these versions, but many problems cannot be addressed without upgrading to an updated version that provides the same functionality. For instance, we cannot address many of the issues with early versions of CESM 1.0.z, but the newest versions of CESM 1.0.z are supported and have the same scientific features.
Some code bases are not official releases of the model at all, but are supplied for reference purposes, because of the importance of individual experiments that used them. Since they are not official CESM releases, they have limited or no support from CSEG.
Some special cases:
CCSM4 is treated as an old CESM 1.0 version for support purposes; CSEG maintains the capabilities of CCSM4 within the CESM 1.0 code base.
The code used for CCMI WACCM runs done in 2013 is not supported at all, neither by CSEG, nor WAWG, nor CCWG. The scientific features of this tag are slated for a future supported CESM release, but the details are not yet determined.
The code used for the 2013 large ensemble runs is supported only by maintaining a functional version of the code on yellowstone.
CESM 1.2.1:
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 history file output "kp" is actually the value that "ap" should have. The value "ap" is never set. A workaround can be found here.
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-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.
WACCM doesn't build properly on pleiades due to a bug involving invalid XML. There is a simple fix for this.
CESM 1.2.0:
Same list as CESM 1.2.1, except that the build on pleiades works in 1.2.0.
Large Ensemble and 2013 CCMI code bases:
These releases are similar to CESM 1.1.1, which they are based upon.
CESM 1.1.1/1.1.2:
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!
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 (NTHRDS_ATM set to 1).
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
An experimental version of WACCM5 was present in this release, but a number of bugs make it unsuitable for scientific use. (Generally, the model will crash within a few years.)
The chemistry preprocessor may cause an error on some machines' batch nodes (including Yellowstone), which prevents the namelists from being updated at the beginning of each job. If you are using a custom (non-standard) chemistry, run the "preview_namelists" script after the first batch job, but before any restarts. In this case you should also run preview_namelists each time you change the namelist after building. This bug can trigger a POP error.
Changing one file in the source code will unnecessarily cause builds to recompile the entire model unless you copy this Makefile into the Tools directory of your case.
Cases will not build on pleiades unless you copy the script "ccsm_utils/Tools/taskmaker.pl" from scripts4_121129 or later. A usable version is attached to this post. This file should be placed in your copy of the scripts or in the "Tools" directory of each CESM 1.1.1 case.
CESM 1.1.0 (formerly CESM 1.1):Do not use this version. It has a significant bug that affects climate, and it was replaced by CESM 1.1.1.
All issues listed for CESM 1.1.1 also apply to this release.
Yellowstone support in this version was incomplete.
Will not build on pleiades at all without an update to the Machines tag.
CESM 1.0.5:
All issues listed for CESM 1.0.6 also apply to this version, except that the FWSC compset runs out of the box (but it is configured incorrectly; see 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!
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.0.6 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.
CESM 1.0.4 and older (and CCSM4):
CESM 1.0.4 is more or less equivalent to CESM 1.0.5. The main differences have to do with machine support.
CESM 1.0.3 and older do not have WACCM-X. WACCM-X was introduced in CESM 1.0.4.
Releases that are no longer supported This post contains information pertaining to releases that are no longer officially supported. It may or may not be fully up-to-date; the bug reporting forums may have more information.The official CESM Support Policy is located here:http://www.cesm.ucar.edu/models/cesmsupportpolicy.htmlBelow is an unofficial summary of that document's implications.Unsupported versions fall into three categories:
Some series may no longer be supported at all. In this case, no further versions will be released, and CSEG may not be able to answer questions about these versions. CCSM3 and earlier versions fall into this category, as does the CESM 1.1 series.
Other series may be supported, but they have specific versions listed below that are out-of-date. CSEG will generally respond to questions about these versions, but many problems cannot be addressed without upgrading to an updated version that provides the same functionality. For instance, we cannot address many of the issues with early versions of CESM 1.0.z, but the newest versions of CESM 1.0.z are supported and have the same scientific features.
Some code bases are not official releases of the model at all, but are supplied for reference purposes, because of the importance of individual experiments that used them. Since they are not official CESM releases, they have limited or no support from CSEG.
Some special cases:
CCSM4 is treated as an old CESM 1.0 version for support purposes; CSEG maintains the capabilities of CCSM4 within the CESM 1.0 code base.
The code used for CCMI WACCM runs done in 2013 is not supported at all, neither by CSEG, nor WAWG, nor CCWG. The scientific features of this tag are slated for a future supported CESM release, but the details are not yet determined.
The code used for the 2013 large ensemble runs is supported only by maintaining a functional version of the code on yellowstone.
CESM 1.2.1:
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 history file output "kp" is actually the value that "ap" should have. The value "ap" is never set. A workaround can be found here.
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-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.
WACCM doesn't build properly on pleiades due to a bug involving invalid XML. There is a simple fix for this.
CESM 1.2.0:
Same list as CESM 1.2.1, except that the build on pleiades works in 1.2.0.
Large Ensemble and 2013 CCMI code bases:
These releases are similar to CESM 1.1.1, which they are based upon.
CESM 1.1.1/1.1.2:
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!
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 (NTHRDS_ATM set to 1).
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
An experimental version of WACCM5 was present in this release, but a number of bugs make it unsuitable for scientific use. (Generally, the model will crash within a few years.)
The chemistry preprocessor may cause an error on some machines' batch nodes (including Yellowstone), which prevents the namelists from being updated at the beginning of each job. If you are using a custom (non-standard) chemistry, run the "preview_namelists" script after the first batch job, but before any restarts. In this case you should also run preview_namelists each time you change the namelist after building. This bug can trigger a POP error.
Changing one file in the source code will unnecessarily cause builds to recompile the entire model unless you copy this Makefile into the Tools directory of your case.
Cases will not build on pleiades unless you copy the script "ccsm_utils/Tools/taskmaker.pl" from scripts4_121129 or later. A usable version is attached to this post. This file should be placed in your copy of the scripts or in the "Tools" directory of each CESM 1.1.1 case.
CESM 1.1.0 (formerly CESM 1.1):Do not use this version. It has a significant bug that affects climate, and it was replaced by CESM 1.1.1.
All issues listed for CESM 1.1.1 also apply to this release.
Yellowstone support in this version was incomplete.
Will not build on pleiades at all without an update to the Machines tag.
CESM 1.0.5:
All issues listed for CESM 1.0.6 also apply to this version, except that the FWSC compset runs out of the box (but it is configured incorrectly; see 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!
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.0.6 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.
CESM 1.0.4 and older (and CCSM4):
CESM 1.0.4 is more or less equivalent to CESM 1.0.5. The main differences have to do with machine support.
CESM 1.0.3 and older do not have WACCM-X. WACCM-X was introduced in CESM 1.0.4.
Releases that are no longer supported This post contains information pertaining to releases that are no longer officially supported. It may or may not be fully up-to-date; the bug reporting forums may have more information.The official CESM Support Policy is located here:http://www.cesm.ucar.edu/models/cesmsupportpolicy.htmlBelow is an unofficial summary of that document's implications.Unsupported versions fall into three categories:
Some series may no longer be supported at all. In this case, no further versions will be released, and CSEG may not be able to answer questions about these versions. CCSM3 and earlier versions fall into this category, as does the CESM 1.1 series.
Other series may be supported, but they have specific versions listed below that are out-of-date. CSEG will generally respond to questions about these versions, but many problems cannot be addressed without upgrading to an updated version that provides the same functionality. For instance, we cannot address many of the issues with early versions of CESM 1.0.z, but the newest versions of CESM 1.0.z are supported and have the same scientific features.
Some code bases are not official releases of the model at all, but are supplied for reference purposes, because of the importance of individual experiments that used them. Since they are not official CESM releases, they have limited or no support from CSEG.
Some special cases:
CCSM4 is treated as an old CESM 1.0 version for support purposes; CSEG maintains the capabilities of CCSM4 within the CESM 1.0 code base.
The code used for CCMI WACCM runs done in 2013 is not supported at all, neither by CSEG, nor WAWG, nor CCWG. The scientific features of this tag are slated for a future supported CESM release, but the details are not yet determined.
The code used for the 2013 large ensemble runs is supported only by maintaining a functional version of the code on yellowstone.
CESM 1.2.1:
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 history file output "kp" is actually the value that "ap" should have. The value "ap" is never set. A workaround can be found here.
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-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.
WACCM doesn't build properly on pleiades due to a bug involving invalid XML. There is a simple fix for this.
CESM 1.2.0:
Same list as CESM 1.2.1, except that the build on pleiades works in 1.2.0.
Large Ensemble and 2013 CCMI code bases:
These releases are similar to CESM 1.1.1, which they are based upon.
CESM 1.1.1/1.1.2:
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!
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 (NTHRDS_ATM set to 1).
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
An experimental version of WACCM5 was present in this release, but a number of bugs make it unsuitable for scientific use. (Generally, the model will crash within a few years.)
The chemistry preprocessor may cause an error on some machines' batch nodes (including Yellowstone), which prevents the namelists from being updated at the beginning of each job. If you are using a custom (non-standard) chemistry, run the "preview_namelists" script after the first batch job, but before any restarts. In this case you should also run preview_namelists each time you change the namelist after building. This bug can trigger a POP error.
Changing one file in the source code will unnecessarily cause builds to recompile the entire model unless you copy this Makefile into the Tools directory of your case.
Cases will not build on pleiades unless you copy the script "ccsm_utils/Tools/taskmaker.pl" from scripts4_121129 or later. A usable version is attached to this post. This file should be placed in your copy of the scripts or in the "Tools" directory of each CESM 1.1.1 case.
CESM 1.1.0 (formerly CESM 1.1):Do not use this version. It has a significant bug that affects climate, and it was replaced by CESM 1.1.1.
All issues listed for CESM 1.1.1 also apply to this release.
Yellowstone support in this version was incomplete.
Will not build on pleiades at all without an update to the Machines tag.
CESM 1.0.5:
All issues listed for CESM 1.0.6 also apply to this version, except that the FWSC compset runs out of the box (but it is configured incorrectly; see 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!
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.0.6 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.
CESM 1.0.4 and older (and CCSM4):
CESM 1.0.4 is more or less equivalent to CESM 1.0.5. The main differences have to do with machine support.
CESM 1.0.3 and older do not have WACCM-X. WACCM-X was introduced in CESM 1.0.4.
Releases that are no longer supported This post contains information pertaining to releases that are no longer officially supported. It may or may not be fully up-to-date; the bug reporting forums may have more information.The official CESM Support Policy is located here:http://www.cesm.ucar.edu/models/cesmsupportpolicy.htmlBelow is an unofficial summary of that document's implications.Unsupported versions fall into three categories:
Some series may no longer be supported at all. In this case, no further versions will be released, and CSEG may not be able to answer questions about these versions. CCSM3 and earlier versions fall into this category, as does the CESM 1.1 series.
Other series may be supported, but they have specific versions listed below that are out-of-date. CSEG will generally respond to questions about these versions, but many problems cannot be addressed without upgrading to an updated version that provides the same functionality. For instance, we cannot address many of the issues with early versions of CESM 1.0.z, but the newest versions of CESM 1.0.z are supported and have the same scientific features.
Some code bases are not official releases of the model at all, but are supplied for reference purposes, because of the importance of individual experiments that used them. Since they are not official CESM releases, they have limited or no support from CSEG.
Some special cases:
CCSM4 is treated as an old CESM 1.0 version for support purposes; CSEG maintains the capabilities of CCSM4 within the CESM 1.0 code base.
The code used for CCMI WACCM runs done in 2013 is not supported at all, neither by CSEG, nor WAWG, nor CCWG. The scientific features of this tag are slated for a future supported CESM release, but the details are not yet determined.
The code used for the 2013 large ensemble runs is supported only by maintaining a functional version of the code on yellowstone.
CESM 1.2.1:
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 history file output "kp" is actually the value that "ap" should have. The value "ap" is never set. A workaround can be found here.
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-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.
WACCM doesn't build properly on pleiades due to a bug involving invalid XML. There is a simple fix for this.
CESM 1.2.0:
Same list as CESM 1.2.1, except that the build on pleiades works in 1.2.0.
Large Ensemble and 2013 CCMI code bases:
These releases are similar to CESM 1.1.1, which they are based upon.
CESM 1.1.1/1.1.2:
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!
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 (NTHRDS_ATM set to 1).
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
An experimental version of WACCM5 was present in this release, but a number of bugs make it unsuitable for scientific use. (Generally, the model will crash within a few years.)
The chemistry preprocessor may cause an error on some machines' batch nodes (including Yellowstone), which prevents the namelists from being updated at the beginning of each job. If you are using a custom (non-standard) chemistry, run the "preview_namelists" script after the first batch job, but before any restarts. In this case you should also run preview_namelists each time you change the namelist after building. This bug can trigger a POP error.
Changing one file in the source code will unnecessarily cause builds to recompile the entire model unless you copy this Makefile into the Tools directory of your case.
Cases will not build on pleiades unless you copy the script "ccsm_utils/Tools/taskmaker.pl" from scripts4_121129 or later. A usable version is attached to this post. This file should be placed in your copy of the scripts or in the "Tools" directory of each CESM 1.1.1 case.
CESM 1.1.0 (formerly CESM 1.1):Do not use this version. It has a significant bug that affects climate, and it was replaced by CESM 1.1.1.
All issues listed for CESM 1.1.1 also apply to this release.
Yellowstone support in this version was incomplete.
Will not build on pleiades at all without an update to the Machines tag.
CESM 1.0.5:
All issues listed for CESM 1.0.6 also apply to this version, except that the FWSC compset runs out of the box (but it is configured incorrectly; see 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!
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.0.6 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.
CESM 1.0.4 and older (and CCSM4):
CESM 1.0.4 is more or less equivalent to CESM 1.0.5. The main differences have to do with machine support.
CESM 1.0.3 and older do not have WACCM-X. WACCM-X was introduced in CESM 1.0.4.
Releases that are no longer supported This post contains information pertaining to releases that are no longer officially supported. It may or may not be fully up-to-date; the bug reporting forums may have more information.The official CESM Support Policy is located here:http://www.cesm.ucar.edu/models/cesmsupportpolicy.htmlBelow is an unofficial summary of that document's implications.Unsupported versions fall into three categories:
Some series may no longer be supported at all. In this case, no further versions will be released, and CSEG may not be able to answer questions about these versions. CCSM3 and earlier versions fall into this category, as does the CESM 1.1 series.
Other series may be supported, but they have specific versions listed below that are out-of-date. CSEG will generally respond to questions about these versions, but many problems cannot be addressed without upgrading to an updated version that provides the same functionality. For instance, we cannot address many of the issues with early versions of CESM 1.0.z, but the newest versions of CESM 1.0.z are supported and have the same scientific features.
Some code bases are not official releases of the model at all, but are supplied for reference purposes, because of the importance of individual experiments that used them. Since they are not official CESM releases, they have limited or no support from CSEG.
Some special cases:
CCSM4 is treated as an old CESM 1.0 version for support purposes; CSEG maintains the capabilities of CCSM4 within the CESM 1.0 code base.
The code used for CCMI WACCM runs done in 2013 is not supported at all, neither by CSEG, nor WAWG, nor CCWG. The scientific features of this tag are slated for a future supported CESM release, but the details are not yet determined.
The code used for the 2013 large ensemble runs is supported only by maintaining a functional version of the code on yellowstone.
CESM 1.2.1:
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 history file output "kp" is actually the value that "ap" should have. The value "ap" is never set. A workaround can be found here.
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-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.
WACCM doesn't build properly on pleiades due to a bug involving invalid XML. There is a simple fix for this.
CESM 1.2.0:
Same list as CESM 1.2.1, except that the build on pleiades works in 1.2.0.
Large Ensemble and 2013 CCMI code bases:
These releases are similar to CESM 1.1.1, which they are based upon.
CESM 1.1.1/1.1.2:
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!
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 (NTHRDS_ATM set to 1).
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
An experimental version of WACCM5 was present in this release, but a number of bugs make it unsuitable for scientific use. (Generally, the model will crash within a few years.)
The chemistry preprocessor may cause an error on some machines' batch nodes (including Yellowstone), which prevents the namelists from being updated at the beginning of each job. If you are using a custom (non-standard) chemistry, run the "preview_namelists" script after the first batch job, but before any restarts. In this case you should also run preview_namelists each time you change the namelist after building. This bug can trigger a POP error.
Changing one file in the source code will unnecessarily cause builds to recompile the entire model unless you copy this Makefile into the Tools directory of your case.
Cases will not build on pleiades unless you copy the script "ccsm_utils/Tools/taskmaker.pl" from scripts4_121129 or later. A usable version is attached to this post. This file should be placed in your copy of the scripts or in the "Tools" directory of each CESM 1.1.1 case.
CESM 1.1.0 (formerly CESM 1.1):Do not use this version. It has a significant bug that affects climate, and it was replaced by CESM 1.1.1.
All issues listed for CESM 1.1.1 also apply to this release.
Yellowstone support in this version was incomplete.
Will not build on pleiades at all without an update to the Machines tag.
CESM 1.0.5:
All issues listed for CESM 1.0.6 also apply to this version, except that the FWSC compset runs out of the box (but it is configured incorrectly; see 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!
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.0.6 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.
CESM 1.0.4 and older (and CCSM4):
CESM 1.0.4 is more or less equivalent to CESM 1.0.5. The main differences have to do with machine support.
CESM 1.0.3 and older do not have WACCM-X. WACCM-X was introduced in CESM 1.0.4.
Releases that are no longer supported This post contains information pertaining to releases that are no longer officially supported. It may or may not be fully up-to-date; the bug reporting forums may have more information.The official CESM Support Policy is located here:http://www.cesm.ucar.edu/models/cesmsupportpolicy.htmlBelow is an unofficial summary of that document's implications.Unsupported versions fall into three categories:
Some series may no longer be supported at all. In this case, no further versions will be released, and CSEG may not be able to answer questions about these versions. CCSM3 and earlier versions fall into this category, as does the CESM 1.1 series.
Other series may be supported, but they have specific versions listed below that are out-of-date. CSEG will generally respond to questions about these versions, but many problems cannot be addressed without upgrading to an updated version that provides the same functionality. For instance, we cannot address many of the issues with early versions of CESM 1.0.z, but the newest versions of CESM 1.0.z are supported and have the same scientific features.
Some code bases are not official releases of the model at all, but are supplied for reference purposes, because of the importance of individual experiments that used them. Since they are not official CESM releases, they have limited or no support from CSEG.
Some special cases:
CCSM4 is treated as an old CESM 1.0 version for support purposes; CSEG maintains the capabilities of CCSM4 within the CESM 1.0 code base.
The code used for CCMI WACCM runs done in 2013 is not supported at all, neither by CSEG, nor WAWG, nor CCWG. The scientific features of this tag are slated for a future supported CESM release, but the details are not yet determined.
The code used for the 2013 large ensemble runs is supported only by maintaining a functional version of the code on yellowstone.
CESM 1.2.1:
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 history file output "kp" is actually the value that "ap" should have. The value "ap" is never set. A workaround can be found here.
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-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.
WACCM doesn't build properly on pleiades due to a bug involving invalid XML. There is a simple fix for this.
CESM 1.2.0:
Same list as CESM 1.2.1, except that the build on pleiades works in 1.2.0.
Large Ensemble and 2013 CCMI code bases:
These releases are similar to CESM 1.1.1, which they are based upon.
CESM 1.1.1/1.1.2:
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!
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 (NTHRDS_ATM set to 1).
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
An experimental version of WACCM5 was present in this release, but a number of bugs make it unsuitable for scientific use. (Generally, the model will crash within a few years.)
The chemistry preprocessor may cause an error on some machines' batch nodes (including Yellowstone), which prevents the namelists from being updated at the beginning of each job. If you are using a custom (non-standard) chemistry, run the "preview_namelists" script after the first batch job, but before any restarts. In this case you should also run preview_namelists each time you change the namelist after building. This bug can trigger a POP error.
Changing one file in the source code will unnecessarily cause builds to recompile the entire model unless you copy this Makefile into the Tools directory of your case.
Cases will not build on pleiades unless you copy the script "ccsm_utils/Tools/taskmaker.pl" from scripts4_121129 or later. A usable version is attached to this post. This file should be placed in your copy of the scripts or in the "Tools" directory of each CESM 1.1.1 case.
CESM 1.1.0 (formerly CESM 1.1):Do not use this version. It has a significant bug that affects climate, and it was replaced by CESM 1.1.1.
All issues listed for CESM 1.1.1 also apply to this release.
Yellowstone support in this version was incomplete.
Will not build on pleiades at all without an update to the Machines tag.
CESM 1.0.5:
All issues listed for CESM 1.0.6 also apply to this version, except that the FWSC compset runs out of the box (but it is configured incorrectly; see 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!
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.0.6 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.
CESM 1.0.4 and older (and CCSM4):
CESM 1.0.4 is more or less equivalent to CESM 1.0.5. The main differences have to do with machine support.
CESM 1.0.3 and older do not have WACCM-X. WACCM-X was introduced in CESM 1.0.4.
Releases that are no longer supported This post contains information pertaining to releases that are no longer officially supported. It may or may not be fully up-to-date; the bug reporting forums may have more information.The official CESM Support Policy is located here:http://www.cesm.ucar.edu/models/cesmsupportpolicy.htmlBelow is an unofficial summary of that document's implications.Unsupported versions fall into three categories:
Some series may no longer be supported at all. In this case, no further versions will be released, and CSEG may not be able to answer questions about these versions. CCSM3 and earlier versions fall into this category, as does the CESM 1.1 series.
Other series may be supported, but they have specific versions listed below that are out-of-date. CSEG will generally respond to questions about these versions, but many problems cannot be addressed without upgrading to an updated version that provides the same functionality. For instance, we cannot address many of the issues with early versions of CESM 1.0.z, but the newest versions of CESM 1.0.z are supported and have the same scientific features.
Some code bases are not official releases of the model at all, but are supplied for reference purposes, because of the importance of individual experiments that used them. Since they are not official CESM releases, they have limited or no support from CSEG.
Some special cases:
CCSM4 is treated as an old CESM 1.0 version for support purposes; CSEG maintains the capabilities of CCSM4 within the CESM 1.0 code base.
The code used for CCMI WACCM runs done in 2013 is not supported at all, neither by CSEG, nor WAWG, nor CCWG. The scientific features of this tag are slated for a future supported CESM release, but the details are not yet determined.
The code used for the 2013 large ensemble runs is supported only by maintaining a functional version of the code on yellowstone.
CESM 1.2.1:
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 history file output "kp" is actually the value that "ap" should have. The value "ap" is never set. A workaround can be found here.
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-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.
WACCM doesn't build properly on pleiades due to a bug involving invalid XML. There is a simple fix for this.
CESM 1.2.0:
Same list as CESM 1.2.1, except that the build on pleiades works in 1.2.0.
Large Ensemble and 2013 CCMI code bases:
These releases are similar to CESM 1.1.1, which they are based upon.
CESM 1.1.1/1.1.2:
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!
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 (NTHRDS_ATM set to 1).
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
An experimental version of WACCM5 was present in this release, but a number of bugs make it unsuitable for scientific use. (Generally, the model will crash within a few years.)
The chemistry preprocessor may cause an error on some machines' batch nodes (including Yellowstone), which prevents the namelists from being updated at the beginning of each job. If you are using a custom (non-standard) chemistry, run the "preview_namelists" script after the first batch job, but before any restarts. In this case you should also run preview_namelists each time you change the namelist after building. This bug can trigger a POP error.
Changing one file in the source code will unnecessarily cause builds to recompile the entire model unless you copy this Makefile into the Tools directory of your case.
Cases will not build on pleiades unless you copy the script "ccsm_utils/Tools/taskmaker.pl" from scripts4_121129 or later. A usable version is attached to this post. This file should be placed in your copy of the scripts or in the "Tools" directory of each CESM 1.1.1 case.
CESM 1.1.0 (formerly CESM 1.1):Do not use this version. It has a significant bug that affects climate, and it was replaced by CESM 1.1.1.
All issues listed for CESM 1.1.1 also apply to this release.
Yellowstone support in this version was incomplete.
Will not build on pleiades at all without an update to the Machines tag.
CESM 1.0.5:
All issues listed for CESM 1.0.6 also apply to this version, except that the FWSC compset runs out of the box (but it is configured incorrectly; see 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!
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.0.6 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.
CESM 1.0.4 and older (and CCSM4):
CESM 1.0.4 is more or less equivalent to CESM 1.0.5. The main differences have to do with machine support.
CESM 1.0.3 and older do not have WACCM-X. WACCM-X was introduced in CESM 1.0.4.
Releases that are no longer supported This post contains information pertaining to releases that are no longer officially supported. It may or may not be fully up-to-date; the bug reporting forums may have more information.The official CESM Support Policy is located here:http://www.cesm.ucar.edu/models/cesmsupportpolicy.htmlBelow is an unofficial summary of that document's implications.Unsupported versions fall into three categories:
Some series may no longer be supported at all. In this case, no further versions will be released, and CSEG may not be able to answer questions about these versions. CCSM3 and earlier versions fall into this category, as does the CESM 1.1 series.
Other series may be supported, but they have specific versions listed below that are out-of-date. CSEG will generally respond to questions about these versions, but many problems cannot be addressed without upgrading to an updated version that provides the same functionality. For instance, we cannot address many of the issues with early versions of CESM 1.0.z, but the newest versions of CESM 1.0.z are supported and have the same scientific features.
Some code bases are not official releases of the model at all, but are supplied for reference purposes, because of the importance of individual experiments that used them. Since they are not official CESM releases, they have limited or no support from CSEG.
Some special cases:
CCSM4 is treated as an old CESM 1.0 version for support purposes; CSEG maintains the capabilities of CCSM4 within the CESM 1.0 code base.
The code used for CCMI WACCM runs done in 2013 is not supported at all, neither by CSEG, nor WAWG, nor CCWG. The scientific features of this tag are slated for a future supported CESM release, but the details are not yet determined.
The code used for the 2013 large ensemble runs is supported only by maintaining a functional version of the code on yellowstone.
CESM 1.2.1:
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 history file output "kp" is actually the value that "ap" should have. The value "ap" is never set. A workaround can be found here.
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-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.
WACCM doesn't build properly on pleiades due to a bug involving invalid XML. There is a simple fix for this.
CESM 1.2.0:
Same list as CESM 1.2.1, except that the build on pleiades works in 1.2.0.
Large Ensemble and 2013 CCMI code bases:
These releases are similar to CESM 1.1.1, which they are based upon.
CESM 1.1.1/1.1.2:
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!
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 (NTHRDS_ATM set to 1).
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
An experimental version of WACCM5 was present in this release, but a number of bugs make it unsuitable for scientific use. (Generally, the model will crash within a few years.)
The chemistry preprocessor may cause an error on some machines' batch nodes (including Yellowstone), which prevents the namelists from being updated at the beginning of each job. If you are using a custom (non-standard) chemistry, run the "preview_namelists" script after the first batch job, but before any restarts. In this case you should also run preview_namelists each time you change the namelist after building. This bug can trigger a POP error.
Changing one file in the source code will unnecessarily cause builds to recompile the entire model unless you copy this Makefile into the Tools directory of your case.
Cases will not build on pleiades unless you copy the script "ccsm_utils/Tools/taskmaker.pl" from scripts4_121129 or later. A usable version is attached to this post. This file should be placed in your copy of the scripts or in the "Tools" directory of each CESM 1.1.1 case.
CESM 1.1.0 (formerly CESM 1.1):Do not use this version. It has a significant bug that affects climate, and it was replaced by CESM 1.1.1.
All issues listed for CESM 1.1.1 also apply to this release.
Yellowstone support in this version was incomplete.
Will not build on pleiades at all without an update to the Machines tag.
CESM 1.0.5:
All issues listed for CESM 1.0.6 also apply to this version, except that the FWSC compset runs out of the box (but it is configured incorrectly; see 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!
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.0.6 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.
CESM 1.0.4 and older (and CCSM4):
CESM 1.0.4 is more or less equivalent to CESM 1.0.5. The main differences have to do with machine support.
CESM 1.0.3 and older do not have WACCM-X. WACCM-X was introduced in CESM 1.0.4.
Releases that are no longer supported This post contains information pertaining to releases that are no longer officially supported. It may or may not be fully up-to-date; the bug reporting forums may have more information.The official CESM Support Policy is located here:http://www.cesm.ucar.edu/models/cesmsupportpolicy.htmlBelow is an unofficial summary of that document's implications.Unsupported versions fall into three categories:
Some series may no longer be supported at all. In this case, no further versions will be released, and CSEG may not be able to answer questions about these versions. CCSM3 and earlier versions fall into this category, as does the CESM 1.1 series.
Other series may be supported, but they have specific versions listed below that are out-of-date. CSEG will generally respond to questions about these versions, but many problems cannot be addressed without upgrading to an updated version that provides the same functionality. For instance, we cannot address many of the issues with early versions of CESM 1.0.z, but the newest versions of CESM 1.0.z are supported and have the same scientific features.
Some code bases are not official releases of the model at all, but are supplied for reference purposes, because of the importance of individual experiments that used them. Since they are not official CESM releases, they have limited or no support from CSEG.
Some special cases:
CCSM4 is treated as an old CESM 1.0 version for support purposes; CSEG maintains the capabilities of CCSM4 within the CESM 1.0 code base.
The code used for CCMI WACCM runs done in 2013 is not supported at all, neither by CSEG, nor WAWG, nor CCWG. The scientific features of this tag are slated for a future supported CESM release, but the details are not yet determined.
The code used for the 2013 large ensemble runs is supported only by maintaining a functional version of the code on yellowstone.
CESM 1.2.1:
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 history file output "kp" is actually the value that "ap" should have. The value "ap" is never set. A workaround can be found here.
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-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.
WACCM doesn't build properly on pleiades due to a bug involving invalid XML. There is a simple fix for this.
CESM 1.2.0:
Same list as CESM 1.2.1, except that the build on pleiades works in 1.2.0.
Large Ensemble and 2013 CCMI code bases:
These releases are similar to CESM 1.1.1, which they are based upon.
CESM 1.1.1/1.1.2:
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!
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 (NTHRDS_ATM set to 1).
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
An experimental version of WACCM5 was present in this release, but a number of bugs make it unsuitable for scientific use. (Generally, the model will crash within a few years.)
The chemistry preprocessor may cause an error on some machines' batch nodes (including Yellowstone), which prevents the namelists from being updated at the beginning of each job. If you are using a custom (non-standard) chemistry, run the "preview_namelists" script after the first batch job, but before any restarts. In this case you should also run preview_namelists each time you change the namelist after building. This bug can trigger a POP error.
Changing one file in the source code will unnecessarily cause builds to recompile the entire model unless you copy this Makefile into the Tools directory of your case.
Cases will not build on pleiades unless you copy the script "ccsm_utils/Tools/taskmaker.pl" from scripts4_121129 or later. A usable version is attached to this post. This file should be placed in your copy of the scripts or in the "Tools" directory of each CESM 1.1.1 case.
CESM 1.1.0 (formerly CESM 1.1):Do not use this version. It has a significant bug that affects climate, and it was replaced by CESM 1.1.1.
All issues listed for CESM 1.1.1 also apply to this release.
Yellowstone support in this version was incomplete.
Will not build on pleiades at all without an update to the Machines tag.
CESM 1.0.5:
All issues listed for CESM 1.0.6 also apply to this version, except that the FWSC compset runs out of the box (but it is configured incorrectly; see 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!
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.0.6 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.
CESM 1.0.4 and older (and CCSM4):
CESM 1.0.4 is more or less equivalent to CESM 1.0.5. The main differences have to do with machine support.
CESM 1.0.3 and older do not have WACCM-X. WACCM-X was introduced in CESM 1.0.4.
Releases that are no longer supported This post contains information pertaining to releases that are no longer officially supported. It may or may not be fully up-to-date; the bug reporting forums may have more information.The official CESM Support Policy is located here:http://www.cesm.ucar.edu/models/cesmsupportpolicy.htmlBelow is an unofficial summary of that document's implications.Unsupported versions fall into three categories:
Some series may no longer be supported at all. In this case, no further versions will be released, and CSEG may not be able to answer questions about these versions. CCSM3 and earlier versions fall into this category, as does the CESM 1.1 series.
Other series may be supported, but they have specific versions listed below that are out-of-date. CSEG will generally respond to questions about these versions, but many problems cannot be addressed without upgrading to an updated version that provides the same functionality. For instance, we cannot address many of the issues with early versions of CESM 1.0.z, but the newest versions of CESM 1.0.z are supported and have the same scientific features.
Some code bases are not official releases of the model at all, but are supplied for reference purposes, because of the importance of individual experiments that used them. Since they are not official CESM releases, they have limited or no support from CSEG.
Some special cases:
CCSM4 is treated as an old CESM 1.0 version for support purposes; CSEG maintains the capabilities of CCSM4 within the CESM 1.0 code base.
The code used for CCMI WACCM runs done in 2013 is not supported at all, neither by CSEG, nor WAWG, nor CCWG. The scientific features of this tag are slated for a future supported CESM release, but the details are not yet determined.
The code used for the 2013 large ensemble runs is supported only by maintaining a functional version of the code on yellowstone.
CESM 1.2.1:
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 history file output "kp" is actually the value that "ap" should have. The value "ap" is never set. A workaround can be found here.
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-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.
WACCM doesn't build properly on pleiades due to a bug involving invalid XML. There is a simple fix for this.
CESM 1.2.0:
Same list as CESM 1.2.1, except that the build on pleiades works in 1.2.0.
Large Ensemble and 2013 CCMI code bases:
These releases are similar to CESM 1.1.1, which they are based upon.
CESM 1.1.1/1.1.2:
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!
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 (NTHRDS_ATM set to 1).
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
An experimental version of WACCM5 was present in this release, but a number of bugs make it unsuitable for scientific use. (Generally, the model will crash within a few years.)
The chemistry preprocessor may cause an error on some machines' batch nodes (including Yellowstone), which prevents the namelists from being updated at the beginning of each job. If you are using a custom (non-standard) chemistry, run the "preview_namelists" script after the first batch job, but before any restarts. In this case you should also run preview_namelists each time you change the namelist after building. This bug can trigger a POP error.
Changing one file in the source code will unnecessarily cause builds to recompile the entire model unless you copy this Makefile into the Tools directory of your case.
Cases will not build on pleiades unless you copy the script "ccsm_utils/Tools/taskmaker.pl" from scripts4_121129 or later. A usable version is attached to this post. This file should be placed in your copy of the scripts or in the "Tools" directory of each CESM 1.1.1 case.
CESM 1.1.0 (formerly CESM 1.1):Do not use this version. It has a significant bug that affects climate, and it was replaced by CESM 1.1.1.
All issues listed for CESM 1.1.1 also apply to this release.
Yellowstone support in this version was incomplete.
Will not build on pleiades at all without an update to the Machines tag.
CESM 1.0.5:
All issues listed for CESM 1.0.6 also apply to this version, except that the FWSC compset runs out of the box (but it is configured incorrectly; see 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!
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.0.6 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.
CESM 1.0.4 and older (and CCSM4):
CESM 1.0.4 is more or less equivalent to CESM 1.0.5. The main differences have to do with machine support.
CESM 1.0.3 and older do not have WACCM-X. WACCM-X was introduced in CESM 1.0.4.
Releases that are no longer supported This post contains information pertaining to releases that are no longer officially supported. It may or may not be fully up-to-date; the bug reporting forums may have more information.The official CESM Support Policy is located here:http://www.cesm.ucar.edu/models/cesmsupportpolicy.htmlBelow is an unofficial summary of that document's implications.Unsupported versions fall into three categories:
Some series may no longer be supported at all. In this case, no further versions will be released, and CSEG may not be able to answer questions about these versions. CCSM3 and earlier versions fall into this category, as does the CESM 1.1 series.
Other series may be supported, but they have specific versions listed below that are out-of-date. CSEG will generally respond to questions about these versions, but many problems cannot be addressed without upgrading to an updated version that provides the same functionality. For instance, we cannot address many of the issues with early versions of CESM 1.0.z, but the newest versions of CESM 1.0.z are supported and have the same scientific features.
Some code bases are not official releases of the model at all, but are supplied for reference purposes, because of the importance of individual experiments that used them. Since they are not official CESM releases, they have limited or no support from CSEG.
Some special cases:
CCSM4 is treated as an old CESM 1.0 version for support purposes; CSEG maintains the capabilities of CCSM4 within the CESM 1.0 code base.
The code used for CCMI WACCM runs done in 2013 is not supported at all, neither by CSEG, nor WAWG, nor CCWG. The scientific features of this tag are slated for a future supported CESM release, but the details are not yet determined.
The code used for the 2013 large ensemble runs is supported only by maintaining a functional version of the code on yellowstone.
CESM 1.2.1:
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 history file output "kp" is actually the value that "ap" should have. The value "ap" is never set. A workaround can be found here.
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-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.
WACCM doesn't build properly on pleiades due to a bug involving invalid XML. There is a simple fix for this.
CESM 1.2.0:
Same list as CESM 1.2.1, except that the build on pleiades works in 1.2.0.
Large Ensemble and 2013 CCMI code bases:
These releases are similar to CESM 1.1.1, which they are based upon.
CESM 1.1.1/1.1.2:
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!
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 (NTHRDS_ATM set to 1).
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
An experimental version of WACCM5 was present in this release, but a number of bugs make it unsuitable for scientific use. (Generally, the model will crash within a few years.)
The chemistry preprocessor may cause an error on some machines' batch nodes (including Yellowstone), which prevents the namelists from being updated at the beginning of each job. If you are using a custom (non-standard) chemistry, run the "preview_namelists" script after the first batch job, but before any restarts. In this case you should also run preview_namelists each time you change the namelist after building. This bug can trigger a POP error.
Changing one file in the source code will unnecessarily cause builds to recompile the entire model unless you copy this Makefile into the Tools directory of your case.
Cases will not build on pleiades unless you copy the script "ccsm_utils/Tools/taskmaker.pl" from scripts4_121129 or later. A usable version is attached to this post. This file should be placed in your copy of the scripts or in the "Tools" directory of each CESM 1.1.1 case.
CESM 1.1.0 (formerly CESM 1.1):Do not use this version. It has a significant bug that affects climate, and it was replaced by CESM 1.1.1.
All issues listed for CESM 1.1.1 also apply to this release.
Yellowstone support in this version was incomplete.
Will not build on pleiades at all without an update to the Machines tag.
CESM 1.0.5:
All issues listed for CESM 1.0.6 also apply to this version, except that the FWSC compset runs out of the box (but it is configured incorrectly; see 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!
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.0.6 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.
CESM 1.0.4 and older (and CCSM4):
CESM 1.0.4 is more or less equivalent to CESM 1.0.5. The main differences have to do with machine support.
CESM 1.0.3 and older do not have WACCM-X. WACCM-X was introduced in CESM 1.0.4.
Releases that are no longer supported This post contains information pertaining to releases that are no longer officially supported. It may or may not be fully up-to-date; the bug reporting forums may have more information.The official CESM Support Policy is located here:http://www.cesm.ucar.edu/models/cesmsupportpolicy.htmlBelow is an unofficial summary of that document's implications.Unsupported versions fall into three categories:
Some series may no longer be supported at all. In this case, no further versions will be released, and CSEG may not be able to answer questions about these versions. CCSM3 and earlier versions fall into this category, as does the CESM 1.1 series.
Other series may be supported, but they have specific versions listed below that are out-of-date. CSEG will generally respond to questions about these versions, but many problems cannot be addressed without upgrading to an updated version that provides the same functionality. For instance, we cannot address many of the issues with early versions of CESM 1.0.z, but the newest versions of CESM 1.0.z are supported and have the same scientific features.
Some code bases are not official releases of the model at all, but are supplied for reference purposes, because of the importance of individual experiments that used them. Since they are not official CESM releases, they have limited or no support from CSEG.
Some special cases:
CCSM4 is treated as an old CESM 1.0 version for support purposes; CSEG maintains the capabilities of CCSM4 within the CESM 1.0 code base.
The code used for CCMI WACCM runs done in 2013 is not supported at all, neither by CSEG, nor WAWG, nor CCWG. The scientific features of this tag are slated for a future supported CESM release, but the details are not yet determined.
The code used for the 2013 large ensemble runs is supported only by maintaining a functional version of the code on yellowstone.
CESM 1.2.1:
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 history file output "kp" is actually the value that "ap" should have. The value "ap" is never set. A workaround can be found here.
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-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.
WACCM doesn't build properly on pleiades due to a bug involving invalid XML. There is a simple fix for this.
CESM 1.2.0:
Same list as CESM 1.2.1, except that the build on pleiades works in 1.2.0.
Large Ensemble and 2013 CCMI code bases:
These releases are similar to CESM 1.1.1, which they are based upon.
CESM 1.1.1/1.1.2:
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!
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 (NTHRDS_ATM set to 1).
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
An experimental version of WACCM5 was present in this release, but a number of bugs make it unsuitable for scientific use. (Generally, the model will crash within a few years.)
The chemistry preprocessor may cause an error on some machines' batch nodes (including Yellowstone), which prevents the namelists from being updated at the beginning of each job. If you are using a custom (non-standard) chemistry, run the "preview_namelists" script after the first batch job, but before any restarts. In this case you should also run preview_namelists each time you change the namelist after building. This bug can trigger a POP error.
Changing one file in the source code will unnecessarily cause builds to recompile the entire model unless you copy this Makefile into the Tools directory of your case.
Cases will not build on pleiades unless you copy the script "ccsm_utils/Tools/taskmaker.pl" from scripts4_121129 or later. A usable version is attached to this post. This file should be placed in your copy of the scripts or in the "Tools" directory of each CESM 1.1.1 case.
CESM 1.1.0 (formerly CESM 1.1):Do not use this version. It has a significant bug that affects climate, and it was replaced by CESM 1.1.1.
All issues listed for CESM 1.1.1 also apply to this release.
Yellowstone support in this version was incomplete.
Will not build on pleiades at all without an update to the Machines tag.
CESM 1.0.5:
All issues listed for CESM 1.0.6 also apply to this version, except that the FWSC compset runs out of the box (but it is configured incorrectly; see 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!
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.0.6 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.
CESM 1.0.4 and older (and CCSM4):
CESM 1.0.4 is more or less equivalent to CESM 1.0.5. The main differences have to do with machine support.
CESM 1.0.3 and older do not have WACCM-X. WACCM-X was introduced in CESM 1.0.4.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
