WAMIT .ss file

Dear all,

I am using FASTv8 and in the HydroDyn.dat file it is requiered WAMIT output files. With .hst, .1 and .3 is not problem but how is compound .ss file?

I was reviewing WAMIT documentation but it is not there.

Thanks in advance,
JOE

Dear Joe,

I’m assuming you are referring to the linear state-space model input file (*.ss) of HydroDyn. The *.ss file is not generated by WAMIT, but by the SS_Fitting preprocessor of HydroDyn, which itself makes use of WAMIT output. SS_Fitting is available from: nwtc.nrel.gov/SS_Fitting. The *.ss file is only needed by HydroDyn when the radiation memory effect is calculated using a linear state-space model (RdtnMod=2) in place of the convolution method. If you use the convolution method (RdtnMod=1), only the WAMIT *.hst, *.1, and *.3 files are needed (plus files related to the second-order effects, if enabled).

Best regards,

Dear Jonkman,

Was that. Thank you so much.

Best regards,
Joe

Dear Jonkman,

I return to the subject of *.ss files.

I execute ‘ss_fitting.m’ to my hydrodynamic and hydrostatic results (*.1, *.3 and .hst). But the obtained *.ss file is not good enough. I analyzed the resulting plots and are very different to original ones. There are some oscillations where there should not be. Why can be this?

I attached *.ss results and my hydrodynamic and hydrostatic results.

Thank you in advance,
JOE
K.zip (49.5 KB)
Hydro.zip (27.8 KB)

Dear Joannes,

I’m not an expert on the application of the SS_Fitting software. I would send detailed questions to Tiago Duarte of EDP (who developed SS_Fitting) (and I don’t believe Tiago checks this forum regularly).

Which identification method did you use and what fit accuracy did you select? Have you followed the guidance described in Duarte et al’s OMAE 2013 paper: nrel.gov/docs/fy13osti/58099.pdf?

Best regards,

Dear Jonkman,

Thanks for your quick reply.

Yes, I followed the guidance. I try with fourth identification methods and the one that fits best was Frequency Domain Identification (FDI) with Fit Accuracy of 0.97. But the results are not very accurate as previously attached results shows.

If I introduce this *.ss results in FAST simulations, an error is displayed saying that the system is unstable. And without this *.ss file FAST works well.

And, do you think that FAST simulations without this wave radiation memory-effect activated would be valid? I mean, the system behaviour changes slightly. I test it with the ITIEnergy Barge and the difference is very small.

Thank you for getting in touch with Tiago Duarte.

Kind regards,

Dear Joannes,

Hopefully Tiago can help regarding the SS_Fitting software.

Can you run the simulation in FAST/HydroDyn with the convolution method (RdtnMod = 1) used in place of the state-space method?

The importance of the radiation memory effect likely depends on the platform. The radiation memory effect will influence the level of platform damping so it could be important especially for resonance excitation.

Best regards,

Dear Jonkman,

Ok, thank you.

I can not run the simulation in FAST/HydroDyn with the convolution method (RdtnMod = 1). Error displayed says that it is not allowed with the current version of HydroDyn. I used the version 2.03.

Did you sent to Tiago the files attached by me?

Thank you again,
JOE

Dear Joannes,

I’m not familiar with this error. The convolution method should be available in all versions of HydroDyn. Can you paste a copy of the error shown in the command window?

No, I have not reached out to Tiago. I suggested that you reach out to him yourself. I don’t need to be the mediator.

Best regards,

Dear Jason,

This is the error displayed:

Error using Run_Simu (line 21)
Error reported by S-function ‘FAST_SFunc’ in ‘FOWT_Simulink_Jonkman_detuned/FAST Nonlinear FOWT 5MW NREL/S-Function’:
FAST_InitializeAll:SrvD_Init:ValidatePrimaryData:Yaw angle and rate are not commanded from Simulink model.
ValidatePrimaryData:HSS brake is not commanded from Simulink model.
FAST_InitializeAll:HydroDyn_Init:The value of Conv_Rdtn is not equal to the glue code timestep. This is not allowed in the current version of HydroDyn.

Ok I will get in touch with Tiago.

Best regards,
JOE

Dear JOE,

You can avoid that error by setting RdtnDT equal to the DT specified in the FAST primary input file.

Best regards,

Dear Dr. Jonkman,

Is there another link instead of this one; nwtc.nrel.gov/SS_Fitting? As the SS_Fitting preprocessor is not there anymore. I believe that I can obtain the .ssexctn files using the same preprocessor, can’t I?

Best regards,
Amr

Dear @Amr.Hegazy,

The old NWTC Information Portal has been replaced. The new link to the SS_Fitting archive is: SS_Fitting | Wind Research | NREL.

