- On all Windows versions to date, you can permanently adjust the editor screen size properties to produce an initial console size of at least 55 lines and request the operating system to remember that window size on subsequent executions. Check the "Properties" menus for the editor application.

- This problem can occur in two distinct ways:

In the most common case, your browser (and/or operating system) is caching the directory window information (and possibly even the displayed files themselves if you have downloaded them for viewing) and doesn't know they have been changed on the server. The extent and duration of this manifestation depends on your OS, Browser, and various user-controllable cache settings.

In this case, you should be able to view the newly created files on the server by clicking the "Reload Frame" button in the SeaSoft Log-in Bar area. Alternatively, select (click in) the frame displaying the errant information and, if this option is supported by your browser, use your browser's "reload frame" option (right-click for windows, control-mouse down for Mac).

In a far less common situation, an especially annoying bug in some versions of Microsoft Internet Explorer can prevent a newly modified SeaSoft data file (e.g., a SHIPDAT file) from being uploaded if the upload attempt is not the first one in a particular browser/login session. In these cases, IE fails to notice the change in modification time stamp of the new data file (this is a bug in affected versions of IE) and thinks it *already has* the selected upload file in memory from the previous upload. It then re-sends the old, cached, *pre-modification* copy. If this is happening to you, go into the IE preferences and turn off *everything* you can find related to "caching". In Windows IE, go to the "Advanced Tab" of "Internet Options" in the "View" menu to find these cache controls; there may be several of them. Disabling them all will usually solve the upload problem. Or, perhaps, try Safari, Firefox, Chrome, Opera.

- This is another browser-specific caching problem; a "reload frame" operation aimed at the directory window will usually solve the problem. Alternatively, open the directory frame in a new window, use your browser's "Reload" option on that window, close the window and re-access the log file.

- This depends on many factors including the specific program (e.g., Shipsim is much faster than SPMsim), user-specified output selections and the server load. Generally you should see results appear in your browser window within ten or twenty seconds, although in unusual circumstances, you might have to wait for a minute or more.

- Yes. See the "Batch_Processing_FAQ" (find it in the FAQ Library).

- The website should work seamlessly with any modern browser; you may have to enable client-side Javascript in your browser if it is not enabled by default.

- The *DAT data files are binary files and may therefore be handled differently by different browser/OS/user preference combinations. In any event, you will not be able to view any useful content when these files are opened in a browser window in the way you describe. So don't do it.

- You will need to configure your browser and/or operating system to treat SeaSoft output files, which have a ".stxt" suffix, as plain text files. This will result in the correct line terminators being chosen for your system. Check that your operating system has an application (such as Notepad) assigned to open files of type *.stxt. In ancient browsers such as Netscape, you can set this in the Edit menu by selecting Preferences/Navigator/Applications and editing the "Plain Text" data type to include both *.txt and *.stxt suffixes. In Windows, you can set it from the "file types" sub-menu of the "Options" sub-menu of the "View" menu of "My Computer" (on the desktop).

- See the answer to a related question above; you will need to tell your OS which application to use to open *.stxt files by default.

- There is no formal requirement that you clean/purge your directory when you are done. This capability exists only for those who wish an extra layer of security in protecting their data, or who are by nature tidy souls.

- This is largely for the convenience of the user. Many users prefer to use a dedicated text editor for program output files, for example to prepare the files for presentation, spreadsheets, plotting or otherwise processing the data. A unique file extension facilitates this kind of handling. You can use your operating system to map the *.stxt extensions so that they are opened by the editor of your choice.

- Again, this is for user flexibility, to allow scripts and other automated processes to distinguish input files from output files.

- When you exit the Editor program with an "E"xecute command or select the "Execute program in interactive mode" option on the last Editor page, a large amount of preliminary error checking is done before exiting the Editor. This checking is *not* done when you exit the Editor using the "Exit to operating system and update data file" option on that same page. Therefore, you should always quit the Editor with an "E"xecute command (e.g., by entering E<return> on any Editor page) so that these preliminary checks can be done locally and prevent a wasted round-trip to the server, where the same checks will be done and may produce a program failure.

- Abnormal termination can occur for many reasons. One of the most common reasons for failure of the web-based programs is that the Editor application version used to create or modify the data file is out of date. If this occurs, it will be indicated in the "Diagnostics.stxt" file (and also in the browser program completion notice).

Other failures will be more difficult to troubleshoot. Be sure you are exiting the Editor program using one of the "E"xecution options; this will cause rather extensive preliminary error checking to be performed by the Data Editor application. Also, examine the "Diagnostics.stxt" file carefully for clues to failure; every failure is flagged by at least a minimal notification in the Diagnostics file. Sometimes the message suggests a corrective course of action. If you have exhausted all resources including the various FAQs, on-line Editor help and, of course, the user manual, request assistance from SeaSoft.

