OC4 Phase II results

Dear Dawn,

The mean platform-pitch angle is dictated by the mean rotor thrust and the pitch restoring of the floating platform. The mean rotor thrust at 18 m/s is higher for active blade-pitch-to-stall control than it is for active blade pitch-to-feather control–compare Figure 7-3 to Figure 3-12 in NREL/TP-500-41958. This increase in mean thrust, together with the difference in pitch restoring between the ITI Energy barge and DeepCwind semisubmersible likely explain the differences between your results and those of Figure 7-4 in NREL/TP-500-41958.

Best regards,

Many thanks

Dear Dr. jason
I am verifying my analysis against the OC4 Phase II results for Load Case 3.8 - damage case 1: loss of one mooring line at fairlead (line 1).
The simulation length is 60 s before loss / 60 min after loss.
Do you explain how to simulate the scenario about the loss of one mooring line in FAST 8?

Best Wishes
Jason. Lai

Dear Jason,

FAST v8 does not have the capability to lose a mooring line at a give point in time directly through a specification in an input file. However, this is a fairly easy change to make in the source code (requiring a recompile of FAST). Simply go into the SUBROUTINE *_CalcOutput() of whichever mooring module you are using and implement logic to zero out the loads of the fairlead at a give point in time (the loads at each fairlead are outputs of each mooring module).

Best regards,

Dear Dr. Jason
I have revised the source code and recompiled it.
It can work but the result is wrong.
Do you give me some advice about my code?
Thanks for your help again.

Best Wishes
Jason.Lai

[code]!----------------------------------------------------------------------------------------------------------------------------------
!> Routine for computing outputs, used in both loose and tight coupling.
SUBROUTINE FEAM_CalcOutput ( t, u, p, x, xd, z, OtherState, y, misc, ErrStat, ErrMsg )
!..

REAL(DbKi),                     INTENT(IN   )  :: t           ! Current simulation time in seconds
TYPE(FEAM_InputType),           INTENT(IN   )  :: u           ! Inputs at t
TYPE(FEAM_ParameterType),       INTENT(IN   )  :: p           ! Parameters
TYPE(FEAM_ContinuousStateType), INTENT(IN   )  :: x           ! Continuous states at t
TYPE(FEAM_DiscreteStateType),   INTENT(IN   )  :: xd          ! Discrete states at t
TYPE(FEAM_ConstraintStateType), INTENT(IN   )  :: z           ! Constraint states at t
TYPE(FEAM_OtherStateType),      INTENT(IN   )  :: OtherState  ! Other states at t
TYPE(FEAM_OutputType),          INTENT(INOUT)  :: y           ! Outputs computed at t (Input only so that mesh con-
                                                              !   nectivity information does not have to be recalculated)
TYPE(FEAM_MiscVarType),         INTENT(INOUT)  :: misc        ! misc/optimization variables
INTEGER(IntKi),                 INTENT(  OUT)  :: ErrStat     ! Error status of the operation
CHARACTER(*),                   INTENT(  OUT)  :: ErrMsg      ! Error message if ErrStat /= ErrID_None

! Local variables
REAL(ReKi)                                     :: AllOuts(MaxOutPts)     ! All the the available output channels
INTEGER(IntKi)                                 :: I,J                    ! Generic loop index

! INTEGER(IntKi) :: K ! Blade index
! INTEGER(IntKi) :: ErrStat2
! CHARACTER(ErrMsgLen) :: ErrMsg2
INTEGER(IntKi) :: LEG ! Generic index
REAL(ReKi) :: TEMP ! Temporary storage

! Initialize ErrStat

ErrStat = ErrID_None
ErrMsg  = ""
 
