If any of the options for *_data_type are chosen to be anything besides 'none' or 'analytic', then the user must supply files that contain the appropriate data via the variables *_filename. All data files are currently assumed to be double-precision, direct-access files with each record having the dimensions of the full horizontal grid. The data is also assumed to be in a specific order that varies depending on the forcing formulation to be used. For 'annual' and 'n-hour' forcing, one occurrence of each forcing field should be in the file; for 'monthly-calendar' or 'monthly-equal' forcing, all 12 months of each field should be in the file. For example, if the heat flux is 'monthly-calendar' 'Barnier-restoring', and the horizontal grid is 172x128, then the forcing file should have data in the following order:
If the forcing is 'n-hour' then there needs to be a different file for each forcing time in the sequence. The files are assumed to be labeled by the date of the middle of the forcing period; and are of the form 'root.yyyy.ddd.hh' where 'root' is specified using *_filename, yyyy is the year (0000-9999), ddd is the day (001-366), and hh is the hour (01-24). Note that the dating convention is relative to year 0000, so results may not be what the user expects. For example, with wind stress forcing every 2 days (ws_data_inc = 48.), even number years will expect files dated on even days of the year, and odd days for odd numbered years (in the absence of leap years). Thus, the expected sequence of files at the end of year 1492 is (with ws_filename = 'ws'): ... ws.1492.362.00, ws.1492.364.00, ws.1493.001.00, ws.1493.003.00 ... because ws.1492.364.00 refers to forcing covering days 363 and 364 of year 1492, while ws.1493.001.00 refers to forcing covering day 365 of year 1492 and day 1 of year 1493. Makes perfect sense, doesn't it? It is possible to change the labeling date from the middle of the forcing interval to the beginning by changing a flag in the source code.