beam analysis with beams in z-direction
Moderator: bernd
Forum rules
and Helpful information for the FEM forum
and Helpful information for the FEM forum
Re: beam analysis with beams in z-direction
Should we create a edge (1D line) identifier since elements will change with mesh?
24 nodes per edge
12 elements per edge
12 edges
Group 1 (Edge 1)
- 24 Node ID's
- 12 Elements
- 1 Normal (can be from first element in the edge)
24 nodes per edge
12 elements per edge
12 edges
Group 1 (Edge 1)
- 24 Node ID's
- 12 Elements
- 1 Normal (can be from first element in the edge)
Re: beam analysis with beams in z-direction
@FemUser:
just play a bit with multiple materials and multiple beam sections and mix them each other. The rotation is just another of these kind of property we need to make an own elset in the inp file for.
My suggestion ATM would be.
- a rotation property is added to the beam section object.
- a standard rotation needs to be defined if the rotation is not changed by the user
- if a user would like to have a different rotation from the standard one, he changes it in the beam section object
- if no reference shape is defined all beams use this rotation (as ATM with the cross section)
- it only a few beams should be rotated reference shapes needs to be defined.
- with this it could happen some cross sections are defined twice because of different rotations
the other way to go would be
- we create a new object just for the rotation of beam sections
- if this object is not in the analysis the standard rotations is used
- if this object is in the analysis but no reference shape is defined, all beams use this rotation
- if this object is in the analysis and some reference shapes are defined, these reference shapes use this rotation.
I'm not 100 % sure which one is best. Which one you guys prefer?
cheers bernd
just play a bit with multiple materials and multiple beam sections and mix them each other. The rotation is just another of these kind of property we need to make an own elset in the inp file for.
My suggestion ATM would be.
- a rotation property is added to the beam section object.
- a standard rotation needs to be defined if the rotation is not changed by the user
- if a user would like to have a different rotation from the standard one, he changes it in the beam section object
- if no reference shape is defined all beams use this rotation (as ATM with the cross section)
- it only a few beams should be rotated reference shapes needs to be defined.
- with this it could happen some cross sections are defined twice because of different rotations
the other way to go would be
- we create a new object just for the rotation of beam sections
- if this object is not in the analysis the standard rotations is used
- if this object is in the analysis but no reference shape is defined, all beams use this rotation
- if this object is in the analysis and some reference shapes are defined, these reference shapes use this rotation.
I'm not 100 % sure which one is best. Which one you guys prefer?
cheers bernd
Re: beam analysis with beams in z-direction
depending on the decision above it will be implemented on a different point in the FemInputWriter.
- if we would add a property to the beam section we would need to add it at the multiple beam elsets directly:
https://github.com/FreeCAD/FreeCAD/blob ... 1126-L1136
https://github.com/FreeCAD/FreeCAD/blob ... 1208-L1223
- if we would make a new object we would need to add a level of abstraction in addition to material and beam section would be needed here: https://github.com/FreeCAD/FreeCAD/blob ... #L358-L396
- if we would add a property to the beam section we would need to add it at the multiple beam elsets directly:
https://github.com/FreeCAD/FreeCAD/blob ... 1126-L1136
https://github.com/FreeCAD/FreeCAD/blob ... 1208-L1223
- if we would make a new object we would need to add a level of abstraction in addition to material and beam section would be needed here: https://github.com/FreeCAD/FreeCAD/blob ... #L358-L396
Re: beam analysis with beams in z-direction
Let's use this as an example too. Some voluntary to model this in FreeCAD ?UR_ wrote: ↑Sun Oct 22, 2017 11:08 am on feacluster.com one can find a "official" example for B32 beams with different orientation.
This approach seems to produce smaller INP-files
Please have a look:
screenshot feacluster beam example.png
http://feacluster.com/CalculiX/ccx_2.11 ... ode377.php
Re: beam analysis with beams in z-direction
a new FEM object beam_rotation was born this morning ... https://github.com/berndhahnebach/FreeC ... s/fembeams
It does not write anything to the inp file yet. But all GUI is implemented. You can add beam rotation objects and input a rotation. If one does run an analysis, the rotation of the first rotation object is printed. That's it so far. We need to implement the writer now ...
It does not write anything to the inp file yet. But all GUI is implemented. You can add beam rotation objects and input a rotation. If one does run an analysis, the rotation of the first rotation object is printed. That's it so far. We need to implement the writer now ...
Re: beam analysis with beams in z-direction
@FemUser: At FEM we gone write Python code regarding pep8 and use spaces only (no tabs at all !) for intendeation. On my linux machine I just run the following command to see all format errors. There are a lot on your code in FemWriterCcx.
bernd
Code: Select all
find src/Mod/Fem/ -name "*\.py" | grep -v convert2TetGen.py | grep -v InitGui.py | xargs -I [] flake8 --ignore=E501,E265 []
Re: beam analysis with beams in z-direction
And I was wondering why so many spaces
Re: beam analysis with beams in z-direction
@Bernd: The only thing necessary to achieve that approach is to group all mesh elements of a edge into a group. The cube example or the swing give the same problem.That particular example bundles two legs of the swing and in a separate name the horizontal bar. I don't agree it's automation since two parts are bundled into the same group it will require a harder automation because there will have to be a criteria for bundling things together also remember that the rotation vector will not be the same for every edge case and the user will have a hard time controlling them. For me the correct way is for every edge a specific normal; this for the auto mode and manual mode. Size will not increase with mesh and every edge has its specific configuration and will be compatible with manual definition also. The user sees the resulting beam orientation because all beams will be oriented same way and of course If a change is necessary a specific edge is selected and a new orientation defined.
Meaning 12 edges (In auto mode) = 12 normal definitions if a user wants to bundle further he selects the groups they require and instead of 12 normal's they get 1, 2 or what ever they wish number of rotations.
So in example I would recommend (for auto mode):
Swing: Leg1-Eleg1, Leg2-Eleg2 and horizontal bar - Ehori
or on the Cube:
Cube: ZBar1,ZBar2, ZBar3, ZBar4 & xBar1,xBar2, xBar3, xBar4 and yBar1,yBar2, yBar3, yBar4
Visually all beams will be aligned and look as if they are leaning towards the same direction.
Optionally I could manually select all Z, X and Y bars and define a normal for each group and the inp will look the following:
Cube: ZBar, YBar and Xbar
I.e.
*ELSET,ELSET=Ezbar
(...)
*ELSET,ELSET=Eybar
(...)
*ELSET,ELSET=Exbar
(...)
This reminds me of requesting a feature "Named Spaces". If I could select on the GUI all the edges I wish and associate a name to them then use it on the definition box (constraints i.e.1D beam) that would be very helpful I use them all the time in other FEA apps (The same for nodes and planes)
Meaning 12 edges (In auto mode) = 12 normal definitions if a user wants to bundle further he selects the groups they require and instead of 12 normal's they get 1, 2 or what ever they wish number of rotations.
So in example I would recommend (for auto mode):
Swing: Leg1-Eleg1, Leg2-Eleg2 and horizontal bar - Ehori
or on the Cube:
Cube: ZBar1,ZBar2, ZBar3, ZBar4 & xBar1,xBar2, xBar3, xBar4 and yBar1,yBar2, yBar3, yBar4
Visually all beams will be aligned and look as if they are leaning towards the same direction.
Optionally I could manually select all Z, X and Y bars and define a normal for each group and the inp will look the following:
Cube: ZBar, YBar and Xbar
I.e.
*ELSET,ELSET=Ezbar
(...)
*ELSET,ELSET=Eybar
(...)
*ELSET,ELSET=Exbar
(...)
This reminds me of requesting a feature "Named Spaces". If I could select on the GUI all the edges I wish and associate a name to them then use it on the definition box (constraints i.e.1D beam) that would be very helpful I use them all the time in other FEA apps (The same for nodes and planes)
Code: Select all
*ELSET,ELSET=Eleg
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11,
12,
13,
14,
15,
16,
*ELSET,ELSET=Ehori
17,
18,
19,
20,
*BEAM SECTION,ELSET=Eleg,MATERIAL=EL,SECTION=RECT
0.05
0.,0.,1.
*BEAM SECTION,ELSET=Ehori,MATERIAL=EL,SECTION=RECT
0.05
0.,1.,0.
Last edited by FemUser on Tue Oct 24, 2017 10:05 am, edited 1 time in total.
Re: beam analysis with beams in z-direction
I think I killed all the tabs with Detab in text wrangler...
Re: beam analysis with beams in z-direction
for your featur request in case of group names for other fea which work on the mesh instead om the geometry you should have a look at meshgroup object of FEM wb. You ca explizit set the name for the mesh groups with this object.