Relative address dependency rule sets are used to define generic dependency rules that are applied to a specified range of records (the Successor Range). Instead of specifying the address of the successor and predecessor records absolutely, the address of the predecessor record relative to the successor is specified.

We use the APIL numbers on each level of the database to define the location of each record in the deposit. This also provides a convenient method of specifying the relationships (or APIL offsets) from one record to a neighbouring record.

When the same relationship between predecessor and successor repeats over a section of the mine, the same rule can be used to create the dependencies for every record in that section. A good example would be the generic rule "Block Above", which is applied to every record within an open pit deposit.

Selecting Relative Address from the Type drop down menu displays the same options as the Absolute Address dialog box.

The rule table

Initially, the rule table in the middle of the relative address dependency window will be empty. The table has a column for each level in the database hierarchy (labelled Level 1, Level 2, etc), as well as columns for the successor and predecessor activities. The final column indicates whether the rule is assigned to an alternative rule group.

Database levels

The database level columns in the rule table are used to specify the offsets that must be applied to the APIL numbers of the successor block to obtain the APIL numbers of its predecessor. Offsets for every level must be provided and these are determined by subtracting the APIL number of the successor record from the APIL number of the predecessor record. The general formula for these offsets is as follows.

Offset (Level 1) = Predecessor APIL (Level 1) - Successor APIL(Level 1)

Offset (Level 2) = Predecessor APIL (Level 2) - Successor APIL(Level 2)

Offset (Level n) = Predecessor APIL (Level n) - Successor APIL(Level n)

Whilst these formulae will always generate the correct values, it is normally just a simple case of determining what numbers (which could be positive or negative) must be added to each of the successors APIL numbers in order to find its predecessors APIL numbers.

Offsets must be specified for every level in the hierarchical database, but often many of the offsets will be zero. For example, in an open cut coal mine with a Pit/Strip/Block/Seam database structure, a rule is needed to prevent any seam from being undercut by the seam below. A relative address rule that achieves this would have an offset of -1 on the seam level and an offset of zero on the other database levels.

Although this rule type does not require the deposit to have a regular geometric blocking, its effectiveness can only be realised if the APIL numbers are carefully chosen when the database is constructed. For example, the development in an underground deposit rarely has a regular geometric layout. However, if the blocks along each drive are allocated sequential APIL numbers (which is usually the case), a single rule can be used to assign most of the dependencies required to control the development sequence.

Upper level records - disable column

Relative address dependency rule sets are usually used to create dependencies between lower level records, but it is also possible to define generic rules between upper level records using this type of rule set.

For example, an open pit project with a Pit\Bench\Northing\Easting database structure may require a rule preventing one bench from being mined before the entire bench above has been completed. But this is difficult if we do not know where one bench will be completed and where the next bench will begin.

To define an upper level dependency, the columns representing one or more database levels must be disabled. Right-click on the appropriate level column and selecting the Disable Column option. This will disable the selected column and any columns to its right (representing the levels below the selected level).

A number of precautions should be taken when using dependency rules that involve upper level records.

Successor and predecessor activities

The activity columns in the rule table are assigned the default value All when rules are first created, ensuring Every activity in the predecessor must be completed before Any activities in the successor can be started. This default can be over-ridden by selecting a different activity from the drop down list provided when a cell in one of the activity columns is selected.

Or group number

Multiple relative address rules can be set up as alternative dependencies using the Or Group Number. Note that these relative address rules must all be defined within the same Dependency Rule Set.

For two or more rules to be alternative dependencies, they should all be assigned the same Or Group Number. The number should be an integer greater than or equal to one. If the Or Group Number is set to zero, then the rules will not be alternative dependencies.

Successor range

Because rule sets of this type are generic, they will be applied to every record in the specified Successor Range. The relationships between successor and predecessor records must therefore be valid for every block in this range. If different relationships exist in different portions of the deposit, different rule sets must be created for each portion.

In most situations, each rule in a relative address rule set will create a dependency for every record in the successor range. The main exception is when the associated predecessor record does not exist and in this situation, no dependency will be created.

Predecessor filter

Before the rule set creates a dependency, XPAC tests whether the predecessor record occurs within the range specified in the Predecessor Filter list box. If the predecessor record is within the range, the dependency will be created as normal. But if the predecessor record is not in the range, the dependency will not be created. By default the Predecessor Filter range will be set to All, ensuring that every dependency will be created.

Lag

The Lag list box under the rule table allows users to assign a delay to each of the dependencies created by the rules in the set. The duration of the delay is specified in calendar days and either a reference to a Main database field or an absolute value can be specified. If a main database field is selected, a unique delay can be assigned to each record.

When a lag is assigned to a dependency, the successor will not become available when the rule has been satisfied. This will be delayed by the duration specified in the Lag list box, with the delay beginning the moment the rule is satisfied.

Release profile

The Release Profile list box under the rule table allows the user to assign a release profile to the dependencies created by the rule set. A release profile allows the successor record in each dependency to become available for mining as soon as a specified percentage of the predecessor has been mined.