Main menu


CESM1.2.1 and earlier- Temperature tendency output TTEND_TOT / PTTEND / DTCORE

8 posts / 0 new
Last post
CESM1.2.1 and earlier- Temperature tendency output TTEND_TOT / PTTEND / DTCORE

STATUS: added by cacraig April 21, 2014 - see final post for details.
Affected release 1.2.1 and earlier
- fixed in CESM1.2.2 (release target June 1, 2014)
- User will need to fix 1.0.x with the description below if they require the fix in this version

Bugzilla 1958



Can someone explain me why

TTEND_TOT (total temperature tendency) != PTTEND (temperature tendency from physics) + DTCORE (temperature tendency from dynamical core).

i.e. physics and dynamics temperature tendency doesn't match total temperature tendency.

From our analysis of the source code and the documentation we cannot figure what's missing to get TTEND_TOT.
Does someone have a hint what's missing?




  I replicated the probem and you are correct, something is missing.  Specifically, it is
 a combination of a possibly misleading "feature" and a bug in the calculation of DTCORE
 (TTEND_TOT also had been computed incorrectly in earlier versions of the model, but has
 been corrected as of at least "cesm1_1_1")

  1) feature:  the "addfld" call for DTCORE indicates that the field be written to the
     history file as "instantaneous" rather than time averaged by default.  The other
     two fields are written time averaged by default.  To rectify this in your script,
     add the following to the "FINCL[x]" in your namelist:

         'TTEND_TOT:A','PTTEND:A','DTCORE:A'  for time averaged results
         'TTEND_TOT:I','PTTEND:I','DTCORE:I'  for instantaneous results

  2) bug:  DTCORE is computed by backing out the temperature tendency from the difference
     of the before-and-after "dry static energy" states.  This is incorrect for closure of
     the T-budget.  The correct computation should involve the before-and-after T states

 (this was tested only for the FV dynamical core)

   Thank you for catching this.


Thank you for your comment. If I get you right, I'll have to do two things:

1. modify namelist (easy, I'll test this right now)

2. modify the DTCORE calculations to get the correct dynamics temperature tendency.If you do have a fix for that, I'll appreciate that

We are using CESM/WACCM 1.2.0 with the FV core.



   In the module, "physpkg.F90" modify 2 routines:

   subroutine tphysac:

        move the code block:

       ! store dse after tphysac in buffer
       do k = 1,pver
          dtcore(:ncol,k) = state%s(:ncol,k)
       end do

       to just below the line:

       state%t(:ncol,:pver) = tini(:ncol,:pver) + ztodt*tend%dtdt(:ncol,:pver)

       and change:

       dtcore(:ncol,k) = state%s(:ncol,k)


       dtcore(:ncol,k) = state%t(:ncol,k)

   subroutine tphysbc:

       change the line:

       dtcore(:ncol,k) = (state%s(:ncol,k) - dtcore(:ncol,k))/(cpair*ztodt)


       dtcore(:ncol,k) = (tini(:ncol,k) - dtcore(:ncol,k))/(ztodt) + tend%dTdt(:ncol,k)

     ... that should do it.


Dear Jerry Olson

Thanks for this wonderful support. I just applied the changes and did a short test run. TTEND_TOT now almost exactly matches PTTEND + DTCORE (diff < 1e-11 K/s)
Have a nice week.



Dear Jerry

I assume that this bug is already present in CESM 1.0.x (specifically CESM 1.0.2)? I'm asking this as we are currently extending an older CESM 1.0.2 run where we want to add DTCORE and PTTEND as additional output.

At least the relevant code part (tphysac.F90 tphyspc.F90) in CESM 1.0.2 look similar to CESM 1.2.0 to me.

Thanks for you help




 Correct.  DTCORE was added to the code more than 7 years ago and its original form is the same as today.  So it is

 likely in the same form in all the CESM releases.  Technically it may not be a bug, but a "feature" as the original developer

may have wanted to express the change in dry static energy by the dynamics as a temperature change.  However, I agree it is

not a feature of much use to us.  :)


This fix is in the 1.2.2 release(upcoming June 1, 2014).  It has also been put into the CAM development trunk (at cam5_3_32).  It was decided to not put this bug fix into the cesm1.0.x series, but the user can apply the changes detailed above to fix the bug if they wish.

Log in or register to post comments

Who's new

  • jwolff
  • tinna.gunnarsdo...
  • sarthak2235@...
  • eolivares@...
  • shubham.gandhi@...