Modelling in SubDyn a tendon pinned at the top and connected to a universal joint at the bottom (piled anchor)

Wind & Water Computer-Aided Engineering Software Tools
1

Hi,
I would like to model a tendon that is pinned at the top to the OWT support structure, and connected to a pile anchor through a universal joint at the bottom.

What is did is the following (in sudyn)

  • STRUCTURE JOINTS: Joint 20 is type 3 (Pin), with JointDirX 0, JointDirY 1.0 and JointDirZ 0.0, JointStiff 0.0
  • STRUCTURE JOINTS: Joint 25 is type 2 (Universal), with JointDirX 1.0, JointDirY 1.0 and JointDirZ 0.0, JointStiff 0.0
  • BASE REACTION JOINTS:
    RJointID 25
    RctTDXss,-Yss,-Zss and RctRDZss all 1, RctRDXss' and -Yss` to 0
  • MEMBERS:
    MemberID 24, MJointID1 20, MJointID2 25, MPropSetID1 1, MPropSetID2 1, MType 2
  • CABLE PROPERTIES:
    PropSetID 1 EA 1.489719e+10 MatDens 533.3242, T0 6280e+3 CtrlChannel 0

When I try to run the case, at the beginning I got this error:

Node 25 is an universal joint, number of members involved: 1

  • 8*
  • 8*
  • 8*

FAST_InitializeAll:SD_Init:DirectElimination:BuildTMatrix:JointElimination: universal joints should only connect two elements.

Based on Link:
This version of SubDyn can, in fact, handle partially restrained joints by setting one or more DOF flags to 0 and providing the appropriate stiffness and mass matrix elements for that DOF via the SSIfile

I therefore added a “SSI.txt” file in the BASE REACTION JOINT for RJointID 25, that looks like the following, but I still have the same error.

Where is my mistake?

!---------------- Pile Head K and M elements -------------------!
!Equivalent Stiffness Constants: Kxx, Kyy, Kzz, Kxtx, Kxty..Kztx,Kzty,Kztz in any order; max 21 elements
-1.98E+09 Kxty
-6.83E-02 Kyty
0.00E+00 Kzty
-2.73E-01 Ktxty
1.35E+10 Ktyty
0.00E+00 Kxtz
0.00E+00 Kytz
0.00E+00 Kztz
0.00E+00 Ktxtz
0.00E+00 Ktytz
7.00E+08 Ktztz
5.04E+08 Kxx
3.11E-02 Kxy
5.06E+08 Kyy
0.00E+00 Kxz
0.00E+00 Kyz
2.54E+09 Kzz
6.83E-02 Kxtx
1.99E+09 Kytx
0.00E+00 Kztx
1.35E+10 Ktxtx

2

Dear @Maurizio.Collu,

Just a few comments:

  • JointType = 2-4 (universal, pin, ball) in SubDyn can only be used when interconnecting two beams together.
  • You should designate reaction joints in SubDyn as JointType = 1 (cantilevered) and use the react joint flags to define which DOFs are constrained.
  • You can not attach a cable element in SubDyn to a JointType other than 1.
  • We typically model tendons in floating offshore wind turbines as mooring lines (within OpenFAST mooring modules such as MoorDyn) rather than as beams with joints in SubDyn.

Best regards,

3

Thanks, @Jason.Jonkman.
Yes, I usually use MoorDyn as well when modelling mooring lines, but this platform is a bit “peculiar”.

A picture of a very similar structure is here Link.

There is a central truss structure, of constant section, connected at the seabed with a suction pile anchor, through a universal joint, and at the top is connected with a transition piece through a pin joint.

The transition piece has three protruding horizontal “legs”, to which the tendons are attached through pin joints, and at the bottom are connected to other suction pile anchors, also with a universal joint.

I thought of modelling everything in subDyn - do you think it would be better using moordyn for the tendons? But I did not understand how to have MoorDyn communicating with SubDyn.

Many thanks

4

