Stress Result in Shells

[bernd]

with 1D elements the example is even simpler ...

shell-stress-result-problem-simplified2.fcstd

(17.47 KiB) Downloaded 26 times

FEMMeshGmsh.frd.txt

(4.95 KiB) Downloaded 28 times

Result_mesh001.frd.txt

(4.95 KiB) Downloaded 26 times

[bernd]

my problem is I'm not that good in C++ . I'm only familar with the Python FEM code since 95 % has been changed by myself. I'm still learning C++ I have been done lot's of stuff in this regard for FEM too, but it is not as easy as Python. Main problem in C++ is, it takes a lot of time and FreeCAD is just fun in my spare time ATM.

bernd

[UR_]

Because faulty result mesh display has something to do with node numbering, i've started some test with a 2-element mesh (2 triangles shell mesh).
I tried to repair frd-file manually and found following:
Jumps and gaps in node sequence are without effect, as long as first node has number 1

Therefore a repair of 2d-example from FreeCAD's startpage is pretty easy.

known faulty display.

vanMises.png (155.35 KiB) Viewed 871 times

with repaired frd file

vanMises1stNodeNamed1.png (86.79 KiB) Viewed 871 times

change all appearances from node "178" to "1" (6 times)

Code: Select all

MAT    1SOLIDMATERIAL                                             
    2C                           408                                     1
 -1         1 0.00000E+00 1.00000E+03 0.00000E+00
 -1       179 0.00000E+00 5.00000E+02 0.00000E+00
 -1       180 0.00000E+00 0.00000E+00 0.00000E+00
 -1       181 0.00000E+00 1.00000E+03 1.00000E+03

file:

FEMMeshGmshStart1.frd.zip

(22.61 KiB) Downloaded 20 times

[HarryvL]

Fantastic ... that's easily fixed

[bernd]

workaround with idea of _UR: https://github.com/berndhahnebach/FreeC ... ell2D3Dfix

but it is more a hack than a workaround. I'd like to fix the C++ ...

BTW: in any result section the node number is wrong than, I wonder how it worked for you anyway? NodeNumbers in result object should be wrong if you only change node numbers and element numbers in frd file.

[UR_]

but it is more a hack than a workaround. I'd like to fix the C++ ...

Of course this observation isn't a blueprint for a workaround, source base shouldn't polluted that way.
It's mentioned for further debugging.
I tried to understand under which circumstances these errors occur.
So i introduced gaps and backjumps to frd's node numbering and couldn't confuse viewprovider.
Only renaming node 1 is able to do.

[bernd]

first version of a fix. It works for me ...

https://github.com/berndhahnebach/FreeC ... diff=split

but I need to test this a bit more ...

[bernd]

It's mentioned for further debugging.
I tried to understand under which circumstances these errors occur.
...
Only renaming node 1 is able to do.

it helped to fix it. What the fix does it it does the same for the node numbers before the start node than what is done for the gaps. It does include them in all the helper vectors, but ignores them at colorizing eventually.

[HarryvL]

Hi Bernd,

I ran a few cases and it seems the problem is now fixed in "CalculiX_static_results > Result_mesh". However, a problem still exists for VTK ... both creating a Pipeline and Exporting to VTK make FreeCAD crash for "OUTPUT=3D.

[bernd]

Yes thats true. I did not look into this yet.