DoF Analysis Improvements and Other New Features in C3D Solver

Alexander Maximenko, Head of C3D Solver Development Team, C3D Labs, tells about the new 2D and 3D parametric capabilities now available in C3D Solver.

Creating a geometric kernel is a challenging quest with many subtleties. One day, I will share these subtleties, but for now, let me cover another four areas. One is geometry diagnostics for parametric drafting, and the other three are zero-length segments, the tangent option, and multithreading.

The C3D Solver module consists of two components. One is a drafting processor and is used to create parametric drawings. The other one is the 3D component that handles assembly constraints, kinematic analysis, pipeline and wireframe modeling.

Both components are declarative. What does that mean? The user describes the expected result in terms of constraints, parameters, and dimensions. The solver generates the result. C3D Solver’s primary job sounds simple: find a position for the geometric objects in which all the geometric and dimensional constraints and satisfied. There are also many supporting tasks, and one of them is geometry diagnostics.

C3D Solver notifies the user whether the sketch is fully defined and whether there are any issues. For this, a sketch has multiple statuses.

• Not Fully Defined: There are objects with a higher-than-zero number of degrees of freedom (DoF). This status happens most of the time. The user adds one constraint after another until the sketch goes to the next status: fully defined.
• Fully Defined: all the objects are located as intended and cannot be moved for a given set of control dimensions.
• The third status is Over Defined: the sketch contains extra constraints. There are two types of over-defined sketches. Type 1: there is a conflict so the sketch is impossible to solve. In this case, the system of constraint is inconsistent. Type 2: there are no conflicts, but just extra constraints that can be removed without affecting possible solutions.

A model can contain both not fully defined, fully defined, and over-defined fragments. Note that the over-defined status applies not to the entire drawing, but to its fragment provided that the fragment has at least two mutually redundant constraints. Looking ahead, let me also note that not every redundancy is an issue. Some redundancies do not spoil a parametric drawing, and C3D Solver handles them well.

You can identify not fully defined fragments of the drawing through API calls. For this, query the control points of the objects. For each point, its degree of freedom (from zero to two) and a vector of possible motion are returned. For scalar parameters, use the GCE_CoordDOF function. Using it, you can check, for instance, it the radius of a circle is fixed or not.

You can query every constraint using the GCE_ConstraintStatus API call to check for over-defined entities or conflicts. This function returns the constraint type as reported by C3D. Constraints categorized as Well-treated belong to the “well-treated” fragment without any extra constraints. Suppose some constraints are well-treated and well-conditioned. Note that constraints with the Well-conditioned status may also fall into the subset of redundant constraints that have the following three statuses: Well-conditioned, Ill-conditioned, and Redundant. The Redundant status means verified and confirmed redundancy, a positive result. Ill-conditioned is a preliminary check, when C3D Solver provides an approximate answer. Still, it draws the user’s attention to the system of constraints.

Types of Over Defined Constraints

Presumably redundant

C3D Solver can handle such cases. For preliminary analysis, It applies linear algebra methods to obtain a linear approximation of the linearized system of equations. The linearized system of equations indicates which equations may be redundant. C3D Solver makes assumptions about the redundancy. If the assumption is proven, the constraint gets the Redundant status, otherwise, it gets the Ill-conditioned status.

Proven Redundancy Cases

Detecting redundant equations is significant as it also accurately detects the number of degrees of freedom to let the user know which geometry is still under-defined. The main focus in the development of the C3D Solver diagnostic algorithms is to identify more Redundant cases and have fewer unproven Ill-conditioned type redundancy cases.

For example, what C3D Solver is good at is parallelism, perpendicularity, horizontal, vertical, collinearity, fixed angle, etc. constraints in various combinations. The Solver effectively identifies redundancies in such combinations and rejects them so they don’t interfere with the solution.

Algebraic geometry methods identify another class of proven redundancy. They detect nonlinear equations in the system that can be replaced by linear ones while preserving the set of solutions. It is easy to prove the redundancy in subsystems consisting of equations reduced to linear form.

Discrete mathematics methods also help detect Redundant constraints. An obvious solution is removing redundant constraints when the graph representing the distribution of degrees of freedom and constraints is overflown.

Redundancy of Invariant Constraints in Clusters

We have introduced a new, interesting case that we can handle: the cluster search algorithm. Clusters are subsets of geometric entities to which translation, rotation, and scaling transformations apply. As we apply these transformations, all the constraints remain satisfied (they are invariant). Redundant constraints can easily be found in such clusters. The image on the right shows the right-angled triangle ABC with redundant constraints that are invariant to translation. Therefore, the cluster must have only 2 translational transfer degrees of freedom (TDOF = 2) and 0 rotational degrees of freedom (RDOF=0). A cluster with such DoFs should have no more than 6-2=4 constraints. A fifth constraint, such as perpendicularity, should be removed as redundant. The other constraints are sufficient.

