(back to Summer 07 Release Page)
Orbital Forcing
For the moment, control of the orbital forcing parameters is via the new local post-processing script orbital_parameters.sh. The variables defined at the top of the script need to be edited by hand to change the model behaviour:
Variable | Purpose | Default |
SC | Value of the solar constant, in W/m^2 | 1365.0 |
SEC_VAR_YEAR | If the solar forcing is to be fixed at a particular year (L_SEC_VAR=.FALSE.) and a calculation method is given (either L_SEC_VAR_ONLINE or L_SEC_VAR_FILE is .TRUE.) this is the year for which the fixed orbital parameters will be calculated | 2000 |
L_SEC_VAR | If .TRUE., orbital forcing will vary throughout the run based on the model year. If .FALSE., orbital forcing will be fixed at a certain year | .FALSE. |
L_SEC_VAR_ONLINE | If .TRUE. the model will calculate the required orbital forcing itself via the method of Berger78, as implemented in UM6.1 | .FALSE. |
L_SEC_VAR_FILE | If .TRUE. the model will calculate the required orbital forcing using data from the table specified in SEC_VAR_FILE | .FALSE. |
SEC_VAR_FILE | If L_SEC_VAR_FILE is .TRUE., this file will be used to calculate the required orbital forcing. It is a table of Year, Eccentricity, Obliquity and the Longitude of Perihelion Relative to the Moving Vernal Equinox, usually from one of the published calculations of the Earth’s orbit (i.e. Berger78, Laskar04) | $FAMOUS_ANCIL/solar_params_berger78 |
SEC_VAR_FACTOR | Acceleration factor for the orbital forcing. If L_SEC_VAR is .TRUE., the timescale of the orbital forcing will be reduced by this factor i.e. if set to “10″, changes in orbital forcing that would normally take 100 years will be applied over 10 years. | 1. |
With both L_SEC_VAR_ONLINE and L_SEC_VAR_FILE set to .FALSE., the model will default to a fixed set of parameters corresponding to the year 2000, as hardcoded into UM6.1. This is the default behaviour. If both L_SEC_VAR_ONLINE and L_SEC_VAR_FILE are set .TRUE. (should not occur) the L_SEC_VAR_FILE method will take precedence.
The Berger78 calculation implemented for L_SEC_VAR_ONLINE is valid for ± 1Myr. More recent calculations have provided values with some usable accuracy ± 250 Myr (i.e. Laskar04, although the values we want are probably only meaningful back to −65 Myr), which can be used by providing a correctly formatted table and using the L_SEC_VAR_FILE option.
Back to −1Myr there is very little difference between the various different tables/online method, except in the eccentricity, where Laskar04 values can differ by a few percent. Under the L_SEC_VAR_FILE method, the table is searched, line by line, from the top everytime a new value is required. Given the size of the full Laskar04 table, this can be quite a time consuming process, should one want to use a “realistic” time varying forcing for very old periods where the Berger78 method is inaccurate. If you really did want to do this, you’d be better off constructing a new table containing just the subset of dates required for the run.
(note: dates must go back in time down the table, as in the web-published Laskar04 data)
Different published calculations use different reference years as Year 0 - i.e. all dates in Berger78 are relative to 1950, whilst Laskar04 is relative to 2000. This is the year that should be put as the <offset year>. The published values can then be cut and pasted into the relevant column.
A. L. Berger, J. Atm. Sci, 35, 2362–2367 (1978)
J. Laskar et al., Astronomy and Astrophysics 428, 261–285 (2004)
http://users.skynet.be/erik.desonville/en/astro.paleo.htm (links to papers/data sets)
Long Filename Format
For the moment, control of the new filename format is via the new local post-processing script long_output_names.sh. The mod has been written such that any of the old filename formats specified by the UM is still available, but the script (as default) overrides the UMUI choice to specify the new “Absolute_verylong” format, not yet available through the UM. To use one of the old formats, simply disable this script. The new Absolute_verylong format overrides the UM date-coding conventions for the file names, and simply specifies the year as an 9 digit integer in the file name, with a “+” or “-“ at the end to signify whether it is an AD or BC date. For example: xbyvra@pyo71c1 becomes xbyvra#py000002471c1+