[MBDyn-users] QUESTION to the 'improved' version of the "CART"-WindTurbine example model & AeroDyn-12.58 interface

Pierangelo Masarati masarati at aero.polimi.it
Tue Aug 28 16:45:48 CEST 2012


[replying to mbdyn-users according to your suggestion]

On 08/28/2012 01:53 PM, Rix, Patrick wrote:
> Dear Pierangelo,
>
> as I already mentioned I attached a third version of the CART model
> hidden in a sub-archive which was an attempt (work around) to improve
> the model by decoupling the structural and aerodynamic discretization
> when using AeroDyn.
>
> I wanted to ask you for your feedback, what you think about the
> solution, if you see any short comings or disadvantages in the
> approach.
>
> The situation + work-around is as follows:
> ------------------------------------------- Let's start assuming a
> relatively coarse structural discretization of a wind turbine rotor
> blade being composed of a few number of beam3 elements (e.g. 5-10
> beams) with corresponding dynamic structural nodes and rigid bodies
> attached. Now we want to add the aerodynamic behaviour represented by
> a relatively fine aerodynamic discretization (e.g. 40-50
> AeroDyn-elems) in order to correctly capture the variations of the
> chord, twist and airfoil distributions along the blade span. The
> situation would be easy if each AeorDyn-elem could be placed/attached
> to the next (nearest) structural node (of the beam3-line) in a
> controlled way by prescribing it's offset from the structural node -
> but unfortunately the current interface has the short-coming that
> only the orientation of the AeroDyn-elem w.r.t. the structural node
> can be specified. This results in the AeroDyn-elems being
> automatically placed with their middle point on the struct.node they
> are mapped to. Now if a user would like to place several
> AeroDyn-elems (representing a certain spanwise segment of the blade)
> to one struct.node all elems would be placed with their mid-point on
> the struct.node what results in a wrong representation of the blade
> [we tested that]. Now in order to overcome this weakness of the
> current module-aerodyn interface and to make the structural and
> aerodynamic disretization independent of each other, we added a
> number of extra structural HelpNodes (dynamic nodes), one extra node
> for each aerodynamic element (AeroDyn). We only added extra nodes
> without any extra beam3 elements. Each of these extra HelpNodes will
> be located at the correct spanwise position, where the mid-point of
> the respective Aero-elem is located on the real blade. Each extra
> HelpNode is clamped via a total joint to the next (nearest)
> struct.node (of the beam3-line). Now having struct.markers (nodes) at
> the correct positions each AeroDyn-elem will be attached to its
> HelpNode inside the user defined elem.
>
> We wrote some scripts to automate this procedure during the model
> generation and it seems to work fine - at least producing correct
> results.
>
> The disadvantage I see are the many extra elements (e.g. for 50
> AeroDyn-elems we get 50 extra dynamic nodes and 50 extra total joints
> - per each blade !). So we introduce 3(blades)x50(nodes)x6(DOFs) =
> 900 extra_DOFs, which will be all cancelled out through the total
> joints (i.e. 900 extra_Constraints). I have absolutely no feeling for
> the effect on the performance, as right now we have a quite low
> performance resulting from AeroDyn, anyway (so we don't recognize it
> by now).
>
> [BTW:..does your simulation with AeroDyn also take several 10 seconds
> right at the start before the calculation really begins to run ?]
>
> I hope this significant inflation of the system matrix preserves the
> band structure of the system matrix such that it does not cost the
> solver too much extra effort..or something like that.
>
> Could you please comment on that.
>
> Idea / proposal for interface improvement:
> ----------------------------------------- Wouldn't it be a good idea
> to improve the current interface by adding the possibility to define
> the exact position of an AeroDyn-elem by giving its offset w.r.t. to
> the struct.node it belongs to (in order to save the extra HelpNodes +
> total joints) ?
>
> Another point of the current module-aerodyn I see is, that the choice
> of reference frames is not conform to GL or IEC coord.systems. The
> approach of NREL's ADAMS_to_AeroDyn is much closer to the common
> standard, well documented and being in use by a broader
> (SIMPACK+ADAMS) user community and thus being sort of validated.
> Tower-effects are also included.

I see your idea of decoupling the two discretizations is very 
interesting; however, I think the approach of adding nodes that are 
rigidly attached to those involved in the structural model is 
unnecessarily complex and heavy.

My suggestion is to use the "external structural mapping" force approach 
to consistently map the kinematics of the structural nodes to the 
kinematics required by AeroDyn, and to map back the resulting loads on 
MBDyn's structural nodes.

The generation of the consistent mapping between the two domains is 
already automated thanks to the "create_mls_interface.m" script provided 
in contrib/MLS.

In order to use the "external structural mapping" force as is, AeroDyn 
would need to be cast in a separate, concurrent task.  Otherwise, a 
monolithic element could be obtained by inheritance from the 
StructMappingExtForce element (mbdyn/struct/strmappingext.*).  I think 
this could be one way to go for an overhaul of module-aerodyn.

Cheers, p.

> PS:..if you like, you can answer via the mailing list, as others
> might be interested in this discussion, too.

-- 
Pierangelo Masarati
Associate Professor
Dipartimento di Ingegneria Aerospaziale
Politecnico di Milano


More information about the MBDyn-users mailing list