- In our original implementation, we offered two access methods based on two independent Internet protocols (HTTP and FTP) for redundancy: if a particular operating system/browser combination proved problematic with one of these methods, there was an immediately available alternative. The increase in standards adaptation by modern browsers has rendered this redundancy superflous.

- The website processor now examines the filenames of submitted data files to determine which simulation(s) to run.

- The occasional catastrophic failure of offshore mooring systems is as inevitable as occasional failures of any other complex system such as commercial aircraft, nuclear power plants or the space shuttle. The job of the ocean engineer at any point in time is to reduce the likelihood of such a failure to the lowest practical level consistent with the technology available at that moment. As time passes and we learn ever more about optimal design for these systems, the frequency of failure will steadily decline. It will never, however, become exactly zero. Nature is too capricious.

- When you press the browser "Back" button in the situation you describe (immediately after clicking the "Execute" button in the sidebar), you re-send the execute command to the server; i.e., you effectively re-submit your execution request. Depending on the state of completion of your previous job, any of several things can happen, most of them bad or at least undesirable. Examples: A re-submission of a job that may have already completed; An interruption of a simulation in process causing a start-over, with unpredictable consequences (and, often corruption to your user logs). Using the "Back" browser button while a job is in progress is as problematic as out-of-sequence clicks in your sidebar area ("Execute", "Archive", "Tidy", etc.)

So, avoid using your browser's "Back" button, ESPECIALLY any time your immediately previous action in the window was a server directive (like "Execute", "Archive", "Upload", etc., i.e. any of the action buttons in your sidebar). In particular, inadvertent re-executions caused by this mechanism are billed to your account; there is no way to distinguish these unwanted "Back"-button related executions from legitimate execution requests.

Note also that should you "back up too far", by repeatedly clicking the "Back" button after a sequence of sub-directory clicks or file-viewing clicks, you may inadvertently back up into your most recent execution request, similarly causing the batch run to be re-executed. The "Back" button can be dangerous; use with care.

- The "Tidy" button deletes everything inside your current directory except *top-level* binary or text data files (e.g., "BatchTest.zip", MOORDAT, CURNTPROF.txt, etc.). Note: The "Account_Log.stxt" file in an exception; it is never deleted.

So, for example, if you have uploaded, along with your first *DAT file (e.g., MOORDAT) a set of supporting text-based datafiles (e.g., WINDCOFS.txt, CRNTCOFS.txt, USERRAOS.txt, DRFTCOFS.txt), "Tidy" will preserve all these uploaded files so that you can proceed to the *next* simulation by uploading only the file(s) that have changed (possibly, e.g., only the MOORDAT file). This prevents the need to upload the same supporting text files again.

The "Purge" button scrubs the entire directory, leaving only your running "Account_Log.stxt" summary.

- No. You may simply upload your new data and re-execute.

- That is entirely up to you. However, user directories are in a less-secure portion of the server storage area than the server operating software itself, since your directory is accessible to anyone with your username and password. Hackers and script-kiddies are everywhere these days and although we do our best, there can be no guarantee that your directory contents are absolutely secure against hacking attempts. If your data is sensitive, you should delete it when you are finished with your session.

- That depends upon whether you access our site using the "http" or "https" protocol; both are supported. That is, if you access the site using:

	http://seasoftsys.com

	https://seasoftsys.com

It is becoming common for large commercial sites to default to the https (secure) protocol for everyone. SeaSoft users are sophisticated and knowledgeable, and we feel they are capable of making their own choice in this matter.

One consideration: Using the http (unencrypted) protocol, your user name and password traverse the internet unencrypted (although your password is stored in an encrypted form on the server). This provides the most basic level of authentication (appropriately called "basic authentication" in the lingua franca of the Apache web server). It is therefore theoretically possible that a hacker "sniffing" your data stream could capture your username and password in transit and use it to access your account. This represents virtually zero risk to you as it would simply permit the attacker to execute SeaSoft simulations using your credentials, or view any data or files you had not "Purged" from your directory. Should such an unlikely scenario unfold, upon notification of the breach, SeaSoft would delete your account and you would be given a new account, username and password; there would be no charge to you for the unauthorized access or for the account re-assignment.

If your data is extremely sensitive (perhaps containing a proprietary mooring or vessel design), you should consider using https (secure) transport protocol for your access, and purge all data from your directory when you finish your work session.

- Because our security requirements are minimal, we do not normally permit a change of password. If you feel particularly strongly about this for some reason, just ask.

Should your account be "hacked", as discussed in a previous FAQ, we will simply issue you a new user name and password.