Beam Section and Shell Thickness - Test Request

[bernd]

...
- results should be viewed in cgx since FreeCAD does not display them...

for reference.
The problem is in frd reader. The shells are expanded to solids. That is why the results read by the ccxInpReader do not fit to the FEMMesh see http://web.mit.edu/calculix_v2.7/Calcul ... ode39.html

Just check the FEMMesh NodesCount and the length of the results objects ... I need to fine a solution for this.

[bernd]

Minor code changes and a fix for lots of coin errors due to not yet supported graphical output:

https://github.com/berndhahnebach/FreeC ... hellbeam05

coin error fix:
https://github.com/berndhahnebach/FreeC ... 7a1c4b0fe0

[bernd]

In preparation of the implementation of multiple materials I did some heavy rewriting of the Calculix inp file writer inside the beamsection and shellthickness part. At the end there are only small changes inside the CalculiX input file. It's just the way how the CalculiX input file is written.

https://github.com/berndhahnebach/FreeC ... hellbeam08

[PrzemoF]

I'll post my comments here (I'm waiting for a new hardware to setup the code review system for FreeCAD):
Local compiling & automated tests: PASS
Travis CI: https://travis-ci.org/PrzemoF/FreeCAD/builds/82436449


1. That deserves a separate commit - it's not a comment, it's a change of way we filter inp files:

Code: Select all

diff --git a/src/Mod/Fem/TestFem.py b/src/Mod/Fem/TestFem.py
index ed822c0..7589ec5 100644
--- a/src/Mod/Fem/TestFem.py
+++ b/src/Mod/Fem/TestFem.py
@@ -119,8 +119,8 @@ class FemTest(unittest.TestCase):
         file2 = open(file_name2, 'r')
         f1 = file1.readlines()
         f2 = file2.readlines()
-        lf1 = [l for l in f1 if not l.startswith('**')]
-        lf2 = [l for l in f2 if not l.startswith('**')]
+        lf1 = [l for l in f1 if not l.startswith('**   written ')]
+        lf2 = [l for l in f2 if not l.startswith('**   written ')]
         import difflib
         diff = difflib.unified_diff(lf1, lf2, n=0)
         result = ''

2. I don't thinks it's right to use:

Code: Select all

__title__ = "FemShellThickness"

in src/Mod/Fem/ccxInpWriter.py
3. All prints should use brackets to be future proof (python3 porting):

Code: Select all

