View Issue Details

IDProjectCategoryView StatusLast Update
0001519GCSBugpublic2018-04-27 22:46
Reportertempr Assigned Tochrisb  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
PlatformPCOSWindows UltimateOS VersionSP 1
Product Version0.14 
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
Tagsconstraints, Solver
FreeCAD Information

Activities

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

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

tempr

2014-04-27 16:34

reporter   ~0004587

Last edited: 2014-04-27 16:36

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.

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

"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

yorik

2016-03-06 02:45

administrator   ~0006882

Is this still an issue?

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.

Kunda1

2017-01-21 13:46

administrator   ~0007906

Reminder sent to: yorik

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

Kunda1

2017-08-23 12:05

administrator   ~0010000

@abdullah when you have time again for FC please weigh in? Thanks!

abdullah

2017-12-12 15:20

manager   ~0010588

Last edited: 2017-12-12 15:21

@Kunda1

I could just repeat what Werner said. It is a solver issue.

I have an idea for a potential solution. If the solver cannot be improved or we cannot improve it or we are not sufficiently motivated, what we could theoretically do is detect strong value changes and force a progressive change (basically programatically do what the work-around is). So if a change involves a change to a parameter of more than a 50%, programatically do a first solve by exactly 50% and then as many 50% additional solves as needed to cover the whole change. 50% is just a guess, but we could get a better guess by running all the examples we are storing in the bug tracker regading jumps and similar.

Way forward?
Create a Solver Project move it there, put it in priority low severity minor and wait for a rainy day, weekend, winter... ;)
I think we need to create a solver (gcs) project.

chrisb

2018-04-27 22:46

developer   ~0011215

Works as designed. Issue originates from the misunderstanding of the difference between the notions "fully constrained" and "unique solution".

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
2014-04-27 16:35 tempr Note Edited: 0004587
2014-04-27 16:35 tempr Note Edited: 0004587
2014-04-27 16:36 tempr Note Edited: 0004587
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
2014-05-22 03:04 tempr Note Edited: 0004721
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
2017-05-03 12:50 Kunda1 Tag Attached: Solver
2017-05-09 03:05 normandc Project PartDesign => Sketcher
2017-05-13 12:16 Kunda1 Tag Detached: #pending
2017-08-23 12:05 Kunda1 Note Added: 0010000
2017-08-23 12:07 Kunda1 Product Version trunk => 0.14
2017-08-23 12:07 Kunda1 Target Version trunk =>
2017-09-27 12:19 Kunda1 Tag Attached: constraints
2017-12-12 15:20 abdullah Note Added: 0010588
2017-12-12 15:21 abdullah Note Edited: 0010588
2017-12-13 15:20 Kunda1 Project Sketcher => GCS
2018-04-27 22:46 chrisb Assigned To => chrisb
2018-04-27 22:46 chrisb Status feedback => closed
2018-04-27 22:46 chrisb Resolution open => fixed
2018-04-27 22:46 chrisb Note Added: 0011215