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