Beam not reconstructed properly

[Rob]

I’m having trouble getting B32 beam elements (with a rectangle beam section) to work properly when specifying NORMAL at the nodes. The ‘height’ of the beam comes through, but the ‘width’ appears to be zero.

When I delete the NORMAL specification from my *.inp file, it builds elements with thickness – but of course oriented in the wrong direction.

Can anyone help figure out what is wrong with my input file? I’ve placed it in a Google Drive here. Let me know if it is not available for some reason.

Thanks for any help.

[Rob]

Here is what it looks like when I delete the NORMAL section from the *.inp file.

[dichtstoff]

Hello Rob,
is it possible to create an example inp. file with 1 B32 element with *NORMAL card,
acoording to coordinate system and get these work?
and in second step to change to random direction?
i think that could be very helpful to locate the error or problem!?
also for the community?!

wbr

[JuanP74]

you have an error in your model, when run it casts the following error for all beam elements:

 *ERROR in e_c3d: nonpositive jacobian
        determinant in element         129

I used v2.17

[Disla]

Hi @Rob ,
I recall having troubles when trying to define NORMALS on custom beams.

¿Have you tried to define the orientation directly in the *beam section card?

Would be something like this:

*BEAM SECTION,ELSET=Beam, MATERIAL=Aluminum 7075,SECTION=RECT,OFFSET2=-.52

0.005,0.1

0,0,1

It works straight through

The last three numbers in the card (0,0,1) is the normal.
The other two are built automatically. One in the direction of the beam and the last orthogonal to the previous two.
Check Manual.

[Rob]

Here is an example with just a single element – I had to strip out the pressure load and some of the run information at the bottom, so this may be missing some information, but hopefully it demonstrates the issue.

*NODE, NSET=Nodes
1,3.376000,0.465279,0.465279
2,3.803740,0.468696,0.468696
3,3.589870,0.466988,0.466988

*ELEMENT, TYPE=B32, ELSET=EBLine_PodGeom_Struct0_0_CAP
129,1,3,2

*NORMAL
129,1,-0.014871,0.707029,0.707029
129,3,-0.011525,0.707060,0.707060
129,2,-0.008178,0.707083,0.707083

*BOUNDARY
1,1
1,2
1,3
1,4
1,5
1,6

*BEAM SECTION, SECTION=RECT, ELSET=EBLine_PodGeom_Struct0_0_CAP, MATERIAL=Aluminum 7075-T6
0.100000,1.000000

** Materials
*MATERIAL, NAME=Aluminum 7075-T6
*DENSITY
5.4523
*ELASTIC, TYPE=ISO
1.49749e+09, 0.33
*EXPANSION, TYPE=ISO
1.31111e-05

[Rob]

You are correct – and if I delete the NORMAL vector specification, not only do the elements render in the expected manner, these Jacobian errors go away. I believe they are a second symptom of the same problem.

[Rob]

@Disla I am not ‘just’ trying to generate a single model. I am working on a program that can write out CalculiX models for nearly arbitrary aircraft structures.

Consequently, users can place beams anywhere in their model – and those beams can have any orientation. It makes the most sense to specify the beam properties once (per type of beam) and reference it from all similar beam elements.

If I were to include the orientation information in the beam section, I would have to have one such per each group of beams and those beams could not make a 90 degree turn in the direction of the vector.

When the conventional direction is normal to the nearby shell elements, this would prevent using beams to represent a ring frame around a fuselage (for example).

[Disla]

I see.
The problem could be that using the shell normals as reference can easily invert the beam element or vice versa. This is “not a problem” if the orientation is set for the whole beam as I suggested because the stiffener would show on the other side of the fuselage, but here you are specifying the normal on each nodes and it might be twisting the element (negative Jacobian) if they do not point all to the same side. .

[Rob]

Thanks for the suggestion. Visual inspection of the normal vectors in my example show that they are all very close to parallel. They certainly do not exhibit the sign changes that would indicate a flip in orientation.

Right now, I do not specify NORMALs for the shell elements – but I could.

For a shell element, it makes sense to order the points according to a right hand rule to imply a consistent orientation. Is there some convention for beam elements?

[JuanP74]

looks like bug to me. Normals are properly defined.

[Rob]

Thanks for the confirmation @JuanP74 . Are the developers using GitHub issue reports to track bugs, or is there another preferred way?

I’m running 2.18 – I’ll try updating to 2.20.

Unfortunately, I’m on MacOS and am currently using the HomeBrew installation from here, so it may take some time for me to get running with the newest version.

[Disla]

¿Could you give it a last try decreasing the stiffener height and adding an offset to the beam to visualize if they all go to the same side.?

I say it because I’m getting a fail due to jacobian if the stiffener is too height. I guess it overlaps itself in the expansion.

*ERROR in e_c3d: nonpositive jacobian determinant in element 7219

[Calc_em]

@Rob

Are the developers using GitHub issue reports to track bugs, or is there another preferred way?

There’s a new GitHub repository where we can report issues confirmed on the forum: GitHub - Dhondtguido/CalculiX: This repository contains the source files of CalculiX, a three-dimensional Finite Element Program (www.calculix.de).

[Rob]

@Disla – Thanks for the suggestion. I changed the height so it is 4:1 instead of 10:1.

I also set OFFSET1=0.5 and OFFSET2=0.5. The result is this:

You can see the beam elements were offset in the direction that is not degenerate – and no offset occurred in the zero-width direction.

It seems like the 3rd direction vector is (0,0,0).

[Rob]

Thanks everyone.

I verified that the behavior is the same in 2.20. I also made an issue report on GitHub.

Hopefully it will get picked up and addressed soon.

Rob