XPAC Reference Guide

Dependencies using upper level records

Dependencies using upper level records

Previous topic Next topic  

Dependencies using upper level records

Previous topic Next topic  

Dependencies are always processed at the lowest level in a database because it is the availability of individual records that must be controlled. But when dependencies are created, it is sometimes easier to define the dependency rules in terms of upper level records. XPAC will therefore resolve any upper level dependencies into their equivalent lower level dependencies when the rules are applied.

Consider a project that contains 2 pits and a dependency rule is used to ensure pit 2 will not start until pit 1 has been completed. If the pits were fairly small and only contained 1000 records each, the dependency rule will require 1,000,000 lower level dependencies to implement it. If this approach is followed, the use of upper level dependencies could quickly become very inefficient.

To reduce the impact of upper level rules and reduce the number of lower level dependencies, XPAC performs an optimisation process whenever upper levels rules are applied. This examines the dependencies that already exist between children of the upper level successor and children of the upper level predecessor. This can significantly reduce the number of dependencies required to implement an upper level rule.

In the following example, there are two benches, each with six blocks. We will consider two dependency rules as follows.

Blocks on each of the benches cannot be mined unless the block to their East has been mined (ie mine each bench from East to West).
Bench 2 cannot be mined unless bench 1 has been mined (an upper level rule where both the successor and predecessor are upper level records).

The following diagram shows the dependencies that would be created if the first rule was applied on its own. The arrows always point from successors to predecessors (they point to the blocks that must be mined before the dependency will be satisfied.).

dwg_UpperLevelDependencies_1

The next diagram shows the dependencies that would be created if rule 2 is applied on its own. In this instance, a dependency is required from every record in bench 2 to every record in bench 1.

 

dwg_UpperLevelDependencies_2

 

The final diagram shows the dependencies created when rule 1 is applied to the project followed by rule 2. The redundant dependencies are identified and eliminated when the rule is applied.

dwg_UpperLevelDependencies_3

To function efficiently, all standard dependencies should be applied to a project before rules with the upper level dependency are applied. Rule sets that involve upper level records must basically be applied last.

When XPAC applies dependencies, it does so in the order the rules are displayed within the schedule set up tree. To amend this order, the rule sets can simply be dragged and dropped to new locations. To gain most benefit from the optimisation process, you should place rule sets that involve upper level dependencies at the bottom of the list in the schedule set up tree.

When the Apply All Rule Sets option is selected (either from the menu, the right click menu or from a prompt when a schedule is run) the rule sets will be applied sequentially in the order they occur within the tree. But if rule sets are applied individually, it is possible a dependency that was previously used in the optimisation process is changed or removed.

For this reason, we always recommend the Apply All Rule Sets menu option is selected before scheduling, if any significant changes are made to dependencies in projects. This is more important in projects that use upper level dependencies, where optimisation will have been used.