Configuration File Format - Intergraph Smart 3D - Administration & Configuration

Intergraph Smart 3D Interference Checking
Language
English
Product
Intergraph Smart 3D
Subproduct
Interference Checking
Search by Category
Administration & Configuration
Smart 3D Version
12.1 (2019)

The delivered example configuration file contains a high-level overview of the XML format.

The software evaluates rules in the order that results in the best performance. That is, faster rules are checked before more complicated rules with attributes that require more processing. For example, ByObjectType rules are examined first, followed by ByName rules, then ByObjectPG rules, and so on. Within each rule type, rules are executed in the order given in the configuration file. Anytime a rule is evaluated, the software skips the rest of the rules.

Rules Evaluating a Single Object

Rules evaluating two clashing objects

<CustomClashRules>

Supports an optional Version attribute for change management. Incrementing the version as shown in the following example forces IFC to reprocess the model with the updated rules. <CustomClashRules> is the root tag of the XML file.

Existing definition

<CustomClashRules Version="01.00.00.00">

Incremented version

<CustomClashRules Version="02.00.00.00">

  • <CustomClashRules> contains the child tags listed below. Each child tag is a group of rules.

    • <IgnoreObjectsForClashChecking>

    • <IgnoreClashesBetweenObjects>

    • <SetClashProperties>

    • <AspectToUseForClashDetection>

    • <SetClashType

  • The <IgnoreObjectsForClashChecking>, <IgnoreClashesBetweenObjects>, and <AspectToUseForClashDetection> tags can also contain a <CustomIFCRule> tag.

<IgnoreObjectsForClashChecking>

Preprocessing rules that help determine if an object is to be ignored for clash checking. You can use one or more rules evaluating single object. See Rules evaluating a single object.

<IgnoreClashesBetweenObjects>

Post-processing rules that help determine if a clash between two objects is to be ignored. You can use one or more rules evaluating two clashing objects. See Rules evaluating two clashing objects.

<SetClashProperties>

Sets the ClashStatus and ClashRemarks properties based on objects involved in a clash that evaluates the specified criteria. You can use one or more rules evaluating two clashing objects.

The rules under the <SetClashProperties> tag are similar to the rules under the <IgnoreClashesBetweenObjects> tag. If the rules under the <IgnoreClashesBetweenObjects> tag do not ignore a clash, then the software evaluates the rules under the <SetClashProperties> tag to determine if any rule has the required criteria. If a rule is evaluated, then the ClashStatus and ClashRemarks properties specified with the evaluated rule are applied to the clash.

If the existing ClashRemarks value begins with 'L-', the software considers the value locked and the rule does not change the value.

Use at least one property (ClashStatus or ClashRemarks) with each <SetClashProperties> rule.

  • ClashStatus - the status value to set on the clash. This value can be Undefined, Edit, None, or the equivalent codelist numeric value preceded with a colon (for example, ':1', ':2', or ':3', respectively).

  • ClashRemarks - the remarks text set on the clash.

In the following example, the <SetClashProperties> rule and the ClashStatus and ClashRemarks properties specify that no action is needed for clashes between piping welds:

<SetClashProperties>

<ByObjectType List1="Piping Welds" List2="Piping Welds"

ClashStatus="None" ClashRemarks="weld/weld clashes need no action"/>

</SetClashProperties>

ClashRemarks using Codeless IFC Rules

The following are the new Codeless IFC rules that set the ClashRemarks property based on the objects involved in a clash:

Rule Criteria

Description

LastModifiedObjectUserName

This rule sets the ClashRemarks property to the user name of the last modified object (of the two participating objects), if both objects match the object type criteria mentioned in List1 and List2.

According to following sample rule, if a clash exists between two Pipes or Piping object types, say PipeA modified by user Domain\PipingDesigner1 at Jan 01 2017, 9:00 AM and PartB modified by Domain\PipingDesigner2 at Jan 01 2017, 10:00 AM, then the ClashRemarks is set to To be handled by Domain\PipingDesigner2 because PipeB is the last modified object.

<SetClashProperties>

<ByObjectType
List1="Pipes,Piping *"

List2="Pipes,Piping *"

ClashRemarks="To be handled by {{LastModifiedObjectUserName}}"/>

</SetClashProperties>

FirstModifiedObjectUserName

This rule sets the ClashRemarks property to the user name of the first modified object (of the two participating objects), if both objects match the object type criteria mentioned in List1 and List2.

According to following sample rule, if a clash exists between two Ducts or HVAC Components object types, say DuctA modified by Domain\HVACDesigner1 at Jan 01 2017, 9:00 AM and HVAC1 modified by Domain\ HVACDesigner2 at Jan 01 2017, 10:00 AM, then the ClashRemarks is set to To be handled by Domain\HVACDesigner1 because DuctA is the first modified object.

<SetClashProperties>

<ByObjectType
List1="Ducts, HVAC Components"

List2="Ducts, HVAC Components"

