Parametric constraint can be changed only one way for fully constrained sketch (Needs friendlier error/warning message)

[FreeCAD-Bug-Importer]

Issue imported from https://tracker.freecad.org/view.php?id=4154

• Reporter: axos88
• Date submitted: 10/5/2019
• FreeCAD version: 0.18
• Category: Bug
• Status: new
• Tags: #pending-forum

Original report text

I've a sketchup drawing with named constraints. Increasing the constraint value works, decreasing it does not. (Increasing to a value and then trying to change back is broken too).

I've encountered this bug in many forms, if the R is not a radius constraint but one of the length constraints (see file 2), it's not possible to change the value AT ALL.

Additional information

OS: Windows 10
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.16131 (Git)
Build type: Release
Branch: releases/FreeCAD-0-18
Hash: 3129ae4
Python version: 3.6.6
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/UnitedKingdom (en_GB)

Steps to reproduce

1. Open attached file
2. Open sketcher with the "Sketch"
3. Change constraint R to 4mm
4. Change constraint R back to 3mm

Observe error: Negative datum values are not valid for the constraint with index 10 (That is the R constraint).

Expected: Change back obviously.

Other bug information

• Priority: normal
• Severity: minor
• Category: Bug
• Platform: Windows 10
• Updated: 2/6/2021

Discussion from Mantis ticket

Comment by openBrain 2019-10-07 10:46

axos88 thanks for reporting. According the guidelines (big yellow box on top of page), could you please first post to forum so your findings can be discussed ?
Notice that despite what you found can lead to interesting corner case tests, your sketch is very very lamous. It's highly suboptimal, and I could have bet just by seeing it that it can seriously hurt the solver. :)

EDIT : JFYI, you're cumulating 2 known corner cases.
1 - Setting equal radius and horizontal/vertical distance on an arc
2 - Having tangent arc/line obtained by construction but not by constraint

---

Comment by axos88 2019-10-07 17:02

openBrian, thanks for getting back to me. Sorry for not asking in the forum first, I understood it's for verifying and prefiltering wether reports are actually bugs, and it was pretty straightforward that this is.

I'll do that now, I'm curious why my sketch would be lamous and suboptimal and to learn how to do it better.

I'm not sure I understand the second corner case you mentioned, but I'm sure I'll get an answer there.

---

Comment by openBrain 2019-10-07 17:09

axos88 actually the problem with direct reporting is that there is high chance that your "bug" is known & already reported. ;) Also it can be a known limitation.
Once you open a forum topic, may you please cross-reference it in this ticket ? Thx

---

Comment by axos88 2019-10-07 17:13

Once it gets approved, and I get a link to it, yes, of course.

---

Comment by Kunda1 2020-10-08 01:12

axos88 link to forum thread?

[adrianinsaval]

Judging solely from the discussion it seems this is about known limitations, not sure if it should remain open

[chennes]

For reference: https://forum.freecadweb.org/viewtopic.php?f=8&t=39904

[adrianinsaval]

The error message is very poor, it talks about an invalid constrain index, how is that interpreted? Maybe what's happening is that it tries to solve before evaluating the expressions, leading to an invalid set of constrains (although the constraining is VERY bad to begin with)

[adrianinsaval]

@abdullahtahiriyo @AjinkyaDahale what do you think of this issue? should we keep it open? I'm inclined to consider this user error and close it. I believe the problem comes from having these horizontal and vertical distance constraints with expressions bound to the radius of the circle:

I believe when you change the radius constraint, sketcher tries to solve this before evaluating the expressions
If the value goes up the constraint is still valid even without updating the expressions so it is accepted then leads to the expected result once the expressions are evaluated.
If the value goes down the constraint is invalid in combination with the not updated constraints so the change is rejected before ever evaluating the expressions

I came to this conclusion after removing the expressions and then testing the behavior when changing the radius value without changing or after having changed the distance values manually.

[abdullahtahiriyo]

I think your assessment is correct. However, we should probably look into the error message. We need to provide more meaningful error/warning/information messages to the user. That would reduce the number of issues due to cryptic misunderstood messages.

This one could probably go in the lines of converting the "developer information" to a log and creating a user notification indicating that "the solver cannot find a solution meeting the dimensional constraint"...

[adrianinsaval]

Actually now thinking again about this, can't we evaluate expressions before running the solver?

Certainly the constraint strategy here was incorrect, but the principle of having constraints with expressions is ok and it's desirable to have them evaluated before trying to solve the sketch

[abdullahtahiriyo]

I have not checked the trace of what is evaluated when and I do not know it by heart. What you say makes sense to me.

I am ok with leaving it to further investigate the issue. If anybody feels enthusiastic, checking what triggers what with a debugger should not be very cumbersome...