What's new in this version

New in version 8.0f

Bug fix

The date information emitted as part of DOF console list output was not correct.

New in version 8.0e

Console list output

The DOF console list all jobs command now has a more comprehensive output for both csv and yaml. This more closely matches the job details in the viewer program.

New in version 8.0d

Support for OrcFxAPI EnableMultipleOrcFxAPIPythonModuleSupport policy

OrcaFlex version 11.6 introduces a new policy named EnableMultipleOrcFxAPIPythonModuleSupport. This policy must be enabled for any process that hosts multiple instances of the OrcFxAPI DLL and which use embedded Python (external functions, post calculation actions, user defined results, etc.) The Distributed OrcaFlex client process is the canonical example of a process that needs to use this policy, and so it enables this policy for each OrcaFlex DLL that it loads. If you are using OrcaFlex 11.6, and process jobs which use embedded Python, you must upgrade Distributed OrcaFlex so that this required policy can be enabled.

One consequence of the EnableMultipleOrcFxAPIPythonModuleSupport is that any embedded Python code must not explicitly import the OrcFxAPI module and instead rely on it being imported implicitly. This can be inconvenient, so if your Distributed OrcaFlex installation can guarantee not to use multiple instances of the OrcFxAPI DLL (i.e. you only use a single version of the DLL) then you do not need to enable this policy. You can arrange for the client process to skip enabling the policy by adding a registry setting for each machine which runs the client process:

New in version 8.0c

List files

The DOF viewer now has support for list files. You can submit jobs from a text file containing a list of OrcaFlex files. These files can be generated from the main jobs page or the submit dialog.

Bug fixes

• Jobs which used embedded Python scripts which enabled the boolean data type policy would fail.
• Relative paths in a text file would cause the DOF viewer and DOF console to throw an error when adding jobs if Respect restart sequence was enabled, even if the file was not a simulation restart.

New in version 8.0b

Bug fixes

• If a DOF client was started in disabled mode, it would seem to respond to processor count changes in the DOF viewer but would not take on any jobs.
• If the DOF viewer was reopened from the taskbar notification area it would not get an immediate update from the DOF server until the next status action or forced update. This could be 3 minutes if DOF was idle.
• If a DOF client had its MachinePriority value set in the registry, this was not acknowledged by the DOF server when the DOF client was restarted.

New in version 8.0a

New job list views

There are now two tabs to view the list of jobs with different perspectives:

Active

The active list displays only the running or waiting jobs, the the same order as the job list in previous versions. However, it has a simplified interface for a quick overview.

Detailed

Batches of submitted jobs are now grouped together under the detailed tab. In this view, more information can be seen about particular jobs, and the order of jobs remains constant (sorted by age).

Batch actions

The new job list structure allows for actions that can be performed on a whole batch at once:

• Resubmit batch
• Cancel batch
• Pause batch
• Resume batch

High DPI

The UI elements of Distributed OrcaFlex now scale cleanly at any resolution, improving use with high DPI displays.

Status icons

Icons have been added to the job status for readabilty, doubling as a summary of the job list in the status bar.

Proxy client

Previously, each DOF client process on a large machine would communicate individually with the DOF server. To reduce the amount of network traffic, an extra client process is created as a proxy, which collates the messages sent from and recieved by each subprocess.

File operations throttle

In place of the ramping feature, a throttle on the total saving and loading of jobs can be set to reduce the strain on the file server. If the total file operations exceed a certain threshold, the clients will delay the file read and writes by a random interval.

Batch notifications

Users can now be notified when an submitted batch has completed. See batch notifications for more.

New in version 7.0a

Restarts

DOF can now handle simulation restarts

• Restart parents are identified in the DOF viewer when submitting a batch of jobs
• The DOF server will ensure that the dependency chain is run in the correct order if the Respect restart sequence check box is selected when submitting jobs
• When adding restart child models, you can automatically include the restart parents if you check the Include restart parents check box
• The child restart models must be .yml text data files

View more details

There are more specifics in the DOF viewer

• Full details for a selected job can be displayed in a pop-up window from the context menu
• Client machine details can be viewed in a pop-up from the context menu in the Clients page
• The server settings can be seen in a pop-up window by double-clicking the status bar

Optimisation

The speed of handling of the job status and progress messages in the DOF server has been improved

Client list

The list of clients kept by the server is editable

• Now saved in structured text format (yaml) file
• Can be edited to give a client an alias name for display in the viewer rather than its machine name

See the DOF server for more

Bug fixes

• If a client disconnected during communication with the server this would cause an error in the server
• A client could fail to provide a MAC address to the server which meant that the Wake on LAN feature would not work
• If a client was disabled whilst running jobs, these jobs were given a moving status but could block later scheduling to that client if other client machines were busy

New in version 6.2c

Previous versions supported both 32 and 64 bit versions of the client. Starting from 6.2c, only the 64 bit version is supported.

New in version 6.2b

Bug fixes

• A bug in version 6.2a resulted in simulations not being able to resume from a paused simulation file. This situation occurs when a running simulation is manually paused from the DOF viewer, or the simulation is auto-paused by DOF as a result of being moved between clients (for instance if the processor count is reduced on a DOF client). The DOF client saves an interim sim file that is reloaded when the job is continued on another machine. The bug resulted in the reload of this sim file being handled incorrectly and the simulation was then marked as Completed with the message no analysis performed.

New in version 6.2a

