Stress Result in Shells

About the development of the FEM module/workbench.

Moderator: bernd

User avatar
bernd
Posts: 8488
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: Stress Result in Shells

Postby bernd » Tue Mar 13, 2018 7:09 am

steps to reproduce:

- start FreeCAD
- open FEM 2D example
- double click in tree view on analysis
- select solver object CalculiXccxTools --> change parameter "Beam Shell Result Output 3D" to True
- run analysis
either
- select new result object in tree view --> menu Results --> Postpipline from Result --> bang FreeCAD crashes
or
- select new result object in tree vew --> menu File --> export --> export to FEM vtk results --> bang FreeCAD crashes

OS: Debian GNU/Linux 9.4 (stretch)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.13404 (Git)
Build type: Unknown
Branch: femtmp
Hash: 2fc1763f24e926058bd66b5cc063b24616ad2843
Python version: 2.7.13
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.0.0
Locale: German/Switzerland (de_CH)


debug output:

Code: Select all

...
7fff6d502000-7fff6d503000 r--p 00038000 103:06 2491993                   /home/hugo/Documents/dev/freecad/freecadbhb_dev/build/lib/libDriverUNV.so
7fff6d503000-7fff6d505000 rw-p 00039000 103:06 2491993                   /home/hugo/Documents/dev/freecad/freecadbhb_dev/build/lib/libDriverUNV.so
Thread 1 "FreeCAD" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51      ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht gefunden.
(gdb) 
(gdb) 
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007fffeca5442a in __GI_abort () at abort.c:89
#2  0x00007fffeca90c00 in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7fffecb85d98 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007fffeca96fc6 in malloc_printerr (action=3, str=0x7fffecb85e10 "double free or corruption (!prev)", ptr=<optimized out>, ar_ptr=<optimized out>) at malloc.c:5049
#4  0x00007fffeca9780e in _int_free (av=0x7fffecdb9b00 <main_arena>, p=0x555559e1ed80, have_lock=0) at malloc.c:3905
#5  0x00007fff67105b75 in vtkDataArrayTemplate<float>::DeleteArray (this=0x55555a515f30) at /home/hugo/Documents/dev/vtk/VTK-7.0.0/vtk/Common/Core/vtkDataArrayTemplate.txx:212
#6  0x00007fff67105317 in vtkDataArrayTemplate<float>::~vtkDataArrayTemplate (this=0x55555a515f30, __in_chrg=<optimized out>) at /home/hugo/Documents/dev/vtk/VTK-7.0.0/vtk/Common/Core/vtkDataArrayTemplate.txx:92
#7  0x00007fff6710102a in vtkFloatArray::~vtkFloatArray (this=0x55555a515f30, __in_chrg=<optimized out>) at /home/hugo/Documents/dev/vtk/VTK-7.0.0/vtk/Common/Core/vtkFloatArray.cxx:36
#8  0x00007fff6710105a in vtkFloatArray::~vtkFloatArray (this=0x55555a515f30, __in_chrg=<optimized out>) at /home/hugo/Documents/dev/vtk/VTK-7.0.0/vtk/Common/Core/vtkFloatArray.cxx:38
#9  0x00007fff6717edaf in vtkObjectBase::UnRegisterInternal (this=0x55555a515f30, check=0) at /home/hugo/Documents/dev/vtk/VTK-7.0.0/vtk/Common/Core/vtkObjectBase.cxx:232
#10 0x00007fff67181184 in vtkObject::UnRegisterInternal (this=0x55555a515f30, o=0x55555a515eb0, check=0) at /home/hugo/Documents/dev/vtk/VTK-7.0.0/vtk/Common/Core/vtkObject.cxx:900
#11 0x00007fff6717ec78 in vtkObjectBase::UnRegister (this=0x55555a515f30, o=0x55555a515eb0) at /home/hugo/Documents/dev/vtk/VTK-7.0.0/vtk/Common/Core/vtkObjectBase.cxx:189
#12 0x00007fff671876b1 in vtkPoints::~vtkPoints (this=0x55555a515eb0, __in_chrg=<optimized out>) at /home/hugo/Documents/dev/vtk/VTK-7.0.0/vtk/Common/Core/vtkPoints.cxx:72
#13 0x00007fff6718770e in vtkPoints::~vtkPoints (this=0x55555a515eb0, __in_chrg=<optimized out>) at /home/hugo/Documents/dev/vtk/VTK-7.0.0/vtk/Common/Core/vtkPoints.cxx:73
#14 0x00007fff6717edaf in vtkObjectBase::UnRegisterInternal (this=0x55555a515eb0, check=0) at /home/hugo/Documents/dev/vtk/VTK-7.0.0/vtk/Common/Core/vtkObjectBase.cxx:232
#15 0x00007fff67181184 in vtkObject::UnRegisterInternal (this=0x55555a515eb0, o=0x55555a671070, check=0) at /home/hugo/Documents/dev/vtk/VTK-7.0.0/vtk/Common/Core/vtkObject.cxx:900
#16 0x00007fff6717ec78 in vtkObjectBase::UnRegister (this=0x55555a515eb0, o=0x55555a671070) at /home/hugo/Documents/dev/vtk/VTK-7.0.0/vtk/Common/Core/vtkObjectBase.cxx:189
#17 0x00007fff683c1588 in vtkPointSet::Cleanup (this=0x55555a671070) at /home/hugo/Documents/dev/vtk/VTK-7.0.0/vtk/Common/DataModel/vtkPointSet.cxx:73
#18 0x00007fff683c13f7 in vtkPointSet::~vtkPointSet (this=0x55555a671070, __in_chrg=<optimized out>) at /home/hugo/Documents/dev/vtk/VTK-7.0.0/vtk/Common/DataModel/vtkPointSet.cxx:43
#19 0x00007fff6848011a in vtkUnstructuredGridBase::~vtkUnstructuredGridBase (this=0x55555a671070, __in_chrg=<optimized out>) at /home/hugo/Documents/dev/vtk/VTK-7.0.0/vtk/Common/DataModel/vtkUnstructuredGridBase.cxx:28
#20 0x00007fff6847a0a6 in vtkUnstructuredGrid::~vtkUnstructuredGrid (this=0x55555a671070, __in_chrg=<optimized out>) at /home/hugo/Documents/dev/vtk/VTK-7.0.0/vtk/Common/DataModel/vtkUnstructuredGrid.cxx:167
#21 0x00007fff6847a0f6 in vtkUnstructuredGrid::~vtkUnstructuredGrid (this=0x55555a671070, __in_chrg=<optimized out>) at /home/hugo/Documents/dev/vtk/VTK-7.0.0/vtk/Common/DataModel/vtkUnstructuredGrid.cxx:312
#22 0x00007fff6717edaf in vtkObjectBase::UnRegisterInternal (this=0x55555a671070, check=1) at /home/hugo/Documents/dev/vtk/VTK-7.0.0/vtk/Common/Core/vtkObjectBase.cxx:232
#23 0x00007fff67181184 in vtkObject::UnRegisterInternal (this=0x55555a671070, o=0x0, check=1) at /home/hugo/Documents/dev/vtk/VTK-7.0.0/vtk/Common/Core/vtkObject.cxx:900
#24 0x00007fff683c28dc in vtkPointSet::UnRegister (this=0x55555a671070, o=0x0) at /home/hugo/Documents/dev/vtk/VTK-7.0.0/vtk/Common/DataModel/vtkPointSet.cxx:449
#25 0x00007fff671b7065 in vtkSmartPointerBase::~vtkSmartPointerBase (this=0x7fffffffb1c8, __in_chrg=<optimized out>) at /home/hugo/Documents/dev/vtk/VTK-7.0.0/vtk/Common/Core/vtkSmartPointerBase.cxx:62
#26 0x00007fff8030baa0 in vtkSmartPointer<vtkUnstructuredGrid>::~vtkSmartPointer() () from /home/hugo/Documents/dev/freecad/freecadbhb_dev/build/Mod/Fem/Fem.so
#27 0x00007fff8030dc11 in Fem::FemPostPipeline::load(Fem::FemResultObject*) () from /home/hugo/Documents/dev/freecad/freecadbhb_dev/build/Mod/Fem/Fem.so
#28 0x00007fff803b9e3a in Fem::FemPostPipelinePy::load(_object*) () from /home/hugo/Documents/dev/freecad/freecadbhb_dev/build/Mod/Fem/Fem.so
#29 0x00007fff803b87e8 in Fem::FemPostPipelinePy::staticCallback_load(_object*, _object*) () from /home/hugo/Documents/dev/freecad/freecadbhb_dev/build/Mod/Fem/Fem.so
#30 0x00007ffff4cb1091 in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#31 0x00007ffff4e1829c in PyEval_EvalCodeEx () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#32 0x00007ffff4ca89c9 in PyEval_EvalCode () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
---Type <return> to continue, or q <return> to quit---

