What exactly causes references to break?

[laukejas]

Hi, I am designing another boat (yeah, again) model as a non-removable male mold (core) for composite resin infusion. The model is reasonably complex (345 features), done with hybrid surface and solid modeling. The dimensions are not final, and I may need to adjust them many times over during the rest of the project development, so I tried my very best to make features parametric, robust and reliable, so I don't get rebuild errors when I start changing things.

But for some reason, I am completely failing at it, and I don't get why. To my understanding, SW tracks references through internal ID of various geometric elements (sketch elements, vertexes, edges, faces, etc.). If modifying a dimension causes some element to disappear, then it's very logical that it results in an error.

However, I'm observing that even when I make absolutely tiny dimension changes that do not cause any geometric elements to disappear, model still breaks into pieces with tons of broken reference errors.

Note that if I do a forced CTRL+Q rebuild, nothing breaks, indicating that references are generally fine and there are no hidden errors in the tree.
However, if I'm modifying a dimension that has a very tiny impact on the geometry, and most certainly does not cause any elements to disappear...

...then everything is broken instantly. Which makes no sense because all geometric elements should be preserved, so no IDs should be changing.

Iterating through the errors, this is the behavior I observed:

1. Edge and face references become dangling;
2. Loft and Boundary features say "Please check input curves", although those curves are not dangling, and simply re-selecting them fixes the error;
3. Trim Surface loses reference of pieces to keep and delete (inverts them);
4. Fill Surface simply deletes the edges that were previously selected and then complain about it;
5. Merge Result and Combine lose body references or refer wrong body;
6. Sketch elements created with Convert Entities and Intersect go dangling as well.
Etc...

So for whatever reason whenever I make even a tiny change to the dimensions, it appears that SW shuffles these IDs around, and I can't find any obvious pattern as to why this occurs.

Now, I know my model is a bit dirty and I could improve it further (reduce the number of features, use less surfacing tools, reference sketch elements instead of solid/surface geometry, etc.), but these errors should not be appearing in the first place, because again, making these tiny dimensional changes should not destroy any IDs.

So I find myself repairing tons of features every time I need to make an adjustment to the model. I do try to utilize Display/Delete Relations and Replace Entity to preserve IDs as much as possible, but it is still a major headache.

Can anyone take a look at my model, and help me understand why SW behaves like this? File was saved in 2024 SP3.1 (yeah, I was forced to update), so if you can't open it, maybe you can give some general insights into why this tends to happen?

[matt]

This is something I've run into on most complex projects eventually. Edges will sometimes change types. For example from a circle to an ellipse or ellipse to spline. This can cause the reference to be lost. Also a single edge may turn into multiple edges due to tolerance values in a trim feature.

One thing I try to do is to use references as high up the tree as possible. For example use a sketch instead of the edge of a feature it creates.

Its a huge waste of time that just changes for reasons that are hard to understand or predict.

[laukejas]

This is something I've run into on most complex projects eventually. Edges will sometimes change types. For example from a circle to an ellipse or ellipse to spline. This can cause the reference to be lost. Also a single edge may turn into multiple edges due to tolerance values in a trim feature.

One thing I try to do is to use references as high up the tree as possible. For example use a sketch instead of the edge of a feature it creates.

Its a huge waste of time that just changes for reasons that are hard to understand or predict.

Good point on the edges changing type. But in this instance, where I'm making a tiny change to a dimension, shouldn't cause that either. As far as I checked, all edges retain the same type. I'm completely at a loss of what is causing these losses of references here. Hopefully someone can share some insights into what SW is doing here and why.

As for the using references high up the tree - I try to do that as well wherever possible. But often it's not, for example if I need to do a Loft/Boundary/Fill between surfaces with C1 or C2 continuity - there is no choice then but to reference edges and faces. There are lots of cases like that in this model I uploaded.

[Jim Elias]

The best way to figure these things out is to roll back to the point you want to change, then roll down the tree step-by-step after changing.

If you change the parameter in your screen-shot ("Wing plan"), the following errors occur:

1) Sketch86 under Surface-Trim22 throws a tangency unsolvable. This is annoying but doesn't seem to be fatal, and will likely just have to be dealt with each time by deleting and replacing the tangency.

