Subject: (none)
From: Gerhard Gross (gery@global.phy.pdx.edu)
Date: Thu May 01 1997 - 16:11:17 MDT
I hope this is not a dumb question but I'm afraid I may be
missing something obvious. It concerns putting a tracer in
the model as a constituent and what happens to it depending
on whether it is updated every time step or only when 'dosw'
is TRUE (IRADSW = -1; every third time step).
It seems that the tracer mass mixing ratios behave predictably
when the source/sink array is updated every time step.
But the behavior baffles me when the source/sink array is
updated only every third step. The tracer mass mixing ratios
take on strange values in this case.
I tested this by putting the following code in 'tphysac.F'
and increasing 'PCNST' in 'params.h' from 1 to 2.
This block goes at line 201, just before 'qnm1' is updated
in 'tphysac.F':
> if(dosw) then
> if(nstep .ne. 0 .and. lat .eq. 1) then
> x = x + 0.05
> end if
> do k=1,plev
> do i=1,plon
> srcsnk(i,k,2) = (x - qm1(i,k,2))/ztodt
> end do
> end do
> end if
The following support code goes at the top of the subroutine
somewhere:
#include <comtim.h>
> real x
> data x / 1.0 /
> save x
Now I set these namelist parameter in 'nl.init':
> SETTRACE = 'zero'
> DTIME = 1200.
> NELAPSE = 7
> NHTFRQ = 1
> IRADSW = 1
> IRADLW = -1
> IRADAE = -12
> NINAVG = 'A'
> PRIMARY = 'TR02'
If I run this with 'IRADSW = 1' as above then the added block
in 'tphysac.F' is executed every time step and the value of the tracer
'tr02' in the output history file increases by about 0.05 every
time step, as expected. The global volume weighted averages for
each of the 7 time steps are (expectedly):
> 0.000000000000e+00
> 1.000759903399e+00
> 1.050795962505e+00
> 1.100833233991e+00
> 1.150872395173e+00
> 1.200910160643e+00
> 1.250947574085e+00
> 1.300984801100e+00
Now if I limit the new code in 'tphysac.F' to run only every
third time step by setting 'IRADSW = -1' in 'nl.init' then
the history file output data for 'tr02' is not
consistent. The global volume weighted averages are:
> 0.000000000000e+00
> 1.000759903399e+00
> 1.200910652480e-01
> 8.950778428355e-01
> 2.224325544118e-01
> 9.513926867109e-01
> 3.099077206379e-01
> 9.218697279688e-01
The direct effect of doing this is just setting the 'srcsnk'
array values to zero every two out of three time steps
('srcsnk' is reset to 0.0 at the top of the subroutine).
I would expect that the constituent values remain unchanged
from the last time step if the 'srcsnk' values are zero.
It seems as though something drastic is happening to the
values in the 'qm1' array between calls to 'tphysac.F'.
I suspect this may be due to the time step leap frogging
scheme used by CCM, but even that does not seem to explain
this.
I'm running this on a SUN single processor machine (ULTRA 1)
at T21 resolution.
Can someone please shed some light on this for me?
Thank you very much.
Gerhard Gross.
This archive was generated by hypermail 2b27 : Thu Jun 01 2000 - 09:10:58 MDT