Our batch capability expands on the legacy single-execution-at-a-time process. Note that the legacy method is still supported and in fact has been streamlined for situations in which more than one input file is required per execution (e.g., SPMDAT + LOWDAT + DRFTCOFS.txt + ...). Some of the material in this introduction can also be found in the "Batch_Processing_FAQ" on the SeaSoft server.
Using the batch process has a number of advantages:
* All SeaSoft data files (e.g., MOORDAT, SHIPDAT, LOWDAT, USERRAOS.txt, etc.) are highly compressible; jobs submitted as zipped batch files upload to the server *much* faster. (And, as a corollary, zipping the output using the "Create Archive" sidebar directive results in *much* faster and more efficient downloads of output.)
* The batch file processor detects and reports failed simulations so that problematic cases can be discovered and easily studied for issues.
* The batch file processor produces a useful catalog, suitable for historical archiving, of the jobs processed in each batch run.
* The batchfile submission process is extremely simple since all uploads to the server comprise a single zipfile. There are really only three rules:
a) The submitted batchfile MUST begin with the 5 characters "batch" and end with the extension ".zip". Examples: BATCH.ZIP, BATCH_test.zip, batch_test.zip, batch13.zip. (Letter case is unimportant; also allowed: dashes and underscores; specifically FORBIDDEN: all other non-alphanumeric characters such as commas, spaces, slashes, question marks, stars, parens, brackets, etc.).
b) Each simulation-specific "*DAT" binary data file (e.g., MOORDAT) must be contained within its own directory (this directory will also contain the associated simulation output at execution termination).
c) Just as was required for datafile submissions under the legacy scheme, *all* submitted MOORDAT, etc., files must first be processed locally on your local computer by updating (i.e., "Executing") them with the appropriate *current* SeaSoft editor program (e.g., moorEdit); current editor versions are always available on the website.
Note: People doing large-volume batch submissions will ultimately want to automate this preliminary-to-web-submission process with an operating system script on your client system to crawl down your batch directory tree, make the required editor changes and editor "Executions", and delete all unnecessary backup files (MOORBAK, etc.) resulting from the preparatory runs. The Batch_Processing_FAQ has some questions about, and primitive examples of, this process.
Additional considerations:
- Batchfile submissions can be arbitrarily complex in their directory structure (some simple examples are shown below), with support for multi-level nesting of directories. But don't get carried away...
- For the time being, we are imposing a limit of 200 executions per batchfile to avoid crushing the server. If this works out well, we may bump that in the future, and will try to accommodate special requests.
- As a matter of simple cross-platform good practice, you should also avoid directory names containing spaces, forward or back-slashes, parens, brackets, or other non-alphanumeric characters such as #, $, &. They may work for you, they may not. (Dashes - and underscores _, are safe *and encouraged* for legibility.)
- We believe that everything is case-agnostic; MOORDAT, moordat, mOoRdAt, etc., should all work. Still, this runs on a unix system which is case-aware, so keep your life simple by trying to stick with the caps conventions indicated in the upload file universe shown below.
The following examples pretty much exhaust the batchfile structural possibilities; given in increasing stages of complexity:
1. Single-execution batchfile containing all necessary input files:
You can put the principal datafile (e.g., MOORDAT) and any required supporting input files (LOWDAT, DRFTCOFS.txt, etc.) into a single batch.zip archive as shown below. Note that the universe of SeaSoft input datafiles is listed at the end of this note.
This first example simply duplicates the legacy website single-execution capability; the only difference is that all necessary datafiles can be gathered on your local computer, zipped and submitted to the server as a single batchfile (we're calling it batchTest.zip here) rather than uploaded separately as single files.
Note: Directories in all directory tree depictions below are designated by the suffix "_DIR" for illustration purposes. All other objects are files in these examples. Each typographical indentation represents a descent into the daughter _DIR directory.
batchTest.zip
batch_DIR
MOORDAT, LOWDAT, DRFTCOFS.txt
2. Multi-execution batchfile with every sub-directory containing *all* necessary input datafiles. This example includes 3 SPMsim submissions (each with differing support files), and 2 Slowsim submissions. The suggested organization of the directories is arbitrary; any organization whatever is permitted.
batchTest.zip
spmTOP_DIR
spm1_DIR
SPMDAT, USERRAOS.txt, LOWDAT
spm2_DIR
SPMDAT, USERRAOS.txt, CRNTCOFS.txt
spm3_DIR
SPMDAT, CRNTCOFS.txt, DRFTCOFS.txt
slowTOP_DIR
slow1_DIR
SLOWDAT
slow2_DIR
SLOWDAT, LOWDAT
3. Multi-execution batchfile with common input support files at the top level of the directory tree. This architecture eliminates the need for multiple copies of support files in every sub-directory of the batchfile.
In this example, the top-level USERRAOS.txt and DRFTCOFS.txt files will be used for all executions in all the sub-directories of the batchfile (one execution for each principal SPMDAT, etc., file found). If a top-level input file (e.g., USERRAOS.txt) *also* occurs *within* a sub-directory, the sub-directory copy will be overwritten *without warning* at execution time by the top-level copy. Any other sub-directory support file(s) (such as CRNTCOFS.txt below) that does *not* exist at the top level will only be used in the processing of its adjacent SPMDAT.
To reiterate: Using this scheme, the common datafiles MUST be at the top level of the directory tree exactly as shown. The lower-lying directory structure is at the user's whim.
batchTest.zip
USERRAOS.txt
DRFTCOFS.txt
spmTOP_DIR
spm1_DIR
SPMDAT, LOWDAT
spm2_DIR
SPMDAT, CRNTCOFS.txt < --- CRNTCOFS.txt will get used
spm3_DIR
SPMDAT, USERRAOS.txt < --- USERRAOS.txt will get overwritten
slowTOP_DIR
slow1_DIR
SLOWDAT
slow2_DIR
SLOWDAT, LOWDAT
Below is the Universe of all permissible SeaSoft input file types and names. Don't submit anything in a batchfile that isn't in this Universe.
** SeaSoft Datafile Universe **
>>> Simulation-created binary datafiles (simulation-specific)
CALMDAT
CATDAT
DISCDAT
MOORDAT
SALMDAT
SEMIDAT
SHIPDAT
SLOWDAT
SPARDAT
SPMDAT
STATDAT
TLPDAT
TOWDAT
>>> Simulation-created binary datafile (simulation-agnostic)
LOWDAT
>>> Externally-created text datafiles (simulation-agnostic)
++> Mooring line data (Comprehensive apps and Catsim)
LINE_STRAIN_DB.txt
++> Environmental spectral data
WAVSPEC.txt
CRNTSPEC.txt
WINDSPEC.txt
++> Vessel data (single-vessel simulations)
USERRAOS.txt
DRFTCOFS.txt
CRNTCOFS.txt
WINDCOFS.txt
++> Vessel data (CALMsim)
UBUOYRAO.txt
BUOYDRFT.txt
BUOYCRNT.txt
BUOYWIND.txt
UTANKRAO.txt
TANKDRFT.txt
TANKCRNT.txt
TANKWIND.txt
++> Vessel data (Towsim)
UTUGSRAO.txt
TUGSDRFT.txt
TUGCRNT.txt
TUGWIND.txt
UBARGRAO.txt
BARGDRFT.txt
BARGCRNT.txt
BARGWIND.txt
++> Offset data (Catsim)
INPUTOFF.txt