Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

RRTMG scheme treats ozone data incorrectly

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.

t-banno

New member
Hi.
I'm using em_convrad test case on v3.9.1.1, and I have found a critical bug in the radiation scheme.
From v3.7, the default ozone input option has been changed to CAM (o3input=2) when using RRTMG.
However, this adaptation is incomplete, and ozone input data is almost zero on 12 a.m. in January 16.
Here's my understanding and quick solution. I hope this will be helpful.

In module_radiation_driver.F, ozone input is time-interpolated in the subroutine ozn_time_int:
Code:
SUBROUTINE ozn_time_int(julday,julian,ozmixm,ozmixt,levsiz,num_months,  &
							  ids , ide , jds , jde , kds , kde ,     &
							  ims , ime , jms , jme , kms , kme ,     &
							  its , ite , jts , jte , kts , kte )
This subroutine has two ozone variables: ozmixm, ozmixt. ozmixm is the input data from module_physics_init.F, and ozmixt is the time-interpolated data.
In module_physics_init.F, ozone data is read by subroutine oznini, included in module_ra_cam_support.F.
In subroutine oznini, ozmixm has 13 elements in time dimension, and monthly ozone data is stored in the 2nd to 13th elements, not in 1st element.

On the other hand, subroutine ozn_time_int assumes ozmixm has monthly ozone data in 1st to 12th element.
If it is January 16 now, intJULIAN = 16.0, fact1 = 0.0, fact2 = 1.0 in ozn_time_int, so interpolation is:
Code:
ozmixt(i,k,j) = ozmixm(i,k,j,12)*0.0 + ozmixm(i,k,j,1)*1.0
but ozmixm:),:,:,1) doesn't have any ozone data, so ozmixt becomes much smaller than reasonable values.

This time-interpolation code is originally from module_ra_cam.F, and there is a code bridging this index gap in it:
Code:
do m=1,num_months-1
do k=1,levsiz
do i = its,ite
ii = i - its + 1
ozmixmj(ii,k,m) = ozmixm(i,k,j,m+1)
enddo
enddo
enddo
while ozn_time_int doesn't have the counterpart.

A quick solution to this issue I think is to increment time index in interpolation code:
Code:
	  do j=jts,jte
	  do k=1,levsiz
	  do i=its,ite
			ozmixt(i,k,j) = ozmixm(i,k,j,nm+1)*fact1 + ozmixm(i,k,j,np+1)*fact2
	  end do
	  end do
	  end do
I have confirmed this code works correctly.

I also think this subroutine can't deal with leap year correctly, but it's another topic and not mentioned here anymore.

Thank you,
Takahiro Banno
 
Banno,
Thank you for the information. We will take a look at this issue and get back to you. It probably will take a while because we are on a business trip.
 
This problem will be fixed in v4.1 (next release?).

Ming, I've watched your pull request on GitHub repository. I'm poor at git repository, so thank you very much!

Best regards,
Takahiro BANNO
 
Banno,
I am sorry to get back to you late but this is because we are extremely busy with many issues going on simultaneously.
We have confirmed the problem you reported and the fix you provided has been adopted. The code will be corrected in WRFv4.1.
Thank you.
Ming
 
Top