Multiple input files

[kate]

As you may know, it is now possible in ROMS to use multiple forcing files, with each field being in its own file. The distribution ROMS does not yet support sequential files, with say one file per year of input.

Last year the UCSC people gave me some code to allow the sequential files. They coded it up for an OFFLINE_FLOATS option, where the output of one run is used to provide the environment for a floats-only simulation, using the climatology fields to do the time interpolation. This is in some ways similar to using LTRANS.

My branch of ROMS now has this OFFLINE_FLOATS capability with multiple climatology files. It would probably work with the forcing files as well. It might even be useful enough to warrant having it work even without having the OFFLINE_FLOATS option turned on - and put into the main ROMS code.

If you want to try the OFFLINE_FLOATS, make sure you set idTclm(xxx) in varinfo.dat for each tracer it wants beyond T and S (if any).

[arango]

Actually, this concept will be completely revised in ROMS 4.0 to allow OpenDAP access. The logic gets complicated to allow the restarting of adjoint-based algorithms, like 4DVar. The basic state files may get very large. So we need different strategy to split those files and access the split records when processing the basic state. A solution is to use object structures (numbers and strings) when processing such files.

ROMS 4.0 will include nesting, so the logic is complicated and several things were changed. I still don't know exactly when this version will be released yet. But I hope that it is soon. I have been working heavily on this over the last three months.