Using the ExtData/History tool: Difference between revisions
No edit summary |
No edit summary |
||
(2 intermediate revisions by the same user not shown) | |||
Line 14: | Line 14: | ||
:: | :: | ||
</pre> | </pre> | ||
The CAP.rc for each cases is a little different than the normal cap and looks like so. | |||
<pre> | |||
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 | |||
:: | |||
</pre> | |||
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: | |||
<pre> | |||
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 | |||
</pre> | |||
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. | |||
<pre> | |||
FILL_DEF:: | |||
PS time | |||
:: | |||
REF_TIME: 20040101 000000 | |||
</pre> | |||
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. |