User avatar
bernd
Posts: 8488
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: Stress Result in Shells

Postby bernd » Tue Mar 13, 2018 7:16 am

IMHO it is vtk related and not FreeCAD ...
wmayer
Site Admin
Posts: 15000
Joined: Thu Feb 19, 2009 10:32 am

Re: Stress Result in Shells

Postby wmayer » Tue Mar 13, 2018 10:55 am

I have tried the example several times and always got a crash. However, each time the stack trace looked different and I guess the reason must be somewhere else. But I have no clue what the root cause is.
User avatar
HarryvL
Posts: 1052
Joined: Sat Jan 06, 2018 7:38 pm

Re: Stress Result in Shells

Postby HarryvL » Tue Mar 13, 2018 11:26 am

bernd wrote:
Tue Mar 13, 2018 7:16 am
IMHO it is vtk related and not FreeCAD ...
I thought VTK was simply a XML file format? Having said that, I have not found the place in the source code yet where this XML gets written. Bernd, do you mean that VTK is written by a library function outside FC?
User avatar
bernd
Posts: 8488
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: Stress Result in Shells

Postby bernd » Tue Mar 13, 2018 11:52 am

@HarryvL: yes and yes ... vtk is one file format of VTK tool kit. See google. Paraview is a GUI based on the toolkit. All green post processing icons in FreeCAD use VTK tool kit. Means if we gone write a VTK file we call VTK and pass our results and mesh data.


