Suppose we define two dependencies such that A is a predecessor of B and B is a predecessor of A. This will prevent both records A and B from ever becoming available. We call this situation a Circular Reference and must obviously avoid them in AutoScheduler projects.

When a record is dependent upon itself, a circular reference exists with a length of 1. When two records are dependent upon one another, the length of the circular reference is two. Circular references can have any length.

Because a record within a circular reference will never become available, it will never be scheduled. Furthermore, any records that are dependent on any of the records in the circular reference will never be scheduled, nor the records dependent on them and so on.

This is clearly an undesirable situation, but it can occur, particularly when the dependencies derived from several complex rules interact. Two techniques are currently available to help users avoid circular references. The first is simply the detection of circular references, so that users can refine the rules and therefore avoid the circular references. The second technique involves filtering out the dependencies generated by a rule if they would create circular references.

Standard circular reference testing

To test if there are any circular references within a project's dependencies, select Scheduling > Scan Circle References from the application menu. XPAC will check every dependency within the current scenario and generate a report outlining the records within the first circular reference it finds. Use this information to help rectify the problem by identifying why the current set of dependency rules created a circular reference.

It is important to note that circular reference testing is performed using the dependencies in the current scenario and not the rules that created them. If a rule has been temporarily removed, the dependencies it creates will not exist in the current scenario and will not be included in the circular reference test.

Standard circular reference testing can also be performed whenever a rule set is applied. To use this facility, the rule set must be edited and the Circular Reference Checking tab should be selected. The options are not available with script dependency rule sets, although XCM functions are available that allows the script to perform this function itself.

Standard circular reference testing is not active by default, but two options are available for rule sets whose type is not script.

If the After Every Rule option button is selected, a scan for circular references will be performed once every rule in the set has been applied to each records in the specified range. This is the standard option and when applied, the time required to apply the rule set will increase.

If the Every Single Dependency Instance option is chosen, a scan for circular references will be performed whenever a dependency is created. This option causes a significant increase in the time required to apply the rule set.

Under normal circumstances, these options would not be applied to dependency rules, as the reduction in speed when the rule set is applied would be unacceptable. Instead, a full circular reference scan would be performed after all rule sets in the current scenario had been applied. If a circular reference was detected during this scan, individual rule scanning can then be used to help identify which rule set (or combination of rule sets) resulted in the circular reference.

Pre-emptive circular reference detection

Circular references rarely occur as a result of absolute address rule sets, as the user has considered the implications of each individual rule. But this is not the case with the generic rule sets that are defined for a small, idealistic portion of the mine but are applied to large areas with varying geometry.

When you use relative bearing rule sets, the risk of generating circular references increases significantly. It is very easy to repeatedly modify the face advance directions when using this type of rule and it is easy to overlook the implications associated with this.

Problems occur most frequently along boundaries between areas with different face advance directions. For example, if two areas have opposite face advance directions and the block behind is specified as a predecessor, a line of circular references would be created along the boundary of the two areas.

A typical characteristic of this type of circular reference is that they have a length of two and occur when the face advance bearings of two adjacent records move away from one another at an angle of 90° or more. It is not uncommon to obtain many thousands of circular references in these situations and normally they result from the same combination of rules.

Pre-emptive circular reference detection overcomes this problem by determining in advance whether the rules in any given rule set will cause circular references. If they will, remedial action is taken to avoid the problem arising.

Although very powerful, the facility is only available for absolute bearing and relative bearing rule sets. Furthermore, it will only test for possible conflicts between the rules in a single rule set.

 

 

By default, pre-emptive circular reference detection is not active and if it is required, the option button associated with one of the three operating modes should be selected.

When pre-emptive circular reference detection is active, the AutoScheduler evaluates whether the rules within the current rule set will create any circular references. If it finds that a circular reference will be created, the remedial action it takes will depend on which operating mode has been chosen. Only rules within the current rule set are tested in this manner and dependencies generated by other rule sets are not included in the test.

If the Omit Rule option was chosen, a dialogue will be displayed when a circular reference is found that asks which of the two rules forming the circular reference should be omitted. The dependency created by the selected rule or rules will then be omitted from the project.

Because this type of circular reference usually occurs in groups, similar circular references are likely to occur in the project. To avoid having to select the same option many times over, check the Apply action to all identical Circular References check box. Thereafter, if XPAC finds a circular reference as a result of the same pair of rules applied to blocks with the same face advance bearings, it will not display the dialogue again. Instead, XPAC will use the previous response.

Despite this option, there are still many different combinations of mining directions and rules that can cause a circular reference. To avoid the need to select which rule to omit each time a new combination is found, you can check the Don't Ask (Omit Both Rules) check box when setting up the search. In this configuration, neither of the dependencies that would have caused the circular reference will be omitted from the project.

While this option may appear quite drastic, only a small number of rules are omitted and many thousands of rules will remain. Because of this, omitting both rules seldom has any significant impact on the face advance profile.

If you select the Run Script option, the AutoScheduler will not create the dependency when XPAC detects a circular reference. Instead, it will execute an XCM, allowing the user to evaluate the circumstances and take the most appropriate action.

If the Apply Alternative Rule option is selected when a circular reference is detected, the AutoScheduler will apply the alternative rule associated with the rules that would cause the circular reference. If the alternative predecessors exist, a dialogue will be displayed asking which rule should be replaced by it's alternative. Again a check box can be ticked to avoid having to select an option if a similar circular reference is detected.

If the Don't Ask (Apply Both Rules) check box is ticked, the dialogue box will not be displayed and instead, both of the dependencies that would have caused the circular reference will be replaced by their alternatives.

You can define an alternative rule set by clicking the Edit Rules button when you define any absolute bearing or relative bearing rule set (you may need to change back to the first tab). Three alternative rule columns are provided in the rule table to enter the alternative offsets in the X, Y and Z directions. These columns are greyed unless the Apply Alternative Rule pre-emptive circular reference testing mode has been selected on the Circular Reference Checking tab.

The alternative rules used in this pre-emptive circular reference testing mode should not be confused with the alternative dependencies added to an OR rule groups.

Limitations when OR rule groups are used

Although circular reference testing is an invaluable tool for detecting problems within complex projects, there is one limitation when there are rules in OR Rule Groups.

The number of alternative dependency networks increases exponentially as the number and complexity of the OR rule groups increases, making a rigorous test prohibitive in all but the simplest cases.

Currently, circular reference testing will only include dependencies that are created by standard dependency rules. Dependencies created by rules within OR rule groups are ignored. This small limitation will be addressed in a future release of the package.