|
|
Setting up dependencies using in-file attributes |
Attribute-based Dependencies
To access this dialog:
-
Using the Edit Dependency Rules panel, select the Attributed Based Rules tab.
Attribute-based dependencies operate regardless of an activity point's location in 3D space (in relation to other points). Instead, an attribute is used to govern whether a dependency is formed. One example of where this could be useful is in conjunction with Datamine's Mineable Shape Optimizer module; the output stopes could be sequenced/connected in the order of the IDs that MSO assigns.
For these rules, you select a Filter for the activities, an Attribute Grouping (which contains a reference to one or more design attributes) to use for grouping the filtered activities and a Dependency Layer to which the dependencies will be added. It’s a highly flexible way to configure your inter-activity rules.
|
With existing activities, adding attributes and assigning values and then reprocessing will apply those attributes and values to the activities. This is useful for attribute-based dependency rule processing as it means you can simply re-run the processing to get attribute changes onto the activities as required for the rules to be effective. |
Ultimately, attribute-based dependencies can be used with any attribute or group of attributes that can define the mining sequence, and you may even want to consider using coordinate fields to control the direction of sequencing, such as with an outlines design like the one below, where you may want to link using X or Y for sorting:
Attributes and Attribute Grouping
Attribute grouping is a good way to produce a set of simple rules that can apply to multiple attribute value combinations in your project.
Consider an example where a project consists of two orebodies, A and
B, and each level is divided into 3 sublevels. In both A and B mines,
the direction of mining differs depending on the relative position of
stopes to the access drives, e.g.:
One option would be to set up dependencies between each of the mine, level and sublevel combinations using several filters to separate each area according to the mine, the level and the mining direction (for example, "DESIGNDF='STOPES' and MINE='A' and LEVEL = 'L1' and SUBLEVEL = 'S1' and DIRECT='Left' and so on). This would result in a lot of filters, even in a fairly simple project!
A more practical approach is to use attribute grouping and corresponding filters. For example, set up a filter called "ZONE_1_Deps" which simply refers to the mine and the direction (e.g. MINE='A' and DIRECT='Left'). Then, define an Attribute Grouping containing the attributes LEVEL and SUBLEVEL. Then, set up the attribute-based rule so that the "ZONE_1_Deps" filter is used to segregate all left-right dependencies in Mine A, and that LEVEL and SUBLEVEL dependencies are applied in an order of ascending X coordinate value.
In the latter scenario, only four rules and four corresponding filters would be required:
-
MINE A, for all left-right dependencies
-
MINE A, for all right-left dependencies
-
MINE B, for all left-right dependencies
-
MINE B, for all right-left dependencies
Here's another example:
In this example, a rule is being set up that applies to imported wireframe activities only
-
Filter = *WFM: The dependencies will be created for all the Imported Wireframes activities.
-
Grouping = Stope: This is the name of the pre-defined grouping tree used to group the activities with the same attribute values.
In the Grouping definition the setting are as follows: -
Name = Stope: This will be the name of the grouping to be used for the dependency rule
-
Attribute = Level; Region: This means that the rule will group all the activities that have the same Level and Region values and create the dependencies between them following the sorting attribute and the sort direction specified in the dependency rule.
You can select more than one attribute to specify a grouping tree that will be used to create the attribute based rules. See the example below.
-
Sorting Coordinate = _X_Coord: The X coordinate will be defined as the attribute used to govern the direction of the dependencies.
-
Sort Direction = Ascending: The ascending direction means that the dependencies will be created following the X coordinates form the smallest value to the highest value.
...and one more stoping example:
In this example, an attribute-based rule is set up using a Grouping for the attributes LEVEL and REGION, and using two separate Filters, one for the West Stopes and one for the East Stopes. The sorting attribute is _X_Coord and the sort direction is [Ascending] for the West Stopes and [Descending] for the East Stopes.
In this case, the Attribute Based Rules table would look like this:
|
Filter |
Grouping |
Sorting Attribute |
Sort Direction |
Dependency |
| STOPES_W | STOPE | _X_Coord | Ascending | Stopes |
| STOPES_E | STOPE | _X_Coord | Descending | Stopes |
This could result in a set of dependencies like this, for example:
Importing and Exporting Data
You can import and export data on panels like this one using the following buttons:
Import XML data containing settings information
for this task
Export the currently defined data
Data is stored in XML format and can be transferred to other UG projects and systems, for example.
|
|
Rule-based dependencies can be transferred between projects using the Import Dependency function. You can choose to import rule-based dependencies if you wish (disabled by default). |
Field Details
As with the Spatial Based Rules (see above), configure a rule set using the panel on the left of the screen.
Next, fill out the following fields for each rule:
Filter: define the scope of your activities using a predefined filter.
Grouping: select an attribute group to use for grouping the filtered activities. These are defined using the Edit Groupings panel.
Sorting Attribute: an attribute to use for sorting the activities in each group.
Sort Direction: you can sort activities in either [Ascending] or [Descending] order.
Dependency Layer: select the layer to which dependencies will be added..
