Dear @Emanuel.Rergis,
Regarding your specific questions:
- I would think the monopile would be quite stiff relative to the tower, so, I agree that the displacement and rotation of the tower base / top of the monopile should near zero.
- The BModes output only includes the tower, which in your case extends from 10 (= -
ref_msl + hub_rad in BModes) to 87.6 m (= radius in BModes) above MSL.
- From my quick review, your BModes input files, they look correct to me except for the values of
hydro_M and hydro_K, which donât match MBBt and KBBt that I obtain when I run SubDyn with the OC3-monopile with rigid foundation. Or do you have a different monopile you are using?
Best regards,
Dear Dr. @Jason.Jonkman:
Thanks for your reply again. Iâm using the same OC3 Monopile. What might be different is that I included soil interaction. I used the cross-coupling model through a 6x6 stiffness matrix. The values correspond to those you shared with me in a previous discussion. Does it make sense to you now? Or do you think I should review anything in particular?
Thanks a lot for your help.
Kind regards
Emanuel Rergis
Dear @Emanuel.Rergis,
Thanks for clarifying. To confirm that your process is correct, I suggest rerunning BModes with a rigid foundation, which will hopefully help you confirm that the solution with the flexible foundation makes sense.
Best regards,
Dear Dr. @Jason.Jonkman:
Thank you very much for the advice â I will immediately begin running BModes with rigid foundation. This raises a few questions which may sound a bit naĂŻve, however:
a) What types of mode shapes should I expect with a rigid foundation? I vaguely assume that the first mode in both the side-to-side and fore-aft directions should be identical, as well as the second and third in both directions. Is this assumption correct?
b) How can I verify that these mode shapes are consistent?
c) Going back to the mode shapes related to soil-structure interaction, specifically the third mode in the side-to-side direction, Iâve observed that the largest displacement appears to occur very close to the platform, at 10 m above MSL. Does this mean that I can place a Tuned Mass Damper via StrCtrl at 10 m (in the z-axis location)? I may be mistaken, but I believe that physically, this might not be feasible. Could you kindly suggest any alternative approach to address this issue?
Many thanks and kind regards,
Emanuel Rergis
Dear @Emanuel.Rergis,
Iâm not sure I know how to answer (c), but here are my responses for your other two questions:
a) I would expect the fore-aft and side-side modes to be similar, but not identical, due to the differing tower-top inertia in each direction.
b. If fitting the BModes-generated mode shapes with polynomials and using them in ElastoDyn, results in the OpenFAST model returning the same natural frequencies as the BModes model (with rigid RNA), than I would be confident the modes are correct.
Best regards,
Thank you once again for your recommendations, Dr @Jason.Jonkman.
I have been reviewing BModes and its parameters and input files even more carefully, and Iâve realised that changing the values of draft and ref_msl significantly affects the natural frequencies associated with the towerâs vibration modes. Thatâs why I must be especially cautious with those values.
In previous discussions, you recommended setting both values to â10 m. However, after revisiting their definitions â and based on the figure Iâm sharing with you â Iâm afraid that, at least for my model, the values of draft and ref_msl should not be â10 m.
This is what I understood:
draft â Distance from the still water level (MSL) down to the seabed.ref_msl â Height of the reference point (origin of tower mode shapes) above MSL. This is usually the tower base in OpenFAST.
If my understanding is correct, then shouldnât it be:
draft = 36 m and ref_msl = 10 m?
You will find attached a screenshot of the model Iâm referring to.
Thank you once again â and if my assumptions are correct, then the mode shapes I previously shared with you may not be entirely consistent.
Best regards,
Emanuel Rergis
Dear @Emanuel.Rergis,
When using BModes to compute tower mode shapes for an OpenFAST model, where the tower is modeled in ElastoDyn and the substructure is modeled in SubDyn, the BModes model should only consider the distributed tower properties, with the substructure represented by the platform mass and stiffness matrices. In this case, draft should locate the tower base and ref_msl should locate the reference point for the mass and stiffness matrices in BModes. So, setting draft = ref_msl = -10 m for the NREL 5-MW monopile will locate these points at the tower-base, which is correct.
Best regards,
Thank you for the clarification, Dr @Jason.Jonkman .
I re-ran BModes using the suggested values and found that the natural frequencies of the modes in the fore-aft direction match very well. However, this is not the case for the side-to-side direction. What would you recommend I check?
According to the literature I have reviewed, I find it quite surprising that there is such a large discrepancy in the SS direction. Iâm well aware that FA and SS should not be exactly the same, but they should be reasonably close â for instance, in the first mode I found a difference of 33%, and this is while assuming rigid soil.
I would very much appreciate your thoughts on the matter.
Many thanks again.
Emanuel Rergis
Dear @Emanuel.Rergis,
When you say âmatch very wellâ, are you referring to a comparison between the BModes outputs and OpenFAST outputs, when the tower mode shapes in ElastoDyn are derived from the BModes output? Can you clarify what you are comparing and the results you are seeing?
Best regards,
Dear Dr @Jason.Jonkman ,
You are absolutely right â I failed to clarify the specific reference point for my measurements. The natural frequencies of the first three modes in both the fore-aft and side-to-side directions were taken from a paper written and published by a certain Donagh McNamara from University College Dublin, Ireland (please see the attached screenshot).
It is worth noting that I am using the same tower and monopile geometry as in that study. I also apply the same wind profiles in TurbSim and similar oceanographic conditions in HydroDyn, as well as similar setups in SubDyn and ElastoDyn.
That being said, after running OpenFAST, I obtained PSD plots of both the tower-top moments and displacements in the fore-aft and side-to-side directions. In both cases, and under rigid soil conditions (as used by McNamara) and the cross-coupling model with the stiffness matrix from the official documentation you kindly shared with me, I observed that the first fore-aft mode matches very well with McNamaraâs reported value. This mode also aligns with the first fore-aft mode computed in BModes.
Moreover, the second and third fore-aft modes also agree with those reported in the paper and obtained in BModes. The issue lies, however, in the side-to-side direction, where I observe a deviation of about 33% across the three modes when comparing the BModes output with McNamaraâs data (rigid soil).
To summarise:
- The PSD plots yield a first fore-aft mode that closely matches the first BModes mode, under both rigid soil and soil-structure interaction conditions.
- The three side-to-side modes from BModes differ significantly from McNamaraâs results, whereas the OpenFAST PSD plots suggest a closer agreement.
This leads me to suspect there may be a serious issue with the tower geometry. What do you think I might be overlooking? Is there perhaps something critical I have failed to take into account?
I would greatly appreciate your thoughts on this.
Kind regards,
Emanuel Rergis
Dear @Emanuel.Rergis,
Iâm not familiar with the paper you are referring to from McNamara. Regardless, it could be that theyâve used different tower-top boundary conditions from you. For example, if the tower-top generator degree-of-freedom is enabled, the full inertia of the RNA will not follow the rotation of the tower-top associated with tower side-side deflection, and with a differing effective RNA inertia, the tower side-side bending frequencies would be quite different (higher).
To gain confidence in your own results, I would verify that the natural frequencies of the OpenFAST model match the BModes outputs when the tower mode shapes in ElastoDyn are derived from the BModes output. This should be the case when the RNA is modeled rigidly in OpenFAST (to match the conditions of BModes).
Best regards,
Dear Dr. @Jason.Jonkman
Is this statement related to OpenFAST or to BModes?
âFor example, if the tower-top generator degree-of-freedom is enabled, the full inertia of the RNA will not follow the rotation of the tower-top associated with tower side-side deflection, and with a differing effective RNA inertia, the tower side-side bending frequencies would be quite different (higher)â.
Iâm asking because Iâve noticed that the higher-frequency modes come from BModes results and not from OpenFAST PSD plots. And one more thing, when you say rigid RNA, do you mean turning off the Generator degree of freedom in ElastoDyn? Or is there any other setting that I should consider?
Thanks again for everything
Warm regards!
Emanuel Rergis
Dear @Emanuel.Rergis,
When I was referring to the generator degree of freedom (DOF), I was referring to OpenFAST (GenDOF in ElastoDyn).
When BModes is used to compute tower modes, the RNA must be modeled rigidly because BModes does not have any DOFs in the RNA.
To model the equivalent rigid RNA in OpenFAST, you should disable all DOFs in ElastoDyn above the tower (YawDOF = GenDOF = DrTrDOF = TeetDOF = EdgeDOF = FlapDOF1 = FlapDOF2 = FALSE).
Best regards,
Dear Dr @Jason.Jonkman,
Thank you for your advice. I have run OpenFAST once again, first assuming rigid soil and then a flexible one using the stiffness matrix you previously suggested, along with the cross-coupling model.
I obtained several PSD plots with the tower-top displacements in both the fore-aft and side-to-side directions. In an initial attempt, I enabled all degrees of freedom, and then I repeated the experiments while deactivating the degrees of freedom you had recommended. The outcome was that I did not observe any significant variations.
I intend to rerun these experiments, as I found it quite unusual that the PSD plots showed no difference between the cases with all degrees of freedom enabled and those assuming a fixed or rigid RNA.
In light of this, I would like to ask whether I should consider disabling SubDyn in OpenFASTâparticularly the section that governs the generatorâand whether it would be appropriate to run all these simulations with InflowWind and HydroDyn activated.
What is your opinion on all this?
I remain very attentive to your comments, and thank you once again.
Kind regards,
Emanuel Rergis
Dear @Emanuel.Rergis,
Presumably you mean ServoDyn, not SubDyn. When YawDOF and GenDOF disabled, I would not expect ServoDyn to have any effect, so, yes, it could be disabled.
HydroDyn should be enabled for added mass effects in OpenFAST if youâve included those in BModes.
BModes has no way of specifying aerodynamic stiffness (or damping), so you can disable InflowWind and AeroDyn in OpenFAST when comparing eigenfrequencies against BModes.
Best regards,
Dear Dr. @Jason.Jonkman:
Thank you for your previous advice. I would like to let you know that I now need to run HydroDyn in standalone mode. Unfortunately, I cannot find the appropriate driver for the version of OpenFAST that I have, which is 3.1.0. Do you have a way to share this driver with me? Where could I obtain it in case you are not able to help me directly?
Thank you for your help, as always.
Best regards,
Emanuel Rergis
Dear @Emanuel.Rergis,
You can download precompiled Windows executables of OpenFAST and the various standalone drivers for each module for each recent release of OpenFAST here: Releases ¡ OpenFAST/openfast ¡ GitHub. But earlier in OpenFASTâs development (including OpenFAST v3.1.0), we only provided precompiled Windows executables for the main OpenFAST tool, not the standalone module-level drivers.
That said, we provide the documentation and scripts so that you can compile yourself: 2. Installing OpenFAST â OpenFAST v4.1.2 documentation. On Windows, I personally find compiling with Visual Studio with the Intel Fortran Compiler, which are both free to download, easiest: 2.4.3.1. Building OpenFAST on Windows with Visual Studio â OpenFAST v4.1.2 documentation.
Best regards,
Dear Dr. @Jason.Jonkman
Thank you very much for your comments and suggestions. They have been very helpful to me.
I would like to let you know that I am currently trying to implement the restoring force of a Pendulum Tuned Mass Damper. I am doing this by using a forceâdisplacement table. The formula that I believe adequately represents the pendulumâs restoring force is:
Fx=-mgx/sqrt(L^2-x^2)
where L is the pendulum length and m is the mass of the pendulum bob. I have attached the StrcCtrl file for your reference. I have also attached some screenshots of the errors I obtained when running the simulation.
I would like to ask you: how can I make my model stable? Could it be that the formula Iâm using in the tables is incorrect? Or perhaps I have misconfigured something in the StcCtrl input file?
Thank you very much for your help.
Kind regards,
Emanuel Rergis
StrcCtrl code:
Dear @Emanuel.Rergis,
Iâm not sure why, but looking at the StC source code, I see that the sign is flipped on the forces specified in the StC spring-force table. So, you should specify a negative force for negative displacement, and a positive force for positive displacement, as shown in the example in the OpenFAST r-test: r-test/glue-codes/openfast/5MW_Baseline/NRELOffshrBsline5MW_ServoDyn_StC.dat at main ¡ OpenFAST/r-test ¡ GitHub. Hopefully with this sign flip your model will run as expected.
FYI: I also noticed in the source code that when Use_F_TBL = TRUE, the linear TMD stiffness and stop spring stiffness and damping are not used.
Best regards,
Thank you for your replies, Dr. @Jason.Jonkman
One more thing â could you please clarify whether what you mentioned about the use of Use_F_TBL = TRUE always applies whenever this flag is activated, or if perhaps I mistakenly disabled the use of springs and damping?
Thank you again.
Kind regards,
Emanuel Rergis
