Error in Sketcher/Solver

[chrisb]

The attached sketch has 2 DOF. The lower of the selected arcs can be moved (more or less) freely. It should be possible to reduce the number of DOF by setting an equality constraint between the two arcs.

Bildschirmfoto 2019-09-02 um 09.59.10.png (17.4 KiB) Viewed 2157 times

However, if I do so two things happen:
- the arc is correctly made equal
- I get a redundant constraint message.

This is wrong, because the equality consumes just one DOF

I was not able to simplify this sketch further so that it still shows this behaviour. So I'm asking for two things:
- confirmation of the described behaviour
- simplification of the sketch if possible.

I would have understood conflicting constraints, because the minimum radius seems to be what equality yields, but I don't understand redundancy.

[freman]

Thanks, I had not spotted that 2df. I had a lot of trouble with the four slotted holes in the same model. The sketcher was forever wanting to remove "unnecessary" constraints but then left the holes insufficiently constrained but in the right place. I am fairly sure that it was not displaying extra d.f. afterwards and this went unnoticed until something moved the slots and it became obvious they were not properly constrained. I had to repair the results of accepting automatic redundancy selection several times.

That would corroborate that d.f. counting may have a bug. It may be worth looking at that sketch too for clues.

If I highlight the two lines indicated and try to add an equality, it say "select a valid line". It seem is is the arc linking the two straight lines which it does not like. I'm unable to confirm what you did because it refuses to do the equality.

OK, I just went back and was able to do it ( no idea what had changed since I last looked before typing the above ). Now I get the same result. The new equality is the one it selects for removal. I think this must be how the sketch ended up in the state it did when I uploaded. I thought I had got the last df pinned down and did not notice that deleting the "redundant" constraints reintroduced 2df. Good catch.

OS: Linux (LXDE/LXDE)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.16988 (Git)
Build type: Unknown
Branch: master
Hash: ff7975291d33a88e6a8282b88a62dbcbcc01ba2b
Python version: 2.7.15
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedKingdom (en_GB)

[Roy_043]

It may be an intermittent issue:

1. Open the sketch.
2. Click on the Recompute tool.
3. Select the bottom arc and then the top arc.
4. Click on the Equal constraint tool.
5. If the error occurs click Undo and repeat from step 2.
6. After 0, 1 or 2 repeats I get the expected result: 1 LOF has been 'consumed'.

[chrisb]

If I highlight the two lines indicated and try to add an equality, it say "select a valid line". It seem is is the arc linking the two straight lines which it does not like. I'm unable to confirm what you did because it refuses to do the equality.

I don't think we recently had any changes in the sketcher so our different versions shouldn't matter here. I cannot provoke this message at all. I tried equality on arc/line, arc/point, arc/axis, line/point, line/axis and all error messages are very sensible.

Are you sure you applied equality and not parallel constraint?

[chrisb]

It may be an intermittent issue:

I like those issues even less than real errors .

[freman]

edge4 has a tangential constraint but can change in length. edge14 is free in x,y. The two are linked and there is only 2df.

setting radius manually to 26.5 is refused as is ( correctly ) any lesser value. poss rounding error issue?

Cannot set the datum because the sketch contains conflicting constraints

Setting 53mm to 50 to make the geometry more predictable, we can set rad to 25 manually, however this also gets picked up as "redundant". This should be a legitimate configuration since the length of vertex17 on edge14 still has 1df around the circle at rad=25.

If I change 53mm to 52 and apply the equality, it works and I have 1df.


edge10 and edge14 have a point coincidence on their common endpoint : vertex17 . If these two edges are given a tangent constraint, the coincidence is automatically removed ( and notified ) . The radial equality then works as expected and df=0.

It seems that some rounding errors are leading to false inequalities in tests which cause legit conditions to be rejected. Maths precision. Python vs C++ ?
Could this also be the root of the false redundancy claims? How is redundancy check for? Is this deep in the guts of someone else's libs?

[chrisb]

Could this also be the root of the false redundancy claims?

I think so.

How is redundancy check for? Is this deep in the guts of someone else's libs?

This is done in FreeCAD. Abdullah can tell you more, but he is busy with other stuff.

Until he returns you can search for a document which he has provided. I had it in an open browser tab since a long time, because I wanted to continue reading, but when my laptop crashed the other day, he lost all the tabs.

[DeepSOIC]

I can confirm the false redundant constraint. However, it appears to be essentially the same situation as with coincident+tangent constraint combo that we used to have all the time.

See that point that joins the arc with the line in the right? Solver has to solve for intersection there. And since they are tangent, that intersection is a double zero, which makes for a situation that looks like a redundant constraint in the gradient matrix. That is, the problem is likely unfixable.

[openBrain]

No explanations but some more trials (starting point is the chrisb's file as posted) :

• Applying a point-on-line between geometry arc endpoint and construction arc bugs in the same way
• Applying a tangency between geometry arc & right-connected geometry lines works OK
• If the "53 mm" distance is removed and construction arc defined with its radius instead, everything's back to normal working

How is redundancy check for? Is this deep in the guts of someone else's libs?

This is done in FreeCAD. Abdullah can tell you more, but he is busy with other stuff.
Until he returns you can search for a document which he has provided. I had it in an open browser tab since a long time, because I wanted to continue reading, but when my laptop crashed the other day, he lost all the tabs.

I remember also a post with a nice explanation about redundancy test. I'll try to find it back.

[freman]

I can confirm the false redundant constraint. However, it appears to be essentially the same situation as with coincident+tangent constraint combo that we used to have all the time.

See that point that joins the arc with the line in the right? Solver has to solve for intersection there. And since they are tangent, that intersection is a double zero, which makes for a situation that looks like a redundant constraint in the gradient matrix. That is, the problem is likely unfixable.

I was guessing that is was a matrix solution but didn't see much point in speculating blindly. That's why I was asking how it's done.

There are four circles linked with tangents in a similar way here. I doubt that one is giving a unique problem. As I pointed out above, when I add yet another tangent constraint it all starts working.

If there are numerical accuracy problems I can imagine an ill-conditioned matrix throwing false results. Looking into the numerical critical cases I highlighted above should help track this down. For example looking at values returned by equality constraint which work, when round number values from keyboard fail.

A few months ago I found a bug where trying to cut a 6mm trough with a 6mm endmill got refused in the UI. It was dismissed as not a bug since "you should not be doing like that anyway". My experience is that these kind of things are worth chasing down because they are pointers to underlying problems, even if they are not a major problem in their own right.

Possible related issue:
https://forum.freecadweb.org/viewtopic.php?t=35767