View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001519 | GCS | Bug | public | 2014-04-26 20:16 | 2018-04-27 22:46 |
Reporter | tempr | Assigned To | chrisb | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Platform | PC | OS | Windows Ultimate | OS Version | SP 1 |
Product Version | 0.14 | ||||
Summary | 0001519: Weird constraint behavior | ||||
Description | When 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 Reproduce | 1. 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 Information | My 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 | constraints, Solver | ||||
FreeCAD Information | |||||
|
|
|
SS are here (search for this text): "0001519 before:" http://forum.freecadweb.org/viewtopic.php?f=8&t=6400&start=20 |
|
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 |
|
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. |
|
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. |
|
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. |
|
"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 |
|
Is this still an issue? |
|
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. |
|
Reminder sent to: yorik @yorik wmayer replied above. Should we move this out of 'Feedback' ? How do you want to proceed ? |
|
@abdullah when you have time again for FC please weigh in? Thanks! |
|
@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. |
|
Works as designed. Issue originates from the misunderstanding of the difference between the notions "fully constrained" and "unique solution". |
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 |