Hierarchical project group paths

The following hierarchical group structure illustrates hierarchical project group paths:

Enabling hierarchical project group paths allows the following:

• Features can use hierarchical project groups with project and project group names that are not unique, as long as the projects or project groups do not have the same parent. That is, you can define projects and project groups in more than one hierarchical project group.

  For example, the p4 project can be defined for project groups g4 and g6, each with its specific resource allocation within the project groups.

  Important: Do not define a project group as a child of itself, because this results in a loop. For example, if project group g3 is a child of project group g1, do not define project g1 as a child of g3, as this will result in a loop of g1 and g3 being child project groups of one another.
• When specifying -Lp license_project, you can use paths to describe the project hierarchy without specifying the root group.

  For example, if you have topgrp as your root group, which has a child project group named g1 with a child project group named g3, which has a project named p1, you can use -Lp /g1/g3/p1 to specify this project.

• Hierarchical project groups have a default project named others with a default share value of 0. Any projects that do not match the defined projects in a project group are assigned into the others project. If the others project has a share value of 0, this project can still use licenses if the defined projects with shares are not using the licenses. Therefore, by default, the others project has the lowest priority within a project group.

  For example, if you have topgrp as your root group, which has a child project group named g1 with a child project group named g3, which has a project named p1, if you specify -Lp /g1/g3/project3 (which does not match a project), the effective license project is /g1/g3/others project. Similarly, specifying -Lp /g1/g3/gA/gB/gC/project3 results in an effective license project of /g1/g3/others because there are no subsequent child project groups under /g1/g3.

  If there is already a project named others, the preexisting others project specification overrides the default project.

When defining hierarchical project groups, you can define project and project group names that are not unique.

For example, to define the previously-illustrated hierarchical project group in lsf.licensescheduler:

Begin ProjectGroup
GROUP              SHARES  OWNERSHIP LIMITS NON_SHARED
(topgrp (g1 g2)    (1 1)   ()        ()     ()
(g1 (g3 g4 others) (1 1 1) ()        ()     ()
(g2 (g5 g6)        (1 2)   ()        ()     ()
(g3 (p1 p2 others) (2 2 1) ()        ()     ()
(g4 (p3 p4)        (2 1)   ()        ()     ()
(g5 (p5 p1)        (1 3)   ()        ()     ()
(g6 (p6 p4)        (1 1)   ()        ()     ()
End ProjectGroup

Begin Feature
NAME=f1
GROUP_DISTRIBUTION=topgrp
SERVICE_DOMAINS=LanServer
End Feature

The others projects are explicitly defined for g1 and g3 (with a specific share), while the other project groups use the default others projects with 0 share.

The p1 project is defined for both g3 and g5, with a larger share if specified through the g5 project group. The p4 project is defined for both g4 and g6, with a larger share if specified through the g6 project group.

You can also specify different project groups with different root groups. Different features can use different root groups (as defined by the GROUP_DISTRIBUTION parameter), each with its own project group hierarchy and share policies.

When a job requests multiple features in fast dispatch project mode, LSF License Scheduler generates an effective license project for each feature. This means that it is possible for one job to have multiple effective license projects if the features use different project group hierarchies. LSF License Scheduler and LSF will calculate the effective license project for the feature based on its related project group hierarchy. The effective project is the path of the project resulting from the -Lp specification.

When specifying a project name without a hierarchical project group path in fast dispatch project mode with hierarchical group paths enabled, LSF License Scheduler uses the shortest path to the left that ends with the name of the project, as long as the cluster that submitted the job is authorized to use the selected project. If LSF License Scheduler cannot find such a project in the hierarchy, LSF License Scheduler uses the /others project.

For example, the following hierarchical group structure illustrates which clusters (c1 and c2) are authorized to use each project:

If you specify -Lp p2 from the c2 cluster (by submitting bsub -Lp p2 -R "rusage[f1=1]" myjob) without specifying a hierarchical group path, c2 is authorized to use /g2/p2 and /g2/g3/p2. The shortest path to the left that leads to p2 is /g2/p2, so the job is associated with the /g2/p2 hierarchical project.