Dear @Maurizio.Collu,

I would say that there are a few challenges with modelling the tendons and central truss section of this FOWT in SubDyn:

  • For floating substructures, SubDyn assumes elastic motion is much smaller than rigid body motion
  • The elastic motion is assumed to be fully linear such that the Craig-Bampton reduction applies
  • There can be no internal rigid-body modes of the elastic DOFs based only stiffness known by SubDyn (if hydrostatic restoring is providing the stiffness, this is not known by SubDyn when computing the Craig-Bampton modes).

If you can get by with these limitations, then you can use SubDyn for modeling your FOWT; otherwise, I’d recommend using MoorDyn to model the tendons.

The MoorDyn-SubDyn connection is handled intrinsically within OpenFAST (likewise for HydroDyn-SubDyn coupling). Basically, the fairleads in MoorDyn are mapped to the closest nodes in SubDyn, and if these are not the same point in space, rigid-body kinematics are used between them.

Best regards,

5

Thanks @Jason.Jonkman,
I think I understood.

I am going to model the tendons with MoorDyn, then, thanks for letting me know this “intrinsic” feature of OpenFAST, and see how they compare with the experimental tests we did here.

For the central truss section, do you recommend to model it in SubDyn, or is there an alternative?

I must say that, based on the tank experiments, the structure is quite stiff - global motion is less than a TLP, would say close to a monopile.

Kind Regards

6

Dear @Maurizio.Collu,

I’m not sure what to recommend for the central truss section. I do know that if you add the reaction joint, that SubDyn will assume the substructure is fixed bottom rather than floating, which does have several implications on the formulation of the SubDyn solution, as summarized here: https://openfast.readthedocs.io/en/main/source/user/subdyn/theory.html#summary-of-the-formulation-implemented.

Best regards,

7

Thanks a lot, @Jason.Jonkman.
You actually foresaw one question I had: how the SubDyn module understand that is a fixed or a floating platform (and I suppose this is what is declared at the beginning of the simulation once launched).
Based on what you mentioned, if there is a reaction joint (at the seabed), then SubDyn adopts the “fixed” approach (independently of the GuyanLoadCorrection being on or off), while if there is no reaction joint, then it considers the platform floating, correct?

I need to have a better look at the link you suggested, thanks a lot for pointing me toward it, and still need to define if, based on the reaction joint/no reaction joint definition of fixed/floating platform above, this platform is fixed or floating…

Kind Regards

8

Dear @Maurizio.Collu,

I confirm that your understanding is correct.

Best regards,

1 Like
9

Thanks, @Jason.Jonkman.

I’ve modelled the tendons in moordyn, in which I have some challenges, but first I would like to clarify a point about the centraltruss section.

Since this truss section is connected, through a universal joint, to a pile anchor at the bottom, and since this pile anchor provides a reaction force in the vertical direction, counteracting the weight of the whole system (minus the buoyancy, which I think is small) plus the downward forces coming from the tendons, I do not think I can model it as a floating structure - since, if I do so, i.e. if I remove the BASE REACTION JOINT, then there will be nothing counteracting the downward force acting on the pile anchor at the bottom, right?

If this assumption is correct, then I have another question.

Initially I modelled the universal joint between the bottom of the truss structure and the pile anchor by imposing RctRDXss and RctRDYss flags to zero, i.e. leaving free these DOFs, and then using a SSI input file where I specified the rotational stiffnesses equal to zero (which I think can be imposed by putting Ktxtx, Ktxty, Ktxtz,Ktyty, Ktytz to zero in the SSI txt file), then I run into problems, since Subdyn states that there are some ill-conditioned modes.
If I put some finite numbers for Ktxtx, Ktxty, Ktxtz,Ktyty, Ktytz, then I manage to run it, but it is not the joint that I would like to model.

Therefore, what I did was to add an extra member between the bottom of the central truss and the pile anchor, which is rigidly connected to the reaction point at the bottom, and connected through a ball joint at the top with the truss structure.

