Hydrodynamic coefficients HELP!

And here are my files

Thank you
hydro.zip (233 KB)

Dear Bartosz,

I’m not sure I understand the problem you are describing. What are the various results you are plotting (I don’t understand the labels: ORE Catapult and OpenFAST, N-S, E-W, etc.)? What is the difference between HWS.png and SurgeSawySparInput.png?

I see some basic differences in your frequency domain solution of wave-excitation, wave radiation, and added mass, but nothing that stands out as concerning that would cause strong oscillatory response.

Could the problem be that the natural frequencies of your platform coalesce with the first-order wave-excitation frequency, unlike in OC3-Hywind spar, whereby the natural frequencies in surge/sway and pitch/roll are placed outside the frequency range of the first-order wave excitation?

Best regards,

Dear Jason,

This is very intersting! I’d better make sure these frequencies are in order!
I’m going to have a go this weekend.

In fact the SurgeSawySparInput.png is a plot of the results when I set PotFile to link to Spar files that you produced for OC3 Hywind turbine. And HWS is when I use the data I generated with Nemoh. Both sets are posted above in the .zip file. Nothing else was modified and the turbine is still the same model with my blades, and producing 6MW of power!
ORE Cataput is a UK based organization who share operational data from Hywind Scotland timeseries which I’m trying to match to with my model.
What I find amazing is that just by changing the hydrodynamic input files one gets completely different resoponses. It’s important because the pitch controller is very sensitive to this.
Is the process of placing the natural frequencies dealt with by setting the controll gains, like here (page 22)
nrel.gov/docs/fy10osti/47535.pdf
or is it rather a more general turbine-support structure configuration issue?
Thank you again for your comments!

regards,

BS

Dear Bartosz,

OK, thanks for clarifying.

The natural frequencies of the platform modes will be dictated by the full system mass / inertia (including added mass) and stiffness (including hydrostatic and mooring), and will thus be based on the system configuration (geometry, material properties). If the platform-pitch or platform-surge natural frequencies are heavily impacted by the change in spar properties, then as you said, you may also have to modify the controller gains to ensure overall stable operation in above-rated operating conditions.

Best regards,

Dear Jason,

Thank you for your comments! It’s true, the natural frequencies from OpenFAST are nothing like the ones I believed to have modeled for!
To obtain the natural frequencies I ran a simulation with no waves or inflow and linearized with only the 6 DOFS of the platform enabled. Then I ran the matlab scripts fx_mbc3.m and campbell_diagram_data.m
Was this the right way to do this?

Now that I have to remodel the whole turbine, I would really like to have a quick way to view the mass matrix of the system in OpenFAST. is there a way to output it somehow?

Thank you again!

Dear Bartosz,

Yes, your linearization process sounds correct.

The OpenFAST linearizations do not show the mass matrix directly, but this matrix can often be inferred from other matrices generated through the linearization process. A similar question was asked and answered in the following forum topic: http://forums.nrel.gov/t/openfast-2nd-order-linearization/2249/2.

Best regards,

OMG!
I’m such a dummy,
Thank you!

Dear Jason,
I’ve been trying to visualize the mode shapes of the platform motions,
using

..\..\..\Desktop\OF25\openfast_x64.exe  -VTKLin .\ED_HWS_CASE_0_MODSHPSMBC.viz

with a fx_mbc3 file linked all right and the program generates the yaw motion OK, but then I get this error:

Is this something you could help me with?
Other modes are not generated.

Regards
BS

Dear Bartosz,

It looks like there are many warnings about large angles, but it also said OpenFAST terminated normally. So, what do you mean that “other modes are not generated”? What does your ED_HWS_CASE_0_MODSHPSMBC.viz file look like? You can probably eliminate the warnings by reducing VTKLinScale in this mode-shape visualization file.

Best regards,

Dear Jason,

Thank you for your help.
I am attaching the files.
Now that I have read your previous reply though… Could it be that the other mode shapes are just zero? And that I am only seeing the yaw due to the ED Yaw moment I have in the inputs?
Maybe my linearization didn’t produce the results needed to visualize surge, sway, and other modes of the platform displacements?
I can see how I can find the