Previously, when submitting jobs, you specified whether you wanted both statics and dynamics to be performed, or just statics. Starting in OrcaFlex 11.1 the input data specifies whether statics and/or dynamics are to be performed. Because this setting has been moved into the model data, it is no longer possible to make this choice when submitting jobs in Distributed OrcaFlex. However, it is sometimes useful to be able to skip dynamics even if it is enabled in the input data. A new skip dynamics option has been added to the submit job dialog which mirrors the identically named option on the OrcaFlex batch processing form.

The console program (dofcmd.exe) can now list jobs in both yaml and csv format. Previously only csv format was available.

Jobs with post calculation actions would sometimes be restarted by the server if the post calculation action spent too long processing without sending a progress update. This release fixes that issue, but also requires that the Python OrcFxAPI module is updated.

New in version 6.1a

There have been some minor operational changes within the DOF client and DOF server designed to reduce incidents of submitted jobs becoming stuck in a scheduled state and not running.

When a DOF client disconnects from the DOF server it is now listed in the DOF viewer as Disconnected rather than Sleeping or Unavailable since the DOF server has no knowledge of the actual cause of the disconnection.

Wake on LAN is now not enabled by default. This relies on the WOL feature being enabled in the client computer’s BIOS which is usually disabled by default.

New in version 6.0d

A new Orcina logo.

Adds a small delay between starting DOF client processes running on the same machine (computers with large core counts may start more than one DOF client). This is to allow more time for the DOF server to add each client as it connects.

Supports a new external function attribute (CanResumeSimulation) that was added in OrcaFlex 10.3a to identify functions that do not save their processing state correctly (often they are using code provided by a third party). This means the simulation cannot resume from a partially run state and consequently DOF will not auto-save the model. If DOF is required to pause or move one of these models then the DOF client will ignore this and continue running the simulation. This only applies to models run with OrcaFlex DLL version 10.3a or later, with earlier DLL versions the simulation will paused, moved or auto-saved as normal, but it will not resume correctly if using such an external function.

The default setting for writing the job list to a file has changed from automatically writing this file to not writing this file unless the registry setting DisableListPersistence is set to false. The job list can be large and impose a performance penalty when the DOF server is busy. It is also a potential source of error when restarting the DOF server. A consequence of this change is that when the DOF server restarts, any record of pending jobs is lost and they will need resubmitting.

The DOF server also used to write completed job details to a completion log (JobLog.txt), this log will not be written automatically unless specifically enabled with the DisableCompletionLog registry setting.

New in version 6.0c

Bug fixes

• Sometimes, in the event of an error, the DOF server would produce a cascade of error reports that made the DOF server unresponsive for a while. This is now resolved, the DOF server reports all errors to the DOFServer.log without generating any further error files.
• When sending jobs to DOF using dofcmd, a value of 0 (= disable autosaving) for the Autosave interval was not allowed, when this is actually a valid interval.
• If the DOF server is restarted while some jobs are still running on clients, then those jobs could end up being cancelled rather than re-added to the job list to continue as normal.
• If jobs were submitted whilst the DOF server was already distributing jobs to DOF clients then the scheduler ramping feature was re-initiated. Now the ramping feature only starts if the jobs are added when the DOF server is idle.

In the client list view of the DOF viewer, the list columns are now resizeable.

New in version 6.0b

Bug fixes

• At startup, a DOF client machine running multiple client processes would appear in the DOF viewer with a low processor count rather than the true total for the machine. A related problem was that setting the client’s processor count to None through the DOF viewer had no effect.
• If an error occurred in the DOF server caused by a repeating problem (such as a communication error), then multiple error reports were created that could fill the C:\ProgramData\Orcina\DOF directory, and prevent the DOF server from responding to the DOF clients and Viewer.
• When adding small job batches, these may be all scheduled and queued locally to a small number of DOF clients, leaving other clients idle that should be sharing the processing.

New in version 6.0a

The major change in this release is the ability to have more than one DOF client program running on the same physical computer. This enables Distributed OrcaFlex to utilise all the processor cores on a computer that has processor groups – generally large capacity servers. A DOF client process starts per processor group to give full utilization, and optionally the number of DOF clients can be set higher than this. This will also benefit models using Python external functions or post-calculation actions as there will now be a Python interpreter per DOF client process, reducing the impact of the processing bottleneck the Python Interpreter introduces.

Jobs can now be manually paused and resumed from the DOF viewer. A paused job will remain so until resumed by the user from the DOF viewer.

DOF server functions that automatically move jobs between clients have been removed. This includes forcibly pausing and moving one user’s jobs to make way for another user’s, and moving jobs from slower to faster computers towards the end of a batch run. In the previous version of DOF these functions were disabled by default. These functions offered only limited benefits and in some cases unnecessarily moved jobs. Removing the functions allows for a more streamlined server. The new manual pause and resume feature can be used to achieve the same ends.

You can optionally choose to set up the DOF server to operate as a straightforward batch processor (using a registry setting). In this mode, processors are not shared between users, instead jobs are run in the order they are submitted to DOF.

Each DOF client has a small queue for buffering pending jobs sent by the DOF server. This reduces the time between finishing one job and starting another. This will improved throughput for shorter jobs.

Processing of new job batches is ramped up slowly (over about 2 mins). This smooths the job throughput by preventing a spike of jobs saving and starting at the same time. This feature is enabled by default but can be disabled using a registry setting.