ARCSCM (ARCtic Single Column Model)
ARCSCM is the University of Colorado’s One-Dimensional (Single Column) Thermodynamic Atmospheric Model.
ARCSCM was designed as a testbed and developmental tool for parameterizations of
thermodynamic physical processes unique to high latitude climates. As such, ARCSCM includes
a mixed-phase microphysics package, predicts surface drag and heat fluxes consistent with an ice
covered surface, and is currently set up to be driven by SHEBA data. The surface boundary
conditions are read in from a data file assembled from the SHEBA ice camp, and the lateral
boundary conditions are supplied by the ECMWF single column data set, a data set specially
prepared for SHEBA single column studies by incorporating SHEBA raywinsonde profiles into
the ECMWF model. A host of information about these data, as well as numerous other
interesting products of relevance to arctic climatology and modeling can be found at:
www.joss.ucar.edu/cgi-bin/codiac/projs?SHEBA
Model Description.
ARCSCM uses a vertical grid of  coordinates defined by:
 ( p) 
p  pt
ps  pt
(1)
In (1) p is the pressure, pt denotes the model top, and ps denotes the surface.
The computational domain of the model consists of two arrays of gridpoints defined by
(1) that span the range of pressure levels between the surface and an arbitrary, user defined top
pressure level. At the surface
(ps ) 1
and at the model top,
( pt )  0 .
The first array is given the
name ‘sigma’ and includes both of these endpoints. Since these values of  require a flux as
boundary conditions, the 'sigma' levels are also referred to as the 'flux' levels of the model. For
consistency, all of the model fluxes are therefore computed on the ‘sigma’ grid. The second grid
is given the name ‘a’ and its values occur at the midpoints of adjacent ‘sigma’ gridpoints. The
values of the prognostic variables are forecast at the ‘a’ grid. The 'a' values are referred to as the
'variable' levels, and they represent the mean variable values between adjacent flux levels.
Architecture.
A diagram of the model architecture as well as the required boundary conditions is given
in figure 1 below.
ARCSCM Computational Domain, Boundary Conditions and Physical
Processes
SWdn
Model Top
p=pt
Top Boundary Condition
ARCSCM
Lateral Boundary Conditions:
u
,

(u )
t
Physical Processes:
Radiative Transfer
Cloud Microphysics
Cumulus convection
Variable level ('a')
Turbulent Diffusion
Flux level ('sigma')
Model
Bottom
p=ps
Ts, Qs, As, Ps, Hi, Es
Surface Fluxes
w'x' Bottom boundary Conditions
p = pressure
SWdn = Downwelling Shortwave Flux
u
= 3-D winds
(u )
= 3-D advective tendency of 
Ts = surface skin temperature
Qs = surface vapor mixing ratio
As = surface albedo
Hi = ice thickness
Es = surface emissivity
w’x’ = surface turbulent fluxes
Figure 1.
Boundary Conditions.
The top boundary condition, the downwelling shortwave flux, is computed in the
radiation parameterizations as a function of the solar zenith angle, which is calculated as a
function of the latitude, longitude, date and time of day.
The surface boundary conditions are read in from a data file consisting of surface
observations taken at the SHEBA ice camp. The surface drag and sensible and latent heat fluxes
can either be read in from the SHEBA data set, or can be computed in subroutines for
consistency with ARCSCM temperature and vapor profiles. Various subroutines have further
boundary conditions that must be satisfied, however they are internal to those subroutines and
will not be discussed further. The interested reader can consult the appropriate references for
additional information.
The lateral boundary conditions are provided by the ECMWF single column model data
set. The 3-D advective tendencies of specific humidity and temperature are given hourly at 31
levels of the atmosphere. ARCSCM users may either use the ECMWF 3-D advective tendencies,
which include the adiabatic temperature tendency, or they may choose to have the ECMWF
tendencies partitioned into horizontal and vertical components, use the horizontal components as
specified, and use the ECMWF vertical velocity to obtain vertical tendencies consistent with the
ARCSCM model fields. There are certian caveats associated with either prescription of the
vertical tendencies, so we leave this choice to the user.
At present, the ARCSCM wind field is prescribed completely from the ECMWF model
output.
Parameterizations.
The main purpose of ARCSCM is to predict the tendencies of temperature and all present
species of water at each of the ‘a’ gridpoints. The fundamental equations for the model are the
thermodynamic energy equation, and the conservation of water species equations. The thermodynamic energy equation can be written descriptively as:
dT T

dt t

Advect ion/ Adi abatic
T
t

Radiati on
T
t

Latent
T
t

Turbulence
T
t
(2)
Cum ul us
The conservation of water species equation can likewise be written descriptively as:
dq  q

dt  t

Advect ion
q
t

 mi crophysics
q
t

