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
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.
A bug in the chemistry pre-processor can produce non-conservative solutions for chemistry mechanisms that have 99 or more species. This bug is present in all released and development version of CESM. In the file: cam/chem_proc/src/cam_chempp/make_map.fthe variable cls_rxt_map defaults to -99. This causes a problem in cam/chem_proc/src/cam_chempp/pl_code.f, where the reaction rate is calculated: rate = REAL( count( abs( cls_rxt_map(k,4:prd_lim+3,class) ) == species ) ) If there is a species 99, this reaction rate can incorrectly be multiplied by 2 or more, as this line falsely counts the default -99 setting as matching the species number. The fix is to change the default value of cls_rxt_map in cam/chem_proc/src/cam_chempp/make_map.f:
--- cam_chempp/make_map.f (bug)+++ cam_chempp/make_map.f (fix) exit end if else- cls_rxt_map(kp3) = -99+ cls_rxt_map(kp3) = -huge(0) end if end do=================================================================== This will only fix the bug when a usr_mech_infile is used to create the chemistry subroutines. Existing chemistry mechanisms that have 99 or more species in the source code under cam/src/chemistry may have the bug in those chemistry mechanisms. This bug has been reported here: http://bugs.cgd.ucar.edu/show_bug.cgi?id=2535
A bug in the chemistry pre-processor can produce non-conservative solutions for chemistry mechanisms that have 99 or more species. This bug is present in all released and development version of CESM. In the file: cam/chem_proc/src/cam_chempp/make_map.fthe variable cls_rxt_map defaults to -99. This causes a problem in cam/chem_proc/src/cam_chempp/pl_code.f, where the reaction rate is calculated: rate = REAL( count( abs( cls_rxt_map(k,4:prd_lim+3,class) ) == species ) ) If there is a species 99, this reaction rate can incorrectly be multiplied by 2 or more, as this line falsely counts the default -99 setting as matching the species number. The fix is to change the default value of cls_rxt_map in cam/chem_proc/src/cam_chempp/make_map.f:
--- cam_chempp/make_map.f (bug)+++ cam_chempp/make_map.f (fix) exit end if else- cls_rxt_map(kp3) = -99+ cls_rxt_map(kp3) = -huge(0) end if end do=================================================================== This will only fix the bug when a usr_mech_infile is used to create the chemistry subroutines. Existing chemistry mechanisms that have 99 or more species in the source code under cam/src/chemistry may have the bug in those chemistry mechanisms. This bug has been reported here: http://bugs.cgd.ucar.edu/show_bug.cgi?id=2535
A bug in the chemistry pre-processor can produce non-conservative solutions for chemistry mechanisms that have 99 or more species. This bug is present in all released and development version of CESM. In the file: cam/chem_proc/src/cam_chempp/make_map.fthe variable cls_rxt_map defaults to -99. This causes a problem in cam/chem_proc/src/cam_chempp/pl_code.f, where the reaction rate is calculated: rate = REAL( count( abs( cls_rxt_map(k,4:prd_lim+3,class) ) == species ) ) If there is a species 99, this reaction rate can incorrectly be multiplied by 2 or more, as this line falsely counts the default -99 setting as matching the species number. The fix is to change the default value of cls_rxt_map in cam/chem_proc/src/cam_chempp/make_map.f:
--- cam_chempp/make_map.f (bug)+++ cam_chempp/make_map.f (fix) exit end if else- cls_rxt_map(kp3) = -99+ cls_rxt_map(kp3) = -huge(0) end if end do=================================================================== This will only fix the bug when a usr_mech_infile is used to create the chemistry subroutines. Existing chemistry mechanisms that have 99 or more species in the source code under cam/src/chemistry may have the bug in those chemistry mechanisms. This bug has been reported here: http://bugs.cgd.ucar.edu/show_bug.cgi?id=2535
A bug in the chemistry pre-processor can produce non-conservative solutions for chemistry mechanisms that have 99 or more species. This bug is present in all released and development version of CESM. In the file: cam/chem_proc/src/cam_chempp/make_map.fthe variable cls_rxt_map defaults to -99. This causes a problem in cam/chem_proc/src/cam_chempp/pl_code.f, where the reaction rate is calculated: rate = REAL( count( abs( cls_rxt_map(k,4:prd_lim+3,class) ) == species ) ) If there is a species 99, this reaction rate can incorrectly be multiplied by 2 or more, as this line falsely counts the default -99 setting as matching the species number. The fix is to change the default value of cls_rxt_map in cam/chem_proc/src/cam_chempp/make_map.f:
--- cam_chempp/make_map.f (bug)+++ cam_chempp/make_map.f (fix) exit end if else- cls_rxt_map(kp3) = -99+ cls_rxt_map(kp3) = -huge(0) end if end do=================================================================== This will only fix the bug when a usr_mech_infile is used to create the chemistry subroutines. Existing chemistry mechanisms that have 99 or more species in the source code under cam/src/chemistry may have the bug in those chemistry mechanisms. This bug has been reported here: http://bugs.cgd.ucar.edu/show_bug.cgi?id=2535
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.
