[RegCNET] solin

[XUNQIANG BI]

Hi, Jonathan:

I want to mention a few words firstly,

In the very code (RegCM2), the code use ktau (step count) and xtime 
(time count) to control the time. but unfortunately, after a long
time integration, due to the round-off error, xtime (real*8) becomes
strange, and ktau (integer*4) becomes negative. Which causes the model
out of control, It causes the restart inconsistency problem, and
sometimes it even fails to write out the results at the right time.

Then I figure a way to use 7 integer number (in Main/Commons/date.cb)

       integer ldatez,lyear,lmonth,lday,lhour,NNNNNN,NNBASE
       common /ctltime/ldatez,lyear,lmonth,lday,lhour,NNNNNN,NNBASE

and let them work togather with ktau and xtime, to replace the old way of 
time control function by just using ktau and xtime. The new way
works well.

In the latest version, xtime is just used as the count in every 6 hour
(in Main/tend.f, xtime is reset to 0.0 every 6 hour)
And ktau is just used as the count of step in every year,
(also in Main/tend.f, ktau is reset to 0 at 00GMT of YYYY010100).

But I get the other report (from kchow) that the present eccf formulae
might have problem if you not initialize (or restart) the run at 00GMT.
We haven't check this issue yet.

In ICTP, we almost always have the restart at 00GMT, so we don't have
this problem. But if you use RegCM3 as weather forecast purpose (not 
initialized or restart from 00GMT), then you need pay this attention.
Hope we could find a fix later.

On Tue, 8 May 2007, Jonathan Winter wrote:

> While comparing two runs, one using an older version (summer 2004) of
> the model that I had modified and the other a newer version (~ fall
> 2004) that has not been modified, I noticed a difference in solin, which
> is top of atmosphere instantaneous incident solar.  It didn't seem
> logical that this had changed between model revisions, so with some
> print statements I found the formulation of calday, which is used to
> calculate eccf (eccentricity factor) which in turn is part of the
> equation for solin, is different.  In the older version, it's:
>
> calday = dble(julday)+(NNNNNN-NSTRT0)/4. + (xtime/60.+gmt)/24.

The above one is correct. It's also the same in the latest
version. But you need double check if the NNNNNN and xtime
are reset every 6 hour. (actually every IBDYFRQ hour)

>
> but in the newer version (as well as in the latest release I think)
> it's:
>
> calday= dble(julday)+mod(NNNNNN-NSTRT0,4)/4. + (xtime/60.+gmt)/24.

The above line is wrong, I must say it's not in the latest version.
I wonder where you get this line of code, and where you got the version. 
If you got in subroutine getdat, then you're fine, because in getdat, 
calday is just used to calculate the local time. But if you got from
subroutine solar1, then it's a really BIG BUG in your version.

>
> The top statement seems to keep track of the calendar day correctly
> (where noon on Jan. 15 would be 15.5) while the lower seems stuck on Jan
> 1st with the fraction of whatever day it is (Jan. 15 at noon would be
> 1.5)  The difference in calday changes eccf which changes solin.
>
> Does anybody know why this was changed, which statement is right, and if
> it's the bottom statement, why?  Thanks in advance for the information.
>

Hope it helps,
Xunqiang Bi

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Dr. Xunqiang Bi         email:bixq at ictp.it
   Earth System Physics Group
   The Abdus Salam ICTP
   Strada Costiera, 11
   P.O. BOX 586, 34100 Trieste, ITALY
   Tel: +39-040-2240302  Fax: +39-040-2240449
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~