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 5.2d 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 (6.9 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.
- 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.
- The Post Calculation Action ‘Skip Save’ setting, introduced in OrcaFlex 9.7c, is now supported. This enables specific results to be extracted and saved to a text file by a post calculation action after dynamics has completed. This avoids the need to save the whole simulation file if only a particular result is of interest. In this situation the feature will enable an increase in throughput of jobs since the time taken to save simulation files can be significant.
- Jobs can be cancelled using the dofcmd console program.
- There have been some changes to the job scheduling mechanism aimed at improving client utilization when processing batches of short duration jobs, particularly with prioritized clients. For higher capacity machines, more jobs are issued at a time and the threshold for recruiting lower priority clients has been lowered.
- There have been some improvements in the way the Distributed OrcaFlex Server manages the distributed clients and viewers. Previously when operating on congested or slow networks, or with large joblists, the DOF Server could take decisions that adversely affected the situation and could result in unresponsive clients and viewers, and jobs not being processed.