Altair Accelerator User Guide
This guide describes basic tasks in Accelerator, including submitting jobs, tracking job information, and analyzing and solving common problems.
The terminology in this release has changed from the previous one.
The Accelerator products are built on platform called vov using a client-server architecture with remote-procedure-calls (RPC). The server software module is called vovserver. It communicates to clients using the vov protocol; vovservers can also be configured to respond to http requests: the REST API is implemented on top of http. There are several different client types, those that make requests to the vovserver are typically implemented using vovsh (the vov shell - a Tcl interpreter); those that respond to vovserver requests to run jobs or tasks are taskers and the software here is called vovtasker. The vovtasker can run on the same host as the vovserver or on a separate host; these hosts are typically referred to as compute nodes, compute hosts or execution hosts.
The architecture allows for multiple vovservers to communicate with each other via a vovagent. Examples of vovagents include vovwxd, indirect taskers and vovlad.
In the 2021.1.0 release, the term slave has been deprecated and has been replaced with the term tasker. The web user interface and the online documentation have been updated to reflect this change, as has the majority of the code base. Subsequent releases will complete the transition.
Accessing Accelerator
- Web UI. Configuring Accelerator properties, and viewing job status, configurations, available resources and more is available through the Web user interface.
- GUI. Graphical user interface, independent of the Web is also available for graphical views of current job and resource statuses.
- CLI Command. Commands are also available for configuration, viewing the status of jobs and resources. GUI and WebUI can be invoked through CLI commands.
Theory of Operation
During the initial setup, the Accelerator host server, vovserver, establishes a main port for communication and additional ports for web access and read-only access. Afterwards, the vovserver waits for and responds to incoming connection requests from clients.
Clients consist of regular clients that request a particular service, taskers (server farms) that provide resources, and notify clients that listen for events. In addition to tasker-based resources, some clients provide central resources, which are stored in and tracked by the vovserver.
Regular clients can define jobs, or query data about jobs or system status. When a job is defined, it is normally placed in a scheduled state. Scheduled jobs are sorted into buckets. Jobs that have the same characteristics go in the same bucket. Buckets are placed in prioritized order for dispatching. This prioritization is based on FairShare, an allocation system. The top priority job in each bucket is dispatched when each of the defined resources (requests) for that job is available. The job requests can be fulfilled from the central pool as well as the tasker resources. When a tasker is found that completes the job's resource request, the job is dispatched to that tasker and the job status changes to running.
When the job has completed, the tasker notifies the vovserver. The resources, both tasker-based and central, are recovered, which allows subsequent jobs (queued in the buckets) to be dispatched. When completed, the job status is normally updated to either valid or failed.
As previously stated, in addition to dispatching jobs and processing their statuses, the vovserver responds to queries about system and job requests, publishes events to notify clients, and continues to process incoming job requests.
Known Limitations
In the Windows environment, PowerShell is not supported; it is strongly recommend to avoid using PowerShell.