NAN error detected in the transformation algorithm between motion and force in two modules

Wind & Water General
1

Dear all

I am trying to model the soil-pile interaction for anchor piles of wind turbine floater in OpenFAST. I choose a simple way by merging the SubDyn code (along with SoilDyn) into MoorDyn. It is achieved by the transformation algorithm between motion and force in OpenFAST. More specifically, the anchor point is set free in MoorDyn and transfers the motion of anchor point to the TP point in SubDyn, and receives the force from the TP point in SubDyn.

I tested the modification with NREL 5MW TLP wind turbine and found that the motion and force at the TP becomes larger and larger (finally it becomes NAN) as the simulation proceeds, which led to the failure of simulation. The error may be caused by the acceleration component because the simulation can proceed longer if the acceleration is set to zero.

In fact, I encounter the same problem when I compiled the OpenFAST as a dynamic link library (dll) to be called by another program. These make me think that the transformation algorithm between motion and force in two modules/programs shall work with some requirements, for which I am writing this topic.

Many thanks.

2

Dear @Teng.Long,

Module coupling that involves one module taking force as input to calculate acceleration, which is then output to another module to compute the force needed as input to the first module is inherently implicit. That is, the acceleration can’t be calculated without the force and the force can’t be calculated without the acceleration. Such coupling exists between several modules of OpenFAST, such as ElastoDyn-BeamDyn, ElastoDyn-SubDyn, ElastoDyn-HydroDyn, and SubDyn-HydroDyn. To solve this implicit coupling, the OpenFAST glue code sets up algebraic constraint equations that are solved via a Newton-Raphson scheme, which also involves computing a large Jacobian. Within the glue code, this is referred to as an Option 1 solve (Option 2 solves do not involve implicit coupling, rather, input-output relationships can be optimally sequenced). The MoorDyn-SubDyn coupling you are proposing sounds like it will require an Option 1 type of solve.

Note that in some cases, such as the existing ElastoDyn-MoorDyn coupling, the mass used to calculate the force in MoorDyn is much smaller than the mass used to calculate the acceleration in ElastoDyn, in which case an Option 2 solve tends to be satisfactory even though the coupling is technically implicit. But when the masses in both modules are similar in magnitude, an Option 1 solve is necessary.

Best regards,