Resource Mapping

As the vovservers determines which tasker is most suited to execute a particular job, it performs a mapping of the job resources, followed by a matching of the mapped resources.

When dispatching a job, the vovservers does the following:

Gets the list of resources required by a job.
Appends the resource associated with the priority level, such as Priority:normal.
If it exists, it appends the resource associated with the name of the tool used in the job (reminder: the tool of a command is the tail of the first command argument after the wrappers). The tool resource has type Tool and looks like this: Tool:toolname.
Appends the resource associated with the owner of the job, such as User:john.
Appends the resource associated with the group of the job, such as Group:time_regression.
Expands any special resource, i.e. any resource that starts with a "$".
For each resource in the list, the vovservers looks for it in the resource maps. If the resource map is found and there is enough of it, that is, the resource is available, the vovservers maps the resource. This step is repeated until one of the following conditions is met:
- The resource is not available. In this case, the job cannot be dispatched and is left in the job queue.
- A cycle in the mapping is detected; in this case the job cannot be dispatched at all and is removed from the job queue.
- The resource is not in the resource map.
VOV appends the resource associated with the expected job duration to the final resource list. For example, if the job is expected to take 32 seconds, the resource TIMELEFT#32 will be appended.
Finally, the vovservers compares the resulting resource list with the resource list of each tasker. If there is a match - all resources in the list are offered by the tasker - the tasker is labeled as eligible. If there is no eligible tasker, the job cannot be dispatched at this time and remains in the queue; otherwise, the server selects the eligible tasker with the greatest effective power.

Local Resource Maps

Resource maps can be designated as local, using the local flag.

Important: This flag is only available and supported for a FlowTracer installation, utilizing vovwxd and an LSF interface.

Resource maps designated as local will be managed on the "local" (FT) side of the vovwxd connection instead of the normal case where resource specifications are expected to be managed on the base queue side.

For example, to limit jobs to running 5 at a time from a specific FlowTracer project, do the following:

Enable local resources with run: vovservermgr configure vovwxd.localresources 1
Note: Alternatively, you can add the following to the policy.tcl file:
```
set config(vovwxd.localresources) 1
```
Create the local resource.
1. Run vovresourcemgr set mylocallimit -max 5 -local
  Note: Alternatively, you can add the following to the resource.tcl file:
```
vtk_resourcmap_set mylocallimit -total 5 -local
```

This results in limiting running jobs with the local resource mylocallimit to a maximum of 5 jobs at a time.

For example, FDL to use a local resource named "mylocallimit:

R mylocallimit

J vov /bin/sleep 0

Limitations on the number of Resource Expressions

While the number of OR expressions allowed in a job resource request is limited and controlled by a policy setting, the number of AND expressions including plain expressions without an explicit AND, also has limits.

The scheduler evaluates the resource expressions counting them as it goes. For example a list of 4 separate resource requests (without maps) will result in a max count of 7; 4 from the explicit resource requests and 3 from the automatically added resources (Group, Priority and User). Traversal into a resource map increments the count and a return from a resource map restores the count to value prior to the traversal into the map.

During this traversal, OR operators are recorded and used to influence scheduler operation. The count represents the cumulative depth of the resources. Whenever the count exceeds 30, any traversal that increases the depth is curtailed. This is done silently.

Any OR operators that occur at a depth deeper than 30 are ignored and those scheduling solution are effectively ignored by the scheduler resulting in unexpected behavior.

Large numbers of resource expressions do impact scheduler performance. The general guidance is to keep the explicit resource expressions to fewer than 8 including any mapped ones.

For applications that need a much larger number and where the depth may exceed the 30 limit, it is recommended to place the OR operators early in the resource requests (for example, the left hand side) and to place large numbers of ANDed resource into a resource map.