- In your first example (MOORDAT + batch.zip), the single execution datafile takes precedence; in this case, Moorsim would be run on the MOORDAT file and the batch.zip file would be ignored. In your second example, the first datafile encountered by the operating system would determine which simulation ran, usually determined by filename ASCII-ordering.
Note that there is currently no way to process more than ONE uploaded file (either *DAT or batch.zip) per upload session, and no way to delete single files from the server. (Furthermore, no such capabilities are expected to be implemented.) Therefore, in your examples, after you retrieved your Moorsim output (first case) or Catsim output (second case), you would need to start processing from scratch (by purging your directory and re-uploading the datafile which was not processed: batch.zip in case 1 and SHIPDAT in case 2).
BatchTest.zip: <- Zipfile
Sample <- Top level directory
Case1 <- Second level directory
SHIPDAT <- Datafile
Case2
SHIPDAT
Then, on the server, I get the following directory structure after batch execution:
SeaSoft_Out
Sample
Case1
SHIPDAT (+ Shipsim output)
Case2
SHIPDAT (+ Shipsim output)
How can I eliminate the superfluous extra top-level "Sample" directory?
- You just have to start your zipfile from INSIDE your "Sample" directory. Like this:
BatchTest.zip:
Case1
SHIPDAT
Case2
SHIPDAT
Which will produce this:
SeaSoft_Out
Case1
SHIPDAT (+ Shipsim output)
Case2
SHIPDAT (+ Shipsim output)
- As your batch job progresses, the server will provide progress and limited success/failure information, looking something like this (for a submitted batchfile named "batch_0.zip"):
+++> Begins sample web browser window notification stream
Execution in progress; please be patient...
batch_0_Out/batch_0/Test_Study : ++> Processing SPMDAT
batch_0_Out/batch_0/level2/level3/semi : ++> Processing SEMIDAT
batch_0_Out/batch_0/level2/level3/spar : ++> Processing SPARDAT
batch_0_Out/batch_0/level2/level3/tlp : ++> Processing TLPDAT
batch_0_Out/batch_0/level2/moor : ++> Processing MOORDAT
batch_0_Out/batch_0/level2/spm : ++> Processing SPMDAT
batch_0_Out/batch_0/Cascade : ++> Processing SPMDAT
Batchfile Completion ** With Failures **
Click "View Listing" button in sidebar for directory refresh
Batchfile Completion ** With Failures **
Datafiles Found: ................. 7 [moorsim=1, semisim=1, sparsim=1, spmsim=3, tlpsim=1]
Normal Completions: .............. 4 [sparsim=1, spmsim=2, tlpsim=1]
Failure Totals: .................. 3 [moorsim=1, semisim=1, spmsim=1]
Corrupt or Missing Data Files: ... 2 [moorsim=1, semisim=1]
Elapsed CPU Time (sec): .......... 6
+++> Ends sample web browser window notification stream
Note that when runtime failures *are* detected, an additional textfile called "Failures.stxt" is produced which contains the location of failures; very useful for tracking down one or a few failures when batch jobs with 100+ submissions (i.e., 100+ sub-directories) are involved.
+++> Begins "Failures.stxt" example
Abnormal Termination in: ./level2/level3/semi Abnormal Termination in: ./level2/moor Abnormal Termination in: ./Cascade
+++> Ends "Failures.stxt" example
- That's right. To be safe, you should limit your directory names to alphanumeric characters and underscores. The handling of other non-alphanumeric characters is operating system dependent; in particular, the server currently runs on a Unix variant, for which spaces in directory and file names must be "escaped" if used. Best not to complicate your life; just use underscores for legibility if necessary ("SubDirectory_1", etc.).
- Individual execution times can vary from around one second to many minutes, depending on the server load during the period in question and on your specific datafile details (simulation specified, mooring complexity, environmental complexity, etc.) so no generalities can be made regarding end-to-end batch execution times. However, assuming all your submissions are roughly the same level of complexity (same simulation and environment with slight variations such as environment intensity or direction, or mooring layout adjustments), you may be able to obtain a useful estimate by running a subset of your full batch job and using the "elapsed time" provided in the resulting "Log-delta.stxt" file (also stored in your accounting file) to scale up to your full batch size. Thus, if a 5-run subset executes in 30 seconds, a 100-run batch job of very similar datafiles can be expected to require roughly 10 minutes (20*30 = 600 seconds), more or less.
- This is the incremental addition to your "Account_Log.stxt" running summary which results from the just-completed execution; it is produced to provide a quick review of the execution status. A portion of this file is also displayed in your browser window at the termination of each execution, but that screen-display information disappears when you reload your directory listing; preservation of this transient execution display data is the reason for the Log-delta.stxt file.
Similarly, if your batch run contained any failures (due to missing or corrupt data, or other types of premature simulation terminations), the path to each batch directory which produces problematic or incomplete executions is summarized in a "Failures.stxt" file as an aid to isolating and identifying the problematic data.
For batch runs, copies of both the "Log-delta.stxt" and the "Failures.stxt" files are also included within your SeaSoft_Out directory (and in the SeaSoft_Out.zip file if you archive the output for subsequent download).
- The server currently runs a version of BSD Unix, so the paths are given in UnixSpeak. In that convention, this notification:
Abnormal Termination in: ./level2/level3/ThunderHorse
refers to an abnormal termination in the directory "ThunderHorse", three directory levels below the top-level directory of your batch file. In Unix, that outermost (or "top-level") directory, from which the "Failures.stxt" directory paths begin, is designated by the path abbreviation "."
- The old files are silently overwritten by the newly uploaded data; this is reflected in the time stamp information. There is no warning provided to guard against the overwrite. This permits quicker turn-around; there is no need to "Purge" or "Tidy" your directory before starting a new upload data & execute cycle. The file time stamps are useful to help keep track of what is new and what is old.
- What you want to do requires a reasonably sophisticated level of scripting. People who do a lot of this typically populate a spreadsheet with a table of values they want to change (environmental headings and intensities, mooring line lengths, etc.) and then, using the scripting capabilities of the spreadsheet (or OS scripting capabilities such as DOS "BAT" scripts, UNIX BASH scripts, etc.), prepare a pure text datafile for each required execution, which text file contains only the keystrokes required to make the desired changes, exactly as they would be entered during an Editor session. That datafile is then "fed" to the Editor program (e.g., shipEdit) via a terminal command (a DOS terminal session under Windows, or a shell terminal session under Mac OSX). A nearby FAQ has a very simple illustration of the use of such a file.
Be aware that this is a serious undertaking; it will require many hours of effort for you to get proficient.
- First, we need to emphasize that this "batch" question relates to batch *modifications* of datafiles (e.g., MOORDAT files) on your *local* machine using a SeaSoft Editor (such as moorEdit). Such local "batch" activity (which is confusingly similar by name, but only peripherally related, to batch operations on the remote SeaSoft server) is distinct from "batch" jobs submitted to the server. See FAQs below for additional questions and examples about these local (client-side) batch modifications of data files.
This client-side batch processing capability was added to address a batch-processing issue with the many two-state "Toggle" data items in the SeaSoft input data stream. The "(B) Batch modify" option is functionally identical to the "(M) Modify existing" option *except* in the way the Editor programs handle access to "Toggle" data items.
It is hard to describe these changes briefly, although we will do our best further below. It is easier for you to just fire up an Editor or application, select the "B"atch modify option on the splash screen, page until you see any "Yes/No" toggle item, select that item and see what happens. Then, find another two-state toggle item that is NOT a "Yes/No" item, such as the "Computed/Specified" toggle on the "Vessel Period and Damping Specifications" Editor page and play with that. You'll see what it is all about.
In-depth:
Under the legacy "M"odify scheme, entering the item number of a toggle, such as:
30) Estimate current loads on mooring lines and risers ........ No
results in an immediate state switch of that item to:
30) Estimate current loads on mooring lines and risers ........ Yes
If the state of this item is *not* known in advance, as might be the case in a batch execution scenario, where many data files will be processed automatically and whose internal variables therefore may not be completely known, then the toggle item cannot be set to a desired value; it can only be *switched* from its existing (unknown) value to its toggled (but still unknown) value. The "B"atch modify capability corrects this handling of "Toggle"-type items by converting the legacy one-step data access for toggles into a two-step process: First select the item number, then supply, in response to a prompt from the Editor, a "1" or a "0" in the second step to achieve the desired, known, final state (regardless of the initial state of the variable). Using the above example, the two step process would look like this:
. .30) Estimate current loads on mooring lines and risers ........ No. .
Enter number of selection ("H" for help):___
[User, or batch script, enters 30 to access the item and produces the following:]
. . .
Enter number of selection ("H" for help): 30
Enter 1 for "Yes", 0 for "No":___
[User, or batch script, enters 1 at the prompt to achieve a "Yes" setting:]
. .30) Estimate current loads on mooring lines and risers ........ Yes. .
Similarly, the User or batch script could have entered a 0 at the prompt to achieve a "No" setting, regardless of the initial state of item 30.
To use this capability in a batch script, simply enter the "B"atch mode in your script, rather than the "M"odify mode, as the first Editor command. Handling of non-Toggle items is unchanged from the legacy procedure.
moorEdit < Mods.txt
works in both a DOS window and an OSX terminal window to execute the commands in my file "Mods.txt" using the moorsim Editor. "Mods.txt" might look like this:
b j2 8 0.5 l 4
It would be useful for me to be able to document within "Mods.txt" what the directives apply to. Is there any way to do that?
- Yes; you can use an exclamation mark *as the first character* for a comment delimiter on any line of your "Mods.txt" commands file, in both Windows or OSX/Unix, as illustrated below:
! >>> Comments ! Batch file for execution of Moorsim; created 6/3/2012 for project X b ! Change bottom friction coefficient to 0.5; item 8 of Editor page 2 j2 8 0.5 ! Exit Editor in silent mode l 4
Note: The "!" delimiter must be the *first* character of the comment line. Comments must *not* be appended to a directive or value as permitted in many scripting languages; i.e. DO NOT DO THIS:
j2 ! Jump page 2 8 ! Select friction coefficient item 0.5 ! Change friction coefficient
It will lead to unpredictable and probably unpleasant results.