Topological naming problem

Introduction

The topological naming problem in FreeCAD refers to the issue of a shape changing its internal name after a geometrical modelling operation (pad, cut, fuse, chamfer, fillet, etc.) is performed. This will result in other parametric features that depend on that shape to break or be incorrectly computed. This issue affects all objects in FreeCAD but is especially notable when building solids with the PartDesign Workbench, and when dimensioning those solids with the TechDraw Workbench.

In PartDesign, if a feature is supported on a face (or edge or vertex), the feature may break if the underlying pad changes size or orientation, as the original face (or edge or vertex) may be internally renamed.
In TechDraw, if a dimension is measuring the length of a projected edge, the dimension may break if the 3D model is changed in such a way that it affects the edge.

The topological naming issue is a complex problem in CAD modelling that stems from the way the FreeCAD core routines handle updates of the geometrical shapes created with the OCCT kernel. As of FreeCAD 0.18 there is ongoing efforts to reduce or eliminate such topological issues. New developments may eventually be included in future versions of FreeCAD.

The topological naming problem most often affects and confuses new users of FreeCAD. Careful modelling and use of supporting datum objects like planes and local coordinate systems is advisable to produce stable models that aren't easily subject to such errors.

Example

1. In the PartDesign Workbench, create a PartDesign Body, then use PartDesign NewSketch and select the XY plane to create a sketch; then perform a PartDesign Pad to create a first solid.

2. Select the top face of the previous solid, and then use PartDesign NewSketch to draw another sketch; then perform a second pad.

3. Select the top face of the previous extrusion, and once again create a sketch, and a pad.

4. Now, double click the second sketch, and modify it so that its length is along the X direction; doing this will recreate the second pad. The third pad will stay in the same place.

5. Now, double click the second sketch again, and adjust its points so that part of it is outside the limits defined by the first pad. By doing this, the second pad will recompute correctly, however, when looking at the tree view, an error will be indicated in the third pad.

6. By making visible the third sketch and pad, it is clear that the computation of the new solid did not proceed correctly. The third sketch, instead of being supported by the top face of the second pad, appears in a strange place, with its normal oriented towards the X direction. This results in an invalid pad, as this pad would be disconnected from the rest of the PartDesign Body, which is not allowed.

The problem appears to be that when the second sketch was modified, the top face of the second pad was renamed from Face13 to Face14. The third sketch is attached to Face13 as it originally was, but since this face is now on the side (not at the top), the sketch follows its orientation and now is incorrectly positioned.

7. To fix the issue, the third sketch should be mapped to the top face again. Select the sketch, click on the ellipsis (three dots) next to the DataMap Mode property, and choose the top face of the second pad again. Then the sketch moves to the top of the existing solid, and the third pad is generated without issues.

Remapping a sketch in this way can be done every time there is a topological naming error, however, this may be a tedious task if the model is complicated and there are many such sketches that need to be adjusted.

Solution

As explained in the feature editing page, a solution to this problem is to support sketches not on faces but on datum planes which are themselves offset from the main XY plane of the PartDesign Body.

In this manner, it doesn't matter if the second sketch changes, as the modified second pad will not affect the support of the third sketch.

Adding datum objects is more modelling work for the user, but ultimately produces more stable models that are less subject to the topological naming problem.