Using the ExtData/History tool

This page describes how to use the ExtData/History tool. This application allows the user to run either or both ExtData and History at predefined times, with multiple configurations in one execution. The application has a simple gridded component to make a grid and create either imports or exports for ExtData and History respectively and perform some functions that will be detailed below. The main application for this will be to test ExtData as we refactor it.

The application has the following modes that affect what the application gridded component does:

Generate Exports - Fill the export state with a predefined function

Fill Imports - Create some imports, up to ExtData to put something in them

Fill Exports from Imports - Create some exports and imports and fill the exports with the values of the imports. Obviously the names must match

Compare Imports - Create some imports, ExtData will of course try to fill. Compare the values in the import with a predefined function.

The application has a main CAP.rc file. This is a list of the CAP.rc for each case that will be run and looks like this:

CASES::
CAP1.rc
CAP2.rc
::

The CAP.rc for each cases is a little different than the normal cap and looks like so.

ROOT_NAME: Root
ROOT_CF: AGCM1.rc
HIST_CF: HISTORY1.rc
EXTDATA_CF: EXTDATA1.rc

BEG_DATE:     20040101 210000

JOB_SGMT:     00001200 000000
HEARTBEAT_DT:   3600

RUN_TIMES::
20040115 210000
20040215 210000
20040315 210000
20040415 210000
20040515 210000
20040615 210000
20040715 210000
20040815 210000
20040915 210000
20041015 210000
20041115 210000
20041215 210000
::

The CAP in the application will run a clock from the BEG_DATE for the JOB_SGMT length at a HEARTBEAT_DT interval. ExtData, History, and the application component only run at the times listed in run time. This is a bit clunky but unfortunately History uses alarms which will only go off if a clock advances. This is very unfortunate as it adds confusion to the application. The cap specified an AGCM.rc, ExtData.rc and History.rc for that instance.

An AGCM.rc for the application looks like this:

NX: 1
NY: 1

Root.GRID_TYPE: LatLon
Root.GRIDNAME: DC180x91-PC
Root.LM: 72
Root.IM_WORLD: 180
Root.JM_WORLD: 91
Root.POLE: 'PC'
Root.DATELINE: 'DC'

RUN_MODE: GenerateExports

EXPORT_STATE::
PS , time , hours , xy , c
::

FILL_DEF::
PS time
::

REF_TIME: 20040101 000000

You defined a layout, a grid, the run mode and the definition with how to fill the import/export state. The export/import state are filled from a table similar to the ACG we have in the model. You specify the variable short name, long name, units, the dimensionality 2D vs 3D, and whether center or edge.

You can provide a definition that will be used to fill the export state by providing a fill def section. For now the only thing this can do is fill the variable based on the time. Internal the component creates an internal variable called time and the value is the number of days from a reference date. Here is an example.

FILL_DEF::
PS time
::

REF_TIME: 20040101 000000

One possible use for this application could be to have CASE 1 of the application produce output via history and CASE 2 use that output as input for ExtData. Then we can compare what ExtData filled the import with against the computed values since we know in the previous case exactly what is in the files. For example we could use this to test if ExtDat is performing time interpolation correctly.