2) Bigger problem: the edge geometries for both Boundary-Surface11 and Surface-Loft19 don't seem to be reliable for these operations, and when those surfaces don't form and knit, that's what causes everything downstream to fail. In this case, it seems that it's better to create 3D-sketches, do Convert Entities on the surface edges and then use these 3D-sketches as open loops to create the surfaces.

It's probably going to be unavoidable that some sketches are going to continue to throw tangency errors with the splines, SW is just weak there. But the catastrophic failure associated with changing D1 of "Wing plan" seems to be solved with using the 3D-sketches instead of the edges.

[laukejas]

The best way to figure these things out is to roll back to the point you want to change, then roll down the tree step-by-step after changing.

If you change the parameter in your screen-shot ("Wing plan"), the following errors occur:

1) Sketch86 under Surface-Trim22 throws a tangency unsolvable. This is annoying but doesn't seem to be fatal, and will likely just have to be dealt with each time by deleting and replacing the tangency.

2) Bigger problem: the edge geometries for both Boundary-Surface11 and Surface-Loft19 don't seem to be reliable for these operations, and when those surfaces don't form and knit, that's what causes everything downstream to fail. In this case, it seems that it's better to create 3D-sketches, do Convert Entities on the surface edges and then use these 3D-sketches as open loops to create the surfaces.

It's probably going to be unavoidable that some sketches are going to continue to throw tangency errors with the splines, SW is just weak there. But the catastrophic failure associated with changing D1 of "Wing plan" seems to be solved with using the 3D-sketches instead of the edges.

Thank you for your suggestion, I'd like to clarify on several things:


1. If I use 3D sketches for Boundary/Loft, I won't be able to create C1 / C2 continuity, which is essential here. In some cases it can be approximated with a tangency vector (for C1 only), but not with more complex surfaces where that vector changes along the edge. How do I solve this?

2. If I were to use 3D sketches (I assume you meant by using Convert Entity on the edges), then the lines in these sketches will still go dangling because the underlying edges change their type / ID. It can sometimes be repaired with Display/Delete Relations tool, but more often than not, it won't allow me to select the edge for a new reference. In these cases I'm forced to re-Convert that edge and use Replace Entities to transfer the old ID, but more often than not that doesn't work properly either.

[Jim Elias]

Thank you for your suggestion, I'd like to clarify on several things:


1. If I use 3D sketches for Boundary/Loft, I won't be able to create C1 / C2 continuity, which is essential here. In some cases it can be approximated with a tangency vector (for C1 only), but not with more complex surfaces where that vector changes along the edge. How do I solve this?

2. If I were to use 3D sketches (I assume you meant by using Convert Entity on the edges), then the lines in these sketches will still go dangling because the underlying edges change their type / ID. It can sometimes be repaired with Display/Delete Relations tool, but more often than not, it won't allow me to select the edge for a new reference. In these cases I'm forced to re-Convert that edge and use Replace Entities to transfer the old ID, but more often than not that doesn't work properly either.

re: 1) I think you should have the same tangency control options when using 3D-sketch geometry as well. YMMV depending on the exact conditions. In this case, the tangency of those two surfaces is nailed to whatever is inherent to the boundary geometry, there is no additional continuity "created" by the surface operations.

re: 2) When using the 3D-sketch method with the two surfaces in question, the model then digested the changes to D1 of "Wing plan" without much of a fuss. Sketch221, VarFillet5, Sketch183 and Sketch186 all needed to be repaired once due the references getting swapped (i.e. from edge to 3D-sketch entity) but then stayed ok after that. Sketch86 looks like it will unfortunately always have issues with the spline tangency constraint, maybe there's some other way to define this without that type of constraint... SW is always weak with those.

In any case, the general debugging strategy at the start should be to get Surface-Knit33 stable, it's the gatekeeper for everything downstream. (Just try suppressing it and see what happens.)

i.e. if Surface-Knit33 ever fails again, Undo the change that caused the fail, roll back to Surface-Knit33 and then start looking upstream of there until Surface-Knit33 consistently builds the solid.

[laukejas]

re: 1) I think you should have the same tangency control options when using 3D-sketch geometry as well. YMMV depending on the exact conditions. In this case, the tangency of those two surfaces is nailed to whatever is inherent to the boundary geometry, there is no additional continuity "created" by the surface operations.

