[RegCNET] ALERT - Potential problem in your RegCM set up

[FILIPPO GIORGI]

Dear RegCNETers

We wanted to alert you of a potential problem in your RegCM set up, which 
we just discovered. It concerns the calculation of the sun declination 
angle in relation to the length of the year in your boundary condition 
data.

The declination angle is calculated in Subroutine Solar1. If you go there 
you will find the variable "dayspy", which is the length of the year in 
days. The last version of the model on the web used a value of dayspy of 
365, i.e. it assumed all years are 365 days long, i.e. it assumes there is 
no leap year. If your boundary conditions have the leap year (as in ERA40 
or NCEP fro example), this means that the declination angle will 
incrementally lag for one day every 4 years of simulation. In other words, 
for example in a 10 year run, the lag will be 2.5 days, in a 30 year run 
12.5 days, 100 year run 25 days etc. 25 days lag time means that the 
declination angle is almost one month out of phase with the boundary 
conditions and this of course can cause a severe problem especially in the 
intermediate (spring and fall) seasons.

Now, you may or may not have a problem. This parameter has changed in the 
past since different global models assume different lengths of year (some 
have leap years, like ECHAM, some don't, like CCSM/CAM; some have 360 day 
years. like HADCM). So what you need to do is the following:

1) Go to Subroutine solar1.F and check the value of dayspy. The values 
should be

dayspy = 365       if no leap year is accounted for
dayspy = 365.24    if the leap year is accounted for
dayspy = 360       if every month is 30 day long

2) Check whether the LBC you are using have the same length of year as 
the dayspy value.

3) For future runs, make sure these values are the same.

4) For past runs, if these values are not the same you may have a problem.
    As I mentioned earlier, the problem is cumulative. In the case of the
    leap year inconsistency (one day every 4 years), you are likely not to
    have a substantial problem for relatively short runs (say up to 10-15
    years), but for longer ones you might. To check the extent of the
    problem you can re-run the last year with the proper dayspy value and
    compare with the original last year. Anyways, the first 10-15 years of
    your simulations could still be ok. You are well adviced to check all
    your runs, if at all possible.

5) This problem is zero-ed out every time you re-initialize (not re-start)
    the model, so if you have time slices instead of a long continuous run
    this is good, because the problem depends on the length of the time
    slice.

we apologize if this issue might have created you a problem. In the 
present version dayspy has been now set to 365.24, but, again, previously 
it was 365, so you should check since a lot of moedls used for LBC have 
the leap year. For the future we plan to actually have dayspy as an 
external parameter to be set by the user, so that the user does not forget 
to check its value,

good luck to all with this,   Filippo Giorgi and the RegCM team


################################################################
# Filippo Giorgi, Head                                         #
# Earth System Physics Section                                 #
# The Abdus Salam International Centre for Theoretical Physics #
# P.O. BOX 586, (Strada Costiera 11 for courier mail)          #
# 34100 Trieste, ITALY                                         #
# Phone: + 39 040 2240 425                                     #
# Fax: + 39 040  2240 449                                      #
# email: giorgi at ictp.it                                        #
################################################################