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:
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:
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:
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:
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
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 )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.0This 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
enddoA 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 doI 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