1D Beam elements (B32) with orthotropic material

1

Hi,

I’ve run into a problem with a model that uses 1D elements (B32) with an orthotropic material.

It seems that the orientation of the material is always locked to global space and doesn’t align with the beam coordinate system… Is there a simple trick that I am missing?

I tried adding an *ORIENTATION and *DISTRIBUTION card to set the orientation for each element, but it seems that it only respects the default orientations specified under one of those cards, which it then takes for all elements…

As an example, here is a cantilevered beam (2 B32 elements), supported in DOFs 1 through 6 at the origin.

Here it is aligned with the X-axis:

image
image908×653 26.1 KB

Here it is rotated so it is aligned with the Y-axis:

image
image941×635 26.2 KB

Material and section definitions are:

*Material, Name=Wood
*Elastic, Type=Engineering Constants
9.7E+09, 4.0E+08, 2.2E+08, 0.35, 0.6, 0.55, 4.0E+08, 2.5E+08,
2.5E+07
*Density
480

*Beam Section, Elset=beamElements, Material=Wood, Section=RECT
0.2, 0.1
0, 0, 1

BC and load settings:

*Boundary
supports, 1, 6
*Dload
all, GRAV, 200, 0, 0, -1

where supports is a node set with the first node (1) located at the origin, and all is an element set for all 2 elements :stuck_out_tongue:

I expected that the material axes would be aligned with the beam element axes, but this is clearly not the case, and I can’t seem to control this with the *DISTRIBUTION card for beam elements according to the docs, so I’m wondering if it is possible to do that for each element?

Much thanks!

Tom

2

As a side note, I’ve been also trying to adjust this by writing an external material and loading a rotation matrix for each element/integration point and doing the transformation there, but haven’t had any luck so far either. It seems that would be the place where it must work because everything should be controllable at that point…

3

I guess you need to add the orientation card to the each beam section definition.

*ORIENTATION,NAME=ORTHO_X
1,0,0,0,1,0

*ORIENTATION,NAME=ORTHO_Y
0,1,0,-1,0,0

*Material, Name=Wood
*Elastic, Type=Engineering Constants
9.7E+09, 4.0E+08, 2.2E+08, 0.35, 0.6, 0.55, 4.0E+08, 2.5E+08,
2.5E+07
*Density
480

*Beam Section, Elset=Beam_X, Material=Wood, Section=RECT,ORIENTATION=ORTHO_X
0.2, 0.1
*Beam Section, Elset=Beam_Y, Material=Wood, Section=RECT,ORIENTATION=ORTHO_Y
0.2, 0.1

imagen

4

Thanks, Disla!

Does that mean that for each element that is pointing in a different direction, I will need a separate beam section card? What about for curved beams (a series of linear elements) where the orientation changes gradually? I can just see the .inp size exploding with all these beam sections…

5

I don’t other way sorry. :disappointed_relieved:

6

@tsvilans writing an orientation and section card for each element shouldn’t be too troublesome. Could you upload your .inp so that i can take a look?

7

Thanks, NorbertH! I know how to do this, it’s OK, I was just hoping for a simpler and more compact way of doing it with a *DISTRIBUTION card as for normal 3D elements.

In any case, I found a workaround using an external material that reads the orientation data from somewhere else :slight_smile:

8

Feel free to post it so others in the future can use this method when facing similar problems :sweat_smile:

9

Sure thing, I’ll try to put together something more comprehensive when I can, but essentially I implemented an orthotropic elastic material using linel.f and umat_lin_iso_el.f as guides and compiled it as a shared library written in C. This is then called as an external material (with a material name something like @LIB_MATERIAL)

Instead of looking at the usual orientation pointer (orab) it looks into a bit of shared memory, if it exists, for the axis values for each element and constructs the rotation matrix from those. This way I can specify the orientations in a script or other program before launching CalculiX, and the idea is to expand it to also include other per-element variables (such as varying the stiffness at each integration point) that would be relevant to heterogeneous materials - though this part would be more aimed towards 3D elements and volumes.

I realized that the normal binaries for CalculiX don’t have external materials enabled, so CalculiX needs to be compiled with the CALCULIX_EXTERNAL_BEHAVIOURS_SUPPORT flag.

1 Like
10

In situations like these, I tend to write a Python script to generate (part of) the inp file.

2 Likes