View Issue Details

IDProjectCategoryView StatusLast Update
0001519PartDesignBugpublic2017-01-21 13:46
ReportertemprAssigned To 
PrioritynormalSeverityminorReproducibilityalways
Status feedbackResolutionopen 
PlatformPCOSWindows UltimateOS VersionSP 1
Product Versiontrunk 
Target VersiontrunkFixed in Version 
Summary0001519: Weird constraint behavior
DescriptionWhen changing one constraint dimension on the (apparently) fully constrained sketch from negative to positive (X axis) value sketch gets "reversed".
If you gradually change the values on the constraint it retains it original orientation.
Steps To Reproduce1. Open the attached file
2. Edit the Sketch001 sketch
3. Change the horizontal constraint with the -100 value to 100 (also try changing from -100 to -50 then to 50 then to 100)
Additional InformationMy FreeCAD build info:

OS: Windows 7
Platform: 32-bit
Version: 0.14.3389
Python version: 2.6.2
Qt version: 4.5.2
Coin version: 3.1.0
SoQt version: 1.4.1
OCC version: 6.5.1


I have also tried it on this unofficial build with same results (bug):

OS: Windows 7
Platform: 32-bit
Version: 0.14.3343 (Git)
Branch: libpack
Hash: 8dcb8f68cf17ef152d34d226d7699c98c5bb59fb
Python version: 2.7.6
Qt version: 4.8.5
Coin version: 3.1.3
SoQt version: 1.5.0
OCC version: 6.7.0
Tags#pending

Activities

2014-04-26 20:16temprNew Issue
2014-04-26 20:16temprFile Added: test4.FCStd

tempr

2014-04-26 20:16

reporter  

test4.FCStd (7,271 bytes)

tempr

2014-04-26 21:40

reporter   ~0004581

SS are here (search for this text):
"0001519 before:"

http://forum.freecadweb.org/viewtopic.php?f=8&t=6400&start=20
2014-04-27 14:00jmaustpcPriorityhigh => normal
2014-04-27 14:00jmaustpcSeveritymajor => minor

jmaustpc

2014-04-27 14:30

manager   ~0004585

I can confirm this behaviour with the version below.


OS: Ubuntu 14.04 LTS
Platform: 64-bit
Version: 0.14.3476 (Git)
Branch: master
Hash: 3ceb840f5dc1570a6b1d7cdb2295f7f1becf33b6
Python version: 2.7.6
Qt version: 4.8.6
Coin version: 4.0.0a
SoQt version: 1.6.0a
OCC version: 6.7.0


However to label this as high priority and major, I believe is in appropriate, so I lowered both by one setting. With best practice modelling techniques I think this would be unlikely to show up often, but even if others disagree with that, it is easy enough to work around....its certainly a bug but not a massive show stopper
2014-04-27 15:21jmaustpcProduct Version0.13 => trunk
2014-04-27 15:21jmaustpcTarget Version => trunk

tempr

2014-04-27 16:34

reporter   ~0004587

Last edited: 2014-04-27 16:36

View 5 revisions

IMO, that option should be taken away from the reporters. :) To be honest, in most cases I didn't know what to put there. Since this was a bug in a part of the program that was supposed to be precise with no margin for error (constraints), I have marked it as major.
And I agree, it isn't a show stopper.

