CESM1.2.2 PTTEND!=QRS+QRL+DTCOND+DTV+TTGWORO+(TFIX)

[simchan_yook@colostate_edu]

Hi all,

I'm looking for the temperature budget variables.

I've checked that temperature tendency calculated by difference in instantaneous temperature at each time step is almost identical so the sum of DTCORE + PTTEND.
T[i+1]-T = (DTCORE[i+1]+PTTEND[i+1])*(time step)

However, it seems like
PTTEND != QRS+QRL+DTCOND+DTV+TTGWORO

Is this because there are still some other factors contributing to the physical temperature tendency (e.g. temperature changes associated with Rayleigh friction) rather than the above five processes?

Looking forward to any suggestions for resolving this issue.

Thank you,
Shim


*updates on Oct 9th, 2019
- I've realized that Rayleigh friction isn't turned on as a default so it didn't influenced temperature tendency in my case.
- one potential difference (but probably only important for WACCMX I guess) tendency term such as TTGWORO is calculated using cpair, while physics_update subroutine uses cpairv. (Checked it doesn't matter)

-I've tracked all temperature tendencies in the subroutines tphysac and tphysbc (physpkg.F90)
and found that
QRS + QRL is not equal to the temperature tendencies calculated by the subroutine radiation_tend

 

[hannay]

We checked the log file and QRS and QRL are k/s on history files. Which tag are you using?
You are running cam6, you have to use TTGW, not TTGWORO.


+++++++++++++++++++++++++++++++

I've looked for the temperature budget variables.

I've checked that
PTTEND is not equal to the sum of (QRS+QRL+DTCOND+DTV+TTGWORO)
because
QRS + QRL is not equal to the temperature tendencies calculated by the subroutine radiation_tend

I figured out that this is because
The actual unit of QRS, QRL is not K/s but K*(Pa)/s.

Temperature budget (state%dtdt) is calculated using qrs(i,k)/state%pdel(i,k), qrl(i,k)/state%pdel(i,k)

! convert radiative heating rates from Q*dp to Q for energy conservation
if (conserve_energy) then
!DIR$ CONCURRENT
do k =1 , pver
!DIR$ CONCURRENT
do i = 1, ncol
qrs(i,k) = qrs(i,k)/state%pdel(i,k)
qrl(i,k) = qrl(i,k)/state%pdel(i,k)
end do
end do
end if

While QRS and QRL variables are written without divided by state%pdel(i,k).

As a results
PTTEND budget is not same as the sum of QRS+QRL+DTV+DTCOND+TTGWORO

*** Maybe this is not a sole factor causing the difference, even though I divide the qrs and qrl by pdel some difference still existed.
If I get the QRS and QRL from the radheat_tend subroutine then the difference has been fixed.



Thank you,
Shim

 

[hannay]

I am extremely confused what your question is. You updated the question after I replied but you posted it as an update from: *updates on Oct 9th, 2019. So, I am not sure if you have all the answer you need or not (?)

 

[simchan_yook@colostate_edu]

I am extremely confused what your question is. You updated the question after I replied but you posted it as an update from: *updates on Oct 9th, 2019. So, I am not sure if you have all the answer you need or not (?)

Sorry for late reply, I did't realize that you've replied to this post.

1) I was using cesm1.2.2 not cesm2 so I've used TTGWORO.

2) My question was:
Temperature change (red solid line below) didn't match with sum of temperature tendency variables (blue solid line), while the sum of DTCORE and PTTEND (black dashed line) was identical to temperature.


3) And, I've found that this is because QRS and QRL were different from those used for calculating PTTEND.
QRS and QRL were originally written to output in /models/atm/cam/src/physics/rrtmg/radiation.F90,
but if I wrote them as an output from /models/atm/cam/src/physics/cam/radheat.F90 (after call physics_ptend_init(ptend,...)
then they matched with PTTEND and Temperature.

4) I thought that the difference might caused by unit conversion between Q <-> Q*dp , but it wasn't. (I first posted this article on October 7th, and tried several things to figure what's going on for a couple of days and updated some results on October 9th, which confused people... sorry)

I couldn't find real factor causing the bias but I just stopped there, because writing output of QRS/QRL in radheat.F90 rather than radiation.F90 worked for me anyway...

Thank you,
Shim

 

[simchan_yook@colostate_edu]

*** One additional note,

I've found that if I set the output frequency as model time step (1800 sec),
then QRS and QRL (original one from radiation.F90) are set to 0 for every even timestep.

 

[simchan_yook@colostate_edu]

I've realized that my problem was caused since 1) I wrote the output for each model time step, and 2) I used 'I' as an avgflag_pertape.

If I use an 'A' rather than 'I' as an avgflag_pertape in the namelist with write-frequencies longer than two model time steps, it seems like working well.
(I guess if I use 'I' avgflag then QRS and QRL is save only when the SW/LW radiation calculation is performed).

If I want to get an instantaneous value of QRS/QRL for each model timestep, I think writing QRS/QRL in radheat.F90 works better, but now I think I have all answers that I need and everything seems good... Thank you.

 

[hannay]

Thanks for the update.

 

[simchan_yook@colostate_edu]

Thanks for the update.

I've just realized that clear sky radiative heating rates (QRLC and QRSC) also have same issue.

Perhaps, SW/LW are calculated every two time steps (every odd-numbered timestep)?
Thus, the QRLC/QRSC value written in output every even-numbered timestep were always 0.