The left image shows a common engineering feature: a keyseat. We have improved the redundancy detection for exactly this kind of geometry. Consider the arc AB of radius R: the At a distance constraint is redundant. Finding redundancies is crucial for the efficiency of subsequent analysis. Note that the keyseat drawing with its At a distance constraints can be translated, rotated, and scaled.

To summarize: we have improved invariant class detection where the number of DoFs used to be underestimated. This is common when the user is just one click away from a completely defined drawing, but because there are redundant constraints, the system reports that the drawing is completely defined which is misleading. We have solved all such problems.

As a consequence, dragging is now enabled. Dragging means editing the drawing (as much as the DoF allows) by moving the handles with the mouse.

Another achievement is that in many cases the fuzzy Ill-conditioned status has been replaced by the proven Redundant status. We can safely ignore such constraints and even not bother the user unless the constraints lead to conflicts.

A pleasant surprise we’ve discovered through testing is the quick termination of calculations when the system has no solution. C3D Solver removes a redundant constraint that cannot be satisfied.

So, we discussed how C3D Solver detects and solves over-defined constraints. Please note that the quality of CAD geometry definitions is no less important.

This is especially true for typical elements available in mechanical CADs. Their constraint subsystems are generated not by the human but by the application. The image shows a keyseat with some parameters. If L is not fixed, the arcs can even be inverted as shown in the bottom image. To avoid this, add the L > 0 inequality using the GCE_AddBound API call to create a range constraint.

the curved groove is another similar example. It can also be “reversed” unless we apply the inequality stating that Rb must be greater than Ra. To do this, use the GCE_AddLinearEquation call, add a linear equation, and turn it into a linear inequality by adding a range constraint to one of its variables.

Zero-Length Segments

Another C3D Solver aspect we’ve advanced is the support for degenerate geometry.

The term “degenerate object” is not derogatory. Degeneracy is quite valid and even necessary. The drawing above shows that if we make the two vertical dimensions (30 and 50) equal to 30, the segment and arc must disappear. They are reduced to a point. We’ve made some enhancements to solve such cases. Another advantage is that when we create a 3D model from a 2D sketch, the model’s topology will be variable.

We’ve applied this improvement to the variable section sweep operation. In this case, C3D Solver generates each section using the cross-section geometry vs. position on the sweep path relationship. The image shows the original section as a rectangle with a fillet. The final section is a square. In real life, this could be a transition piece of an air duct. Now we can use degenerate geometry to construct such a model. A similar example: an L-shaped section is gradually transformed into a rectangle.

There are two API callback functions to be implemented in your application. They enable/disable each object individually to be degenerate. Example: a centerline is a dash-and-dot line that always divides a drawing into mirrored parts. A centerline segment would be meaningless if reduced to zero length. To avoid this, the CAD application should pass false when calling allowZeroLength for centerline segments.

Another function of interest is getLSegDirection. It is required when we need to restore the length of a degenerate, zero-length line segment that has lost its initial direction. Call getLSegDirection, and C3D Solver will store the segment direction.

Tangency Constraint

The curve tangency constraint how has a new option.

There are two versions of this constraint: the direction vectors at the point of tangency can coincide or be opposite. Previously, the tangent orientation was saved directly as the current arrangement of the geometry. This was acceptable until we faced cases where geometry was changed on the CAD side before it was even under C3D Solver’s control. The information about the side where one curve touched the other was lost.

The tangency side had to be explicitly specified. With the new GCE_COORIENTED and GCE_OPPOSITE options, you now can inform C3D Solver about the tangency type, and CAD can memorize the side where the curves touch. Let’s consider an example: the user intends to inscribe a circle in a fixed hexagon. If we move the hexagon before we add it to C3D Solver, the circle may get the wrong position.

There is a dedicated API call for this as well.

C3D Solver Thread Safety

Among others, we’ve improved the thread safety.

We received a customer report about a crash. It was hard to imagine because our solver runs like a Swiss watch, it never crashes. The testing indicated that it was a case of multithreading. To fix the issue, we complied have the following scale, where Level 0 means no thread safety. Level A means that C3D Solver can be called from different threads provided that the constraint systems are thread-isolated. As the complexity increases, B means full thread safety with no parallelization. Levels C1 and C2 mean there is parallelization.

3D Solver can solve isolated systems of equations in each thread. This is Type A thread safety.

2D Solver has already reached the C1 level. Most 2D Solver functions send some data to the solver. Such functions has ‘add’ in their names (refer to Fig. 18), e.g., GCE_AddLine, GCE_AddCircle, GCE_AddDistance, and others. The CAD system uses these functions to send a system of constraints to the solver. This is usually done right after reading a drawing/fragment file. CAD developers can significantly accelerate the opening of complicated drawings by calling these functions in individual threads.

For example, there are API calls to read data. After reading a document, the subsequent computation can be parallelized to run faster. The evaluate call waits until the last of the add calls are completed and stays non-parallelized because it is critical to enable secure shared access from different threads.

The list of improvements is not limited to this. Wait for more!