I would like to check the internal DOF evolution of a time-marching simulation in FAST. I had a look to the FAST OutList.txt and, unfortunately, I cannot see any reference to internal DOF variables.
When performing a linearization, i obtain the internal DOF index/names as:
1 = Variable speed generator DOF (internal DOF index = DOF_GeAz)
2 = 1st flapwise bending-mode DOF of blade 1 (internal DOF index = DOF_BF(1,1))
3 = 1st flapwise bending-mode DOF of blade 2 (internal DOF index = DOF_BF(2,1))
4 = 1st flapwise bending-mode DOF of blade 3 (internal DOF index = DOF_BF(3,1))
5 = …
These variables are available (as state variables) when using matlab port FAST_SFunc.mexw32, but i wonder if Is there any way to access, let say, DOF_BF(i,j) without modifying/compiling the command line version of FAST.
Thank you in advance.
You are correct, the internal DOFs are not direct outputs of FAST even though the linearized matrices output by FAST are expressed in terms of internal DOFs. You are also correct that the internal DOFs are available wthin Simulink (as the internal states are integrated by Simulink’s solver).
At present, obtaining the internal DOFs from the command-line version of FAST will require a recompile. You can access the instantaneous values of the DOFs and their derivatives by using MODULE RtHndSid() and MODULE DOFs(). Array QT() are the displacements, QDT() are the velocities, and QD2T() are the accelerations. The FAST linearization output file tells you which index to use for each state. For example, to access the current displacement of the variable speed generator DOF, use QT(DOF_GeAz).
We plan to add the internal DOFs as direct outputs of FAST in a future release (we are currently working on an update to FAST that includes several new outputs). But this update will not be available in the immediate future.
As you mentioned,
together with some arrangements in FAST_IO.f90 will provide all the information I need (easier than I thought). Thank you for your priceless help.
As you suggested, I haver compiled a new version of FAST ( FAST_v602c-jmj ) and compared the standard outputs of FAST in the local coordinate system (TipDxbi,TipDybi) with the amplitude of the nodal coordinates ( QT(DOF_BF(i,1)), QT(DOF_BE(i,1)) ) in a parked turbine situation:
As the amplitude of modal shapes are all = 1 for the blade tip position, my first thought was to compare the tip deflections with the modal amplitudes. This seems to be a correct approach in the case of flapwise deflections. By contrast, in the case of edgewise deflections, QT(DOF_BE(i,i)) is not equal (or even similar) to TipDybi, so I wonder how tip deflections are calculated in such direction.
Thank you in advance.
The blade bending-mode DOFs internal to FAST are not the flapwise and edgewise deflections of the blade tip. This is due to the blade structural pretwist. Instead, the DOFs are values proportional to the curvature of the blade along the pretwisted structural axes. (When you integrate the curvatures about pretwisted axes, you end up with both flapwise, edgewise, and axial components of deflection for either flapwise or edgewise curvatures). Only if a blade had no structural pretwist would the blade DOFs equal the tip deflections in the flapwise and edgewise directions.
Because the blade flapwise stiffness is typically quite a bit less than the edgwise stiffness, the influence of the edgwise bending on TipDxbi will be much less than the influence of flapwise bending on TipDybi. I suspect this is the reason why you are seeing good agreement in TipDxbi, but not in TipDybi.
You were right. The differences between QT(DOF_BE(i,1)) and TipDybi are due to pre-twist of the blade sections. I was just trying to obtain a simplified approximation to the blade deflections by using modal coordinate amplitudes. Now I have an idea about the limitations of this approach.
Thank you very much for your kind replies.