Is this a correct way to proceed?

10

Dear @Maurizio.Collu,

I’m not sure I understand what you mean when you say:

Therefore, what I did was to add an extra member between the bottom of the central truss and the pile anchor, which is rigidly connected to the reaction point at the bottom, and connected through a ball joint at the top with the truss structure.

Can you clarify?

Otherwise I agree with what you are saying, which may point to a limitation in OpenFAST for modeling this design. The Craig-Bampton reduction of SubDyn requires that there are no zero-frequency (rigid-body) modes in the SubDyn-only model when the interface is clamped. The universal joints in this system (when stiffness is not added to such joints) may be introducing rigid-body modes.

Best regards,

11

Thanks, @Jason.Jonkman.
What I meant is that, to avoid having a reaction joint at the seabed having free horizontal rotations and no rotational stiffness in those DOF, which is not compatible with subdyn formulation, I divide the last beam element at the bottom in two (with the separation just above the seabed), and I added a universal joint between those - since there are no limitations there.

I hope it is clearer now

12

Hi @Jason.Jonkman ,
I have a follow up request about the above.
In the manual here, it is specified in the example the following

3 NJoints - Number of joints (-)

JointID JointXss JointYss JointZss JointType JointDirX JointDirY JointDirZ JointStiff
(-) (m) (m) (m) (-) (-) (-) (-) (Nm/rad)
101 0.0 0.0 50.0 1 0.0 0.0 0.0 0.0
111 0.0 0.0 10.0 2 0.0 1.0 0.0 100.0
102 0.0 0.0 -45.0 1 0.0 0.0 0.0 0.0

Now, as written in the manual, JointDirX, JointDirY, and JointDirZ are to specify the vector coordinates of the direction around which rotation is free for a pin joints.

Questions are:

  1. In the example above, the JointType is 2, i.e., a Universal joint, so why it is specified JointDirY equal to 1?
  2. How to specify which 2 rotations are free in a Universal joint type?
  3. Also, is it correct to assume that the X, Y, Z are parallel to the substructure coordinate system (i.e., global inertial-frame system)?
13

Hi @Maurizio.Collu,

Here are my responses:

  1. Actually, JointDirX, JointDirY, and JointDirZ are only used for pin joints (JointType = 3). So, this is somewhat of an odd example where JointDirY is set for a university joint, but not used SubDyn.
  2. For a universal joint in SubDyn, the moment is assumed to transfer through local z-axes of each member, with the local x and y axes the free axes of the universal joint. This is explained in the SubDyn documentation here: 4.2.5.6. SubDyn Theory — OpenFAST v3.5.0 documentation.
  3. Correct, for a pin joint, JointDirX, JointDirY, and JointDirZ are expressed in the substructure coordinate system.

Best regards,

14

Thanks a lot, @Jason.Jonkman.

I have another couple of questions then:

  1. I’ve found other oddities in the manual, as well as links pointing to the wrong place, missing words…is there a way to suggest a modification, to help the community?

  2. Going back to the problem at hand, in SubDyn.dat, I set the JointID 16 as a universal joint as follow:
    JointID JointXss JointYss JointZss JointType JointDirX JointDirY JointDirZ JointStiff
    (-) (m) (m) (m) (-) (-) (-) (-) (Nm/rad)
    16 0.00000 0.00000 19.0000 2 0.0 0.0 0.0 1.0E+2

with a very small JointSitff value for the rotations in x and y to avoid instabilities.

I have two beam members connected through JointID 16, as follow:

MemberID MJointID1 MJointID2 MPropSetID1 MPropSetID2 MType COSMID
(-) (-) (-) (-) (-) (-) (-)
15 15 16 3 3 1 ! Main barrel, member 15
16 16 17 1 1 1 ! Transition piece, member 1