-M^-1K,-M^-1C

matrices, but in order to find

M^-1

do have to have loads acting on the platform listed as inputs?

Regards,

BS
ED_HWS_CASE_0_MODSHPSMBC.viz.txt (1.3 KB)
HWS_CASE_0_MODSHPVIS.1.lin.txt (21.8 KB)

Dear Bartosz,

It looks like you are only seeing one mode because VTKLinModes = 1 in your mode-shape visualization file.

Yes, you need to have loads acting on the platform as inputs to derive the 6x6 rigid-body mass matrix. These are available by setting LinInputs = 2 in the OpenFAST primary (*.fst) file and regenerating the linearization output.

Best regards,

Dear Jason,

Thank you for your suggestions!
I successfully generated VTK output for all modes of platform displacements but 1 and 2, surge and sway, but I’m sure that with some more trying it’ll be possible to get them as well.

I also obtained the M matrix from the linearization output. Thank you for your advice.
I used the subset of D transmission matrix produced by fx_mbc3.m from ED Platform XYX forces/moments, node 1 into ED Platform XYZ translation and rotation accelerations, node 1
I noticed the damping present in the model and stiffnesses affect the result.
At the moment I set the PotMod to 0 (and set the simple hydrodynamic coefficients to 0 as well) and I have good agreement with the mass matrix supplied by Equinor in terms of the mass of the total system. This matrix from Equinor is one without the part from mooring stiffness influence. the mooring stiffness matrix is supplied separately and I used it for the matrix of additional stiffness in Hydrodyn and disabled CompMooring. There is information that mooring creates 270 tons force downward, so I set this as preload in Hydrodyn in the -z direction.

I tried to balance with the mass of the platform to have as good a steady state as possible but there was an oscillation, so I set additional damping to 100 on all the diagonals but it didn’t help much. I had 0.4 m amplitude of the oscillation in surge when linearizing after 2000 seconds.

Taking into account how the mass matrix from OpenFAST was calculated from Newtons Law, I wanted to ask you:
1.Could I do anything else to get a more exact mass matrix? Rignt now I have differences of about 4000 kg between elements M(1,1), M(2,2) and 1000 kg between M(2,2) andM(3,3). Considering the mass is 11.5 thousand tons the error is not huge, but maybe I did something wrong?
Would constraing the DOFs and calculating one Platform DOF at a time change anything?

  1. Should the specified preload be considered as mass added on top of the system mass and added to the element M(3,3)? this would make the results much worse…

  2. Was my way of obtaining the mass matrix correct?

  3. Is this right that to have as similar system as possible using the Force- acceleration transmission from linearization I would have to have some information about the damping in the real turbine which was not supplied. Is there a way to use the PotMode and somehow filter out the mass matrix of the model?
    All I have is mass matrix, mooring stiffness matrix and eigenperiods.
    My plan now is to adjust the inertias and mass distribution to match to the eigenperiods and mass matrix supplied using the mooring restoring matrix and linearizing to get the mass matrix of the model. but I’m afraid that later when I use PotMod=1 again for simulations the system will be wrong again.
    What do you think I should do?

thank you again for all your help and patience!

Regards,

Bartosz

Dear Bartosz,

Regarding oscillations even after 2000 s, this is probably because you’ve zeroed the simple hydrodynamic coefficients (drag coefficients) and the remaining damping is low. You could always look at how the platform displacements are converging and use those (mean of the response) as initial conditions for a subsequent simulation.

Here are my answers to your questions:

  1. Are you already generating your linearization output file with fine precision, e.g., OutFmt = “ES17.9E3”? If not, that may help improve the accuracy of the method.
  2. No, the preload comes from the mooring system, but my understanding is that you want the rigid-body mass matrix of the FOWT without moorings.
  3. Yes, that sounds correct.
  4. I’m not sure I understand your question, but the force-acceleration transmission method should be independent of the damping specified.

Best regards,

Dear Jason,

