- the spring constraint is currently unused but it can be used for Elmer mechanical analyses
This PR does so and also overhaul the dialog UI.
- use the spring constraint also in an example file
- add fields to specify a formula for the displacement, this is necessary to make transient deformation analyses with Elmer
- add option to set displacement from result of flow equation
- this way also a major overhaul -> simpler dialog logic etc.
- adds new equation "Deformation" (this name since the stress solver got in FreeCAD the misleading name "elasticity")
- this way change icon of elastic solver to make the difference clear
- same as #8963 but for initial velocity
- add an example file that demonstrates the influence of the initial velocity
- some fine-tuning for the existing flow example
- complete revision of the constraint.
This is a breaking change, meaning existing constraints won't work.
This is possible because since 2 days ago the whole flow equation did not work at all. Also the existing constraint implementation if buggy and cannot be used to do the Elmer tutorial. Also, the constraint is only used by Elmer and only be the flow equation.
Since nobody complained about the obvious wrong results, we can assume the flow equation was not yet in practical usage (and for FC 0.20 we known that it does not work at all, first with FC 0.20.1).
It is necessary since it must be possible to either input a velocity or an equation. With an equation, a velocity profile can be specified.
- update the flow examples accordingly:
-- simplify them since an initial and and output velocity is not necessary to specify
-- use a formula as input velocity for the non-turbulent example
- make the connection also working for frequency and buckling analysis by directly creating/updating the pipeline where the CalculiX results are loaded
- was reported and automatically fixed by Qt's Designer that the size in the file is incorrect, (the sum of the widget's widths is wider than the main widget's specified size)
- was reported and automatically fixed by Qt's Designer that the size in the file is incorrect, (the sum of the widget's widths is wider than the main widget's specified size)
- vector must be initialized and vector size requires a const int
- also some sorting
- also some formatting changes to be consistent (either always "x." or "x.0")
- when the option "use this task panel" is not checked the edit fields must be disabled.
This also fixes the often hard to understand issue that while scrolling to the end of the dialog the material suddenly changes to "_transient" because the scroll wheel can trigger to change the edit fields.
- if pvtu file filtering is on, there is by design not on every call of WriteColorData() data
(on other occasions of GetArray(array) the result is checked, for two calls is was forgotten)
- also some automatic code formatting according to our current clang file
- it is sensible to filter by default, however, it turned out that on some complex models Elmer fails to compute if the mesh volume regions are too small (in most cases) or at a certain mesh region. By disabling the filtering, one gets at least for the latter case a visual feedback where the mesh volume of the different CPU are (by also setting a transparency to the result pipeline).
- To speed up analyses one calculates on several CPU cores. The result is a partial VTU file.
Unfortunately when applying a transparency the boundaries of the volumes computed by each CPU core are always visible. This makes it often unusable for visualizations.
The solution is to filter the results the same way a clip filter does.
- the ViewProvider sorting of the field can be different from the sorting in the dialog
- also hide a Contours property (I forgot this when the contours filter was added)
- sort the functions alphabetically to know where to scroll to - eases the reading at least a bit
- some automatic reformatting according to our current clang file
- split too long lines