Tightly coupling AeroDyn and BeamDyn to a external driver program

Wind & Water Computer-Aided Engineering Software Tools
1

Hi all,

I’m looking into coupling both AeroDyn and BeamDyn to an external piece of simulation software. One of the main problems I foresee is that the software that will act as the driver program uses an explicit numerical integrator for updating its states, and these states would be used as inputs to both AeroDyn and BeamDyn. This means that I cannot just use OpenFAST as a reference for how to coordinate the two modules with the driver program because OpenFAST uses a predictor-corrector integration method (and uses an “iterative nonlinear input-output solver” for BeamDyn because I believe it has “direct-feedthrough” due to accelerations playing a role in both its input and output). That is to say, I can’t see how these same methods could be used in a driver program that uses explicit integration only for its own states.

So I’ve been trying to find other options. I’ve seen reference to OpenFAST’s modules having been built with the possibility of tight coupling, where some driver program actually uses its own numerical integration method to update the states of the modules. I’m thinking that this might be the way to go. I found a small guiding template in the NWTC Programmer’s Handbook for tight coupling (which I’ve posted below), but I’m unclear of two main things.

The first is that AeroDyn doesn’t actually have a function AD_CalcContStateDeriv, and I was wondering why that is. Is it because AeroDyn doesn’t actually have any continuous states unless DBEMT is enabled, i.e. when WakeMod=2? In general, how is tight coupling expected to be done with AeroDyn?

The second thing is how to deal with the result from the constraint state residual. In the template code below, the residual is calculated, and then the constraint variable is set. I’m wondering what this section of a tight coupling would look like with AeroDyn specifically. My confusion is probably due to the fact that I haven’t come across constraint residuals or Differential Algebraic Equations before, so it’s a bit new to me. If the explanation is too difficult for here, could you point me to some resources?

Thank you,
Dustin

!............................................................................................................. ! Routines called in tight coupling -- time marching only !............................................................................................................. DO n = 0,2 Time = n * TimeInterval ! Note that the discrete states must be updated only at the TimeInterval defined in initialization ! set inputs (u) here: ! u = ! Update constraint states at Time ! DO CALL ModName_CalcConstrStateResidual( Time, u(1), p, x, xd, z, OtherState, Z_residual, ErrStat, ErrMsg ) IF ( ErrStat /= ErrID_None ) THEN ! Check if there was an error and do something about it if necessary CALL WrScr( ErrMsg ) END IF ! z = ! END DO ! Calculate the outputs at Time CALL ModName_CalcOutput( Time, u(1), p, x, xd, z, OtherState, y, ErrStat, ErrMsg ) IF ( ErrStat /= ErrID_None ) THEN ! Check if there was an error and do something about it if necessary CALL WrScr( ErrMsg ) END IF ! Calculate the continuous state derivatives at Time CALL ModName_CalcContStateDeriv( Time, u(1), p, x, xd, z, OtherState, dxdt, ErrStat, ErrMsg ) IF ( ErrStat /= ErrID_None ) THEN ! Check if there was an error and do something about it if necessary CALL WrScr( ErrMsg ) END IF

2

Dear Dustin,

So, does the “external piece of simulation software” you are trying to couple with AeroDyn and BeamDyn solve structural equations of motion such that you’ll have structure-to-structure coupling (BeamDyn coupled to your structural solver)? You mention that your software has explicit integration, but is the output calculation in your software separated from the state update, as it is in the implicit loose coupling approach of OpenFAST, such that you can still implement the “iterative nonlinear input-output solver”?

Your understanding is correct, AeroDyn doesn’t have an AD_CalcContStateDeriv routine because most of its states are not in continuous-time form (the BEMT states are in algebraic/constraint form, the unsteady aerodynamic states are in discrete-time form, and DBEMT has a mixture of continuous-time and discrete-time states). That said, we are working on an updated version of AeroDyn that does have an AD_CalcContStateDeriv routine, where both the DBEMT and unsteady aerodynamic states are fully in continuous time (this is useful for full-system linearization, including aerodynamic states).

Tight coupling was proposed when the FAST modularization framework was first established, but never fully implemented. So, I can’t offer much guidance with regards to tight coupling.

Best regards,

3

Hi Jason

Thanks for the very helpful reply! I had been confused about tight-coupling for a while, thinking it was actually supported for each module, but not being sure how to approach it. Hearing that it isn’t fully implemented finally has it making sense.

So yes the driver program I’m working with does solve structural equations of motion, and there will be this structure-to-structure coupling between it and BeamDyn. I’m actually not 100% sure of the details of this driver program’s implementation yet, so I will have to investigate. And in the meantime I’m going to try and understand how OpenFAST is coordinating the modules (particularly in the SolveOption1 subroutine) and see if I can get a clearer idea of what I need to do if I were to use the same method.

Thanks again,
Dustin