re: 2) When using the 3D-sketch method with the two surfaces in question, the model then digested the changes to D1 of "Wing plan" without much of a fuss. Sketch221, VarFillet5, Sketch183 and Sketch186 all needed to be repaired once due the references getting swapped (i.e. from edge to 3D-sketch entity) but then stayed ok after that. Sketch86 looks like it will unfortunately always have issues with the spline tangency constraint, maybe there's some other way to define this without that type of constraint... SW is always weak with those.

In any case, the general debugging strategy at the start should be to get Surface-Knit33 stable, it's the gatekeeper for everything downstream. (Just try suppressing it and see what happens.)

i.e. if Surface-Knit33 ever fails again, Undo the change that caused the fail, roll back to Surface-Knit33 and then start looking upstream of there until Surface-Knit33 consistently builds the solid.

Ok, I am attempting to do what you described, but I can't seem to get it working. How did you manage to get it working? This is what I did:

1. Roll back to before Boundary-Surface11, create two 3D sketches to convert the original edges;
2. Modify Boundary-Surface11 to use these sketches - this causes Surface-Loft19 to fail.
3. Roll forward to before Surface-Loft19, again add two 3D sketches to convert the original edges;
4. Modify Surface-Loft19 to use these edges;
5. Roll forward - everything in the Feature Manager fails to rebuild, starting with Surface-Trim73, which swapped which piece of the surface should be kept.

[Jim Elias]

I only created one 3D-sketch each, but that shouldn't make a difference.

After making these changes and rolling to end:

Model should rebuild ok. Surface-Trim73 didn't have an issue.
-> Sketch144 will go yellow (point needs replacing)
-> Sketch183 will go yellow (point needs replacing)
-> VarFillet5 will go red (edges need re-selecting)

[Jim Elias]

5. Roll forward - everything in the Feature Manager fails to rebuild, starting with Surface-Trim73, which swapped which piece of the surface should be kept.

There's no point in rolling forward of Surface-Knit33 if it's failed (in fact, it's better if you stay rolled back there and don't give the tree downstream of Surface-Knit33 the chance to fail).

I don't know why you're having the problem with Surface-Trim73 when I'm not, but probably most expedient just to fix it. The main thing is getting Surface-Knit33 to behave, i.e. before rolling any further forward.

[laukejas]

There's no point in rolling forward of Surface-Knit33 if it's failed (in fact, it's better if you stay rolled back there and don't give the tree downstream of Surface-Knit33 the chance to fail).

I don't know why you're having the problem with Surface-Trim73 when I'm not, but probably most expedient just to fix it. The main thing is getting Surface-Knit33 to behave, i.e. before rolling any further forward.

Thank you very much, it actually appears that whether you make 1 or 2 3D sketches matters in this instance, but repairing that feature fixed it.

Regarding tangency - yeah, SW doesn't seem to do this well. Sometimes CTRL+Q fixes these "overdefined" sketches (which really are not), sometimes no. What I tend to do in these situations is to first create another sketch (before the main one), containing only one line which is tangent to the edge, and in the main sketch, make whatever I need tangent to that line, rather than the edge. Basically breaking down that sketch into two, using that line as an intermediary. This typically solves such issues.

Your suggestions helped make this model more robust, but I'm still observing rebuild errors when I change various dimensions. In some cases CTRL+Q fixes it, but not always. For example, if I change D2@Transverse wing curve from 12° to 12.1° (again, very small change, shouldn't cause any edges to disappear)...

Then everything breaks, starting with VarFillet6, which is failing for no apparent reason. I tried this several times, and in one instance it didn't fail, but then Surface-Fill5 failed, losing it's edges. When it comes to Fill, I can't really use the 3D sketch approach, since it does require tangent/curvature relation to the adjacent surfaces. Do you have any advice on how to prevent these errors?

[Jim Elias]

Then everything breaks, starting with VarFillet6, which is failing for no apparent reason. I tried this several times, and in one instance it didn't fail, but then Surface-Fill5 failed, losing it's edges. When it comes to Fill, I can't really use the 3D sketch approach, since it does require tangent/curvature relation to the adjacent surfaces. Do you have any advice on how to prevent these errors?

VarFillet6 is likely failing because the math had already ended up on the edge of being able to calculate the overflow. (Try "Keep Edge" under Overflow to see what happens when you sidestep the issue)