DO LEG=1,p%NumLines
   IF (t>=60 .AND. LEG==1) THEN
    ! Fairlead & Anchor tensions Output
    misc%FAIR_T(LEG) = x%GLU(LEG,0*((p%NumElems+1)*p%NHBD-1))
    misc%ANCH_T(LEG) = x%GLU(LEG,0*(p%NHBD-1))
    ELSE
    misc%FAIR_T(LEG) = x%GLU(LEG,(p%NumElems+1)*p%NHBD-1)
    misc%ANCH_T(LEG) = x%GLU(LEG,p%NHBD-1)
    END IF    
    ! Fairlead & Anchor angle output
    DO I=1, p%NDIM
        misc%FAIR_ANG(LEG,I) = x%GLU(LEG,p%NumElems*p%NHBD+I*2)
        misc%ANCH_ANG(LEG,I) = x%GLU(LEG,I*2)
    ENDDO

    ! Line element displacement & tangent vector output
    DO I=1, p%NumElems+1
        DO J=1, p%NDIM
            misc%Line_Coordinate(LEG,I,J) = x%GLU(LEG,(I-1)*p%NHBD+J*2-1)
            misc%Line_Tangent(   LEG,I,J) = x%GLU(LEG,(I-1)*p%NHBD+J*2  )
        ENDDO
    ENDDO

     ! OtherState%FAST_RP is set in UpdateStates (FEAM_Solve); seems like we should just recalculate it here:        
   TEMP = SQRT(OtherState%FAST_RP(LEG,1)**2+OtherState%FAST_RP(LEG,2)**2+OtherState%FAST_RP(LEG,3)**2)
   DO J=1,p%NDIM
       misc%F_Lines(LEG,J) = misc%FAIR_T(LEG)*(-OtherState%FAST_RP(LEG,J)/TEMP)
   END DO

ENDDO 

DO i = 1,y%PtFairleadLoad%NNodes
    y%PtFairleadLoad%Force(1,i) = misc%F_Lines(i,1) 
    y%PtFairleadLoad%Force(2,i) = misc%F_Lines(i,2)
    y%PtFairleadLoad%Force(3,i) = misc%F_Lines(i,3)
END DO

[/code]

Dear Jason,

It looks like you are zeroing out an index of an array instead of the tension itself i.e. change:

misc%FAIR_T(LEG) = x%GLU(LEG,0*((p%NumElems+1)*p%NHBD-1)) misc%ANCH_T(LEG) = x%GLU(LEG,0*(p%NHBD-1))
to

misc%FAIR_T(LEG) = 0*x%GLU(LEG,((p%NumElems+1)*p%NHBD-1)) misc%ANCH_T(LEG) = 0*x%GLU(LEG,(p%NHBD-1))
Best regards,

Dear Dr. Jason
Load Case 3.8 - damage case 1: loss of one mooring line at fairlead (line 1).
The simulation length is 60 s before loss / 60 min after loss.

I have revised it according to your suggestion.

misc%FAIR_T(LEG) = 0*x%GLU(LEG,(p%NumElems+1)*p%NHBD-1) misc%ANCH_T(LEG) = 0*x%GLU(LEG,p%NHBD-1)
Now, It can’t zero out loads of the fairlead at a given point in time.
Is the other code wrong?

[code] !----------------------------------------------------------------------------------------------------------------------------------
!> Routine for computing outputs, used in both loose and tight coupling.
SUBROUTINE FEAM_CalcOutput ( t, u, p, x, xd, z, OtherState, y, misc, ErrStat, ErrMsg )
!..

REAL(DbKi),                     INTENT(IN   )  :: t           ! Current simulation time in seconds
TYPE(FEAM_InputType),           INTENT(IN   )  :: u           ! Inputs at t
TYPE(FEAM_ParameterType),       INTENT(IN   )  :: p           ! Parameters
TYPE(FEAM_ContinuousStateType), INTENT(IN   )  :: x           ! Continuous states at t
TYPE(FEAM_DiscreteStateType),   INTENT(IN   )  :: xd          ! Discrete states at t
TYPE(FEAM_ConstraintStateType), INTENT(IN   )  :: z           ! Constraint states at t
TYPE(FEAM_OtherStateType),      INTENT(IN   )  :: OtherState  ! Other states at t
TYPE(FEAM_OutputType),          INTENT(INOUT)  :: y           ! Outputs computed at t (Input only so that mesh con-
                                                              !   nectivity information does not have to be recalculated)