ClashRemarks="To be handled by {{FirstModifiedObjectUserName}}"/>

</SetClashProperties>

LastModifiedObjectPermissionGroup

This rule sets the ClashRemarks property to the permission group of the last modified object (of the two participating objects), if both objects match the object type criteria mentioned in List1 and List2.

According to following sample rule, if a clash exists between two “Cable Trays, Cable Tray Components, Cableway *” object types, say CableTrayA modified by Domain\ ElectricalDesigner1 (in permission group Electrical1) on Jan 01 2017, 9:00 AM and CableTrayB modified by Domain\ElectricalDesigner2 (in permission group Electrical2) on Jan 01 2017, 10:00 AM, then the ClashRemarks is set to To be handled by Electrical2 because Electrical2 is the Permission group for CableTrayB (which was the last modified object).

<SetClashProperties>

<ByObjectType
List1="Cable Trays, Cable Tray Components, Cableway *"

List2="Cable Trays, Cable Tray Components, Cableway *"

ClashRemarks="To be handled by {{LastModifiedObjectPermissionGroup}}"/>

</SetClashProperties>

FirstModifiedObjectPermissionGroup

This rule sets the ClashRemarks property to the permission group of the first modified object (of the two participating objects), if both objects match the object type criteria mentioned in List1 and List2.

According to following sample rule, if a clash exists between two “Equipment, Pipe Nozzle, HVAC Port *” object types, say Equipment modified by Domain\EquipmentDesigner (in permission group Equipment) on Jan 01 2017, 9:00 AM and PipeNozzle modified by Domain\PipingDesigner (in permission group Piping) on Jan 01 2017, 10:00 AM, then the ClashRemarks is set to To be handled by Equipment because Equipment is the Permission group for Equipment (which is the first modified object).

<SetClashProperties>

<ByObjectType
List1="Equipment,Pipe Nozzle, HVAC Port"

List2="Equipment,Pipe Nozzle,HVAC Port"

ClashRemarks="To be handled by {{FirstModifiedObjectPermissionGroup}}"/>

</SetClashProperties>

Object1ModifiedByUserName

This rule sets the ClashRemarks property to the user name of the object whose object type is in List1 of the IFC rule, if both objects match the object type criteria mentioned in List1 and List2.

According to following sample rule, if a clash exists between Equipment and (Pipes or Piping) object types, say Equipment modified by user Domain\EquipmentDesigner and Pipe modified by Domain\PipingDesigner, then the ClashRemarks is set to To be handled by Domain\EquipmentDesigner because Equipment object type is in List1 of the rule.

<SetClashProperties>

<ByObjectType
List1="Equipment"

List2="Pipes, Piping *"

ClashRemarks="To be handled by {{Object1ModifiedByUserName}}"/>

</SetClashProperties>

Object2ModifiedByUserName

This rule sets the ClashRemarks property to the user name of the object whose object type is in List2 of the IFC rule, if both objects matches object type criteria mentioned in List1 and List2.

According to following sample rule, if a clash exists between Duct and Equipment object types, say DuctA modified by user Domain\HVACDesigner and EquipmentA modified by Domain\EquipmentDesigner, then the ClashRemarks is set to To be handled by Domain\EquipmentDesigner because Equipment object type is in List2 of the rule.

<SetClashProperties>

<ByObjectType
List1="Ducts"

List2="Equipment"

ClashRemarks="To be handled by {{Object2ModifiedByUserName}}"/>

</SetClashProperties>

Object1PermissionGroup

This rule sets the ClashRemarks property to the permission group of the user who modified the object from List1 of the IFC rule, if both objects match the object type criteria mentioned in List1 and List2.

According to following sample rule, if a clash exists between Pipes, Piping, and Ducts object types, say PipeA modified by user Domain\PipingDesigner and DuctA modified by Domain\HVACDesigner, then the ClashRemarks is set to To be handled by Domain\PipingDesigner because Pipe object type is in List1 of the rule.

<SetClashProperties>

<ByObjectType
List1="Pipes, Piping *"

List2="Ducts"

ClashRemarks="To be handled by {{Object1PermissionGroup}}"/>

</SetClashProperties>

Object2PermissionGroup

This rule sets the ClashRemarks property to the permission group of the user who modified the object in List2 of the IFC rule, if both objects match the object type criteria mentioned in List1 and List2.

According to following sample rule, if a clash exists between Pipes, Piping and Cable Trays object types, say PipeA modified by user Domain\PipingDesigner and CabelTrayA modified by Domain\ElectricalDesigner, then the ClashRemarks is set to To be handled by Domain\ElectricalDesigner because Cable Tray object type is in List2 of the rule.

<SetClashProperties>

<ByObjectType List1="Pipes, Piping *"

List2="Cable Trays"

ClashRemarks="To be handled by {{Object2PermissionGroup}}"/>

</SetClashProperties>

ClashRemarks is a keyword used in CodelessIFCRule. Values specified for ClashRemarks are reflected in the Notes box.

<SetClashType>

