Change the Config File at Run Time
The SDS configuration may be changed while the server is running.
View new features for Accelerator 2021.1.1.
Discover the available Altair Accelerator guides.
Discover Accelerator functionality with interactive tutorials.
Basic tasks in Accelerator, including submitting jobs, tracking job information, and analyzing and solving common problems.
Configure and manage the use of Accelerator after it is installed.
Accelerator documentation is available in HTML and PDF format.
Accelerator has two main commands, nc and ncmgr.
To regulate access to Accelerator, the security file vnc.swd/security.tcl must be edited. To deploy the changes after editing the file, Accelerator must be reset.
It is a recommended best practice to employ change control on your project configuration files.
Once the Accelerator vovserver has been started, you can view and manage it using your web browser.
You may wish to run a few simple jobs to confirm that the system is running properly.
In Accelerator, each job goes through a number of states until completion.
An important feature of Accelerator is job persistence. After a job completes, its information remains in vovserver's memory until the job is forgotten, manually or automatically.
The autoforget flag sets up a job to automatically be forgotten by the system after a certain time, (not including suspension time) if and only if the job is done, failed, or idle. Jobs that are scheduled, running, suspended or transfer are never autoforgotten.
vovserver configuration parameter values may be changed in a running vovserver using the CLI, or prior to the starting the server via the policy.tcl file. An administator can configure the parameters in the running vovserver using the vovservermgr command or the vtk_server_config procedure.
VOV and the jobs it runs depend on external resources such as available licenses, RAM, swap, tmp and disk space, which may become exhausted, damaged or otherwise unavailable. When users are subject to disk quotas, writes may fail when the disk is not completely full.
With the command vovautostart, on vovserver startup, scripts can be specified to execute automatically.
With the command vovautostop, on vovserver shutdown, scripts can be specified to execute automatically.
The job submission behavior of Accelerator or Accelerator Plus can be controlled by the file vnc_policy.tcl, which resides in the vovserver configuration directory.
The nc run command has built-in default features that include checking the validity of the run directory, enabling job profiling, etc. This section describes how the Accelerator administrator can use the file $VOVDIR/local/vncrun.config.tcl to modify some defaults.
The overhead in the nc run commands consists mostly in the on-demand compilation of Tcl code and secondarily on the number of round-trips to vovserver.
This section describes how the Accelerator administrator can use the file $VOVDIR/local/vnclist.config.tcl
to modify some defaults for the nc list command. This file does not exist by default; it must be created when needed.
VOV issues an "alert" when an event requires attention. An alert can range from information that does not require action to an urgent fault that requires immediate action.
An Access Control List (ACL) is a list of permissions that are attached to an object. The list defines who can access the object (an agent) and what actions the agent can perform on the object.
This section shows an example of using a web browser to submit jobs.
The scheduling process controls the order of job execution.
The maximum number of clients - the combination of vovtaskers, user interfaces and proxies, that can be concurrently connected to a vovserver is limited by the number of file descriptors available.
Users are now able to leverage existing Kafka systems and compatible reporting tools to monitor VOV projects.
This daemon vovfilerd replaces older daemons like vovisilond, vovnetappd and vovregulatord. Also the utility vovfiler_setup is no longer needed. The visualization of the filer information is now done either via the vovfilerd.cgi page or via the utility vovfilerdgui.
Accelerator stores historical information about jobs in a relational database. As of version 2015.09, the database is fully integrated and managed as part of Accelerator. This section provides an overview of the components that run and manage the database.
Preemption is the process of reserving or revoking resources from other jobs in order to help "important jobs" finish quickly.
Altair Accelerator includes a subsystem for managing computing resources. This allows the design team to factor in various constraints regarding hardware and software resources, as well as site policy constraints.
To ensure the correct and repeatable behavior of the tools, the environment must be controlled. This chapter explains how VOV supports multiple reusable environments.
If a server crashes suddenly, VOV has the capability to start a replacement server on a pre-selected host. This capability requires that the pre-selected host is configured as a failover server.
This section provides instructions to change the software version on which Accelerator runs.
This chapter provides information about deprecated features that are still supported. This information is provided should you see older commands in use after a software upgrade or migrating to a newer Accelerator.
Configure and manage the use of Accelerator after it is installed.
Users are now able to leverage existing Kafka systems and compatible reporting tools to monitor VOV projects.
The SDS configuration may be changed while the server is running.
$ vovservermgr config sds.enabled 1/0
$ vovservermgr config sds.readconfig 1
$ vovservermgr config set_debug_flag SDS
$ vovservermgr config reset_debug_flag SDS
Copyright (c) 1994-2021. Altair Engineering, Inc. All Rights Reserved. Contains trade secrets of Altair Engineering, Inc. Copyright notice does not imply publication.