TYPE(FEAM_MiscVarType),         INTENT(INOUT)  :: misc        ! misc/optimization variables
INTEGER(IntKi),                 INTENT(  OUT)  :: ErrStat     ! Error status of the operation
CHARACTER(*),                   INTENT(  OUT)  :: ErrMsg      ! Error message if ErrStat /= ErrID_None

! Local variables
REAL(ReKi)                                     :: AllOuts(MaxOutPts)     ! All the the available output channels
INTEGER(IntKi)                                 :: I,J                    ! Generic loop index
INTEGER(IntKi)                                 :: LEG                    ! Generic index
REAL(ReKi)                                     :: TEMP                   ! Temporary storage

! Initialize ErrStat

ErrStat = ErrID_None
ErrMsg  = ""
 
DO LEG=1,p%NumLines
   IF (t>=60 .AND. LEG==1) THEN
    ! Fairlead & Anchor tensions Output
    misc%FAIR_T(LEG) = 0*x%GLU(LEG,(p%NumElems+1)*p%NHBD-1)
    misc%ANCH_T(LEG) = 0*x%GLU(LEG,p%NHBD-1)
    ELSE
    misc%FAIR_T(LEG) = x%GLU(LEG,(p%NumElems+1)*p%NHBD-1)
    misc%ANCH_T(LEG) = x%GLU(LEG,p%NHBD-1)
    END IF    
    ! Fairlead & Anchor angle output
    DO I=1, p%NDIM
        misc%FAIR_ANG(LEG,I) = x%GLU(LEG,p%NumElems*p%NHBD+I*2)
        misc%ANCH_ANG(LEG,I) = x%GLU(LEG,I*2)
    ENDDO

    ! Line element displacement & tangent vector output
    DO I=1, p%NumElems+1
        DO J=1, p%NDIM
            misc%Line_Coordinate(LEG,I,J) = x%GLU(LEG,(I-1)*p%NHBD+J*2-1)
            misc%Line_Tangent(   LEG,I,J) = x%GLU(LEG,(I-1)*p%NHBD+J*2  )
        ENDDO
    ENDDO

     ! OtherState%FAST_RP is set in UpdateStates (FEAM_Solve); seems like we should just recalculate it here:        
   TEMP = SQRT(OtherState%FAST_RP(LEG,1)**2+OtherState%FAST_RP(LEG,2)**2+OtherState%FAST_RP(LEG,3)**2)
   DO J=1,p%NDIM
       misc%F_Lines(LEG,J) = misc%FAIR_T(LEG)*(-OtherState%FAST_RP(LEG,J)/TEMP)
   END DO

ENDDO 

DO i = 1,y%PtFairleadLoad%NNodes
    y%PtFairleadLoad%Force(1,i) = misc%F_Lines(i,1) 
    y%PtFairleadLoad%Force(2,i) = misc%F_Lines(i,2)
    y%PtFairleadLoad%Force(3,i) = misc%F_Lines(i,3)
END DO [/code]

Best Regards
Jason.Lai

Dear Jason,

The only other thing that I noticed from my brief review of your source code is that you’ve used “60” in place “60.0” and “0” in place of “0.0”. Without the decimal, Fortran will assume the number is an INTEGER instead of a REAL, which may cause the compiler to complain when comparing “t>=60”.

If that does not fix the problem, what is happening in the simulation after recompiling FAST? Are the simulation results affected by the change?

Best regards,

Dear Dr. Jason
Thanks for your help and it can work smoothly.
However, I have another question about MoorDyn.
How to output FairAng and AnchAng in MoorDyn?
I read MoorDyn User’s Guide but it doesn’t describe about these parameter output?

Best Regards
Jason. Lai

Dear Jason,

Without modifying the source code, you cannot directly output the line angle from the horizontal plane from MoorDyn. However, you can output the global X, Y, and Z components of the line tension from which you can calculate the angle(s) by post-processing if so desired. See the MoorDyn User’s Guide for more information.

Best regards,

Dear Dr. Jason
Now, I can zero out loads of the fairlead at a given point in time.
However, the roll motion is different from OC4 phase II LC3.8 result.
Do you know how to resolve this question?

Best Regards
Jason. Lai

Dear Jason,