However, the SS_Fitting toolbox can only generate the .ss files for the wave-radiation solution. The state-space wave-excitation data (.ssexctn) file can be generated by the SS_Excitation_Fitting toolbox, which is similar to the MATLAB-based SS_Fitting toolbox for wave-radiation, but for the wave-excitation solution. SS_Excitation_Fitting has been discussed on the OpenFAST issues page: Wave Excitation model generation in state-space (*.ssexctn input file) · Issue #397 · OpenFAST/openfast · GitHub. This issue suggests reaching out to Alan Wright for access to the toolbox. Unfortunately, Alan Wright has recently retired from NREL. I’m not sure why the SS_Excitation_Fitting was never released publicly, but I’ve now sent you the alpha release via WeTransfer.

Best regards,

Dear @Jason.Jonkman,

Thanks a lot Dr. Jonkman for the clear answer, and for the toolbox!

According to that link you shared (Wave Excitation model generation in state-space (*.ssexctn input file) · Issue #397 · OpenFAST/openfast · GitHub) and the documentation of SS_Excitation_Fitting, OpenFAST linearization takes the wave perturbation into account when ExctnMod is set to 2 in HydroDyn.

At the end, we have the only input from HydroDyn included in the input vector is the wave elevation. So, my question is:

Can we have the 6x1 wave excitation force vector as the input from HydroDyn instead of the wave elevation? In other words, can we neglect the .ssexctn file required for ExctnMod = 2, such that we have the excitation forces directly included in the input vector, u, of the state space equations after linearization?

Thanks in advance.

Best regards,
Amr

Dear @Amr.Hegazy,

I’m not sure I fully understand your question, but the state-space wave-excitation model provides a state-space model between wave elevation and wave-excitation loads. If you already know the wave-excitation loads, there is no need for this model.

In OpenFAST, the hydrodynamic loads are output from HydroDyn and input to ElastoDyn. So, effectively, the hydrodynamic loads (summing across all hydrodynamic + hydrostatic contributions) are already included in the input vector of the full-system state-space model (when LinOutputs = 2 is enabled).

Best regards,

Dear @Jason.Jonkman

Thanks for your prompt response.

Let me elaborate more. So, I am trying to get a state space model where the wave excitation loads are in the input vector instead of the wave elevation. However, in the .lin file (when LinInputs = 2 & LinOutputs = 2), I see that the hydrodynamic loads (specifically, the wave excitation loads) are included in the output vector since they are output from HydroDyn, while the wave elevation is an input. Thus, the state space matrices B matrix in the .lin file will correspond to having the wave elevation as the only input, while the wave excitation loads are considered as outputs of the system, and thus, considered in the C matrix.

Best regards,

Dear @Amr.Hegazy,

As I said, the hydrodynamic loads are also module-level inputs to ElastoDyn, and so, will also show up in the B and D matrices of the full system *.lin file when LinOutputs = 2 is enabled.

Best regards,

Dear Dr. @Jason.Jonkman,

Returning to this point again. I set ExctnMod = 0 in HydroDyn since I don’t want to include that transfer from the wave elevation to the excitation forces held via the *.ssexctn file. I also set LinOutputs = 2, yet I get the wave elevation as the only input from HydroDyn.


While, I would like to have HydroFxi, HydroFyi, HydroFzi, HydroMxi, HydroMyi and HydroMzi in this case as inputs from ElastoDyn in the input vector in the *.lin, since they are passed as inputs to ElastoDyn as you mentioned here WAMIT .ss file - #15 by Jason.Jonkman. However, I find these 6 variables in the output vector.

Is there any possibility to do that?

I also included one of the *.lin files for you to check further. 5MW_OC3Spar_DLL_WTurb_WavesIrr.1.lin - Google Drive

Another question, in your paper (https://www.nrel.gov/docs/fy19osti/71865.pdf), it is mentioned that the linearized viscous drag is included in the jacobians. How did you arrive at that linearized form of the viscous drag?

Best regards,

Dear @Amr.Hegazy,

The wave-elevation at (X,Y) = (0,0) is a standard input and is included in the linearization file whenever LinInputs = 1 in the OpenFAST primary (.fst) input file and HydroDyn is enabled, even if ExctnMod is not 2. That said, the elements of the linearized matrices associated with this HydroDyn input will only have nonzero terms when ExctnMod = 2. You can always ignore inputs that you don’t need.

The HydroDyn outputs “HydroFxi, etc” are include as outputs in the linear model because you’ve selected them in the OutList of HydroDyn and LinOutputs = 1 in your OpenFAST primary input file. You can always ignore outputs that you don’t need.

The ElastoDyn inputs associated with the forces and moments applied to the ElastoDyn platform will be included as inputs in the linear model when LinInputs = 2 (referring to all module-level inputs) in the OpenFAST primary input file.

Viscous drag terms in HydroDyn are linearized directly via the central difference method, but this is not a robust method as the magnitude will be dependent on the perturbation size in the absence of sea current or forward speed of the substructure. This is a known issue, which I’ve just raised on the issues page of the OpenFAST github repository: Feature Request: Improve How Viscous Drag is Linearized in HydroDyn · Issue #1210 · OpenFAST/openfast · GitHub.

Best regards,