Surface_ Fluxes
q
q

 t Turbulence t
(3)
Cum ul us
In (2) and (3) T and q are temperature and water species mixing ratio, respectively. The
advection terms in (2) and (3), assuming (3) pertains to vapor, as well as the adiabatic heating
term in (2) are provided by the ECMWF single column model forcing data set. The rest of the
physical processes in (2) and (3) are calculated by the following physical parameterizations.
Radiative processes.
ARCSCM uses the NCAR CCM2 radiation scheme for the shortwave radiation
calculations, and can use either CCM2 or the RRTM scheme for the longwave.
References for the CCM2 scheme are:
Briegleb, B. P., 1992a: Delta Eddington approximation for solar radiation in the NCAR
Community Climate Model. J. Geophys. Res., 97, 7603-7612
------- 1992b: Longwave band model for thermal radiation in climate studies. J. Geophys.
Res., 97, 7603-7612
Ebert, E.E., and J. A. Curry, 1992: A parameterization of ice-cloud optical properties for
climate models. J. Geophys. Res. 97, 3831-3836.
The reference for the RRTM scheme is:
Mlawer, E. J., S. J. Taubman, P. D. Brown, M. J. Iacono and S. A. Clough, 1997:
Radiative transfer for inhomogeneous atmospheres: RRTM, a validated correlated-k model for
the longwave. J. Geophys. Res. 102, 16663-16682
Cloud Microphysics.
ARCSCM contains two moisture microphysics schemes, a simple scheme that removes
any excess vapor above saturation, and a bulk mixed-phase microphysics scheme that contains
prognostic equations for vapor, liquid, ice, snow and rain water mixing ratios. The latter
parameterization, the Reisner 1 scheme, was obtained from the NCAR MM5 model.
The reference for the Reisner 1 microphysics scheme is:
Grell, G. A., J. Dudhia, and D. R. Stauffer, 1994: Description of the Fifth-Generation
Penn State/NCAR Mesoscale Model (MM5). NCAR Tech. Note, NCAR/TN-398+STR, 138pp.
Cumulus Convection.
ARCSCM contains the Grell cumulus scheme, also from the NCAR MM5 model. The
reference for the Grell cumulus scheme is the same as for the Reisner 1 microphysics scheme.
The NCAR Tech. Note describing the cumulus and microphysics schemes, as well as
further information of interest is available on the web at:
www.mmm.ucar.edu/mm5/mm5-home.html
Planetary Boundary Layer.
The turbulent diffusion of passive scalars, heat and momentum is performed by the
Holtslag and Boville 1993 scheme. This package utilizes first-order closure with nonlocal eddy
diffusion coefficients, and a countergradient term for heat transfer during strong convective
events.
A reference for the Holtslag and Boville PBL scheme is:
Holtslag, A. A. M., and B. A. Boville, 1993: Local versus nonlocal boundary layer
diffusion in a global climate model. J. Climate, 6, 1825-1842
Surface Turbulent Fluxes.
The surface drag is calculated from a neutral drag coefficient which is a function of the
roughness length and a stability correction factor based on the bulk Richardson number. The
method for calculating the turbulent fluxes of heat and moisture is described in the following two
references:
Schramm, J. L., M. M. Holland, J. A. Curry, and E. E. Ebert, 1997: Modeling the
thermodynamics of a sea ice thickness distribution, 1, Sensitivity to ice thickness resolution. J.
Geophys. Res., 102, 23079-23091
Andreas, E.L., 1987: A Theory for the Scalar Roughness and the Scalar Transfer Coefficients over Snow and Sea Ice. Boundary Layer Meteorology, 38, 159-184.
ARCSCM Model Structure.
There are 5 different types of files that are needed to run ARCSCM, the '*.F' files the 'user.in' file
, the 'paramescm' file, the '*.cb' files and the '*.dat' files.
'*.F' files
The code that executes the simulation is contained in the following '*.F' files:
The file 'main.F' initializes the variables used in various subroutines and executes the
subroutine calls to time step the simulation through its duration.
The file 'tendencies.F' containes the subroutines 'tend' and 'update'. The subroutine 'tend'
calls the various physical parameterizations and computes the tendencies from their output. Then
subroutine 'tend' calls subroutine 'update' which updates the prognostic variables using the output
of 'tend'. Update is also where the model boundary values are updated by linearly interpolating
between the data at the hours that bound the current time step.
As a matter of necessity, there are simultaneously three different values of each of the
boundary variables; the '*1', '*', and '*2' variables. The '*1' and the '*2' variables are the values
of the boundary variables at the hours that bound the given model time which is usually
somewhere in between. The '*' boundary values are the values of the boundary variables
interpolated between the hour n and hour n+1 boundary data values. For instance, 'p1' might be
the pressure at hour 12, 'p2' might be the pressure at hour 13 and 'p' might then be the pressure at
hour 12 and minute 26. The prognostic variables are completely predicted after their assignment
during initialization, so no such need arises to establish '*1' and '*2' prognostic variables.
The file 'misc_subroutines.F' contains the subroutines for initializing the model, assigning
various model parameters, reading the forcing data, as well as other extranneous functions and
subroutines. The three subroutines in 'misc_subroutines.F' that are of primary interest to the user
are those that interface the model with the initialization and forcing data, subroutines 'init',
'getvar' and 'getadv', which will be discussed in a later section.
The remainder of the '*.F' files contain various physical parameterizations, whose
inclusion in a given simulation is specified in 'user.in'.
'user.in'
The file 'user.in' is where the user defines the endpoints of the simulation, chooses
between different subroutines, specifies the values of various model parameters, chooses the
stock output files, and defines the 'sigma' grid.
'paramescm'
The file 'paramescm' is where the user specifies the number of vertical gridpoints for all
of the model arrays, including the initialization and the boundary forcing data arrays. The
parameter 'kz' and its associates, such as 'kzp1', etc, are used to specify the size of the arrays in
ARCSCM and various of its subroutines. The value of 'kz' must be initialized to the number of
sigma coordinates minus 1. Hence, 'kz' is the size of the 'a' grid, and 'kzp1' is the size of the
'sigma' grid.
The parameter 'kzi' specifies the number of vertical gridpoints on which the initialization
data is provided. Likewise, the parameter 'kzb' specifies the number of vertical gridpoints on
which the boundary data is provided.
'*.dat' files.
There are 4 types of '*.dat' files that are required to run the model, those for initialization,
those for surface forcing, those for the ECMWF model fields, and those for the ECMWF advective tendencies.
The initialization files take the following form. The initial profiles of temperature and
relative humidity are in the 'month.input.dat', where 'month' can, at present, be april, may, june or
july. These initialization profiles use data obtained from the radiosondes, the 10m tower at the
SHEBA ice camp, and the ECMWF model, as the radiosonde values tend to jump around quite a
bit in the lowest ~50 meters, and sometimes terminate before reaching pt.
First a grid of 80 'a' values, as defined by (1) was established. Then the initial values af
temperature and relative humidity were obtained for each of the 80 'a' values via the following
procedure:
For each of the 'a' values below the first radiosonde reading above 50.0 meters, the
temperature and relative humidity are obtained by interpolating between that radiosonde reading
and either the surface, the 2.5 meter or the 10 meter tower reading, depending on which data are
available at the given time. Above the ~50 meter reading, the radiosonde values are averaged
between the ‘sigma’ values corresponding to the 'a' grid. For all 'a' values above the point at
which the radiosonde terminates, the ECMWF values are used. No radiosonde winds are
included in the 'month.input.dat' files, as the ECMWF wind values are deemed more reliable on
average than those given by the sonde. Hence the wind field is initialized from the ECMWF
model output.
Each of the monthly initialization data files contains profiles for each hour of the
specified month. The hourly profiles are obtained by linear interpolation between the 6 hourly
radiosonde/ tower/ECMWF profiles discussed above.
The CCM2 radiation scheme also requires the atmospheric aerosol initialization profile
'aerosol.dat'.
The advctive tendencies are contained in the 'month.ectend.dat' files, in which 'month' is
the three letter specifier for the given month, apr for April, may for May, jun for June, or jul for
July. These data files contain the the ECMWF advective tendencies of specific humidity,
temperature and the winds.
The ECMWF model fields are contained in the 'month_ecvar.dat' files. These files
contain the pressure and winds needed by ARCSCM at each of the 31 ECMWF model levels.
The values of the wind used throughout the simulation are taken from here, as are the pressure
values, which are used to interpolate the advective tendencies, also obtained at these pressure
levels, to the ARCSCM 'a' grid.
The SHEBA surface forcing data are contained in the 'newmonthshebasfc.dat' files.
The format of the various data files can be found in the 'Readme' files available on the ARCSCM
website.
*.cb files.
The '*.cb' files are the common blocks used by all of the ARCSCM files. The variables
exchanged between subroutines are declared and pased between subroutines in several common
blocks, each of which consist of variables that have similar functions to one another. For
instance, one common block holds constants such as the gravitational acceleration, the dry ir gas
constant, etc., another includes the variables that are explicitely predicted by ARCSCM, another
includes the time variables that run the simulation, etc.
Model Output.
The output files are specified in subroutine ’outputs’ in the file ‘main.F’. It is
straightforward upon inspection to alter the characteristics of the output files or to create new
ones. At present, nothing is written to the PBL output file.
Data Interfaces.
The remaining ARCSCM subroutines interface the various physical processes with each
other. Of particular importance to the user are the subroutines ‘init’, ‘getvar’ and ‘getadv’. Subroutine ‘init’ initializes the model fields, subroutine ‘getvar’ obtains the values of the surface
variables and the ECMWF pressure and winds, and subroutine ‘getadv’ obtains the advective
tendencies. These data are read in hourly. The values of these variables at the model time steps
are obtained by linear interpolation in subroutine ‘update’ as described previously.
Subroutine 'init':
This is the subroutine that initializes the ARCSCM prognostic and diagnostic variables.
These values of termperature and relative humidity are read in from the 'monthshebasfc.dat' files
then interpolated to the ARCSCM 'a' grid, as previously explained.
To obtain initial values for the rest of the atmospheric and surface fields and the advective
tendencies of temperature and specific humidity, 'init' calls 'getvar' and 'getadv'.
Subroutine 'getvar':
The SCM is currently set up to read in boundary data from files that contain one month’s
worth of data at an hourly interval. Hence, in both 'getvar' and 'getadv' there is a counter variable,
'nskp2', that is used to scroll through the data files. The variable 'nskp2' corresponds to the
number of hours into a given month for a given date and time. Therefore the value of 'nskp2'
instructs the program how far to read through the files to get to the data needed for startup. From
that point on, that data file remains open until the end of the given month, at which point the
previous month's data files are closed and the next month’s data files are opened.
This subroutine reads in the ECMWF variable values and the SHEBA surface values at the
appropriate hour of the simulation. The ECMWF pressure levels corresponding to its 'variable'
levels are read in, an ECMWF 'a' grid for those variables is defined according to (1), then the
ECMW wind values are interpolated to the ARCSCM 'a' grid from the ECMWF 'a' grid.
Subroutine 'getadv':
Subroutine 'getadv' is very similar to 'getvar'. The same counter variable, 'nskp2', instructs
the subroutine how far to read into the month long hourly advective tendencies. The tendency
data for each variable has two parts, called the total and the physical tendencies. The advective
tendencies (and the adiabatic tendency for temperature) are obtianed by subtracting the physical
tendencies from the total tendencies. The ECMWF 'a' grid from 'getvar' is used to interpolate the
ECMWF advective tendencies to the ARCSCM 'a' grid.
Interfacing ARCSCM to other data sources is straightforward upon inspection of the three
subroutines 'init', 'getvar' and 'getadv' discussed above.
Conducting a simulation.
Assuming that the initializaton and boundary data files are correctly interfaced,
conducting a simulation is straightforward. The three files which must be modified are 'user.in',
'paramescm' and 'main.F'.
'user.in'.
The endpoints of the simulation are specified as follows. The simulation will run from
‘idatei’ to ‘idatee’, where ‘idatei’ is the starting date and time, and ‘idatee’ is the ending date and
time. Each of these control variables have the format yy/mm/dd/hh where yy is the year (e.g. 98),
mm is the month (e.g. 05), dd is the day of the month (e.g. 16), and hh is the hour of the simulation in Greenwich time (e.g. 21).
The model time steps are also specified in 'user.in'. 'dt' is the model time step for the
prognostic variables, whereas 'trad' is the number of model time steps between calls to the
radiation subroutine. Since the radiation is the most computationally expensive parameterization,
increasing the radiation time step will substantially reduce the time required to coduct a
simulaton on a slower machine without significantly sacrificing the accuracy.
The choice of parameter values, the inclusion of subroutines, selection of the output files
and definition of the 'sigma' grid are all straightforward upon inspection of 'user.in'
'paramescm'.
As alluded to previously, the assignment of 'kz' must be equal to the size of the 'sigma'
array defined in 'user.in' minus 1. When interfacing with alternate initialization and lateral
boundary forcing data, 'kzi' and 'kzb' must likewise be altered accordingly.
'Main.F'.
In the beginning of subroutine 'output' the user may name the output files as follows.
The filenames are of the form ’prefix.suffix’ where the prefix is contained in the variable 'outfile'
and the suffixes are of the form ’.mean.variable’ etc., depending on the particular output file. For
example, to write an output file called 050100_050500_test.mean.variable, assign 'iovar' a value
of 1 in 'user.in', set the length of the variable 'outfile' to 18 and assign 'outfile' the string
'050100_050500_test' in subroutine 'output' in file 'Main.F'.
The fortran code may be uncompressed by typing 'tar -xvf ARCSCM.TAR'
The code may be compiled by typing 'makefile' and run by typing 'a.out'.
Questions.
Questions about ARCSCM can be sent via electronic mail to 'mirocha@colorado.edu'.
The output file '050100_050500_test.mean.variable' is included for confirmation that
your
version of ARCSCM is running properly with the default settings in 'user.in' and 'paramescm'.