=========================================================================
What?
Sometimes this widgets where out of sync
Why?
Under the update only when it is redrawn policy, sometimes only one of them, i.e. the one associated with the property
triggering the updateData was updated.
Solution:
Both are updated after every redraw.
It also complements the previous bug fix related to crash on deleting, by updating the widgets to account for the deleted geometry.
==========================================================
Fixes the one reported by JMG here (Thanks!!):
http://forum.freecadweb.org/viewtopic.php?f=3&t=11508#p92693
Why?
- The newly introduced redrawing policy requires that the solver geometry matches in number the sketchobject geometry.
- Most (all) problems with updateColor or getGeometry returning a null pointer are related to an out of sync between UI geometry and SketchObject geometry.
General solution:
- In other bugs, a missing "solve()" is the problem, once the solver and sketchobject geometries have the same number, an SketchObject::OnChanged triggers
a VPSketch::draw (via VPSketch::updateData) which updates the UI geometry to match SketchObject geometry and then the problem does not arise.
Particular solution:
- In this bug, the problem is not a missing solve, but the fact that the solving was not succesful and did not synchronize the geometries, however triggering a
draw() on unsuccessful solving, syncronizes the UI geometry with the SketchObject geometry and the crash is gone.
=======================================
The SparseQR is set as default method. However, in accordance with the previous commit, only if a new enough Eigen library is present will SparseQR be executed.
If the library is old and SparseQR can not be reliably used, FC will automatically fall back to use DenseQR.
This ensures that users that have a new enough library > 3.2.2 will benefit from the performance increase, while the users that use older library will still have
the same performance as in legacy FC.
==========================================
For Eigen>=3.2.2 SparseQR is compiled in
For older versions SparseQR is not compiled in and if the option is selected FC gives a warning in the console and falls back to DenseQR.
This ensures that a user can get a sketch solved and work normally even if SparseQR is selected and the Eigen version is too old to support SparseQR.
================================================================
A new parameter added to the form in order to control how low a value should be
to be considered zero (how high a value shall be to be accounted for in rank calculation)
Debug for QR pivot threshold is also added.
===================================
Eigen currently only provides multithread for matrix products. It has been reported that it is even slightly slower than single-thread.
Therefore, temporarely the code is commented out. If Eigen ever implements multithread for QR decomposition, then it will make a lot of
sense to enable this.
==================================================================
It allows the view sketch perpendicular button to be active during continuous mode creation (and if activated does not exit the continuous mode).
Feature requested:
http://forum.freecadweb.org/viewtopic.php?f=10&t=11051&start=30#p92256
=============================================
EigenQR branch 3.2 with debug code fails an assertion. The result is generally ok if we disable the assertions, however it
eventually leads to memory leakage.
This commit reenables Eigen's assertions when in debug mode, and sets dense QR as default QR algoritm until Eigen's issue is solved.
==================================================
- ternary operator usage was making BFGS not to iterate
- Amount of debug information for BFGS increased
============================================================
This enables to exit the sketch by clicking the corresponding toolbar icon, even when in creation mode, i.e.
with a drawHandler active.
Requested here:
http://forum.freecadweb.org/viewtopic.php?f=10&t=11051&start=30#p92181
===============================================
- Increased solver debug
- Changing default values from float to string, as float has "only" a precision of 12 decimals.
- Default values as macros
===========================================
- Improvement Debug added to redundant solving in Iteration Mode, to show when just one iteration solved the system
- Fix wrong QR information on empty sketch
===================================================
I makes the advanced solver taskbox by default disabled (not shown) and provides
a setting in Preferences->Display->Sketcher to enable it.
==================================================================================
The solver has been adapted to use Eigen's SparseQR QR decomposition algorithm. The original
Dense QR implementation is maintained and can be selected using the Advanced Control TaskBox (see below).
The use of SparseQR provides over an order of magnitude improvement in solving time in complex sketches due to
the Sparse nature of the Jacobian matrix of the system of equations.
The solver advanced control is a new TaskBox in the Sketcher that allows to select which algorithms are to be used for
the different solving operations and tweak its parameters. It is not intended to be a user control, but means to debug
solving problems and improve the algorithms and their configuration.
This commit also introduces multithread support for Eigen. Currently it is only limited to products and does not provide
a substantial speed improvement. It is expected to have more multithreaded operations in Eigen in the future.
As a bonus, the TaskBoxes in the Taskbar of the Sketcher remember the last state (collapsed or deployed).
===============================================================
The sketcher crashed for example during effecting a fillet operation.
Cause:
The ElementsWidget/ConstraintWidget was being updated as a consequence of adding/removing geometry/constraints, and it was effecting
a selection after the update, in cases where the geometry in the screen was not being redraw (because the sketchobject was still unsolved), therefore
trying to select an element that according to ViewProvider did not exist (as it is created during redraw).
Solution:
Widgets update when their properties changes, provided that a redraw is effected (which actually also saves some (negligible) time, as they are only updated when they should).
======================
In no update mode, the last constraint was not enforced. The DoF was not properly shown.
The trim operation it is always solved at the end now if in no recompute mode.
============================================================
- Crashing on deleting line on fully constraint box
As a bonus:
- Fully constrained sketch not shown in green on opening the sketch
Functionality previously provided by setNodeColorByResult is now
in setNodeColorByScalars. FemResult* object is no longer required,
the function accepts list of elements and a list of values.
Functionality previously provided by setNodeDisplacementByResult is now
in setNodeDisplacementByVectors. FemResult* object is no longer required,
the function accepts list of elements and a list of vectors.
A side effect: FemResultValues and FemResultVector are no longer used
and have bee removed.
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
================================================================
A last moment change to regulate redrawing introduced this issue (reducing the redrawing to the cases where the solver geometry and the sketchObject geometry are equal).
This change also solved other issues.
The case of adding external geometry is special because the DoF is the same after insertion, yet there is an insertion (as opposed to the toggle case, where there is a change but no insertion).
SketchObject has been adapted to require a solver update before moving (which also caused a non-yet-reported crash, a separate bug), and CommandCreateGeo has been adapted to trigger a solve with
auto update mode disabled. This solve is a very low cost one as the geometry is already in place.
===============================================================================================
Group creation:
- complex geometries (consisting of several geometry elements and constraints) have been rewritten to use python list (one command call for all geometries and constraints)
- Ellipse ExposeInternalGeo as group creation of geometries and constraints
To construction mode creation:
- addGeometry python and SketchObject functions modified to take an additional optional parameter "construction" to create the geometry/geometries directly as construction.
In addition to the shorter form, this helps generate less amount of onChange propagation and Redraws.
- all the geometry creation commands in CommandCreateGeo.cpp have been rewritten to use the new construction argument. This includes modifying the regular polygon script to
take a new optional parameter to create geometry as construction in addGeometry.
- special care is taken in group creation not make construction points
- Show/hide internal geometry implemented with this option.
To solving:
- the solve previously included after every geometry addition (when in no Update, e.i. no Recompute mode) has been removed and each Gui::Command calls either an UpdateActive
for recompute or a Solve in no Update mode. This is behaviour is less intrusive and uniform with group creation.
Bug fixes and redrawing reduction:
- Fixes the CheckId exception problem. The solution also helps further remove redraws during creation of complex geometry (e.g. Slot)
- Fixes touching the sketch by only opening it.
- Code clean up.
===============================================
The help button next to the close button in the Task dialog is now removed.
It was requested that this button is removed as it is inconsistent with other help sources and it is not implemented.
================================================
Fixes a bug in master that the dependent 3D geometry would not update on Undo (in Auto update mode enabled).
Undo and redo signals are handled by ViewProvider in order to introduce an recompute or solve() of the sketchObject
as determined by the Auto Update Mode in order to update DoF and dependent geometry if necessary.
=================================================================
The new solving architecture focus all the solving on the SketchObject.
Actions that change the DoF can call execute() (i.e. recompute) or Solve() depending on whether a full recompute of dependent features is required or not.
In both calls the geometry of the solver is updated with the geometry of the SketchObject.
The only additional call that calls the solver is MovePoint. This function may or may not update the geometry of the SketchObject
(as now it is intended for UI related solving, like dragging, rubberbands, ...).
In operations that do not involve a change of DoF and therefore do not require a sketch solving, it may happen that as a side effect of moving a point, the
geometry changes to old behaviour. In order to avoid that, those SketchObject operations, as for example setConstruction or ToggleConstruction,
must set a flag "bool solverNeedsUpdate" to true. In case a movePoint is executed before any other solver execution, the geometry is first updated and then
the moving is performed.
So to keep in mind when programming sketcher operations:
-> Need recompute (UpdateActive)
-> Need solving because DoF changed (solve())
-> The operation does not change DoF (set solverNeedsUpdate to true)
=======================================
- Fixing toggle AutoUpdate Mode
- Fix Auto-Update Sketcher tools
- Fix missing createGeo recomputes
- Missing constraints recomputes fixed
Various fixes for non-Update mode:
- Fixes lack of update upon entering a conflicting datum constraint.
- Fixes lack of update upon setting the reference/driving status of a constraint
- Added tooltips to buttons
=========================================================
Upon deletion of a constraint, the constraint was still enforced for UI operations (dragging of a point) and DoF was not updated.
======================================================================================
There is a checkbox, default disabled, that makes the commands NOT to generate a recompute after each.
This means that if you are editing a sketch that is used to generate a pad or pocket, if the checkbox is
disabled, the dependent objects do not get recomputed.
There is a button next to it to force a manual recompute, in case it is needed.
If the user wants the previous behavior, he only needs to activate the checkbox. The previous status of the box
is restored upon entering a sketch in edit mode.
It is remarkable the case of the Fillet and Trim
On changing ActSketch (solvedSketch) to SketchObject and making movePoint not systematically update the geometry, the solving in MovePoint was confronted with solving for "the last solved geometry",
which is the default behaviour, in some situations (Fillet and Trim) where geometry had changed at SketchObject level, and was the subject of the moving actions.
MovePoint has been updated to take an extra optional parameter, to force the change in solved geometry in those situations.
Some other minor bug also fixed in Fillet creation in CommandCreateGeo.cpp
This commit also introduces conditional recompute on some operations of:
- constraints
- geometry creation (reubication of update active to comprise the autoconstraints within a single UpdateActive)
=======================================================================================
ActSketch in ViewProvider dissapears. The temporal sketch (sketch.cpp) for solving is now a data member of SketchObject.cpp (hereinafter solvedSketch). All the solving is concentrated in SketchObject.cpp.
SketchObject provides an interface to expose its solver, as it is still currently needed for some UI operations from ViewProviderSketch, like dragging points (solving rubber bands).
ViewProviderSketch still can select whether to draw the solvedSketch geometry (previously ActSketch) geometry (UI staff) or the SketchObject geometry. Performancewise, it makes sense to separate this two
geometries, as the SketchObject one involves modifying the Geometry and Constraint Properties (including all the undo related functionality), which would mess the undo functinality and incur in a big
peformance penalisation while dragging. One characteristic of solvedSketch is that its geometry is solved, whereas the geometry of SketchObject may not have been solved yet.
These geometries may differ at for the following reasons:
1. The geometry corresponds to an ongoing dragging operation, so solvedSketch has the last calculated dragging geometry, while SketchObject has the one corresponding to initial position.
2. Geometry/constraints were added to the sketch, but no solve/execute was triggered yet (envisioned situation is the future group creation functionality not in this commit).
What do I gain?
- Inserting a (simple) geometry element now costs 1 solver execution.
- Inserting a constraint now costs 1 solver executions.
For reference, in previous versions inserting a constraint involved 5 solver executions.
The following information provide a historical review of the coding of this commit (formed of 10 squashed commits):
This is a general sketch solve call reduction, not only during geometry creation (this commit does not include until here any specific measure to reduce calls on geometry creation, that is another branch)
After a lot of profiling, it seems that the "cause"(tm) that creates so many solver calls is that every update generates a solving in ViewProviderSketch, regardless of the need for that update,
many times with the only aim of providing the DoF for the message dialog and keeping ActSketch in sync with SketchObject in case it is needed (currently UI moving points, constraints,...).
Sketch solver is now a data member of SketchObject instead of a temporal object that gets initilized and destroyed.
This allows:
1. Potentially more synergy reducing calls to setUpSketch (still to be seen, still to be optimized)
2. Allowing SketchObject to access the latest geometry that has been solved => In future, allow objects that use SketchObject to obtain the latest
solved geometry instead the geometry of SketchObject that may still be unsolved. This is relevant for drawing the geometry
No more solving in ViewProviderSketch. Solving a Sketch is now an exclusive competence of SketchObject.
There is however a lot of cleaning to do in ViewProviderSketch
(I mean, not that these commits are making a mess in VPSketch,
but that as a consequence of the changes, it should be possible to
optimize VPSketch, specially moving and drawing methods)
Very useful comment for future developers that may wonder why a solve per constraint just upon addition is necessary.
Added a new function to get the size of the geometry of the instance of the solver object (Sketch.cpp).
The previous way was to extract the geometry, which is costly and error prone, as you have to delete it afterwards.
Inserted comment about the necessity of triggering a Part2D update during edit mode
Arch objects can now be based on a Part Compound and will take
its DiffuseColor property. Arch objects that are clones of
such objects will also copy that property.
Attributions:
Mark (quick61) - icons
Yorik - help with internationalization
Everyone who appeared in forum thread "A new Part tool is being born...
JoinFeatures!" - for endorsement!
http://forum.freecadweb.org/viewtopic.php?f=22&t=11112
Also animateNodes is now applyDisplacementToNodes.
The funcions are not doing animation, but are responsible
for deforming mesh.
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
This commit add a new object to Analysis: AnalysisStats. AnalysisStats
contains list with 15 values (an example):
-0.000776373 <-- minimum X displacement
-7.74494e-06 <-- average X displacement
0.000774115 <-- maximum X displacement
-0.00416267 <-- minimum Y displacement
-0.00204191 <-- average Y displacement
0 <-- maximum Y displacement
-0.000775108 <-- minimum Z displacement
1.09288e-05 <-- average Z displacement
0.000775122 <-- maximum Z displacement
0 <-- minimum Abs displacement
0.00214509 <-- average Abs displacement
0.00430481 <-- maximum Abs displacement
0.390598 <-- minimum Von Mises Stress
0.93509 <-- average Von Mises Stress
1.47765 <-- maximum Von Mises Stress
Those values will be used to set field values in FEM results dialog
instead of currently used values returned by setNodeColorByResult
function.
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
==============================================================================
Now you can switch from one tool to the next just by clicking on the next tool
==================================================================================
Geometry button:
- if no object selected, the legacy toggle icon has a new functionality, switch to/from creating in construction mode
- if object selected, it has the legacy functionality
- the button can be clicked during "continuos creation mode" to switch from creating to/from creating in construction mode
Constraint button:
- The button is not selectable if nothing is selected (it would be impossible to determine the effect)
- When constraints are selected, the button toggles the constraints to/from Driving.
- When geometry is selected, the button switches from/to reference mode, the change is apparent from the color of the constraint icons.
Continuous creation mode:
- Default changed so that it is active unless you change it in settings
Updated terminology
======================================================================
- Changing from Driving to reference does not include unnecessary solvings.
- Added some checks to avoid making Driving constraints when calling directly from python and involving only external geometry (would give redundant constraints).
- New python command toggleDriving to just change the status from reference to Driving
- New UI toolbar Command to toggle constraints
- Fix to allow switching from/to construction mode during continuous mode creation.
- Enable/Disable for constraints in constraints widget has changed to operate on multiselection and now effects "toggle" instead of enable/disable.
- Disable the option to directly create a SnellsLaw non-driving constraint (this constraint does not support direct creation, it can be toggled to non-driving after creation though).
==============================================
The fillet applied to construction lines generates normal (not construction) geometry.
How to replicate?
1.Make a square and make all lines construction lines.
2.Apply fillet tool, there result will be a white line fillet connecting two blue constructions lines.
===================================================================
It allows to create constraints directly into Reference or Driving mode.
It does not include icons
===============================================
It allows to select whether the geometry will be created as construction geometry or normal geometry.
This commit includes an important bug fix to reduce the number of times the sketcher solver is called when toggling
geometry. It makes an important difference in the creation during construction mode and InternalAligment geometry like the ellipse.
This commit does not include icons.
You have a button next to toggle that after having been clicked, switches from Normal to Construction geometry and vice versa
============================================================
It lifts the need of clicking on the external geometry icon upon importing each external geometry element.
All the elements on which the user clicks are imported until the user right clicks with the mouse or presses ESC, like the Trim or Fillet tools.
===============================================
When creating a type of geometric element, the user can create as many elements of that type he wishes without having to click the button before each insertion.
The insertion of that type of elements ends by pressing ESC or clicking the right button of the mouse.
This mode is by default disabled and can be enabled in Preferences->Display->Sketch->Geometry Creation "Continue Mode".
===================================================================================================
This fixes a bug in the original implementation, that a non-driving constraint value could be
edited by double clicking on it in the 3D view.
It also includes minimal documentation on some functions.
It also includes:
- Color setting for non-driving constraints was not working.
- Settle UI terminology dispute:
* Driving Constraint (normal red constraint)
* Reference Constraint (non-driving constraint)
====================================================================================
It allows to enable and disable a constraint in the constraint list.
When disabled, the constraints current value is shown, but its value is not enforced (it is driven by the other constraints and user interaction).
A disabled constraint can be enabled (as far as it is enforceable, see non-driving constraints to external geometry below).
The sketcher functionality has been extended to support non-driving constraints to external geometry elements. This were previously excluded from
the possibility of creating a constraint on them (as their values depend on other sketches and would be redundant with the unchanged value or conflicting when value is changed).
Now these constraints are created as non-driving, but as they are not enforceable, the UI does not allow you to make them driving.
The constraint filter has been extended to include a Non-Driving constraints category.
Thanks again to Werner for his continuous support, and specially in this case to DeepSOIC, as he pointed towards a much better implementation solution than my original idea.
=========================================
The autoconstraints on creation of an hexagon were not working.
How to reproduce?
1. In a sketch make a couple of lines
2. Create an hexagon (or other polygon of your choice) with center in one end of a line and with side coincident with the end point of the other line
Result:
Neither the center nor the side autoconstraints are properly created.
Fix:
Straightforward. Just correct the indexes. Last is always the circle. Last but one is always a side.
========================================================================================
How to replicate:
1. Go to Preferences->Display->Sketch and disable that checkbox.
2. Create a distance constraint (radius, distance, ...)
It will ask for the value regardless of whether the checkbox is clicked or not.
Why?
In SketcherSettings.ui the prefpath is "Mod/Sketcher"
The code refered to ParameterGrp::handle hGrp = App::GetApplication().GetParameterGroupByPath("User parameter:BaseApp/Preferences/Mod/Sketcher/General");
=============================================================
This function is like this from 2011 according to git blame.
The original code makes no sense. I assume that what is intended in this
function (in accordance with SketchPy.xml) is call the method clear in
Sketch.cpp.
Existing code was producing invalid results:
a = 9876543212346789864323456.9543234578986432345678
>>> print "{:.13}".format(repr(a))
9.87654321234
>>> a
9.87654321234679e+24
The new converision should work fine:
>>> print "{:.13E}".format(a)
9.8765432123468E+24
Reported & fixed by ulrich1a
getccxVolumesByFace returns std::map<int, int> with ID of volume
and a number of face as per CalculiX definition. The same function is
accessible for python and returns list with the same information, like
this: [[229, 3], [230, 3], [233, 2], [238, 2]]
write_face_load produces something like this in the .inp file:
***********************************************************
** element + CalculiX face + load in [MPa]
** written by write_face_load function
*DLOAD
** Load on face Face2
229,P3,10.0
230,P3,10.0
233,P2,10.0
238,P2,10.0
Optimised by wmayer
Signed-off-by: wmayer
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
Adding detailed information which function is responsible for
creating a proticular section of the .inp file should save
some guesswork. An example from the .inp file:
[..]
***********************************************************
** node sets for loads
** written by write_load_node_sets function
*NSET,NSET=FemConstraintForce
1,
3,
[..]
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
The reason behind that change is that auxiliary variables,
like a file handle, should not be too visible. inpfile was
a good description, but we're handling only one file and there
is no need to use a descriptive variable name for it in every function.
It's enough that is used in write_calculix_input_file
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
Also, there is no need to print material parameters to the console.
User can see that info in dialog box, in .inp file and it's also printed
to console after material has been set.
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
Showing ccx output during short colculations doesn't make any sense.
During long calculations user is flooded with messages, that ccx
produced empty output.
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
That function won't be used as there is a plan to merge material
handling with Arch wb and Arch wb already has material editor.
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
That commit fixes inconsistent behaviour of Young's modulus input field
units in FEM material dialog window.
Reported-by: sgrogan
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
By enabling the setting in IFC preferences, the IFC
importer can now detect if an input shape is a normal
extrusion, and create the object as a Part::Extrusion.
CalculiX documentation tells that maximum alowed material name length
is 80 characters, so we have to respect that. Also ccx quietly fails if
that limit is not honoured.
Reported-by: bernd
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
ConfigParser changes option capital letters in keys to small letters.
That commit changes it to generate verbatim keys as read from FCMat
files. Also Section names are no longer used to generate material
dictionary.
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
Identification of selected result item is no longer based
on the item string, but on a separate userData. This method
is language agnostic.
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
ccx crashes when a force has too many digits like this:
FemConstraintForce,2,1.5966711853290134e-18
but it's OK with that format:
FemConstraintForce,2,1.5966711853e-18
An example of ccx error:
*ERROR reading *CLOAD. Card image:
FEMCONSTRAINTFORCE,3,1.5966711853290134E-18
This commits adds formatting to make sure the numbers are within ccx
limits.
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
Printing FEM console message could fail if ccx was compiled in March
and standard output contained double dotted a.
"You are using an executable made on Mi 4. Mär 19:49:02 CET 2015"
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
This commit moves checking prerequisites to function. The function
is called before writing .inp file to make sure all required objects
are included in the analysis. "open editor" and "run ccx" buttons are
if check_prerequisites runs successfully.
Reported-by: wmayer
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
Adding material was using by default transient None material that
has no properties assigned. If use accepted that type of material
an attempt to write CalculiX input file was ending up with a crash.
Using built-in None material prevents that situation.
Reported-by: wmayer
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
Defaulting to False was causing problems during migration. The default
checkbox of linked FEM preferences is True, but for the first time users
there was nothing stored in UseBuiltInMaterials, UseMaterialsFromConfigDir
and UseMaterialsFromCustomDir, so the materials were not showing up in
the material ComboBox.
Reported-by: wmayer
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
Previous method was prone to UnicodeDecodeError. The try-catch for
UnicodeDecodeError stays in as additional safety net.
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
get_material_name provides material name in a safe way, so there is
no need to check in General_name exists in material definition
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
It doesn't make sense to pull preferences in __init__ for later use as
they change dependin on user action.
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
On-demand import is no longer good enough as we have 3 different
material directories and materials may have non-unique names.
A material is now identified by a full file path.
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
Add icons to distinguish where the material is from. FreeCAD icon for
build-in materials, notmal material icon for materials from user
preferences directory which is "~/.FreeCAD/Materials" on linux or
from an user defined location defined in FEM preferences.
Signed-off-by: Przemo Firszt <przemo@firszt.eu>