Then I set OutAll to True, and I plotted M15J2MKxe, M15J2MKye, M16J1MKxe, M16J1MKye. Since JointID 16 is a universal joint, I was expecting these to be zero, since they are free to rotate, but they are not. And they are very large, of the order of 10^9 Nm.

On another hand, M15J2MKze = M16J1MKze, as expected (i.e. the moment around the axis of the beams is transmitted from one to the other).

I am probably missing something basic here?

Kind regards

15

Dear @Maurizio.Collu,

Regarding (1), I would suggest posting the documentation issues you’ve noticed on OpenFAST issues in the GitHub repository: Issues · OpenFAST/openfast · GitHub. Even better, edit the documentation (which is in the repository) directly and submit a pull request to fix the issues.

Regarding (2), by setting a nonzero JointStiff, I would not expect the xe and ye moments at the joints to be nonzero. Moreover, there is also a known issue in SubDyn associated with the member loads on both sides of rotational joint–see: SubDyn issue for loads on both sides of a rotational joints · Issue #855 · OpenFAST/openfast · GitHub. My understanding is that the global response is correct, but the member-level loads right at the joint are not reported correctly because of this bug (loads further down the member are correct).

Best regards,

16

Dear @Jason.Jonkman ,
thanks for your answers.

For (1), I’ll try to directly modify the docs and suggest a pull request.

For (2), ok, understood - I do not expect the xe and ye moments to be zero, but should be small. Thanks for mentioning the signalled issue.
I would not expect the xe and ye moments to be exactly the same, since xe and ye are in local coordinates, and the two members can be aligned along different axis, in general?
Anyway, do you know of any quick workaround to get reasonable values representative of those at the interface? Maybe dividing the members in a number of sub-elements, and get the shear forces/moments corresponding to an internal node, which will be close to the interface?

Many thanks

17

Dear @Maurizio.Collu,

Anyway, do you know of any quick workaround to get reasonable values representative of those at the interface? Maybe dividing the members in a number of sub-elements, and get the shear forces/moments corresponding to an internal node, which will be close to the interface?

This is the workaround I would suggest until that bug is addressed, which will allow you to get the loads at nodes close to the joint, but not at the joint.

Best regards,

1 Like
18

My understanding (based on the verification cases that we ran in the past) is that the output at one side of the revolute joint is wrong, but at the other side is the proper one.

I leave the test case here for reference:

image
image732Ă—363 6.45 KB

Results:

image
image934Ă—335 61.4 KB

image
image949Ă—510 65.8 KB

I hope that helps!

1 Like
19

Thanks, @Roger.Bergua,
for the useful information.

  1. I noticed that it says that the wrong one is at the right side of the pin joint. How is defined the right side? If the pin joint is Jn, and you have the beam from the wall to the pin as M1 (Jn-1 to Jn), and the other beam M2 (Jn to Jn+1), which one is the right side? Not sure which one is defined as M2 in the figure
  2. Is this verification case available somewhere?
  3. To avoid any doubt, I set the universal joint stiffness to zero, but I keep having bending moments at the joint different from zero. Admittedly, they are much larger on one side (that can be the wrong one) than the other side (that maybe is the correct one?).

Looking forward to hearing from you

20

Hi Mauricio,

  1. The right and left convention that I use is based on the first schematic representation that I shared. See below for reference:

    image
    image954Ă—249 11.3 KB

  2. This verification case is not publicly available. We performed several test cases to verify the behavior of new elements in SubDyn like revolute joints, cable elements, rigid links… Maybe it would be good to publish those as an NREL technical report, so people have access to them.

  3. I would recommend you adding 2 nodes around the universal joint and not using the results in those dummy short beams (see example below). By the way, last week an NREL colleague was trying to extract the loads around a universal joint and a ball joint. For those joints, the results at the right and left side were not consistent (i.e., both sides were wrong). The revolute joint only has 1 DOF while these other kinematic joints have 2 and 3 DOFs. So, it may be that the proper loads at one side only applies to revolute joints.

    image
    image967Ă—285 11.6 KB

I hope that helps!