Try an R80 face fillet, and explicitly add the overflow face to the relevant set:

You'll probably want to switch to Flat Tree View because you'll want to roll back to right under 3DSketch19 when you do this, for reasons that will become obvious.

[gristle]

Have you run an evaluate/check on the geometry? I have found some knit errors arise from a general error or inconsistent edge, which can be narrowed down by rolling back feature by feature and re-running the check.

Fill surface. I once found this to randomly change resultant edge ID's. Very Random, hard to trouble shoot.

Tangent constraint failure. As you said, pre-compose the reference into a sketch prior to the one with the spline. Another work around is to use a construction curve, perpendicular to the reference edge/curve, then make the end of the spline perpendicular to the construction curve. Depending on how fussy SW is feeling, this may also need to be 'pre-composed'. This also applies when using G2/3 constraints, as it always seems to be the tangent constraint that is causing the issue. The 'pre-compose' approach will also get around the odd times when G2 constraint is not available in 3D sketches. That is a weird one.

Good luck, looks like a great project to work on!

[laukejas]

VarFillet6 is likely failing because the math had already ended up on the edge of being able to calculate the overflow. (Try "Keep Edge" under Overflow to see what happens when you sidestep the issue)

Try an R80 face fillet, and explicitly add the overflow face to the relevant set:

001-Hull-01-Shape_FaceFillet.jpg

You'll probably want to switch to Flat Tree View because you'll want to roll back to right under 3DSketch19 when you do this, for reasons that will become obvious.

That worked really well. In that particular instance I actually want the "Keep Surface" option, because with "Keep Edge" stops the fillet short of the edge of the first face. But it's ok, I figured out why it was failing. Face Fillet seems to work far better in this case than the regular fillet.

Although I still get some lost references when I change other things, the help you provided reduced my workload massively. Thank you for taking the time to analyze my model and write all that up.

Have you run an evaluate/check on the geometry? I have found some knit errors arise from a general error or inconsistent edge, which can be narrowed down by rolling back feature by feature and re-running the check.

Fill surface. I once found this to randomly change resultant edge ID's. Very Random, hard to trouble shoot.

Tangent constraint failure. As you said, pre-compose the reference into a sketch prior to the one with the spline. Another work around is to use a construction curve, perpendicular to the reference edge/curve, then make the end of the spline perpendicular to the construction curve. Depending on how fussy SW is feeling, this may also need to be 'pre-composed'. This also applies when using G2/3 constraints, as it always seems to be the tangent constraint that is causing the issue. The 'pre-compose' approach will also get around the odd times when G2 constraint is not available in 3D sketches. That is a weird one.

Good luck, looks like a great project to work on!

Yeah, I do run Evaluate/Check pretty often. It seems that with complex geometries, SW often fails to detect that a certain feature generated an invalid geometry (self intersecting, non-Euclidean, etc.), letting that feature complete without explicit errors, so Check is very useful. I sometimes turn on Verification on Rebuild, but generally it slows down everything too much.

Interesting idea on that tangent constrain with the perpendicular relation! I always thought that perpendicular on splines is even more complex than tangent (because it's basically adding a 90° turn to a tangent), so it's surprising that you say it solves better. I will try this, thank you.


Since the way SW handles these IDs seems so mysterious, does anyone know if there is any way to expose the IDs of geometric elements to make them visible to the user? Maybe through API? It would be interesting to try and investigate how these IDs change with various features and workflows to try and identify some logic of why these losses of reference occurs.

[Frederick_Law]

To my understanding, SW tracks references through internal ID of various geometric elements (sketch elements, vertexes, edges, faces, etc.).

From my experience, SW doesn't track ID. It just use item index.
First one created is 1, second is 2.
So if there are 10 items, deleting the last one: 10 will not cause any problem.
Deleting the first one: 1 will cause all other to lose reference.

Everything start with sketch. Everything down the line changes.

[RichGergely]

What you can to to get past some of these problems where it looses reference on things splines is do the following - Use convert line to edges in sketch, then do the ungodly thing of fixing the geometry. Now you should be able to use that fixed convert edge reference without fear of it failing on rebuild.

The rather obvious thing in doing this is yes it stops that annoying rebuild error but you have lost the ability to update it.