[MBDyn-users] Placing the middle node of a 3 node beam -> for using AeroDyn

Jens.vanSchelve at Emerson.com Jens.vanSchelve at Emerson.com
Wed Feb 23 14:47:34 CET 2011

Ok, I asked that because I have difficulties using the aerodyn-module.
This is what I want to have (like mbdyn aero3 beam), with 1-5 beeing nodes 
connected by beam3 elements and A-D beeing AeroDyn elements.

       __A__ __B__ __C__ __D__
 ---  |     |     |     |     |
(HUB) 1-----2-----3-----4-----5
 ---  |_____|_____|_____|_____|

But NRELs AeroDyn expects the position and velocity in the middle of the element.
So if I connect element A to node 2, B to 3 and so on the position and velocities
of node 2 are passed to element A. This means the velocity of element A is too high.

Same with the forces: AeroDyn returns the force in the middle of the element, but
if I connenct A to node 2 the force is applied exactly at node 2 - so I have too
big blade root moments.

The conclusion is what I get, but not want, is a model that one can imagine like this:

          __A__ __B__ __C__ __D__
 ---     |     |     |     |     |
(HUB) 1-----2-----3-----4-----5  |
 ---     |_____|_____|_____|_____|

So something that is similar to a too long aerodynamic-blade. I did a lot of comparisons
With NRELs FAST and in fact if I increase the blade and hub size in FAST by half the
element size, MBDyn-AeroDyn and FAST match very good. Of course if I increase the
number of beam- and AeroDyn elements in MBDyn the error decreases, but it is still
not a nice solution.

So there are two better solutions:
1: Change the mbdyn-aerodyn-module to connect two nodes to one AeroDyn element,
   calculate the mean position and velocity and apply to each node half of the
   force AeroDyn returns or
2. Place the nodes so that one can attach AeroDyn elements without any error, like:

       __A__ __B__ __C__ __D__ __E__
 ---  |     |     |     |     |     |
(HUB) 1--2-----3-----4-----5-----6--7
 ---  |_____|_____|_____|_____|_____|

In this case one can attach AeroDyn element A to node 2, B to 3.. and E to 6.
Node 1 (root) and 7 (tip) do not have an AeroDyn element attached, but are
still inside the aerodynamic area, the forces are just summed into node 2 and 6
which is ok in my opinion.

For the beams you can have three beam3 elements (1-3,3-5,5-7) but node 2 and
node 6 are not in the midle of the beam or another option would be to have
two beam2 elements (1-2,5-7) and two beam3 (2-4,4-6). But as far as I understand
beam2 elements are also not that accurate.
In a third option one can also introduce additional two nodes, one between node
1 and 2 and one between 6 and 7 and than use beam3 elements there instead of beam2
but also those nodes would not have any aerodynamic force applied - not sooo nice. 

Does anyone have some other, better options in mind?


-----Ursprüngliche Nachricht-----
Von: masarati at aero.polimi.it [mailto:masarati at aero.polimi.it] 
Gesendet: Dienstag, 22. Februar 2011 20:01
An: van Schelve, Jens [INDAUTO/SSB/SAL]
Cc: mbdyn-users at mbdyn.org
Betreff: Re: [MBDyn-users] Placing the middle node of a 3 node beam

> Hi,
> just a little question about the 3 node beam element:
> Is it allowed to place the (structual) middle node not exactliy in the 
> middle, but e.g. lets say 1/3 of the lenght of the beam?
> I mean not like:
> 1-----2-----3
> But:
> 1---2-------3

It is, but you must be aware of the possible consequences.  In addition to Romuald's comment, as soon as you move the mid-node you distort the metric of the beam.  Not only this impacts the location of the point where constitutive properties are evaluated; it may also yield surprising
results: as in plane and solid isoparametric elements, moving the mid-node to a quarter-length of the element yields infinite strain at the closest end node, as used in linear fracture mechanics to model crack tip conditions.  I strongly recommend to place the mid-node exactly at mid-span.

> Jens
> BTW: the *.log file patch works fine - thank you very much for that!
> Just the "name" is missing in the headline - but thats realy not that 
> critical :)

Yeah, I noticed that after posting the patch.  It is fixed in the mainstream code, will appear in the official release ;)

Cheers, p.

More information about the MBDyn-users mailing list