thank you!
You’re right.
So it’s only the added hydrodynamic mass that is changing the mass matrix right? Because of how you designed Hydrodyn?
I think the errors in my mass matrix from linearization was due to the poor quality of my operating point selection. I added some more damping and the differences between Mi,i for the masses are gone.
Thank you, now I feel like I know what I’m doing.

Regards,

BS

Dear Bartosz,

I’m not sure I understand your question about the hydrodynamic added mass, but if I understand correctly, you are extracting the 6x6 rigid-body mass matrix of only the structural model because you are deriving this mass matrix by post-processing the ElastoDyn linearization output only (*.ED.lin). The hydrodynamic added mass is included in the full-system mass matrix when HydroDyn is enabled, but these terms are not visible in the ElastoDyn linearization output.

Best regards,

Dear Jason,

Thank you for your suggestions,

To clarify, I was using the rigid body mass matrix from ElastoDyn, yes. The masses I obtained on the diagonal or the first 3 rows and columns of the mass matrix correspond to my overall mass sum, so I think this went well.

I have to ask you about a detail of the Elastodyn input file.
Thanks to your kind remarks, I identified a lot of inconsistencies in my model and now I am rearranging the mass distribution of the whole system. I am getting close. I’ve reviewed most of the masses and made a sketch of the most important of the structural elements in order to get a better approximation of the values of the inertias. For the nacelle, I am considering the elements from the picture below:

I have a doubt about the ingredients of the nacelle inertia parameter NacYIner = Nacelle inertia about yaw axis (kg m^2)

Should I include the hub inertia in calculating the value of this parameter for does OpenFAST do it by itself?

Also, for the GenIner - Generator inertia about HSS (kg m^2), should I only use the inertia of the moving parts of the generator?

Thank you again

Best Regards,

BS

Dear Bartosz,

As you’ve likely noticed, the RNA in ElastoDyn is modeled simply, with only a few user inputs in terms of the nacelle mass (NacMass) and yaw inertia (NacYIner), the hub mass (HubMass) and rotational inertia (HubIner) and generator rotational inertia (GenIner). So, NacMass should represent any mass in the RNA not considered in the blades or the hub. And NacYIner should include any nacelle-yaw inertia that is associated NacMass (not including HubMass). And HubIner should include rotational inertia about the shaft that is associated with HubMass.

The total rotational inertia of the rotor and drivetrain should be reflected in the distributed blade mass, HubIner, and GenIner. So, GenIner should include any rotational inertia of the drivetrain (expressed relative to the high-speed shaft if there is a gearbox) not accounted for in HubIner.

Best regards,

Dear Jason,

I have successfully modeled the turbine using CAD and FEM for masses and inertias and the rigid body matrix is now in agreement with the data I had from the real Hywind Scotland turbine. The error is within 0.1% So I am very happy! But it was a long process!
I have very good agreement in the eigenperiods only 4 seconds difference for surge and sway- 92 for my model against 96 in the data. The other periods are like within 0.2 seconds! This just great!
I just wanted to say thank you for your help!
Realizing I had divided the zero and infinity added masses with g helped too. :slight_smile:.

Thank you again!
Now I’ll check my improved model on the test cases!

Best Regards,
BS

Dear Jason,

I have another problem I’d like to ask you to comment on.
As I wrote above, if I use the mooring matrix for the equilibrium condition supplied in my data from ORE Catapult I have very good agreement in eigenperiods. Here is the matrix:


However as I am unable to set MAP to replicate the above matrix in the zero displacement condition.
Here is the mooring description I have:

The diameter of the Spar is 14.4 so the fairlead should be on a circle of 8m diameter and this is how I located it in input file:

I obtained the line stiffnesses simply by multiplying the Youngs modulus from the table above with a circular section area of the diameter also from the table.

CONT.

The resulting restoring mooring matrix I obtained using the python driver for the setup above is:

Could you please comment if this is normal?
I thought I could at least have the same mooring restoring in the equilibrium condition and similar eigenperiods for small displacement from this initial position, but I have great difficulty to adjust anything in the MAP input to even come close to the response I am getting with the restoring set to mimic the matrix from previous post(there CompMooring=0 and the matrix is in the AddCLin section of Hydrodyn).