Using vovwxd with Flowtracer


Altair Flowtracer manages the jobs in your flow to provide correct execution of each job with up-to-date inputs.

Jobs in your flow can run in several ways:

In the last case, these vovslaves are usually submitted to the batch system by a daemon process that runs in the context of your FT vovserver.  Several versions of these daemons are available

This article discusses how to set up Flowtracer to use vovwxd with an Accelerator batch system.


Change to the .swd of your Flowtracer instance, and make the 'vovwxd' subdirectory, if not already present.

You will need two files, a config file, and an adapter file.  You can find templates in $VOVDIR/etc/config/vovwxd/ for the batch systems that are supported by vovwxd, which include Accelerator, PBS, and LSF.

ft.swd/vovwxd > cp $VOVDIR/etc/config/{vovwxd/config,vovnc}.tcl .

You will need to edit the config file at least to specify the name of the base queue.

In many cases you can use the defaults for the adapter file.

Your FT slaves.tcl file will need a stanza to describe the WXLauncher vovslave, which submits 'vovslave' jobs to the base queue.

This stanza looks like this:

vtk_slave_define localhost -name "WXLauncher" -capacity 4 -resources "WXLauncher" \
    -slavetype "WXLauncher"
vtk_reservation_create slave WXLauncher 1 0 forever -jobclass LauncherClass

The reservation is to keep non-launcher jobs from running on the local machine.  You can find examples of setups for various types of VOV projects in $VOVDIR/etc/ProjectTypes/.   The example for Flowtracer is in the subdirectory named 'generic'.

Multiuser Mode

In mulituser mode Flowtracer jobs can change ownership. This requires the vovslaveroot executable. 

vtk_slave_define localhost -name "WXLauncher" -capacity 4 -executable vovslaveroot -resources "WXLauncher" -slavetype "WXLauncher"
For this to work, the sticky bit "s" needs to be set for the vovslaveroot.

> ls -l $VOVDIR/bin/vovslaveroot
-rwsr-xr-x 1 root admin 3966328 May 22 10:39 /usr/local/bin/rtda/2019.01u5/macosx/bin/vovslaveroot


Theory of Operation

As jobs enter the system, vovserver classifies them into buckets, so that all jobs in a bucket have the same attributes with respect to being dispatched, i.e. are interchangeable.  This way, vovserver's scheduler only needs to examine a representative job from each bucket to determine whether any jobs can be dispatched, and not all jobs in the system.

The daemon vovwxd monitors the jobqueue buckets in the FT vovserver, and when there are jobs needing to run, submits vovslaves to the base queue.   These vovslaves have the specific resources needed to run jobs in that jobqueue bucket.   They are submitted in an environment so that they connect to the FT vovserver to run jobs.  The vovslaves are submitted to the base queue by a 'launcher' job that runs locally in the vovslave named WXLauncher.