@all:
we may need a better example. May be it is not because of the node numbers but because of the penta elements ?


I may have another look if we gone pass the right data to the vtk functions.


Attached a beam example with 3D output (uses hexa elements). VTK does not crash but it does not show anything either ...

beam3D.FCStd
(13.32 KiB) Downloaded 11 times
User avatar
bernd
Posts: 8488
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: Stress Result in Shells

Postby bernd » Tue Mar 13, 2018 11:58 am

HarryvL wrote:
Tue Mar 13, 2018 11:26 am
Bernd, do you mean that VTK is written by a library function outside FC?
https://github.com/FreeCAD/FreeCAD/blob ... s.cpp#L414 I read a bit more in this file, it seams our second order penta (it is what the shell example in 3D mades out of triangles) is not supported ...
User avatar
bernd
Posts: 8488
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: Stress Result in Shells

Postby bernd » Tue Mar 13, 2018 12:06 pm

If first order shells (in 3D first order penta) are used, FreeCAD crashes not, vtk can be exported an imported back into FreeCAD. I have no paraview to test the vtk file right now.

attached the shell with first order elements ...


shell-firstorder-3D.FCStd
(21.5 KiB) Downloaded 10 times
User avatar
bernd
Posts: 8488
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: Stress Result in Shells

Postby bernd » Tue Mar 13, 2018 12:10 pm

https://github.com/FreeCAD/FreeCAD/blob ... #L304-L364

there is no volume with 13 nodes and no ifelse for all other which should raise an exeption. All this would be better with a case switch and at the end a switch for all not handled cases. I may have a look at this. I'm not 100 % sure becasue I have not tested just read code I have not written myself ...

Bernd
User avatar
HarryvL
Posts: 1052
Joined: Sat Jan 06, 2018 7:38 pm

Re: Stress Result in Shells

Postby HarryvL » Tue Mar 13, 2018 1:24 pm

bernd wrote:
Tue Mar 13, 2018 12:06 pm
If first order shells (in 3D first order penta) are used, FreeCAD crashes not, vtk can be exported an imported back into FreeCAD. I have no paraview to test the vtk file right now.

attached the shell with first order elements ...

shell-firstorder-3D.FCStd
Hi Bernd, unfortunately the 6-noded shell is much more accurate and "better behaved", so I would love to keep using that and settle for exporting less information. As you can see from the node numbering, that should be quite easy ... just only export the first 6 nodes of the 15-noded wedge ;)

CALCULIX OUTPUT
15-node wedge.png
15-node wedge.png (21.26 KiB) Viewed 203 times


VTK INPUT
VTK wedge.png
VTK wedge.png (7.79 KiB) Viewed 203 times
User avatar
bernd
Posts: 8488
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: Stress Result in Shells

Postby bernd » Tue Mar 13, 2018 2:19 pm

The test with the six node penta was just to find the problem. If the problem really is only the missing volume in FreeCAD vtk exporter than it will be easy to add all kinde of volumes like we did for other mesh formats in FEM_Mesh . As written I will have a look. bernd