Changes the clash category from the default value that is determined by internal rules according to the standard interference check behavior. You can use one or more ByDefiningInterfacesAndAspect rules in this section. The ByDefiningInterfacesAndAspect rules are described in the table below.

Rule Tag

Details

ByDefiningInterfacesAndAspect

Sets the clash type based on the involved objects and aspects. You must specify the attributes listed in this table.

Attributes

DefiningInterfacesList1
DefiningInterfacesList2

List of interfaces that limit the object1 type and object2 type; use an asterisk '*' to match all objects

Aspect1
Aspect2

The object1 and object2 aspect to match; you must define one aspect attribute

Type

Defines the ClashType; specify HARD, SOFT, or IGNORE

Control

LimitToObjectTypes, ExcludeObjectTypes, ExcludeClashes, and RelationNavigationPath

Example Rules

Example 1

The following rule sets the piping physical aspect versus the equipment maintenance aspect to SOFT:

<ByDefiningInterfacesAndAspect Type = "SOFT" DefiningInterfacesList1="IJRtePiping" Aspect1="Simple Physical" DefiningInterfacesList2="IJEquipmentFurnishings" Aspect2="Maintenance"/>

Example 2

The following rule sets any aspect of piping versus the operation aspect of any object to HARD:

<ByDefiningInterfacesAndAspect Type="HARD" DefiningInterfacesList1 = "IJRtePiping" Aspect1="*" DefiningInterfacesList2 ="*" Aspect2="Operation"/>

Use the LimitToObjectTypes option with wild cards to achieve the same results as those shown in Example 1 and Example 2

Example 3

<ByDefiningInterfacesAndAspect Type = "SOFT" DefiningInterfacesList1="*" Aspect1="Simple Physical" LimitToObjectTypes1="Pipes, Piping *" DefiningInterfacesList2="*" Aspect2="Maintenance" LimitToObjectTypes2="Equipment"/>

Example 4

<ByDefiningInterfacesAndAspect Type="HARD" DefiningInterfacesList1="*" Aspect1="*" LimitToObjectTypes1="Pipes, Piping *" DefiningInterfacesList2="*" Aspect2="Operation" LimitToObjectTypes2="*"/>

Example 5

The following rule sets member parts (Fireproofing Insulation) versus Anything (Physical) to HARD:

<ByDefiningInterfacesAndAspect Type="HARD" DefiningInterfacesList1="*" Aspect1="*" LimitToObjectTypes1="Insulation" DefiningInterfacesList2="*" Aspect2="Simple Physical" LimitToObjectTypes2="*"/>

<AspectToUseForClashDetection>

A rules section that overrides the aspects used for clash detection.

Rule Tag

Details

Sub-tags

Default

The default aspect to use for objects in the clash calculation; Detailed physical is the default aspect

ByObjectType

A list attribute of ObjectTypes (attributes are separated by a comma), and an Aspect attribute that specifies the ObjectTypes aspect; the ByObjectType tag overrides the default aspect of an ObjectType

Example

<AspectToUseForClashDetection>
<Default Aspect="Detailed physical" />
<ByObjectType List = "Pipe Supports, Duct Supports, Cable Tray Supports" Aspect="Simple physical"/>
</AspectToUseForClashDetection>

<CustomIFCRule>

Applies programmatic rules you write if you cannot achieve a particular result using the codeless rules already contained in the configuration file. You can configure custom (VB6 or .NET) IFC Rule ProgIDs within the <IgnoreObjectsForClashChecking>, <IgnoreClashesBetweenObjects>, and <AspectToUseForClashDetection> sections.

  1. Write a custom ProgID and implement the IFC rule interfaces (IJDInterferenceRule, IJDInterferencePrePrcsrRule, and IJDIntPrePrcsrRuleForeign).

  2. Specify the custom ProgID in the ProgID attribute of the CustomIFCRule.

  3. Run the custom IFC rule .dll in [SymbolShare]\Custom Symbols\Interference.

  4. Run the Update Custom Symbol Configuration command in Project Management.

If no text-based rule ignores your object or clash, and your object type contains the specified [LimitTo or Exclude] ObjectTypes or ExcludeClashes criteria, the software invokes the custom ProgID. If the custom ProgID returns false, then the object or clash is ignored.

  • You can use screening criteria attributes to limit rule evaluation to a few ObjectTypes. If your custom code-based rule handles specific ObjectTypes, limit or exclude ObjectTypes and clashes from evaluation to improve software performance.

  • For specific clash situations, specify multiple CustomIFCRule rules that have different screening criteria to define focused, separate coded rules that have separate ProgIDs. The software uses the first qualifying rule result it encounters. See the following example:

    <CustomIFCRule ProgID="MyCustomIFCRule.ProcessorRuleA"
    LimitToObjectTypes="<specifyA1,2,3>"/>
    <CustomIFCRule ProgID="MyCustomIFCRule.ProcessorRuleB"
    LimitToObjectTypes="<specifyB1,2,3>"/>