The ExtPtfm module when it was first introduced into OpenFAST was only valid for superelements with n=6, i.e., a Guyan reduction. However, an updated ExtPtfm module has recently been developed that supports superelements with n>6, i.e., Guyan + Craig-Bampton reduction. This is currently awaiting review and merging into OpenFAST dev–see the following pull request: github.com/OpenFAST/openfast/pull/344.
The linearization functionality of OpenFAST does not yet support linearization with the ExtPtfm module enabled. That said, we are currently working an update to OpenFAST that does support linearization with the SubDyn module enabled.
Normally, the linearization process involves finding a periodic operating point at given mean wind speed (or rotor speed), linearizing an OpenFAST model at a number of azimuth steps about the operating point, applying MBC3 to transform the matrices with rotating states/inputs/outputs into the fixed frame, azimuth averaging the MBC3-transformed matrices, and performing an eigenanalysis on the averaged state matrix; this will result in full system eigenvalues and eigenvectors for a given wind speed. This process would be repeated at each desired wind speed (or rotor speed).
Because it is not yet possible to linearize with the ExtPtfm module enabled, direct eigenanalysis is not possible for models with ExtPtfm. Instead, the eigenfrequencies of such systems could be found through free-decay simulations or simulations with broadband (e.g., white noise) excitation.
You can access the updated ExtPtfm module through the links in the pull request: github.com/OpenFAST/openfast/pull/344. But because this has not yet been reviewed, changes may occur before merging into OpenFAST-dev. I’m not sure when the review and merging will occur.
I am trying to model a superelement built on a finite element package for the OC4 jacket. The OC4 jacket, as modeled in subdyn in reg test folders, does not have a transition piece. Moreover, it seems like the tower is not included in the subdyn module. Can you tell me a better way to proceed with it? I need to define an interface point to generate a superelement. Can you tell me which node/coordinates correspond to the interface point between the tower and the jacket?
The OpenFAST model of the OC4-jacket has 8 interface joints spread around the transition piece/concrete “block” between the tower and jacket. But this model could have been set up with single interface joint, e.g., at the tower base in the middle of the concrete block.
The fem tool i use to model the jacket, does not support concrete elements to be modelled. In such a scenario, how shall I proceed to model the transition piece interface node for the superelement ? Any ideas ?
I have a basic template ready as per the coordinates and the properties of the beam elements for the oc4 jacket using the subdyn file you mentioned.
I see that nodes 24, 28, 32, 36 corresponds to the top most nodes at each jacket leg. Are these nodes the end points for the transition piece( which isn’t directly modelled) ?
In that case how do I get the coordinates of the tower base ? I believe there also needs be some connecting members to the tower base node. Is my understanding correct ? Please let me know if I am not making any sense. My ultimate aim to get a superelement of the jacket with the tower base node as the interface point.
Yes, your understanding of joints 24, 28, 32, and 36 is correct.
The tower base is located at (X,Y,Z) = (0,0,20.15) m, but this is not a joint in the SubDyn model; rather, the interface joints in the SubDyn model are all rigidly connected to this point within OpenFAST.
To clarify, the interface nodes (24,28,32,36 and 53,54,55,56) shall be set without support. This would allow these 8 nodes to deform as per the loads. Further, the tower base node shall be modeled as fixed to these neighboring nodes. My doubt arises from the Subdyn input file for the OC4 jacket. Can you clarify what locked dof means or remove rigid body dof as specified in subdyn in the context of an equivalent model in a fem tool for super element generation?
If I assume fixed supports at the transition piece interface nodes, the fem tool shall assume fixed end boundary conditions like at the sea bed. It would help if you could clarify and enrich my understanding.
INTERFACE JOINTS: 1/0 for Locked (to the TP)/Free DOF @each Interface Joint (only Locked-to-TP implemented thus far (=rigid TP)) ---------
8 NInterf - Number of interface joints locked to the Transition Piece (TP): be sure to remove all rigid motion dofs*
In SubDyn, “locking” an interface joint means that that joint is rigidly attached to the platform reference point in ElastoDyn. This means that all locked interface joints in SubDyn will have the same rigid-body motion as the platform reference point in ElastoDyn. The effect is that there is a rigid link element between each locked interface joint in SubDyn and the platform reference point in ElastoDyn.