And, if I set up 'A' as an avgflag_pertape, they are average value of (value1, value2=0, value3, value4=0...) therefore, it results in half of the actual values (because the averaging includes all 0 values).

For example if, let's say the QRLC is:
1st time step: -0.1 K/s
2nd time step: 0 K/s
3rd time step: -0.2 K/s
4th time step: 0 K/s

And if I get an averaged output (with 'A' as an avgflag_pertape) for every 4 time steps,
I guess the correct results should be [(-0.1 K/s)+(-0.2 K/s)] / [2 * time steps] = -0.15 K/s per timestep
However, the actual output was -0.075 K/s per time step.

Again, sorry for the confusion, I've previously mentioned that QRS/QRL works fine if I use 'A' as an avgflag_pertape,
but I think this issue also occurs in the QRS/QRL, and therefore they are underestimating the heating rates...

Could you double-check whether current output for QRS/QRL/QRSC/QRLC variables are correct or not?
I'm worried that current averaged output of QRS/QRL/QRSC/QRLC variables may not reflect actual temperature changes by SW/LW...

Thank you,
Shim

 

[simchan_yook@colostate_edu]

Example of the QRS time-series.

 

[simchan_yook@colostate_edu]

I'm so sorry about hassle,
please ignore all the comments that I've made today, (I want to delete it to prevent further confusions but I don't know how to delete my comments...)

It turns out that I was confused and nothing is wrong with model code.
Again, if I choose 'A' as an avgflag_pertape for interval longer than 2 model timesteps, everything works well (probably the model internally doubles QRS/QRL/QRSC/QRLC for 'A' flag??).

I'll try to remove my "wrong" comments above...

 

[QINKONG]

We checked the log file and QRS and QRL are k/s on history files. Which tag are you using?
You are running cam6, you have to use TTGW, not TTGWORO.


+++++++++++++++++++++++++++++++

I've looked for the temperature budget variables.

I've checked that
PTTEND is not equal to the sum of (QRS+QRL+DTCOND+DTV+TTGWORO)
because
QRS + QRL is not equal to the temperature tendencies calculated by the subroutine radiation_tend

I figured out that this is because
The actual unit of QRS, QRL is not K/s but K*(Pa)/s.

Temperature budget (state%dtdt) is calculated using qrs(i,k)/state%pdel(i,k), qrl(i,k)/state%pdel(i,k)

! convert radiative heating rates from Q*dp to Q for energy conservation
if (conserve_energy) then
!DIR$ CONCURRENT
do k =1 , pver
!DIR$ CONCURRENT
do i = 1, ncol
qrs(i,k) = qrs(i,k)/state%pdel(i,k)
qrl(i,k) = qrl(i,k)/state%pdel(i,k)
end do
end do
end if

While QRS and QRL variables are written without divided by state%pdel(i,k).

As a results
PTTEND budget is not same as the sum of QRS+QRL+DTV+DTCOND+TTGWORO

*** Maybe this is not a sole factor causing the difference, even though I divide the qrs and qrl by pdel some difference still existed.
If I get the QRS and QRL from the radheat_tend subroutine then the difference has been fixed.



Thank you,
Shim

Hi,

Thanks Hannay for your answer and thanks Shim for your informative discussion which is very helpful.
I have a simple question about TTGW. Does TTGW represents temperature tendency due to vertical diffusion? Also, why people have to choose TTGW in CAM6 but TTGWORO in CAM5? What changed?

Thanks a lot!
-Qin

 

[simchan_yook@colostate_edu]

Hi,

Thanks Hannay for your answer and thanks Shim for your informative discussion which is very helpful.
I have a simple question about TTGW. Does TTGW represents temperature tendency due to vertical diffusion? Also, why people have to choose TTGW in CAM6 but TTGWORO in CAM5? What changed?

Thanks a lot!
-Qin

TTGW (TTGWORO) represents temperature tendency from orographic gravity wave drag. DTV represents temperature tendency due to vertical diffusion both in CAM5 and CAM6. I'm not sure about the updates in the gravity wave drag between CAM5 and CAM6 though...

 

[QINKONG]

TTGW (TTGWORO) represents temperature tendency from orographic gravity wave drag. DTV represents temperature tendency due to vertical diffusion both in CAM5 and CAM6. I'm not sure about the updates in the gravity wave drag between CAM5 and CAM6 though...

Thanks Shim. emmm, so physically, I should understand temperature tendency due to gravity wave drag as the effect of friction?

 

[simchan_yook@colostate_edu]

Thanks Shim. emmm, so physically, I should understand temperature tendency due to gravity wave drag as the effect of friction?

As far as I know, it is the tendency through parameterization of subgrid scale processes associated with subgrid scale surface roughness (including the gravity wave drag). I'm not sure whether it includes influence of large-scale friction or not.
For more precise information, you may want to read below:
McFarlane, N. A., 1987: The effect of orographically excited gravity wave drag on the general circulation of the lower stratosphere and troposphere. J. Atmos. Sci., 44, 1775–1800

 

[QINKONG]

As far as I know, it is the tendency through parameterization of subgrid scale processes associated with subgrid scale surface roughness (including the gravity wave drag). I'm not sure whether it includes influence of large-scale friction or not.
For more precise information, you may want to read below:
McFarlane, N. A., 1987: The effect of orographically excited gravity wave drag on the general circulation of the lower stratosphere and troposphere. J. Atmos. Sci., 44, 1775–1800

Yeah. My understanding was wrong! Thank you for pointing me to the reference!