Actually, I think your results make more sense than what is published in the OC4 Phase II results paper. The paper refers to a growth in response tied to the use of a quadratic drag matrix that disappears when Morison drag is used instead. Your results are more in line with what I would expect from this load case.

Best regards,

Dear Dr. Jason
Thanks for your reply.
Besides, is the figure reasonable compared to OC4 phase II LC3.8 result ?

Best Regards
Jason. Lai

Dear Jason,

If you eliminate the left downwind line (when looking downwind), I would expect the platform to surge upwind to the right, as the OC4 Phase II results are doing. I don’t see the same behavior in your results (at least not to the extent), but perhaps you need to run your simulation longer?

Best regards,

Dear Dr. jason

I can run FAST Certification Test #14: WindPACT 1.5 MW Baseline with stationary linearization in a vacuum successfully.
However, I use the similar method to run Test #25: NREL 5.0 MW Baseline Wind Turbine with OC4-DeepCwind semi configuration.
There are some mistakes in FAST code.

[code]
Running FAST (v8.16.00a-bjj, 27-Jul-2016), compiled as a 32-bit application usi
ng double
precision
linked with NWTC Subroutine Library (v2.09.00, 23-Jul-2016)

Heading of the FAST input file:
FAST Certification Test #25: NREL 5.0 MW Baseline Wind Turbine with OC4-DeepC
wind semi
configuration, for use in offshore analysis

FAST_InitializeAll:FAST_Init:ValidateInputData:Linearization is not implemented
for the HydroDyn
module.
ValidateInputData:Linearization is not implemented for any of the mooring module
s.

FAST encountered an error during module initialization.
Simulation error level: FATAL ERROR

Aborting FAST.

E:\semi-surmersible OWT\LC1.1>[/code]

How to use FAST_v8.16 to analyze OC4 semi-submersible Load Case 1.1_full-system natural frequencies?

Best Wishes
Jason. Lai

Dear Jason,

As discussed several times on this forum, while some linearization functionality has been added to FAST v8, it is not yet possible to linearize a model with HydroDyn enabled in order to derive full-system natural frequencies for offshore systems. It may be possible to use white-noise wave excitation to derive the natural frequencies you seek.

We have funding at NREL this year to expand the linearization functionality of OpenFAST to also include BeamDyn, HydroDyn, and MAP++ (currently only linearization with ElastoDyn, AeroDyn, InflowWind, and ServoDyn are supported), but we have not yet completed with this implementation.

Best regards,

Dear Jason,

Following the discussions between you and Jason Lai, I would like to know how did Amy Robertson calculate the full-system natural frequencies for Load Case 1.1 in her publication (nrel.gov/docs/fy14osti/61154.pdf, Figure 3). Did she use the FAST_v7? But as far as I know, FAST_v7 have limitations in Morison Strip-theory calculation, as you explained many times in this forum.

If Amy was using a customized FAST_v8 and it cannot be provided publicly, would you mind to explain in detail about using the white-noise wave excitation method to derive the full-system natural frequencies as you mentioned? That will be very helpful to the users like me who are interested in this issue.

Thanks a lot.
Best regards,
Yingyi

Dear Yingyi,

For the NREL results in that paper, we used FAST v7 (with a simplified model of the OC4-DeepCwind semisubmersible) to run load case 1.1.

And yes, I’d recommend using white-noise wave excitation until the linearization capability for floating systems is available in OpenFAST if you can’t resort to FAST 7 for that. When running with white-noise wave excitation, compute the power spectra of various output channels can be used to clearly identify peaks in the response i.e. the full-system natural frequencies. The difficult part is to interpret which frequencies correspond to which modes.

Best regards,

Dear Jason,

How about using power spectral analysis on the free-decay platform simulation outputs to find the platform natural frequencies?

Are there any specific differences between performing power spectral analysis on the free-decay time series and the white-noise wave excitation time series?

Thanks.
Best regards,
Yingyi Liu

Dear Yingyi,

Using free-decay simulations can work to estimate natural frequencies, but free-decay simulations may be more difficult to excite all modes of the structure (unless you run many free decay simulations each with different system perturbations).

Best regards,