Time step in OpenFAST from v3.1.0

Wind & Water Computer-Aided Engineering Software Tools
1

Hi,
I am currently trying to interface OpenFAST with in house structural and hydrodynamics solver.
I am trying to upgrade to v3.5.3. With the new AeroDyn_Driver_Subs → there is a new routine Dvr_TimeStep, which essentially takes AeroDyn from one step to the next.
The change I observed is that, in this routine the current time is nt-1 and next step is nt. Can I know the reason for this change ? Why rather than using nt and nt+1, we are using nt-1 and nt.
In the earlier versions we had to manually call AeroDyn_UpdateStates - but this routine does that for us among other things.
In our inhouse solver the time starts from 1, so we have to use a if condition of the last time step, i.e:

if (nt < numsteps)
    call Dvr_TimeStep(nt + 1, ..........)
else
    call Dvr_TimeStep(nt , .............) ! To accommodate the last step

Is this the intended approach ?

Thank you,
Ashok

2

Ashok,

If you take a look at AeroDyn_Driver.f90 where Dvr_TimeStep is called, you can see that the values of nt go from 1 to numSteps. Does nt == 1 correspond to t = 0.0 for your in-house solver? Dvr_TimeStep uses nt to calculate the time at the end of the step as time = dvr%dt * nt. As long as nt is set to calculate the time at the end of the step, I think it will work. However, I don’t see a need for the conditional as the code you have would end up calling the last step twice with the same time.

Thanks,
Derek Slaughter

3

Thanks @Derek.Slaughter .

Yes nt=1 corresponds to t = 0.0 in our solver.

Just one more question:
What is the purpose of Fake Elastodyn [FED] ? Why would we require to set Aerodyn inputs based on FED meshes in the Driver Subroutines ?

image
image1392×552 108 KB

Regards,
Ashok

4

Dear @Ashok.Jammi,

When a standalone driver code is used to drive the simulation of a given module, the inputs to the module normally set by the OpenFAST glue code need to be set in the driver code. For AeroDyn coupled within OpenFAST, much of the inputs–for example, the structural motion of AeroDyn’s aerodynamic analysis nodes–get set by ElastoDyn. So, these inputs are called “Fake ElastoDyn (FED)” in the standalone driver code of AeroDyn.

Best regards,

5

Thanks @Jason.Jonkman .
So does that mean, if we have an inhouse structural solver, we could map our structural data to the FED data structure - and it will take care of the mesh movement/updates and so on for every step ? Till FAST 3.0.0, we used to manually do this.

Regards,
Ashok

6

Dear @Ashok.Jammi,

Yes that sounds correct.

Best regards,

7

That’s quite commendable work @Jason.Jonkman, in-terms of interfaces. Awesome.
Let me implement and see.

Thanks,
Ashok