FAMOUS

(back to Summer 07 Release Page)

Instructions for new features

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:

VariablePurposeDefault
SCValue of the solar constant, in W/m^21365.0
SEC_VAR_YEARIf 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 calculated2000
L_SEC_VARIf .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_ONLINEIf .TRUE. the model will calculate the required orbital forcing itself via the method of Berger78, as implemented in UM6.1.FALSE.
L_SEC_VAR_FILEIf .TRUE. the model will calculate the required orbital forcing using data from the table specified in SEC_VAR_FILE.FALSE.
SEC_VAR_FILEIf 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_FACTORAcceleration 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+

Despite the capabilities of the long filenames mod, the current UMUI will not allow dates outside the range 0–9999. For the moment, dates outside this range must be specified by hand editing the run files.
For things like continuation runs to work correctly, the mod must also be applied to the small execs qxhistreport, qxcombine, qxpickup and qxsetup - i.e. they must be recompiled and the new versions specified for use in the model. Currently, the slightly fiddly recompilation must be done via the procedure outlined in UM users guide 4.5 section 3.3.8, page 56, and the new execs placed in the users local space on the machine running the model. The long_output_names.sh script also specifies the use of these recompiled small execs, which it assumes can be found in $HOME/famous/small_execs/exec on the computer running the model. This path can, of course, be changed if required. it is hoped that suitably altered small execs will be in place as defaults on FAMOUS-using UM installs sometime in the near future, rendering all this unnecessary
The long_output_names.mod also lets the UM use negative dates, so that actual paleo years can be specified. Currently, output file utilities based on conv.sh (including xconv) that convert these output files into other formats (i.e. netCDF) cannot cope with negative dates, so cannot be used on such files. This should be fixed shortly.
Page last modified on August 24, 2007, at 10:40 AM by Robin