Issues with TMD in ServoDyn-Stc

[RBergua]

I'm trying to model a wave energy converter (WEC) in OpenFAST as follows:

I tried modeling the hull as the platform in ElastoDyn and the internal reaction mass (IRM) as a TMD in ServoDyn as part of the structural control module (StC).

For reference, the hull represents 80% of the total system mas, and the IRM represents 20% of the mass.

I started doing some tests in still water conditions without mooring lines.

When modeling the system without IRM, I'm obtaining the expected behavior in heave (e.g., in this case the device moves upwards because it is missing the weight of the IRM).

As part of this verification phase, I also locked the 6 rigid body platform motions in ElastoDyn and looked at the behavior of the IRM. As expected, the ElastoDyn platform stays in place and there is a constant hydrostatic force upwards due to the buoyancy. Looking at he IRM, we can see that it moves 1.63 m downwards due to the gravity acceleration. This behavior is the expected one. For reference, I also include the velocity and the force that the spring of the TMD does in the vertical direction.

Unfortunately, if I try to combine the platform with heave motion and the TMD, the solver experiences a numerical instability. For reference, I'm using OpenFAST dev-tc (https://github.com/OpenFAST/openfast/tree/dev-tc).

As can be observed, the solver does not converge and I get a heave displacement of 3E12 m. I tried using several correction iterations (NumCrctn = 3) and dropping the time step (dt = 1E-3 s). But the results didn't improve.

I understand that this could be a limitation of the loose coupling of ServoDyn within OpenFAST. I tried reducing the IRM mass ratio from 20% to 10%. In this case, I can make it run if I only enable the heave DOF for the platform.

But I have convergence issues again if I enable the 6 platform DOFs (despite the system only moving in the z direction in these tests).

I guess one way to overcome this loose coupling limitation would be modeling the IRM (i.e., spring/dashplot-mass) in SubDyn taking advantage of the spring elements (#1889 (comment)). Although setting up the proper damping in the different directions may be a bit challenging.

Any thoughts or suggestions?

[jjonkman]

@deslaughter -- I believe this issue results from treating the ServoDyn module via explicit loose coupling (option 2) in the glue code. How much effort would it be to treat ServoDyn via implicit loose coupling (option 1)? Another option, though perhaps even harder to support, would be to use tight coupling when integrating the states of the StC submodel of ServoDyn. Let me know your thoughts.

[deslaughter]

@jjonkman it shouldn't be difficult to move ServoDyn into the Option 1 solve assuming that the dYdu Jacobian is calculated properly. It might be possible to use tight-coupling for the StC submodule, but I'd need to research that further.

[jjonkman]

@deslaughter -- ServoDyn should be forming the proper Jacobians for the StC states, inputs, and outputs because StC is one of the features supported through the full-system linearization capability of OpenFAST. There are, of course, other states, inputs, and outputs of ServoDyn that do not support linearization (those related to user-defined controls), so, the ServoDyn coupling would have to use a combination of implicit and explicit coupling. I'm specifically thinking the acceleration-related inputs to StC and associated reaction load outputs would be implicitly coupled, and the other inputs and outputs of ServoDyn would remain explicitly coupled, similar to how we mix implicit/explicit coupling in other modules like HydroDyn. I'm thinking we focus on implicit coupling, not worrying about tight coupling for now, which I could see would be complicated for the mixed coupling approach.

[RBergua]

For future reference, I confirm that I ended modeling this in SubDyn taking advantage of the spring element. The hull mass and inertia is split between the SubDyn and ElastoDyn modules. The behavior is the expected one. Example of gravity-only loading in still water conditions:

[RBergua]

After some tests, an important take away: In this kind of devices (WEC), the internal reaction mass can be pretty large (e.g., 20% of the total mass in this case). In some systems, like in this one, this large mass results in a significant heave offset for the equilibrium condition due to the gravity acceleration (around -2 m as you can see in the above plot). Since SubDyn is based on a linear approach, the mass matrix is not updated at every time step. This means that, in our case, we don't have the proper center of mass and inertia of the system anymore. When testing the system with incident waves along the x-axis, this results in different motions in pitch. Hopefully we can rely on ServoDyn to overcome this linear assumption limitation.

[deslaughter]

@RBergua, I was able to update ServoDyn's Jacobian routines to match the other modules and the tight-coupling framework and add it the Option 1 solve if it contains structural controllers. This allowed me to run the WEC model for 100 seconds and everything seemed stable. The platform motion was smooth as well as the TMD motion. The mooring line tensions were a bit noisy, but that may just be that model. The branch is available for testing at https://github.com/deslaughter/openfast/tree/SrvD_Option1 and I am building Windows binaries through Github which should be available tomorrow.

I had to rebaseline a few of the structural controller regression tests as the finite difference Jacobians gave slightly different results for the structural controller DOFs. Also, having ServoDyn in Option 1 changed a couple of time domain results, but not significantly.

[RBergua]

I have done one verification by comparing a heave free-decay using the SubDyn approach and the new ServoDyn capability. For this test, I only included a TMD in the z-direction. The initial heave displacement for the system is +3 m. Below you can see the hull z-displacement:

And also the Internal Reaction Mass (IRM) z-displacements (relative to the hull):

As can be observed, the behavior is the expected one. I also ran a regular wave condition and the OpenFAST solver converged. This is all great news!

However, I observed something interesting. The Internal Reaction Mass in my case can move in the 3 tanslational directions. Accordingly, I should enable the TMD x, y, and z directions in ServoDyn, But this implies adding 3 independent masses in the system. The gravity acceleration seems to be applied to each of them (not just the z DOF). This results in more weight than expected in my system as can be observed in the new heave equilibrium of the hull:

As you can see, the system equilibrium in heave is not 0 m anymore but -2.3 m.

[jjonkman]

@RBergua -- Thanks for verifying the new StC coupling implementation; I'm glad it works as expected.

While StC supports 2D omnidirectional (x and y) TMDs and 1D independent (x, y, or z) TMDs, it does not currently support a 3-DOF (x, y, and z) TMD. Properly modeling the PTO of the TALOS WEC would require the latter. It sounds like you are trying to mimic that with 3 independent TMDs in the x, y, and z directions, which triples the weight of the PTO.

I'm curious if you can well approximate the behavior by modeling the PTO with 2 TMDs:

1. One 2D omnidirectional TMD
2. One 1D z-based TMD

This will only double the weight of the PTO, which you'd have to correct by reducing structural mass from the platform in ElastoDyn accordingly.