jjonkman
commented
2 years ago Dear @zz17635,
Just a few comments:
- Between your two approaches, you've switched which module outputs loads and inputs motions and which module outputs motions and inputs loads at the transition piece or coupling point between modules. ElastoDyn is set up to output motions and input loads, and my understanding is that ABAQUS is set up the same way. This means that one module would have be modified to output loads and input motions.
- The first approach has been discussed recently in the following issue, but again with the modification needed to rearrange the ElastoDyn equations of motion so that motions are input and loads are output: https://github.com/OpenFAST/openfast/discussions/801.
- As far as I can tell, the second approach is similar to the first except that distinct executables are called in sequence and data is tranferred via file I/O in the second approach. I would generally recommend against that approach, which I would expect to be computationally expensive when coupled as such on a time-step-by-time-step basis.
- The tower geometry can be zeroed and the tower DOFs can be disabled such that the tower is not modeled in ElastoDyn, effectively meaning that the coupling point between modules is at the tower top. We've done this before to model the entire support structure (up to the yaw bearing) in SubDyn. This approach is documented a bit in the online SubDyn documentation: https://openfast.readthedocs.io/en/main/source/user/subdyn/modeling.html#substructure-tower-turbine-coupling.
- We have recently introduced a new soil-structure interaction module in OpenFAST (called SoilDyn) that provides more physics than provided by a simple 6x6 stiffness matrix. This is documented a bit in the following NREL report: https://www.nrel.gov/docs/fy21osti/79938.pdf. However, this functionality currently exists in a branch of OpenFAST that has not yet been submitted as a pull request and is not yet included in the dev or main branches. Hopefully this pull request will be submitted and merged soon. Not exactly what you are asking about, but a push in the direction of more advanced SSI modeling.
I hope that helps.
Best regards,
zz17635
Figure 3: Input/Output of SubDyn (from 
Figure 4: Reversed deta-flow.
Figure 5. Soft-in-the-loop (SiL) diagram from Azcona et al. (2019) (attached at the end).
Figure 6. SiL using cables rather than fans, from Hall and Goupee (2018). (attached at the end)
Figure 7. Hybrid testing scheme, from Hall and Goupee (2018). (attached at the end)
Dear developers,
Under operational-level load combinations, the existing ability of OpenFAST to consider a linear-elastic tower and transition piece, together with SSI effects represented by a 6-DOF elastic stiffness matrix is admittedly sufficient. However, supposed that a detailed modelling of the tower, transition piece as well as the adjacent soil is desirable, such as in a scenario of studying how soil degradation/densification behaviours may affect the SSI of an OWT, for example, is it possible to replace the structural part of OpenFAST with an external programme and proceed the simulation? An illustration of the idea is shown in Figure 1. Essentially it is to put together a bespoke multi-platform analysis, in which the soil-foundation-structure system would be simulated in Abaqus or other structural/geotechnical FE programmes, and the turbine in (part of) OpenFAST. For every time step, the information (motions and forces) at the interfacing degree-of-freedoms (basically 6 DOFs at the top of the tower) should be exchanged to make the analysis two-way coupled.
Figure 1: The idea of a multi-platform analysis, combining OpenFAST and Abaqus.
Based on my limited understanding, I see two possible ways to implement, and I want to know if any one of them is feasible from the perspective of OpenFAST’s software structure:
The idea of the first approach came from the structure of OpenFAST itself. So it looks that OpenFAST itself is already a platform coordinating multiple sub-programmes, as you guys called it “glue-code” (Figure 2a). For SubDyn, in particular, which represents the transition piece and the SSI effect, it interacts with the glue-code in terms of exchanging inputs and outputs of motions and forces. Abaqus, on the other hand, can do that as well. So the idea would be to first de-couple OpenFAST, then replace SubDyn (or more) with Abaqus there, and finally, perhaps to modify the FAST-driver a bit to make the data exchange formatted for Abaqus (Figure 2b). (Another thing, I’m not sure, but it seems ElastoDyn governs both the structural analyses of the blades as well as the tower, so you cannot easily split the two? i.e., in such case, the “substructuring interface” shown in Figure 1 perhaps needs to be placed in between the tower-base and the top of the transition piece, rather than between the nacelle and the tower-top?)
Figure 2a: SubDyn, HydroDyn, and FAST 8 coupled interaction (figure from SubDyn documentation).
Figure 2b: The idea of replacing SubDyn with Abaqus within the OpenFAST framework.
The second possible approach is to “manually” two-way couple these two analysis processes shown in Figure 1. So basically:
Step 1-1: Start a “partial-OpenFAST” analysis, enforce interfacing DOFs’ motions from Abaqus at t = 0 s (initial motions) as boundary conditions, and analyse only a single time step (say, 0.001 s), starting with the status of the partial-OpenFAST model at t = 0 s (initial status of the turbine). ( by saying “partial-OpenFAST”, my understanding is possibly to use the independent version of AeroDyn + ServoDyn +ElastoDyn + HydroDyn). Step 1-2: Kill the partial-OpenFAST simulation at t = 0.001 s, read output forces from partial-OpenFAST at the 6 interfacing DOFs at moment t = 0.001 s, and record the status of the partial-OpenFAST model at t = 0.001 s. Step 1-3: Start an Abaqus simulation, enforce interfacing DOFs’ forces from partial-OpenFAST at t = 0.001 s as boundary conditions, and analyse only a single time step, starting with the status of the Abaqus model at t = 0 s. Step 1-4: Kill the Abaqus simulation at t = 0.001 s, read output motions from Abaqus at the 6 interfacing DOFs at moment t = 0.001 s, and record the status of the Abaqus model at t = 0.001 s. Step 2-1: Start the 2nd partial-OpenFAST analysis, enforce interfacing DOFs’ motions from Abaqus at t = 0.001 s as boundary conditions, and analyse only a single time step, starting with the status of the partial-OpenFAST model at t = 0.001 s. Step 2-2: Kill the 2nd partial-OpenFAST simulation at t = 0.002 s, read output forces from partial-OpenFAST at the 6 interfacing DOFs at moment t = 0.002 s, and record the status of the partial-OpenFAST model at t = 0.002 s. Step 2-3: Start the 2nd Abaqus simulation, enforce interfacing DOFs’ forces from partial-OpenFAST at t = 0.002 s as boundary conditions, and analyse only a single time step, starting with the status of the Abaqus model at t = 0.001 s. Step 2-4: Kill the 2nd Abaqus simulation at t = 0.002 s, read output motions from Abaqus at the 6 interfacing DOFs at moment t = 0.002 s, and record the status of the Abaqus model at t = 0.002 s. Subsequent steps: Start the 3rd partial-OpenFAST analysis … Loop over to the end.
The questions for this second approach are: 1). Can I run AeroDyn + ServoDyn +ElastoDyn as a whole and see them as a “partial-OpenFAST model” representing the substructured turbine? 2). Is it possible to define these new “partial-OpenFAST models” with user-defined inputs of: A) prescribed motions at the 6 interfacing DOFs, and, B) prescribed status of the turbine and wind inputs at the particular moment as initial conditions of these new analyses? 3). Is it possible to record the status of the turbine and the wind profile at the end of each analysis precisely?
Do any of these ideas seem feasible? Any comments or advice on the implementation of these ideas? Your helps will be much appreciated！
Thanks for your time and efforts! Best regards,