Home
Altair Allocator Administrators Guide
Allocator works in conjunction with license monitoring and workload scheduling solutions such as Monitor and Accelerator.
Multiple Queues
Queues Example
This section illustrates the interaction of Allocator with FlexNet Publisher. The setup consists of two Accelerator installations, one in Santa Clara, California, and one in Bangalore, India. We use the Allocator product to allocate resources among the two sites.

Welcome
What's New
View new features for Allocator 2025.1.0.
Allocator Overview
Discover the available Altair Allocator guides.
Allocator Tutorials
Examine the Case Study for a complex Allocator example.
Altair Allocator Administrators Guide
Allocator works in conjunction with license monitoring and workload scheduling solutions such as Monitor and Accelerator.
- Introduction
  Allocator works in conjunction with license monitoring and workload scheduling solutions such as Monitor and Accelerator.
- Start, Stop and Monitor Allocator
- Sharing Licenses Across Multiple Sites
- Configure Allocator
  To configure Allocator, you need to create a file called config.tcl. This is the only file required for configuring Allocator.
- Allocator Procedures
  In this section, the procedures that may be used in the Allocator configuration file are described.
- Procedures Backward Compatibility
  The previous section described the procedures that may be used in the Allocator configuration file. The new procedures are under the Tcl namespace LA; they should be prefixed with LA::
- Allocator Usage Examples
  This section contains simple examples about using Allocator to solve common problems of sharing licenses between sites.
- Map Host Names
  In several points in the systems, it is useful to get the host name for a checkout, for a job, for a daemon, etc. Since every machine may be known by different names, it is important to provide the expert user with the ability to map host names to some canonical form of the host name.
- Resource Groups
  The notion of a "resource group" in Allocator is useful when you have a resource that is derived from multiple sources.
- Allocator and TIMEVAR
  To make the weights of Allocator change as a function of time, you can use the procedure TIMEVAR.
- Passive Mode
- License Overbooking
- Overbooking in Allocator
- Debugging
- View Allocation Details
- Multiple Queues
  - Queues Example
    This section illustrates the interaction of Allocator with FlexNet Publisher. The setup consists of two Accelerator installations, one in Santa Clara, California, and one in Bangalore, India. We use the Allocator product to allocate resources among the two sites.
- PBS and Other Queues
  Allocator can allocate licenses across multiple schedulers, including Accelerator queues, PBS clusters and others. In this section we discuss how to integrate Allocator and PBS.

View All Altair Accelerator Help

Queues Example

This section illustrates the interaction of Allocator with FlexNet Publisher. The setup consists of two Accelerator installations, one in Santa Clara, California, and one in Bangalore, India. We use the Allocator product to allocate resources among the two sites.

In this example we monitor the resource License:lic_sim. Upon querying Monitor, Allocator learns that we currently have a license to run up to 7 concurrent jobs using this resource. Under idle conditions, this license is distributed to the two Accelerator sites as per the specified default weights for the sites.

# Fragment of vovlad/config.tcl
LA::AddSite vncsc@santaclara "SC" { 
} -port 6229 -version 2016.09 -defaultweight 50

LA::AddSite vncblr@bangalore "BL" { 
} -port 6335 -version 2016.09 -defaultweight 20

Using these default weights, Allocator will determine that the Santa Clara office gets access to 5 licenses, while the remote Bangalore office gets 2.

Figure 1.

When a user submits a large batch of jobs in Santa Clara, the licenses get quickly migrated from Bangalore to Santa Clara.

Figure 2.

Now Bangalore also requests to use the same resource. The system therefore wants to send 2 licenses back to Bangalore. This is done incrementally: as the jobs in Santa Clara complete, the license is moved to Bangalore.

The first picture shows allocation to Santa Clara reduced to 5, but since 7 jobs are still running, the 2 licenses cannot yet be moved to Bangalore until running jobs release them, so those 2 are shown in the "Moving" column.

Figure 3.

Once the running jobs in Santa Clara drop to 5, the 2 freed up licenses are now moved to Bangalore and jobs start running in Bangalore.

Figure 4.

The Bangalore workload is now zero, but a user in Bangalore (john@sile) is using one of the licenses outside of Accelerator, so the system needs to throttle down the number of licenses available for Santa Clara from 7 to 6.

Figure 5.

By navigating the browser interface, we can view the historical plots for the utilization, unmet demand (queued), and allocation for this resource, say for the past 4 hours.