CESM Models

do_circulation_diags MUST be .true. in all cases with WACCM's QBO forcing enabled. Cases with qbo_use_forcing = .true. and do_circulation_diags = .false. will produce invalid output.

These changes are necessary for either a control run or not:

xmlchange RUN_REFCASE=b40.rcp4_5.2deg.wcm.carma.bc0tg.002

The following must be added to user_nl_cam to get an actual nuclear winter:

ncdata = "b40.rcp4_5.2deg.wcm.carma.bc5tg.IndPak.002.cam2.i.2013-01-01-00000.nc"

The SE version of gravity_waves_sources in CESM 1.2 has a frontogenesis function ~14x larger than it should be due to a unit conversion error. The main effect is to trigger frontal waves more often and in the tropics. This only affects WACCM-SE.

This will be fixed for CESM 1.3 in the next CAM tag but a workaround patch for gravity_waves_sources is listed below.

@@ -39,7 +39,7 @@
     call initEdgeBuffer(edge3,3*nlev)
     allocate(deriv(0:Nthreads-1))

-    psurf_ref = hypi(plev+1)
+    psurf_ref = hypi(plev+1)/100._r8

   end subroutine gws_init

In WACCM-SE's gravity_waves_sources module, a race condition is present that may cause problems for some runs. For instance, it may cause the model to crash if using the Intel compiler with DEBUG set to TRUE.

To work around this you may either change gravity_waves_sources to make the variables "ie" and "ncol" thread-private, or simply run with NTHRDS_ATM set to 1.

The problem occurs when the solar_parms_file input file contains data for leap days (Feb 29) while the calendar is 'NOLEAP'. A work around to this problem is to use the following alternative datasets for solar_parms_file which do not contain leap days:

B_1850-2000_WACCM_CN
 solar_parms_file = '$DIN_LOC_ROOT/atm/waccm/solar/proxy_solar_Solomon_Richmond_1845-2008_daily_noleap_c110526.nc'

B_1955-2005_WACCM_CN
F_1955-2005_WACCM_CN
B_RCP2.6_WACCM_CN
B_RCP4.5_WACCM_CN
B_RCP8.5_WACCM_CN
 solar_parms_file = '$DIN_LOC_ROOT/atm/waccm/solar/wasolar_1948-2140_daily_noleap_c110525.nc'

In modifying the clm to introduce tropical crop pfts, I have come across the following problem:

The if-statements in biogeochem/CNAllocationMod.F90 and biogeochem/CNNDynamicsMod.F90 that check for soybean do not include the option for irrigated soybean. I'm correcting this in my version of clm4.5 that will run with 78 pfts.

The Bugzilla report contains detailed information regarding this bug and the fix.

The Bugzilla report contains detailed information regarding this bug and the fix.

The Bugzilla report contains detailed information regarding this bug and the fix.

When running CLM45CNDV model (compset: ICLM45CNDV) and after running 400 years, there are no trees in the Amazon. ICNDV works all fine.

The behavior has been attributed to Gordon's physiology changes to the model that improve the GPP simulation. This means that the dgvm needs retuning, and we decided not to proceed with such retuning at this time because we expect this dgvm to be replaced with Rosie Fisher's work in the not too distant future.

It will map to other high resolutions like: ne120np4, 0.23x0.31, 0.47x0.61 however. The problem is that it does the mapping, but puts garbage data values (like e317) in some fields that the program does NOT touch. They happen to be very important indexing fields that can NOT be messed with.

This is fixed when you use the new netCDF library: netCDF-4.3.0-rc3. Note, this library is not yet available on pleiades hosts.

The file clmi.ICRUCLM45BGCCROPmp24.0241-01-01.1.9x2.5_g1v6_simyr2000_c130515.nc was interpolated using interpinic for CROP simulations. But, because of Bug 1725, interpinic gave a file that has CROP NOT spunup, but starting up from bare soil. So we plan to delete this file, and get a version that will work. Users should either wait for that file, or spin up CROP on their own using the standard procedure.

See the bugzilla report for detailed information and a suggested work around.

See the bugzilla report for detailed information and a suggested work around.

Some data related to the running averages of climate variables (and maybe other data) are not written to the restart file. Thus restarts that happen mid-year do not restart properly.

The workaround is to ensure that any _GLC compset runs for an integer number of years before restarting.

The fix is posted in the Bugzilla report.

There have been intermittent failures of CESM that can be traced back to a problem calling MPI_Wtime. We do not use the MPI_Wtime function in the gptl timing library on yellowstone, however some of the CESM component models (notably pop) call MPI_Wtime directly. Adding the module load command below replaces the MPI_Wtime function with a call to system clock. If you have seen this problem on yellowstone, add the lines:

module use -a /glade/app/contrib/wtime
module load wt

to your env_mach_specific file.

This is a problem with the IBM MPI library and so affects all currently supported releases of CESM on Yellowstone.

If you try to set up an ne120_f09_g16 or ne120_f02_t12 case, the grids are not set correctly because of a missing underscore in config_grid.xml. There is no separator between the ocean grid [gx1v6 or tx0.1v2] and the r% header indicating the name of the runoff.

More details and a patch are available from the Bugzilla report.

A partial port to the machine stampede was included in the 1.2.0 release. We apologize - this port is incomplete and should not have been included in a release version of the code.

Currently in env_build.xml we have

<entry id="EXEROOT" value="/blah/$CCSMUSER/$CASE/bld" />

and in env_run.xml

<entry id="RUNDIR" value="/blah/$CCSMUSER/$CASE/run" />

In many cases you may want to change both of these variables, but you cannot currently reference one variable in the other file - that is you cannot set:

<entry id="RUNDIR" value="$EXEROOT/../run" />

The workaround is not to use $EXEROOT in env_run.xml but rather to set it individually

There is an xlf compiler problem using ne30_ne30, compsets FSTRATMAM and FAMIPC5 that requires updating the PE/threading layout. Please post a question to the DiscussCESM Forums if you need help determining an optimal layout.

Intrepid is scheduled for retirement in early 2014. This bug will not be fixed before that time.