Distributed OrcaFlex is a suite of programs that enables networked, OrcaFlex licensed, computers to run OrcaFlex jobs as background tasks. Alternatively, Distributed OrcaFlex can enable a number of users to submit OrcaFlex jobs to a dedicated high capacity server.
Distributed OrcaFlex consists of three separate programs. A Distributed OrcaFlex client program runs on each machine that is to process OrcaFlex jobs (each client machine must have an OrcaFlex license). One machine on the network runs the Distributed OrcaFlex server program that coordinates the list of OrcaFlex jobs and allocates these to the clients. Finally, a Distributed OrcaFlex viewer program that displays the list of jobs and their current status (e.g. pending, running, completed etc.) and allows jobs to be submitted and stopped. The availability and job capacity of each client can also be managed from the viewer program. The viewer and server programs do not use an OrcaFlex licence.
To minimise the impact on a user's work the client program runs at a low operating system priority, this ensures that OrcaFlex jobs run in the background and give way to higher priority user tasks.
Downloading and Installing Distributed OrcaFlex
The latest version of Distributed OrcaFlex is 6.0a which can be installed by following these steps:
- Download DOF Manual.pdf which contains documentation for Distributed OrcaFlex including an installation guide.
- Download DistributedOrcaFlex.zip (7.7 MB), unzip the contents, and run the extracted file DistributedOrcaFlex.msi.
Note: The minimum supported version of OrcaFlex is 9.5
Note: The client runs as a Windows service, but will not run using the 'Local system' account. During the installation you will be prompted for a set of credentials for the client service to run under. We recommend that you create a new user, for example 'DOFUser', that can then be used for all installations of the Distributed OrcaFlex client. This user should be created before you begin the installation and only be used for the Distributed OrcaFlex client service. This user must have “Log on as a service” rights and have rights to read and write to all areas of the network filing system that jobs may be submitted from including the location of the default OrcFxAPI.DLL files. The "Log on as a service" right is normally set by group policy on the domain controller.
32/64 bit installation
OrcaFlex 9.6 introduced 32 and 64 bit versions of the OrcaFlex executables. In order to use the 64 bit OrcFxAPI.dll, a 64 bit version of the Distributed OrcaFlex client program must be used. The installation program gives you the option of running either the 32 bit or 64 bit version of the client.
Be aware that if you run the 64 bit version of the client then you will not be able to process jobs using 32 bit versions of OrcFxAPI.dll. So, if you need to process jobs with OrcaFlex 9.5 then you must run the 32 bit version of the client since those older versions of OrcaFlex are only available as 32 bit executables.
Once you are prepared to commit to OrcaFlex 9.6 and later you can start running the 64 bit version of the client. Note that you do not need to switch every single client on your network to the 64 bit version at the same time. It is possible to operate a mixed installation where you have some clients running 32 bit and others running 64 bit.
In order for such a mixed installation to work, the clients must be able to locate a version of the OrcFxAPI.dll that matches the architecture of the host process. So, a 32 bit client can only load 32 bit DLLs, and a 64 bit client can only load 64 bit DLLs. This issue is dealt with by means of directory naming convention. You must organise the directory that contains the OrcFxAPI DLLs like this:
OrcFxAPI.dll (the 32 bit version)
OrcFxAPI.dll (the 64 bit version)
So long as the two OrcFxAPI DLLs are arranged in this way, the 32 bit DLL inside a folder named Win32 and the 64 bit DLL inside a folder named Win64, the client program will load the appropriate DLL regardless of which version of the DLL is specified when submitting jobs.
- The major change in this release is the ability to have more than one DOF Client running on the same physical computer. This enables Distributed OrcaFlex to utilise properly 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, 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). 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, particularly beneficial 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 file server activity when jobs start or finish at the same time. This is enabled by default but can be disabled using a registry setting.
- This release fixes a bug in 5.2c which caused the DOF Server to attempt to restart a client's jobs if that DOF Client temporarily lost connection with the server (this could occur if the DOF Server was very busy). Although the job usually continued on the same DOF Client, the bug could lead to extended run times and occasional unnecessary restarts. Now the DOF Server waits 10 minutes after a client has disconnected before taking action.
- The Post Calculation Action 'Skip Save' setting is now treated the same way as in OrcaFlex, in that statics only simulations are also not saved after the Post Calculation Action is executed.
- There was a bug in the autosave feature introduced in the previous version, autosave files were not being used when jobs were moved between clients, causing the job to be restarted from the beginning rather than the save point.
- The DOF Client architecture (32 or 64 bit) is now displayed in the DOF Viewer client details list.
- Now supports saving VIV output files, added to the OrcaFlex API in version 9.8a.
- Job list data sent between the DOF Server and DOF Viewer is now compressed, this will improve the responsiveness of Distributed OrcaFlex when it is running large numbers of jobs.
- The working files and log files of the DOF Server and DOF Client are now saved in the Common AppData folder (usually C:\ProgramData\Orcina\DOF\) rather than the temporary directory for the Windows service.
- A user can now clear their own completed jobs from the job list rather than having to wait for the server to do this after the set number of days.
- The DOF Client used to be limited to saving 1 job at a time, but with no limit on loading jobs. This could result in long save queues building up (especially on very high capacity computers) and prevent new jobs being run until the save queue reduced. Now the default limit is 4 jobs at a time and applies to both load and save operations. This value can be altered with a registry setting, described below.
- It was possible to submit a .sim file and .dat file of the same model (filename) to DOF and they would be run as separate jobs. Depending on the order the files were run, changes made to the .dat file may be overwritten by re-running the older .sim file. Now these files are treated as duplicates and only one will be submitted, with preference given to .sim files, then .dat and finally .yml.
- There was a loophole in the handling of ‘unavailable’ clients when WakeOnLAN was enabled. These could remain in ‘sleeping’ mode and never get their status changed to ‘unavailable’ so preventing their removal from the list of clients in the Viewer. Sleeping clients are now all woken together rather than one by one which avoids this problem.
- A bug that was preventing OrcaFlex versions 9.5 to 9.7 from submitting a model to DOF from the file menu has been fixed.
- The DOFMaxNumberOfJobs registry setting for the DOF Client (which limits the maximum processor count) could be overridden by changing the value via the DOF Viewer. This is no longer possible.