Dear Jason,
Thank you very much.
Best regards,
Kevin
Dear Jason,
I have read subroutine UserTwrLd that you wrote and I have two questions:
(1) how to obtain the spring stiffness? If API method is used, the spring stiffness can be presented as dp/dy=d(Aputanh(kz/(Apu)y))/dy=kz. If this is true, then the spring stiffness at the mudline should be zero (z=0). However, the spring stiffness at the mudline spring(37)=1156000.0 in subroutine UserTwrLd is not equal to zero, I’m curious about how to obtain this value;
(2) I want to know whether the unit of foundation loads TwrFt is N/m or else?
Thanks in advance.
Best regards,
Kevin
Dear Kevin,
Regarding (2), the units of the TwrFt output argument from the UserTwrLd() SUBROUTINE in FAST v7 is N/m for forces (elements 1-3 of TwrFt) and N-m/m for moments (elements 4-6 of TwrFt), i.e., the applied loads per unit length along the tower / pile.
Regarding (1), I was not the one who derived the distributed springs used in the OC3 Phase II model, but my understanding is that first distributed springs (per unit length) where generated using LPILE and then discrete springs (lumped) were derived from the LPILE output. My guess is the nonzero value of the spring stiffness at the mudline resulted from this conversion from distributed to discrete springs. The spring stiffness values specified within the UserTwrLd_DS.f90 for the representation of the OC3 Phase II model in FAST v7 are simply the discrete spring constants specified every 1 meter along the pile, which is numerically equivalent to distributed springs specified in 1-m increments.
Best regards,
Dear Jason,
Thanks for your help, and I have a few more questions:
(1) Can TwrFt be considered as lateral soil resistance p(N/m)? If it is correct, the spring force applied to tower can be obtained as p*dl (dl is the length of element, p acts at the midpoints of the elements ).
(2) I use the DS model to simulate the structure soil interaction, and follow the instructions to compile fast, but I’m curious why subroutines UserHSSBr and UserYawCont in UserSubs_forBladedDLL.f90, and subroutine UserVSCont in UserVSCont_KP_forBladedDLL.f90 should be comment out?
Best regards,
Kevin
Dear Kevin,
Here are my answers:
(1) TwrFt can be considered the load applied to the tower (pile) from external forcing, which for the foundation are the loads applied to the pile from the soil. TwrFt is the load per unit length along the tower (pile), so, for forces, have the units of N/m. So, If the soil is represented by a spring via a p-y formulation, TwrFt = ky, the units of the spring (k) should be N/(m^2), where one of the length scales is for length along the pile and the other length scale is for the lateral displacement (y) of pile. Typically, p-y curves are written with the force (p) lumped at a point (with the units of N), in which case the lumped force (p) equals TwrFtL = kyL, where L is the length of the pile element.
(2) I’m not sure I fully understand your question, but compiling-related comments about “commenting out” certain routines are there simply to avoid having the same SUBROUTINE being duplicated within the source code.
Best regards,
1 Like
Dear Jason,
Really appreciate!
(1) As shown in Fig.1, if I use the subroutine UserTwrLd_DS.f90 to model the soil-structure interaction, then should I use the files BladedDLLInterface.f90, UserSubs_forBladedDLL.f90 and UserVSCont_KP_forBladedDLL.f90 to replace the file PitchCntrl_ACH.f90, UserSubs.f90 and UserVSCont_KP.f90? And comment out the subroutines UserHSSBr, UserYawCont and UserVSCont_KP? Is that right?
(2) If the subroutines UserHSSBr, UserYawCont and UserVSCont_KP were commented out, maybe I can’t use option 1 in the YCMode and PCMode settings, option 2 in VSControl and HSSBrMode settings, and option 3 in GenModel settings in .fst file as shown in Fig. 2. Is that right?
(3) when I use subroutine UserTwrLd_DS.f90 to model the soil-structure interaction and file .bmi to compute modes, I want to know where to get the sec_props_file, and how to set the values for distance of element boundary nodes from flexible-tower root?
Thanks in advance.
Best regards,
Kevin
Fig.1
Fig.2
Dear Kevin,
I’m not sure I really understand your first two questions. The figure you post describes how to compile FAST v7 with the Bladed-style DISCON control interface. If you are using a DISCON controller (such as used by the baseline NREL 5-MW controller), these instructions apply whether you use source file UserTwrLD_DS.f90 or not.
Regarding your third question, the sec_props_file in BModes contains similar (but not identical) data used in the TwrFile in FAST v7. So, if you have the data necessary to make the TwrFile, I would assume you’d have the data necessary to make the sec_props_file. Regarding el_loc in BModes, these are the normalized locations of the finite-element nodes, starting from 0 at the root to 1 at the tip. Place the nodes where you want them, e.g., equally spaced.
Best regards,
Hello Jason,
Where can I find the soil spring stiffness values used to model the monopile foundation system for the IEA-15MW-Monopile reference model?
Regards,
Shubham
Dear Shubham,
I’m not an expert on the IEA Wind 15-MW reference wind turbine, but I do see soil spring stiffness defined in its specifications report: nrel.gov/docs/fy20osti/75698.pdf.
Best regards,
1 Like
Hello Jason,
Thanks for your reply. I have referred to this document, and I am using the same equations to model the monopile stiffness in my model. My concern is that the turbine response generated using my model exactly matches the response from the Openfast model except for Tower Fore-aft and side-to-side deformations. I think this could be because of the monopile stiffness.
Is there a way to check the exact stiffness values used in the openfast model to help me resolve this issue?
Thanking you,
Shubham
To chime in on the use of spring stiffness values for the soil modeling for the 15MW: we used those in WISDEM only when doing the monopile design optimization using generic values. For the OpenFAST input files, however, we assumed a perfectly clamped boundary at the monopile mudline. We were not confident enough in the generic values, or the relatively new SoilDyn module, to include it in our loads modeling. Nevertheless, we felt it appropriate to include the values in the report for completeness.
It is also worth noting that in practice, we found that the WISDEM model typically yields identical results whether or not the soil stiffness is included, likely suggesting insufficient fidelity in the underlying implementation.
Apologies if this does not help resolve any of the open issues in this thread.
Thanks for the clarification Garrett.