I am trying to model a 70m jacket in FAST.v8. As an initial step, I have tried running the Test 21 (OC4_JAcket) of FAST.v8. I am using a 64bit machine, but am yet to compile the 64bit version of FAST.v8. So, basically, I am running Test 21 using the 32bit version of FAST.v8.
Though the code runs, I am getting the following warnings:
Message from AD_CalcOutput:
AD_CalcOutput: AeroDyn was designed for an explicit-loose coupling scheme. Using last calculated values from AeroDyn on all subsequent calls until time is advanced. Warning will not be displayed again.
Message from SrvD_CalcOutput:
SrvD_CalcOutput: BladedInterface option was designed for an explicit-loose coupling scheme. Using last calculated values from DLL on all subsequent calls until time is advanced. Warning will not be displayed again.
Could you please explain the significance of these warnings?
The 64-bit Windows version of FAST v8 is included in the archive; you shouldn’t need to recompile unless you want to make changes to the source code.
FAST v8 uses a sophisticated algorithm to time-advance the modular solution forward; this algorithm is explained in the following paper: nrel.gov/docs/fy14osti/60742.pdf. One of the options in the algorithm is to use one or more correction steps. However, the AeroDyn v14 module and the Bladed DLL interface routines in the ServoDyn module where not developed to support correction steps. Thus, you will get those warnings every time you run a model with correction steps that has AeroDyn v14 or calls to Bladed DLLs enabled. Despite these limitations in AeroDyn and ServoDyn, we have found that adding correction steps improves the convergence of some models, such as the OC4-jacket model of Test21.
Thank you for the really quick reply, regarding the warnings displayed during the OC$_Jacket Test 21. I have just now noticed the “FAST_x64.exe” in the bin folder of the FAST.v8 archive. Earlier, I had compiled the 32-bit version using the instructions given in the “Compiling FAST v8.08.00c-bjj.pdf”, to get a “FAST_dev_Debug_Win32.exe” executable. Does your comment mean that I can use the “FAST_x64.exe” directly, without compiling, provided I don’t make any change in the source code?
I was able to run Test-21 for the OC4 jacket in Fast.v8, using the 64-bit version of the program. The only change I made was in the ServoDyn.dat file, where I switched the paths of the DLL_FileNames for the BLADED INTERFACE (line# 61) to “ServoData\DISCON_win64.dll” “ServoData\DISCON_win32.dll”.
However, I observed no improvement in the simulation time, when using the 64-bit version of FAST. Isn’t the 64-bit version expected to speed up the simulations?
I agree that the 64-bit version of the Bladed-style DLL needs to be used with the 64-bit FAST executable.
I would not expect the simulation time to be reduced with a switch from the 32-bit to 64-bit application. The 64-bit application simply allows the use of more memory, which means models can be run with finer discretizations (in space or time) and/or for longer simulation lengths.
In your paper “Jonkman and Musial, 2010, Offshore Code Comparison Collaboration (OC3) for IEA Task 23 Offshore Wind Technology and Deployment, NREL/TP-5000-48191”, you have referred to “Camp T. OC3 internal communication from GH, tower definition_NEW.xls, March 11, 2008” for details on the modelling of the OC3-Tripod. In fact, all publications from NREL on OC3 Tripod refers to this paper. However, I am unable to find it online. Is there any way in which i could access the same? My idea is to build a model of the OC3-Tripod for geotechnical analysis, using loads from FASTv8.
As far as know, Camp’s report was never published. However, the report is posted on the SharePoint site used for the OC3 project (as well as for OC4 and OC5). I’ll send you instructions on how to access this site and the report in an e-mail.
Allow me to finally get to the actual topic. I was able to reproduce the OC4 Jacket in my FE code (USFOS) and validate it with the values for natural frequency and static load-displacements given in the paper “Song et al. (2013), A New Structural-Dynamics Module for Offshore Multimember Substructures within the Wind Turbine Computer-Aided Engineering Tool FAST.”
I have to do the opposite now, i.e., I have modelled a jacket in 70 m water-depth in USFOS. It is required to incorporate the same in FAST v8. I understand that the jacket model up to the TP is to be defined using FE-coordinates in both SubDyn and HydroDyn (the resolutions need not be the same?). But i do not see any definition of the TP in ElastoDyn. My tower is the same as in OC4 (Vorpahl, 2013). Also, how do i check for the fidelity of the model in FAST?
Indeed, the spatial discretization does not need to be the same between SubDyn and HydroDyn. FAST’s mesh-mapping utility handles transfer of motion and loads across meshes in a physically relevant manner, but consistency between the joints and members in HydroDyn and SubDyn is advised.
In ElastoDyn, the “transition piece” is referred to as the “platform”. If the tower and transition piece are the same, the only thing you should need to change in your ElastoDyn model when a different substructure is modeled in SubDyn is the tower mode shapes, which may be effected by the compliance of the substructure.
I’m not sure I understand what you are asking regarding “fidelity”, but the HydroDyn and SubDyn manuals provide guidance on how to specify proper model discretization. As with any finite-element model, it is useful to perform a convergence study to ensure that the discretization is adequate.
By “fidelity,” I was referring to the exactness with which my FE model can be incorporated into FAST. I believe I can check it roughly by comparing the natural frequencies from FAST and USFOS. Does the natural frequency obtained in the “*.SD” file include the TP and the tower? Or is it for the jacket alone (and should i use the power-spectral density method to calculate the natural frequency)?
I believe I should modify the tower mode shapes using BModes. I have a few questions in this regard: the OC3 tripod and OC4 jackets use different towers (diameters, thickness and discretization) - so, i should make new input files for the OC4 jacket. While the changes in the “section properties input file” are pretty straightforward, my doubts are confined to the “BModes Main Input file.”
tower height - is it actually the length of the tower (68m) or the height of the tower top above the MSL (88.15m)
does the tower tip mass properties remain the same, as in the case of a monopile - i believe it would, since the turbine is constant
draft - according to Vorpahl (2013), the tower base is at +20.15m. Will this be the draft for the OC4 jacket, i.e TowerBsHt?
cm_pform and ref_msl - distance of platform c.m. below the MSL (m) - +18.15m above MSL i.e, c.m of T.P?
mass_pform - does it refer to the mass of the platform/TP, i.e. 663t?
does the Platform mass inertia 3X3 matrix have a value?
is the value of the “mooring_K” matrix important for a fixed structure without mooring?
I apologize for posing too many questions, but the old BModes user manual doesn’t cover most of these parameters - reading it failed to resolve my confusion!
Also, I would like to ask if the apparent fixity/coupled springs models can be extended to tripods/jackets to ensure flexibility from soil considerations.
The natural frequencies reported in the SubDyn summary file (.SD.sum) are only for the SubDyn model (not including the TP, tower, nacelle, and rotor). Until linearization functionality is added to FAST v8, computing full-system natural frequencies can be done by system-identification tests (e.g. by identifying the peaks of PSDs computed from time series that make use of broadband excitation).
The latter - the height of the tower-top above MSL.
Yes.
Yes, except that in BModes “draft” is specified positive downwards, so draft = -20.15 m.
Yes, except (as above) that the values should be -18.15 m.
Yes.
Yes. These are the lumped inertias of the TP about the CM. For the OC4-jacket:
6002880 0 0
0 6002880 0
0 0 10229760
Either “hydro_K” or “mooring_K” should be set. See Section 5.4 (Substructure Tower/Turbine Coupling) of the SubDyn User’s Guide and Theory Manual for details.
The apparent fixity model can be employed within SubDyn – see Section 5.2 (Foundations) of the SubDyn User’s Guide and Theory Manual for details.
Thank you so much for the reply. You have cleared all my doubts!! Except the last one. I have read the new and descriptive version of the " SubDyn User’s Guide and Theory Manual." I was not aware of its release.
The “mooring_k” matrix is still not clear to me, even after reading Section 5.4 of the " SubDyn User’s Guide and Theory Manual." I have also trawled the forum for any possible explanation. I couldn’t find anything except "Distributed Spring Model for Monopile. - #11 by Jason.Jonkman
Jason, from the “SubDyn User’s Guide and Theory Manual,” I got the following idea for obtaining tower mode shapes from BModes.
I should use the SubDyn derived “KBBt and MBBt” matrices in place of “hydro_K and hydro_M” matrices in the BModes input file.
Set the appropriate boundary conditions and tower properties to run BModes.
However, nothing is said about the “mooring_k” matrix or its relevance. I have the “mooring_k” value for the CS_Monopile (given below), but you have mentioned in the above referred post that the “mooring_k” value may be set to zero for a fixed monopile. Can i do the same for the jacket? Please help me in this regard.
In BModes, matrices “mooring_K” and “hydro_K” are summed together. So, you may specify KBBt via mooring_K or hydro_K, as long as you set the other one to zero.
I have noticed in literature that when performing uncoupled analysis of an aero-elastic code and a structural program, most-often, authors tend to input time-series of loads at the interface/TP from the former, to the latter, at the corresponding point. The model of the tower is ignored in the structural program. Is there any particular logic or reasoning behind this?
I intend to study the response of the tower also, so the time-series of loads from FAST at the yaw-bearing are transferred to the tower-top of my structural code. Is there any problem with such a coupling? I did notice few changes in the response spectra when i replaced the time series of YawBrFzp and YawBrMzp with a point mass representing the turbine weight.
Regardless, while I have seen some uncoupled analysis studies where the interface is at the tower top, the more common point is the transition piece because this is commonly where the design responsibility is split between the turbine designer and substructure designer.
Coupling software always presents its challenges. Some of the challenges for software coupling in the support structure are discussed in the following forum topic: FAST: Tower Model.
Thank you for the reply. Please allow me to elaborate on my above comment."
I did an ensemble of 25 simulations for the OC4 jacket in FAST - hs = 3m, tp = 8s, V = 12mps. I then plotted the spectra of base shear (ReactFXss) from the above ensemble mean.
Also, I extracted the 6-components of times series of loads from the tower-top of the FAST simulations and applied them as external loads in a USFOS model of the OC4 jacket, for the same sea-state. Again, I obtained the spectra of base-shear from the USFOS simulations and compared them with those from FAST. This exercise was done as an attempt to check the similarity of coupled aerodynamic - hydrodynamic simulations (in FAST) and uncoupled simulations in USFOS.
As is observed from the figure attached, both spectra confirms to each other for the most part, except at a couple of peaks on either side of the second natural frequency of the OC4 jacket. These peaks were observed only in USFOS simulations. To identify the cause of the peaks, I replaced the time series of YawBrFzp and YawBrMzp with a point mass representing the turbine weight in my USFOS model. Also, i ignored the time series of wind loads in the less predominant side-side direction (YawBrFyp and YawBrMxp). While I observed that, while the peaks vanished, i am apprehensive about the correctness of the latter method.
I’m sorry, but I don’t have much experience with the uncoupled method to know what would cause these extraneous excitation peaks. Perhaps someone with more experience in uncoupled methods could comment.
