AeroDyn integrator and a variable time-step

Hello all,

Currently I’m working on a coupling project with AeroDyn. In broad strokes, the project is to write an interface for AeroDyn using AeroDyn_Driver as the starting point, modify it to allow the hub kinematics and inflow velocities to be set from subroutine arguments, and then put it into a DLL for another piece of software to link to.

My question has to do with the fact that the piece of software that is going to use this DLL interface has a variable time-step, and will therefore be providing the kinematic inputs at varying times. So my question is: is it okay for the current integrator used in AeroDyn to change the internal dt variables during a simulation? To illustrate, my initial idea was to establish a maximum dt that AeroDyn will take, so that if the time-step taken by the interfacing software is too big, AeroDyn will break the time-steps into integer multiples of that maximum dt and call AD_UpdateStates using each one, and then set all the dt variables to one last remainder (if needed) so that the last call to AD_UpdateStates brings the states to the same time as the latest inputs provided by the interfacing software. I’d also have to modify the two subroutines AD_UpdateStates, and Set_AD_Inputs to take an actual time instead of a step number, but after this then it should work, depending on if the integrator used in AeroDyn can deal with a varying dt.

I have read this post which states that the integrator in the unsteady airfoil aerodynamics model needs a fixed time-step, but the post is from 2016, so I’m not sure if the integrator implementation has changed since then.

Thank you for any help.

Dear Dustin,

The simple answer is “no”.

A couple comments:

  • The FAST modularization framework requires that all modules share information (inputs/outputs) at the same fixed rate, e.g. the *_UpdateStates() and *_CalcOutput() interface routines are assumed to be called at fixed steps.
  • AeroDyn has a several kinds of states, including constraint, continuous time, and discrete time. The BEMT solution uses constraint states (solving algebraic equations), which in principle do not care what the time step is; though the UpdateStates routine assumes a fixed step (see the first bullet). The unsteady aerofoil aerodynamics solution is implemented mostly with discrete-time states, which inherently assume a fixed time step (you’d have to disable UA if you otherwise changed the AeroDyn interface to support variable time steps). The DBEMT solution uses continuous-time states (ODEs), which are solved using a fixed-step integrator.

It would likely take quite a bit of work to change AeroDyn to handle variable time steps. It is likely better to develop a wrapper for AeroDyn such that the calls to AeroDyn are at a fixed step even if the wrapper is called at a variable step.

I hope that helps.

Best regards,

Dear Jason,

Thank you for the quick reply and explanation! You’ve pointed me in the right direction.