About the other bug (0001520) i still believe it is a highest-priority issue (it doesn't crash but...) as I have noticed while doing a revisit - it changes the work-plane of the mapped sketch completely (to something non-existant, invalid). It also happens if you try to create a new sketch on the selected face.
I would mark this one as a show stopper.

2014-04-27 16:34temprNote Edited: 0004587View Revisions
2014-04-27 16:35temprNote Edited: 0004587View Revisions
2014-04-27 16:35temprNote Edited: 0004587View Revisions
2014-04-27 16:36temprNote Edited: 0004587View Revisions

wmayer

2014-05-20 18:03

administrator   ~0004711

The solver works properly because all constraints are respected but nevertheless gives you an unexpected result.

An easy way to avoid the flip is to remove the horizontal constraint (e.g at the bottom) and set an angle constraint of the bottom line and the Y axis and set this angle to 90 deg.

This way the sketch has no chance to flip any more.

ickby

2014-05-21 05:35

developer   ~0004715

The sketch has multiple solutions, and the one with the smallest overall change in parameters is the one the sketcher will most likely find. That is an property of the nonlinear numeric solving method. The only way around is to implement an algorithm which breaks down the value change in multiple small changes and calls the solver for each small step. It may not even be too slow, as solving is way faster than conflict checking which would not be needed for every step and therefore overall time may only increase slightly. Don't know if this is a feasible solution, though.

tempr

2014-05-22 03:04

reporter   ~0004721

Last edited: 2014-05-22 03:04

View 3 revisions

"The solver works properly..."

I know that there are workarounds but shouldn't the "end product" be without these shortcomings? Maybe (probably) the code does what it was supposed to do but couldn't it be improved? I don't know if it is easy to implement a better solution (algorithm), I am just giving my opinion from a spoiled end-users perspective. :D

2014-05-22 03:04temprNote Edited: 0004721View Revisions
2014-05-22 03:04temprNote Edited: 0004721View Revisions

yorik

2016-03-06 02:45

administrator   ~0006882

Is this still an issue?
2016-03-06 02:45yorikStatusnew => feedback

wmayer

2016-03-06 12:12

administrator   ~0006884

The reported issue is still reproducible.

The question is if and how we want to handle such issues. The basic problem is that from the constraints we have a target function may have several local optimums. If input values are changed too heavily then it easily happens that the new optimal solution is completely different to the previous optimal solution.

I don't know if it's (feasibly) doable to start from the last optimal solution and introduce some kind of penalty function and the more different the new solution is the higher the penalty value. However, therefore we then need several optimums for comparison and this I guess will increase computing time a lot.

After all the algorithm works correctly and for >95% the output is what the user expects. So the question: is it really worth to increase computation for only <5% of all cases where we have problems with. And not to forget: here we have a case that can be easily fixed by setting further constraints which stops the solver from mirroring the sketch.
2017-01-21 13:41Kunda1Tag Attached: #pending

Kunda1

2017-01-21 13:46

manager   ~0007906

Reminder sent to: yorik

@yorik wmayer replied above. Should we move this out of 'Feedback' ? How do you want to proceed ?

Issue History

Date Modified Username Field Change
2014-04-26 20:16 tempr New Issue
2014-04-26 20:16 tempr File Added: test4.FCStd
2014-04-26 21:40 tempr Note Added: 0004581
2014-04-27 14:00 jmaustpc Priority high => normal
2014-04-27 14:00 jmaustpc Severity major => minor
2014-04-27 14:30 jmaustpc Note Added: 0004585
2014-04-27 15:21 jmaustpc Product Version 0.13 => trunk
2014-04-27 15:21 jmaustpc Target Version => trunk
2014-04-27 16:34 tempr Note Added: 0004587
2014-04-27 16:34 tempr Note Edited: 0004587 View Revisions
2014-04-27 16:35 tempr Note Edited: 0004587 View Revisions
2014-04-27 16:35 tempr Note Edited: 0004587 View Revisions
2014-04-27 16:36 tempr Note Edited: 0004587 View Revisions
2014-05-20 18:03 wmayer Note Added: 0004711
2014-05-21 05:35 ickby Note Added: 0004715
2014-05-22 03:04 tempr Note Added: 0004721
2014-05-22 03:04 tempr Note Edited: 0004721 View Revisions
2014-05-22 03:04 tempr Note Edited: 0004721 View Revisions
2016-03-06 02:45 yorik Note Added: 0006882
2016-03-06 02:45 yorik Status new => feedback
2016-03-06 12:12 wmayer Note Added: 0006884
2017-01-21 13:41 Kunda1 Tag Attached: #pending
2017-01-21 13:46 Kunda1 Note Added: 0007906