$ python3
Python 3.4.2 (default, Jul  9 2015, 17:24:30) 
[GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> print 'test'
  File "<stdin>", line 1
    print 'test'
               ^
SyntaxError: Missing parentheses in call to 'print'
>>> print ('test')
test

Below are just mine opinions - please ignore if you don't like them! :
1. I try to use short variable names like f, mo, el, r only when they are used very close to the definition or when it's very obvious what's behind (like our f variable for file in the inp writer that is everywhere).
2. Names like has_remaining_femelements_shellthickness or write_ccx_elsets_definitions_material_and_femelementtype( are probably a bit too long for non German speakers . I don't completely understand the code, so I'm not sure what name would be better (shorter, but still giving a clear message). Again, it's a matter of preference.
3. There is a saying (C language) that if you have more than 3 indentation levels you need to fix you program. I know that python is a bit different, but reading deeply nested if/for is hard. in generate_ccx_elsets there is if/for/for/if/for/if - could you use some helper functions? I tried to analysy the code, but my brain is boiling with that kind of nesting
4. I'm guilty of using that kind of naming as well, but check_femelements_count doesn't tell if True of False is the expected, no error retult. What about name fem_elements_count_ok?
5.

Code: Select all

__author__ = "Przemo Firszt", "Bernd Hahnebach"

should probably be

Code: Select all

__author__ = "Bernd Hahnebach, Przemo Firszt"

I think a single string is expected.

[bernd]

@Przemo, Thanks for reviewing the code. Your reviews make me really think more about my code quality. I did some heavy rewriting. Hopefully this one will be better ...

How about this:
https://github.com/berndhahnebach/FreeC ... hellbeam09

[PrzemoF]

The code looks, so good that it _has_ to be right!

The only thing that I caught is that femelements_count_ok returns True or nothing. It works fine as there is "None" returned by the function, but I think it's safer to add "return True" in the "else" section ot at the very end of femelements_count_ok

Local tests: PASS
Travis CI: https://travis-ci.org/PrzemoF/FreeCAD/builds/83480965

Phabricator test: the comment is also visible here http://pha.geofinder.eu/D4

P.S. I hope you're OK with my comments

[makkemal]

It has been a while since I tried a beam model.
I was unable to get a mesh out of my model, thinking that I may have done the geometry incorrectly I downloaded the example on this thread.
Re meshing it I get a mesh object, but the object does not actually contain a mesh. What am I doing wrong ?

Code: Select all

OS: Ubuntu 14.04.4 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.16.6698 (Git)
Build type: None
Branch: master
Hash: ca7c5d31a4d61f32a25b71025b14641a6e378328
Python version: 2.7.6
Qt version: 4.8.6
Coin version: 4.0.0a
OCC version: 6.8.0.oce-0.17

[bernd]

It has been a while since I tried a beam model.
I was unable to get a mesh out of my model, thinking that I may have done the geometry incorrectly I downloaded the example on this thread.
Re meshing it I get a mesh object, but the object does not actually contain a mesh. What am I doing wrong ?

Internal netgen mesher only meshes solid meshes. For shell and beam meshes I use gmsh. Attached the brep I used for meshing, the mesh file (unv) and a FreeCAD fea example of the flower. Remove .txt from unv file.

[fandaL]

I tried to search for the problem with displaying expanded beams. (That is when you delete "OUTPUT=2d" from the "*NODE FILE" card)

When ccx generates 3D results from beam it builds completely new mesh which is written into .frd file:
1)
I don't know why, but in the frd file from 1st order beam elements there remain some nodes with 0,0,0 coordinates not attached to any element. Frd file from 2nd order beams doesn't contain that nodes.
As far as I understand the ccxFrdReader it computes min, max, and average values of the stress and displacement from all nodes, which contains also the strange 0,0,0 nodes.
2)
Node numbers don't start with 1 and jump over some values. Element numbers also jump some numbers. I tried to renumber nodes in the frd file to start from 1 and not to jump over values. Then FreeCAD displayed 3D model properly coloured.
Theoretically it should not be so hard to renumber all nodes, when reading frd file, but do we want to have different node numbers from the ccx output?

Three frd files are attached (original; with deleted 0,0,0 nodes; and renumbered):

Line_Mesh002.frd.txt

(8.69 KiB) Downloaded 64 times

Line_Mesh002_del0.frd.txt

(6.3 KiB) Downloaded 75 times

Line_Mesh002_del0_renumbered.frd.txt

(4.58 KiB) Downloaded 66 times

[fandaL]

Some other digging
There seems to be a problem with node numbering and associated results. I get only to the point where function setNodeColorByScalars is called, but its inputs (node numbers, e.g. displacement) fit to frd original if printed before calling it
https://github.com/FreeCAD/FreeCAD/blob ... lt.py#L256

Code: Select all

self.result_object.NodeNumbers = 
[4, 5, 6, 7, 12, 13, 14, 15, 20, 21, 22, 23]

Code: Select all

displacements = 
[5.91344e-19, -5.91344e-19, 5.91344e-19, -5.91344e-19, 0.0045, 0.0045, -0.0045, -0.0045, 0.006, 0.006, -0.006, -0.006]

deformed shape seemed to be ok, but displayed coloring was wrong

wrong_coloring.png (59.5 KiB) Viewed 3376 times

tested on expanded seg2 (which is hexa8), but I get this problems also with other meshes with jumping node numbers

two_SEG2.frd.txt

(5.2 KiB) Downloaded 59 times

and original file:

two_SEG2.inp.txt

(2.9 KiB) Downloaded 57 times

Displaying is ok if node numbers go from 1 to the total number of nodes:

two_SEG2_renumbered.frd.txt

(5.2 KiB) Downloaded 54 times

Is someone willing to look if setNodeColorByScalars causes the problem?
https://github.com/FreeCAD/FreeCAD/blob ... mp.cpp#L65