Specification Tree Organization
In this article, we will discuss how to organize the specification tree in a part file during the creation process.
1. Avoid cryptic specification trees
In figure 1, you can compare the difference between; a part with an organized specification tree (left side) versus a part with mixed modelling specification tree (right side). Both files present the same end geometry, considering the initial parameters specified for the design.
Figure 1 - Organised specification tree vs mixed modelling versions of Angle Bracket part
Let us make a comparison between their respective specification trees; notice that the organized part was named and all features in the PartBody were renamed as well. All elements inside the Skeleton geometrical set were also renamed but were not presented in the image.
Renaming may not seem important at first glance and for many designers is not considered a priority at all. We cannot emphasize enough how important this step is, particularly if the model is prone to edition at a later stage. Complex models become particularly hard to interpret, even for the part creator, given enough time.
Renaming should be done considering the function and not necessarily the tool name that was used to create the element. This rule is universal for all created design elements and modelling elements, we specifically state the created elements because imported input elements should keep their name, given in the source file where they were copied from. Notice also that the elements are numbered according to a specific coding method that we will discuss in a future article. This coding will help us group the used feature tools by function and increase model robustness.
Design and modelling stage organization
When we start inserting elements in a part, we should respect the Hierarchy Rule. This rule stratifies elements in different levels:
- Imported reference geometry
- Reference geometry and additional axis systems
- Imported solid geometry
- Solid geometry features
This means a higher hierarchy element, such as reference geometry, cannot depend on elements belonging to lower levels of the hierarchy, such as faces created by solid geometry features. If we create the elements in sequence, it will help us guarantee that the hierarchy is respected. If we do not create them in sequence then we should be careful with the dependencies created.
There is a major difference between specification trees presented in figure 1; the organized specification tree (on the left) has two containers while the mixed modelling version only has the PartBody, thus one container only.
The organized tree version has a geometrical set called Skeleton and the PartBody. This clearly highlights the fact that the designer broke the creative process in two stages; all the design elements were inserted inside the Skeleton while all the modelling elements where created and stored inside the PartBody.
The mixed modelling version only has the PartBody because the sketch elements and reference geometry were created when needed and not according to the Hierarchy Rule. This makes the edition process that much harder because the sketch elements depend on existing modelled geometry (and they shouldn’t), this method increases the size of the dependency ladder and lends the model its unpredictable behaviour when edited.
In this article, we discussed that in CATIA V5 elements in the specification tree should be renamed according to function and how much easier the edition process will be with proper naming of elements. We also discussed that the elements created in the stages discussed in the previous article should be stored in different containers inside the part file; the Skeleton geometrical set and the PartBody.
In the next article, we will talk in detail about the design stage.
Related article: Modelling Methodology in CATIA V5 - Part 1