One result object...

[PrzemoF]

...to rule them all!! (I couldn't resist)

There is one FEM result object containing all data generated by frdReader: displacement, stress and stats. A side effect is that FemResultVector/FemResultValue are no longer used, so they got removed. I had multiple reasons to write that patch:
1. One result object looks much better in object tree (this is the only visible change for the GUI user)
2. One result object will make handling multiple FEM calculation results much easier
3. ViewProviderFemMeshPy::setNodeColorByResult was handling to completely different data types (vector list and value list). It was too complicated for me
4. Unix Rule of Representation: complicated data + simple handling procedures are easier to read than simple data + complicated handling procedures.
FemResultVector/FemResultValue (children of FemResultObject) were very elegant and clean, but handling them in ccxFrdReader, MechanicalAnalysis.py and ViewProviderFemMeshPyImp.cpp was much more complicated (my commit removes over 300 lines)

Please test and share your opinions
[1] https://github.com/PrzemoF/FreeCAD_sf_m ... ult_object

Log:
Przemo Firszt (1):
FEM: All FEM results are stored in a single object

src/Mod/Fem/App/AppFem.cpp | 8 +-------
src/Mod/Fem/App/CMakeLists.txt | 4 ----
src/Mod/Fem/App/FemResultObject.cpp | 13 +++++++------
src/Mod/Fem/App/FemResultObject.h | 15 ++++++++-------
src/Mod/Fem/App/FemResultValue.cpp | 74 -------------------------------------------------------------------------
src/Mod/Fem/App/FemResultValue.h | 66 -----------------------------------------------------------------
src/Mod/Fem/App/FemResultVector.cpp | 74 -------------------------------------------------------------------------
src/Mod/Fem/App/FemResultVector.h | 64 ---------------------------------------------------------------
src/Mod/Fem/Gui/ViewProviderFemMeshPy.xml | 9 +++++++--
src/Mod/Fem/Gui/ViewProviderFemMeshPyImp.cpp | 89 ++++++++++++++++++++++++++++++++++++++++++++--------------------------------------------
src/Mod/Fem/MechanicalAnalysis.py | 67 +++++++++++++++++++++++-------------------------------------------
src/Mod/Fem/ccxFrdReader.py | 36 +++++++++++++++---------------------
12 files changed, 106 insertions(+), 413 deletions(-)
delete mode 100644 src/Mod/Fem/App/FemResultValue.cpp
delete mode 100644 src/Mod/Fem/App/FemResultValue.h
delete mode 100644 src/Mod/Fem/App/FemResultVector.cpp
delete mode 100644 src/Mod/Fem/App/FemResultVector.h

[ickby]

I like this very much! IMHO a big step to make the fem workbench more universal. I do also have a suggestions to further improve this:

Create a new object FemStaticMechanicalResult which is derived from FemResultObject and move the displacement and stress to it. Here are a few reason for this suggestion:

1. In the future someone may like to extend the workbench to modal or heat or whatever kind of analysis. Then he don't need the currently available properties but different ones. With the proposed structure he can easily derive a new object type for his purpose and get a clean interface. Even easier: in Python he can simply create a FemResultObject and dyamicly add the properties he needs to store his results.

2. This allows you to add a.custom view provider for the special purpose of mechanical static analysis with a own task dialog pop up on double click without creating something unwanted for other future result types.

3. Imho the most important. Fem results are always scalar or vector fields. So basicly all types of visualisation can be shared no matter what kind of result you have. Now if all results are added to FemResultObject one can build the visualisation tools in a general way: they just search the properties of the result object and pick all they can handle, then the user selects the relevant and the tool does its work. For example imagine arrows for vector fields: they can show head flux, magnetic fields and even displacement (what is really handy for anisotropic material). So if you split the result objects.as.proposed you get the best of both worlds: easy and fast visualisation as currently by a specialised task dialog AND the possibility to handle all result properties with general visualisation tools.

4. If the propossed general approach is used freecad would gain the posability to load and handle arbitrary fem result from other applications.


As always feel free to ignore my comments if you have a different opinion, the one doing the work decides the direction it is going

[bernd]

tested on Debian Jessie. As you stated not much changes at the gui but inside ... Wow I really appreciate the changes you made. It really will simplify things a lot. Things ickby has mentioned makes sense from my point of view.

[PrzemoF]

Thanks for the tests & opinions!
I don't know if we can have different FemResultObjects like FemResultStatic and FemResultHeat and still have just one object in the tree - probably not. If we don't hit a performance/memory problems I'd rather have one Fem result object with all types of the results. Anyway we'll worry about it when someone implements another type of calculation I like the idea of being able to handle different results in a single procedure, but I want to have it as simple as possible. Currently we have this in the master branch:

master.png (82.16 KiB) Viewed 2696 times

I want to change it to:

future.png (23.15 KiB) Viewed 2696 times

where "All to scalar converter" would extract X/Y/Z or calculate lengths of vectors, so the output of it would ba always list of float numbers (scalars)
In far future we might want to show some vectors (like CalculiX cgx does), so it would be like this:

far_future.png (29.53 KiB) Viewed 2696 times

where showVectors would be given a list of vectors that should be rendered as 3D arrows using mesh nodes as base points - that part actually might be quite easy, we already have very similar code that renders Pressure constraint arrows.

P.S. I'm learning GraphViz, so probably there will be more graphs in my posts

[ickby]

I don't know if we can have different FemResultObjects like FemResultStatic and FemResultHeat and still have just one object in the tree - probably not.

That is true. I thought the goal was to have one object for each analysis and all results of this analysis are grouped into this object. Then a different analysis (or the same one run again with different values) would create a new FemResultObject. Seems I have misinterpreted your plans.

If we don't hit a performance/memory problems I'd rather have one Fem result object with all types of the results

But with the current approach you get a multitude of properties and no way of knowing which ones are used and which ones are empty (and still you are never be able to get all possible result types). I still think it is a better idea to only place the infrastructure to the FemResultObject, everything you need to handle the (arbitrary) resutls, and then add the results dynamicly as properties. The infrastructure function would just work with those properties.

Anyway we'll worry about it when someone implements another type of calculation

True one But it would be easier if the visualisation and data handling tools already account for arbitrary result properties as then nothing that already works needs to be changed when someone does come up with other analysis types. And it then would be possible to read in result files from other FEM software.


EDIT: Just tested it and pne can only add dynamic properties to python objects, totally forgot about that one. So for my idea one would need to implement a dynamic result handling in FEMResultObject from ground up, which makes it way more work than I initially thought.

[PrzemoF]

One step closer to the final version [1] - summary: 102 insertions(+), 470 deletions(-)
Changes:
-one procedure to handle node colours using element/float list. It can be used with anything that provides a list of element numbers and a list of corresponding float numbers that has to be shown as colours on the mesh. Example usage (pseudocode):

Code: Select all

MeshObject.ViewObject.setNodeColorByScalar(element_numbers_list, values_list)

and a real FreeCAD python session (after calculation, analysis selected) to show Von Misses stress colour on the mesh:

Code: Select all

>>> import FemGui
>>> a = FemGui.getActiveAnalysis()
>>> mesh = a.Member[0]
>>> mesh.Name
'Cut_Mesh'
>>> r = a.Member[4]
>>> r.Name
'Results'
>>> mesh.ViewObject.setNodeColorByScalar(r.ElementNumbers, r.StressValues)

- added DisplacementLengths property to FEM result object - it's a list containing lengths of displacement vectors, so they don't have to be calculated every time user selects mesh deformation

Things that need some more polishing:

- name of the function: setNodeColorByScalar. I'm sure there is a better name, but I haven't found it yet. It has also take account of the future setNodeDisplacementByVectors (currently: setNodeDisplacementByResult) and a function that will render vector arrows. All 3 should use similar names as they will be used for similar purpose.
- return value from the function is Py_Return and I had a problem using void instead

[1] https://github.com/PrzemoF/FreeCAD_sf_m ... _object_v1

[PrzemoF]

Ready for review (especially C++ part): https://github.com/PrzemoF/FreeCAD_sf_m ... _object_v2

Added setNodeDisplacementByVectors(list_of_elements, list_of_vectors). Example usage:

Code: Select all

>>> import FemGui
>>> a = FemGui.getActiveAnalysis()
>>> mesh = a.Member[0]
>>> r = a.Member[4]
>>> mesh.ViewObject.setNodeDisplacementByVectors(r.ElementNumbers, r.DisplacementVectors)
>>> mesh.ViewObject.applyDisplacement(5000)
>>> type(r.ElementNumbers)
<type 'list'>
>>> type(r.ElementNumbers[0])
<type 'int'>
>>> type(r.DisplacementVectors)
<type 'list'>
>>> type(r.DisplacementVectors[0])
<type 'Base.Vector'>