Using vovwxd with Flowtracer - Altair Community

Overview

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 a vovslave running locally on your workstation
In a batch system via an 'indirect vovslave' integrated with Tcl procedures
In vovslave submitted to a batch system, that connects back to your FT vovserver

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

vovelasticd, for Accelerator batch system
vovlsfd, for LSF batch system
vovwxd, for Accelerator+, adapted to the batch system by a config file

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

Configuring

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.