rts.xml
This page documents the tags available for use in FRE xml files.
______________________________________________________________________________
<!--
This is a comment in xml. You can put comments anywhere in your xml file
but only AFTER the <?xml version="1.0"?> line, which must always be the
first line of any valid xml file.
-->
<?xml version="1.0"?>
<!--
The <experimentSuite> tag should contain the <setup> tag and all of your
experiments. The "name" attribute is not used for anything at the moment,
you can leave it out if you wish.
-->
<experimentSuite rtsVersion="2" name="regression_test_suite">
<!--
The <setup> tag contains information that will be used for all experiments
below.
-->
<setup>
<!--
The root directory should be where your xml file is located. Within this
directory, a directory for scripts will be created. Also, fremake will
create a directory inside root for each experiment, and it will check out
code from the cvs repository into root/experiment_name/src.
-->
<directory type="root">$HOME/fms/jakarta</directory>
<!--
This specifies the base directory where frerun will create the output
directory tree. A directory for each experiment will be created here
for that experiment's archive output.
-->
<directory type="archive">/archive/$USER/fms/jakarta</directory>
<!--
This specifies the base directory where frerun will create the analysis
figures. A directory for each experiment will be created here for that
experiment's analysis figures.
-->
<directory type="analysis">/archive/$USER/fms/jakarta</directory>
<!--
This is the temporary directory to run the model in. GFDL users should
leave this line as is.
-->
<directory type="work">$TMPDIR</directory>
<!--
The platform determines the system-dependent templates which will be used for
compilation and running. Identify the target platform and any csh that should
be performed on script run on that target with
-->
<target platform="sgi">
<csh>
</csh>
</target>
<!--
Specifies the city release of FMS that your models are based on.
If you do not specify a <modelConfig> in the <cvs> section below,
this will be used as the tag for the first cvs checkout command.
This is used as the release argument to get_fms_data.
-->
<fmsRelease>khartoum</fmsRelease>
<!--
Optionally specify a project for the job.
-->
<project>-P omd</project>
<!--
the directory where FRE executables are located
-->
<directory type="fmsBin">/usr/local/fre/bin</directory>
<!--
the root data directory used by get_fms_data
-->
<directory type="inputData">/archive/fre/data</directory>
<!--
directories containing include files that should be used when compiling
-->
<directory type="include">/usr/local/include</directory>
<!--
your cvsroot
-->
<directory type="cvsRoot">:pserver:cvs@fms.gfdl.noaa.gov:/cvsroot/mom4</directory>
<!--
root location for backing up production runs. functionality in development.
-->
<directory type="backup">/archive/fre/backup</directory>
<!--
commands for working with a remote machine. available attributes:
uname - output of 'uname -m' on remote machine
get - analogous to 'cp' to remote machine
put - analogous to 'cp' from remote machine
prefetch - optional. like dmget; acquire data from tapes
perl - optional. if need a non-default perl executable path on remote machine
exec - optional. special string to use when running commands on a remote machine
-->
<remote uname="IP35" get="cp" put="cp"
perl="/usr/freeware/bin/perl5.6.1"/>
<!--
The following variables will be replaced by their appropriate values inside
the batchCmd string:
$defaultQueue - from <defaultQueue> below
$npes - as needed in script
$stdoutPath - if use this variable, compile stdout in $root/$name/exec/stdout
production run stdout in $archive/$name/ascii/$stdout
regression run stdout in $archive/$name/$runparams/ascii/$stdout
$project - from <project> below
$maxRunTime - as needed by script based on run parameters and maxRunTime below
only $npes is replaced in runCmd and debuggerCmd.
-->
<batchConfig>
<compile maxRunTime="00:30:00"
batchCmd = "qsub -pe $defaultQueue $npes -o $stdoutPath -r y -l h_cpu=$maxRunTime">
<defaultQueue name="ac.alloc"/>
</compile>
<run maxRunTime="08:00:00"
batchCmd = "qsub -pe $defaultQueue $npes -l cpuset -o $stdoutPath -r y $project -l h_cpu=$maxRunTime"
runCmd = "mpirun -np $npes"
debuggerCmd = "totalview mpirun -a -np $npes">
<defaultQueue name="lsc.alloc"/>
<altQueue name="lsc.windf"/>
</run>
<postProcess/>
</batchConfig>
<!--
Specify a non-default location for the mkmf utility.
-->
<mkmf>/home/fms/bin/mkmf</mkmf>
<!--
Specify a non-default location for the mkmf template.
You can specify a second mkmfTemplate with type="debug", which
will be used when you do "fremake -t" to compile a debug executable.
-->
<mkmfTemplate file="$HOME/templates/mkmf.template.mine"/>
<mkmfTemplate type="debug" file="$HOME/templates/mkmf.template.mine"/>
<!--
Specify a non-default location for the mppnccombine utility.
-->
<mppnccombine>/home/fms/bin/mppnccombine</mppnccombine>
<!--
Specify a non-default location for the get_fms_data utility.
-->
<getFmsData>/home/fms/bin/getFmsData</getFmsData>
<!--
This closes off the setup portion of the xml.
-->
</setup>
<!--
This starts a new experiment. The experiment name is a unique identifier
for the experiment, and will be used to name the output directory, which will
be located inside the archive directory specified above. Within the
<experiment> tag, you can use the variable $name to refer to this identifier,
but beware that if you like to copy and paste between experiments this can
get you into trouble.
-->
<experiment name="cm2_latest" >
<!--
This provides an official space to describe the experiment.
"frelist -v" will show experiment descriptions, but not xml comments.
-->
<description>
om2p2_smg plus am2p11.
</description>
<!--
The cvs section is used by fremake to check out code.
-->
<cvs>
<!--
The following two tags are used to construct the first cvs checkout command.
For example, the cvs command created here would be "cvs co -r latest mom4".
-->
<codeBase>mom4</codeBase>
<modelConfig>latest</modelConfig>
<!--
You can specify additional cvs commands in the <cvsUpdates> tag. This will
be executed in a unix shell, so you can also specify unix commands to
execute here.
-->
<cvsUpdates>
mv path_names path_names_mom4
cvs co -r latest {atmos_bgrid,atmos_coupled,atmos_param,atmos_shared,coupler,ice_sis,ice_param,land_lad,land_param,shared}
</cvsUpdates>
</cvs>
<!--
Compilation information is specified next.
-->
<compile>
<!--
cppDefs to use on the mkmf command line. The FRE also parses this
section to determine whether you are using libMPI or libSMA. This
information is required to set up the runscript, so this section is
required in your xml.
-->
<cppDefs>"-Duse_netCDF -Duse_libMPI"</cppDefs>
<!--
Providing a mkmfTemplate is optional. By default,
/home/fms/bin/mkmf.template.$targetPlatform will be used.
Specifying a mkmf template here will override the default as well
as any mkmf templates set in the setup section.
You can specify a second mkmfTemplate with type="debug", which
will be used when you do "fremake -t" to compile a debug executable.
-->
<mkmfTemplate file="$HOME/templates/mkmf.template.mine"/>
<mkmfTemplate type="debug" file="$HOME/templates/mkmf.template.mine"/>
<!--
Specifying the executable is optional and not recommended unless
you are using a pre-existing executable and do not plan to run
fremake. The default location is shown below.
-->
<executable>$root/$name/exec/fms_$name.x</executable>
<!--
If a path_names file exists in your code directory, it will be used
in the compilation. You may additionally specify files or directories
in the <srcList> tag, which will be given on the mkmf command line.
mkmf will give preference to code files given on the command line
before those in the path_names file. Therefore, if you specify
/home/user/newcode/mpp/mpp.F90
inside <srcList> and your path_names file contains
/home/user/fre/experiment1/src/shared/mpp/mpp.F90
then /home/user/newcode/mpp/mpp.F90 is the version that will be compiled.
Additionally, mkmf will give preference to those files specified first inside
the <srcList> tag.
-->
<srcList>
mom4/ocean_core
mom4/ocean_param/sources/shortwave/ocean_shortwave_pen.F90
mom4/ocean_param/sources/sponge/ocean_sponges.f90
mom4/ocean_param/sources/xlandmix/ocean_xlandmix.f90
mom4/ocean_param/mixing/sigma/ocean_sigma_diffuse.F90
mom4/ocean_param/mixing/neutral/ocean_neutral_physics.F90
mom4/ocean_diag
mom4/ocean_param/mixing/sigma/ocean_sigma_diffuse.F90
mom4/ocean_param/mixing/neutral/ocean_neutral_physics.F90
mom4/ocean_param/mixing/convect
mom4/ocean_param/mixing/horz/tracer/lap
mom4/ocean_param/mixing/horz/velocity/lap/smag
mom4/ocean_param/mixing/horz/velocity/bih/const
mom4/ocean_param/mixing/vert/kpp
mom4/ocean_param/mixing/vert/ocean_vert_mix.f90
mom4/ocean_param/sources/rivermix
mom4/ocean_param/mixing/polarfilter
</srcList>
</compile>
<!--
The next section specifies input files and namelists. If some of the
tags shown below do not apply to your run, you can leave them out.
-->
<input>
<!--
Namelists can be specified in multiple ways. You can specify files
containing namelists as follows.
-->
<namelist file="/home/fms/preinchon/cm2_l/input/namelist"/>
<!--
You can specify multiple <namelist> tags, all the namelist files
will be concatenated.
-->
<namelist file="/home/user/namelist1"/>
<namelist file="/home/user/namelist2"/>
<!--
Namelists can also be specified directly within the xml as
follows. Namelists specified in the xml take precedence over
those in files. Therefore, if ocean_model_nml is specifed both
directly, as below, and in a file, such as /home/user/namelist1
above, the values from the namelist specified directly in the
xml will be used. If you specify a namelist multiple times
directly in the xml, the first occurence will be used. frerun
will issue warnings if you attempt to specify a namelist multiple
times.
Do not use the ampersand or any other namelist formatting inside
the xml.
-->
<namelist name="ocean_model_nml">
momentum_ts_split = 1
freesurf_ts_split = 60
energy_diag_freq = 120
eta_ts_split = 1
debug=.false.
pressure_gradient_averaging =.false.
non_boussinesq = .false.
</namelist>
<!--
Following is an example of an empty namelist. It will be translated to
&ocean_rivermix_nml
/
in input.nml
-->
<namelist name="ocean_rivermix_nml"/>
<!--
coupler_nml is almost always specified within the xml, because it
is handy to view and edit the parameters. $months and $days will be
determined by the scripts based on the <runtime> information below and
the command line arguments you give frerun.
-->
<namelist name="coupler_nml">
months = $months,
days = $days,
dt_atmos = 1800,
dt_ocean = 3600,
dt_cpld = 10800,
current_date = 1982,1,1,0,0,0,
override = .false.,
calendar = 'julian'
</namelist>
<!--
Path to the grid_spec file.
-->
<gridSpec file="/home/ar/EXP/cm2_a10o2/N45_LON2OM2p2.nc"/>
<!--
Path to the initial conditions file.
-->
<initCond file="/archive/ar/EXP/cm2_a10o2/restart/1986jan01h00.cpio"/>
<!--
Path to the diag_table.
-->
<diagTable file="/home/fms/preinchon/cm2_latest/input/diag_table"/>
<!--
Path to the data_table.
-->
<dataTable file="/home/fms/preinchon/cm2_latest/input/data_table"/>
<!--
Path to the field_table. Multiple field tables may be specified as follows,
much like namelist files. All field_tables will be concatenated.
-->
<fieldTable file="/home/fms/preinchon/cm2_latest/input/field_table"/>
<fieldTable file="/home/user/field_table"/>
<!--
Datasets are listed with syntax as accepted as arguments to get_fms_data.
get_fms_data recognizes certain keywords like "amip1" and "lad".
You can also specify the full path to any file you want copied to your INPUT
directory. If you want to rename the file, use the form
/home/user/original_file=new_file_name
To view more information on available datasets and syntax, execute
'~fms/bin/get_fms_data' with no arguments.
-->
<fmsDataSets>-r inchon ggrpsst amip1 seaesf albedo lad topog
/home/wfs/FMS/ATMOS/havana/N45L18/AM2amip2/ch4_1650ppb_n2o_306ppb=id1ch4n2o
/archive/fms/om2/om2p2/preprocessing/omip_rotated_tau.nc=tau.nc
/archive/rgg/FMS/ATMOS/havana/N45L18/AM2p10+_i/LEG2/NETSW_clim.nc
/archive/rgg/FMS/ATMOS/havana/N45L18/AM2p10+_i/LEG2/WFLX_clim.nc
</fmsDataSets>
<!--
Within the CDATA section inside of the <csh> tag, you can specify any unix
commands you want run at the time the script is setting up the input data.
The commands will be run from the INPUT directory. The CDATA terminology
is part of the xml standard, and prevents greater-than and less-than signs
from being interpreted as denoting xml elements. It is good practice to use
it around all shell commands.
-->
<csh>
<![CDATA[
ncvarrename temp_sfc_restore.nc sst temp
ncvarrename salt_sfc_restore.nc sss salt
ncatted -h -a units,TIME,m,c,'days since 1899-12-31 12:00:00' tau.nc
ncvarrename temp_ic.nc TEMP temp
ncvarrename salt_ic.nc SALT salt
ncatted -h -a modulo,TIME,c,c," " hflux.nc
ncvarrename chl.nc CHL_A chl
]]>
</csh>
<!--
There are four categories of csh you can use.
-->
<csh>
<![CDATA[
#cshell to be run from INPUT/ at the beginning of each job
]]>
</csh>
<csh type="always">
<![CDATA[
#cshell to be run from INPUT/ before each mpirun command
]]>
</csh>
<csh type="init">
<![CDATA[
#cshell to be run from INPUT/ before the very first mpirun command of the first
job of the experiment only
]]>
</csh>
<csh type="postInit">
<![CDATA[
#cshell to be run from INPUT/ before each mpirun command EXCEPT the very first
mpirun command of the experiment
]]>
</csh>
</input>
<!--
Runtime parameters are described below.
-->
<runtime>
<!--
The following tags are used to specify regression test parameters.
Each set of regression runs is labeled with a name attribute. On the
frerun command line, you specify which set you want to run. For example
"frerun -r basic" would create a single runscript based on the <run>
tag inside <regression name="basic">. The sets "basic", "restarts",
"scaling", and "trapnan" are provided by default, and you can add your own.
frerun also recognizes the keyword "suite", which will create scripts for
all "basic", "restarts", and "scaling" tests.
Within the <run> tag, you specify several attributes. "npes" is the number
of processors the run should use. "runTimePerJob" is the time that the script
should be given to run. The simulation time is specified in the "days" and/or
"months" attributes. You must specify at least one of the two; they default
to "0". Specifying space-delimited numbers means that multiple mpirun commands
will be issued. For example, <run days="4 4"> means to do two four-day runs,
totaling 8 days.
This may look complicated but allows much flexibility in setting the run
length, which can be useful for testing purposes. For example, using
<run months="1 0" days="1 1"> would do a run of length one-month-and-one-day,
then a second run of length one-day.
The processor layouts will be parsed into the appropriate namelists.
-->
<regression name="basic">
<run days="8" months="0" npes="15" runTimePerJob="00:60:00"/>
</regression>
<regression name="restarts">
<run days="2 2 2 2" npes="45" atmos_layout="3,0" ice_layout="15,0" ocean_layout="1,10" runTimePerJob="01:00:00"/>
</regression>
<regression name="scaling">
<run days="8" npes="60" atmos_layout="4,0" ice_layout="15,0" ocean_layout="1,15" runTimePerJob="01:00:00"/>
<run days="8" npes="15" atmos_layout="1,0" ice_layout="5,0" ocean_layout="1,5" runTimePerJob="02:00:00"/>
</regression>
<regression name="trapnan">
<run days="2" months="0" npes="15" runTimePerJob="00:60:00"/>
</regression>
<!--
The following tags are used to specify a production run.
The production attribute "simTime" specifies the total simulation time, and the
only units currently supported for production runs are months and years.
Specify the number of processors with the npes attribute.
Each mpirun command will run one segment. The script's algorithm is to see how
many segments it can fit into a job based on the segment runTime you specify and
the length of a production job, then calculate how many jobs it will need to reach
the total simTime. The default production job runtime is 10 hours, but you can
customize that with the "runTime" attribute in the production tag. The maximum allowed
is 16 hours. You can find out the maximum requestable cpu time per HPCS node with the
command "ql".
IMPORTANT: Note that the postprocessing requires that the segment simTime be
1month, 6months or 1year. You can use other segment lengths, but the postprocessing
should not be used with other segment lengths.
The processor layouts will be parsed into the appropriate namelists.
The <peLayout> tag is optional.
-->
<production simTime="17" units="years" npes="45" runTime="10:00:00">
<segment simTime="1" units="months" runTime="01:00:00"/>
<peLayout atmos="1,0" ice="1,0" ocean="1,0"/>
</production>
</runtime>
<!--
Postprocessing can be performed using frepp.
This section is optional. If not specified, your multi-processor output will be
combined with mppnccombine but no further postprocessing will be done.
Postprocessing is currently done on an annual basis, so you must run at least one year
to create timeSeries and timeAverages. The segment simTime currently must be
1month, 6months or 1year to perform postprocessing other than just combining the files.
The sample postProcess section below is taken from Jeff Ploshay's am2p12c3yr experiment.
The component type is used as the name of the output directory as in
$archive/$experiment/pp/component_type/. Component types should be distinct,
so for example, you should only have one <component type="atmos"> in <postProcess>.
-->
<postProcess>
<component type="atmos_level" start="1983" source="atmos_month">
<timeSeries freq="monthly" chunkLength="16yr">
<variables> ucomp vcomp temp sphum liq_wat ice_wat cld_amt pres_full pres_half </variables>
</timeSeries>
</component>
<component type="atmos" zInterp="ncep" start="1983" source="atmos_month">
<timeSeries freq="3hr" source="atmos_8xdaily" chunkLength="16yr"/>
<!-- timeSeries freq="daily" source="atmos_daily" chunkLength="16yr"/ -->
<timeSeries freq="monthly" chunkLength="16yr">
<variables>
bk pk zsurf ps ucomp vcomp temp sphum omega slp hght
precip prec_conv snow_conv prec_ls snow_ls WVP LWP IWP rh
alb_sfc tdt_sw tdt_lw swdn_toa swup_toa olr swup_sfc swdn_sfc lwup_sfc lwdn_sfc
swdn_toa_clr swup_toa_clr olr_clr swup_sfc_clr swdn_sfc_clr lwup_sfc_clr lwdn_sfc_clr
tot_cld_amt high_cld_amt mid_cld_amt low_cld_amt
land_mask ice_mask wind t_surf tau_x tau_y shflx evap lwflx rh_ref t_ref u_ref v_ref
</variables>
<analysis switch="on" mode="batch" startYear="1983"
script="/home/jjp/rtspp_analysis/templates/atw_atmos_obsmod_ts_mon.csh"/>
<analysis switch="on" mode="batch" startYear="1983"
script="/home/jjp/rtspp_analysis/templates/atw_atmos_obsmod_ts_mon_anom_regr_NINO3.csh"/>
<analysis switch="on" mode="batch" startYear="1983"
script="/home/jjp/rtspp_analysis/templates/mjn_calc_regr_postprocess_rts.csh"/>
<analysis switch="on" mode="batch" startYear="1983"
script="/home/jjp/rtspp_analysis/templates/tg_mon_ts.diag.new.csh"/>
<analysis switch="on" mode="batch" startYear="1983"
script="/home/jjp/rtspp_analysis/templates/bjs_mon_ts.diag.csh"/>
<analysis script="/home/fjz/rtspp_analysis/templates/tk_stddev_temp_mon_ts.csh"/>
</timeSeries>
<timeSeries freq="annual" chunkLength="16yr"/>
<timeAverage source="monthly" interval="16yr">
<analysis switch="on" mode="batch" startYear="1983"
script="/home/jjp/rtspp_analysis/templates/sak_atmos_clim.csh"/>
<analysis switch="on" mode="batch" startYear="1983"
script="/home/jjp/rtspp_analysis/templates/primary_pjk_atmos_clim.csh"/>
<analysis switch="off" mode="batch" startYear="1983"
script="/home/jjp/rtspp_analysis/templates/supplemental_pjk_atmos_clim.csh"/>
<analysis switch="on" mode="batch" startYear="1983"
script="/home/jjp/rtspp_analysis/templates/tk_atmos_clim.csh"/>
<analysis switch="on" mode="batch" specify1year="1983"
script="/home/jjp/rtspp_analysis/templates/tk_lonvst.hpcs_rts.csh"/>
<analysis switch="on" mode="batch" startYear="1983"
script="/home/jjp/rtspp_analysis/templates/jjs_run_tstorms_rts.csh"/>
<analysis>
<addexpt switch="on" name="CM2.1N_Control-1990_c2"
xmlfile="/home/fjz/cm2.1/CM2.1N_Control-1990_c2.xml"/>
<script>"/home/fjz/rtspp_analysis/templates/sak_atmos_clim_2mods.csh"</script>
</analysis>
</timeAverage>
<timeAverage source="seasonal" interval="16yr"/>
<timeAverage source="annual" interval="16yr"/>
</component>
<component type="land" start="1983" source="land_month">
<timeSeries freq="monthly" chunkLength="16yr"/>
<timeSeries freq="annual" chunkLength="16yr"/>
<timeAverage source="monthly" interval="16yr"/>
<timeAverage source="seasonal" interval="16yr"/>
<timeAverage source="annual" interval="16yr"/>
</component>
</postProcess>
<!--
Marks the end of the experiment.
-->
</experiment>
<!--
If you want to base an experiment on another experiment, you can use the "inherit"
attribute as follows. In this example, all fields from experiment "cm2_latest" will
be used except for <namelist name="coupler_nml">, which will be overridden with
new values.
-->
<experiment name="cm2_new_time_step" inherit="cm2_latest" >
<input>
<namelist name="coupler_nml">
months = $months,
days = $days,
dt_atmos = 1800,
dt_ocean = 3600,
dt_cpld = 3600,
current_date = 1982,1,1,0,0,0,
override = .false.,
calendar = 'julian'
</namelist>
</input>
</experiment>
<!--
Marks the end of the xml document.
-->
</experimentSuite>
Generated by GNU enscript 1.6.1.