source: lmdz_wrf/branches/LMDZ_WRFmeas/WRFV3/README.io_config @ 38

Last change on this file since 38 was 1, checked in by lfita, 10 years ago
  • -- --- Opening of the WRF+LMDZ coupling repository --- -- -

WRF: version v3.3
LMDZ: version v1818

More details in:

File size: 3.3 KB
Line 
1Run time control of IO stream variable sets
2
3For WRF releases prior to V3.2, state variables were associated with I/O
4streams at compile time via their entries in the Registry.  That will
5still work, and should still be considered the primary method for defining
6stream variable sets in WRF. This new capability allows users to add or
7exclude state variables from a history or input stream at run-time without
8recompiling.  Also, this can be done on a per-domain basis as well.
9
10Here's a quick sketch of how it is used:
11
12a) There are two new namelist variables in the time_control section
13of the namelist.input file.  The first is iofields_filename. This is a
14character variable, settable separately for each domain and defaulting
15to "NONE_SPECIFIED".  This is where a user can list the names of text
16files containing lists of variables to added/removed from history and
17input streams for that domain.  As with other namelist variables that
18have max_domains in their rconfig definitions, each domain does have
19to have an entry in the namelist.input file. You can set each entry to
20the name of separate definitions file for each domain, or some or all
21of them can be the name of the same file.
22
23The second namelist variable is a logical, ignore_iofields_warning,
24which tells the program what to do if it encounters an error in these
25user-specified files.  The default value, .TRUE., is to print a warning
26message but continue the run.  If set to .FALSE., the program will
27abort if there are errors in these user-specified files.
28
29b) The user-specified files, named as settings to the iofields_filename
30   in the namelist.input file.  The files contain lines associating
31   variables with streams.  Each line has the form:
32
33  op:streamtype:streamid:variables
34
35    op:          either + (plus) or - (minus) for adding or removing
36                 a variable
37    streamtype:  either i (input) or h (history) indicating which type
38                 of stream is being affected
39    streamid:    an integer between 0 and the number of streams (0
40                 represents main input or history)
41    variables:   comma separated list of variables
42
43Example.  The line:
44
45    +:i:5:u,v,w
46
47will add the U, V, and W variables to auxinput5.  Note for this example,
48these are 2 time-level variables so that, as with Registry-defined
49stream-associations, the designations apply to variables representing
50the highest numbered time level (U_2). See the file test/em_real/sample.txt
51
52These lines cannot be longer than 256 characters, but you can associate
53long lists of variables using multiple lines with the same op, streamtype,
54and streamid. You can have comments in these files by putting # on the
55line, causing the entire line to be a comment (even characters before
56the #).
57
58An implementation note: the mechanism is not very efficient at this
59point. Each variable listed involves a search through all the state
60variables in the grid.  That is still relatively quick - even a very
61long list shouldn't take more than a couple seconds -- and the lists are
62processed only once when a grid is allocated.  Even so, super-long lists
63of these run-time stream associations are mildly discouraged. In other
64words, use this as a mechanism to tweak the Registry I/O definitions or to
65get domain by domain specific behavior, but don't use it as a substitute
66for defining I/O definitions with state variables in the Registry.
67
Note: See TracBrowser for help on using the repository browser.