[RegCNET] ALERT - Potential problem in your RegCM set up
FILIPPO GIORGI
giorgi at ictp.it
Mon Dec 1 15:25:59 CET 2008
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 #
################################################################
More information about the RegCNET
mailing list