Hello All,
I have installed standalone AeroDyn and am compiling the executable AeroDyn_Driver via Visual Studio. I understand that AeroDyn takes in initialization inputs (environmental, inflow, blade data etc) to setup the simulation. I was a bit confused what exactly the inputs and outputs are during the time-stepping phase of the simulation - could you help point me out to what those are and where that would be in the Visual Studio files?
I am interested in replacing the inputs during time-stepping phase with sensor data from a laboratory in real-time to complete a hardware-in-loop simulation. Thanks!
Best,
Elaine
Dear @Elaine.Liu,
The standalone AeroDyn driver is used to run the AeroDyn module uncoupled from OpenFAST. So, the AeroDyn driver sends the AeroDyn module all of the inputs it need to advance its states in time and calculate its outputs. The time-based inputs include the structural motion of the aerodynamic analysis nodes and the undisturbed inflow. The AeroDyn driver file (documented here: 4.2.6. AeroDyn Driver — OpenFAST v4.1.2 documentation) allows you user to prescribe these inputs through an input file. Is that sufficient for your needs, or do you need to modify the source code to better control the inputs you are sending AeroDyn?
Best regards,
Hi Jason,
Thank you for the quick reply.
If I understand correctly, to advance time, AeroDyn takes in inputs of structural motion at nodes and undisturbed inflow. Is this structural motion just the prescribed tower base motion as mentioned in the documentation? What are the exact outputs resulting from its time-stepping?
I believe I would need to modify the source code to change how the inputs and outputs are sent. Do you know where in the Visual Studio solution this would be?
Thank you for your guidance!
Elaine
Dear @Elaine.Liu,
The inputs to AeroDyn are the structural motions of all aerodynamic analysis nodes. The AeroDyn driver takes a simplified representation of the turbine and allows the user to prescribe motion based on a limited set of inputs like tower-base motion, rotor rotation, and blade pitch; the driver then uses rigid-body kinematics to calculate the motions of all nodes AeroDyn needs as input. But AeroDyn doesn’t require that the blades and tower be rigid bodies, so, the driver source code could be changed if you need to specify the full set of motions, including structural flexibility.
The core outputs of AeroDyn are the aerodynamic applied loads at the aerodynamic analysis nodes.
The main routine the AeroDyn driver uses to call the AeroDyn time-stepping modules, including setting inputs and receiving outputs, is in SUBROUTINE Dvt_TimeStep() of AeroDyn_Driver_Subs.f90.
Best regards,
Thank you for that feedback, Jason. I was able to locate that Dvr_timestep() function. When I build the AeroDyn_Driver file, I see that there are a few warnings from the FVW_Subs.f90 and SysIVF.f90 files regarding the Fortran language. Do you know if I need to upgrade Fortran on my Visual Studio, or is this to be expected? Many thanks!
Best,
Elaine
Dear @Elaine.Liu,
Are you just getting warnings, or are you also getting errors that prevent the executable from being compiled? Some warnings are expected, but not errors.
Best regards,
Hi Jason,
These are just warnings. But I wasnt sure if it is expected. It is about Fortran 2003. Thanks!
Best,
Elaine
Dear @Elaine.Liu,
I’ve certainly seen this warning before and wouldn’t be concerned if you don’t receive errors.
Best regards,
Thank you for the information, Jason.
I had a question regarding AeroDyn_Driver_Subs.f90. In line 823, is the rotor acceleration meant to be hubMotion(3)? The previous line had defined rotor speed as hubMotion(2).
Regarding my own project, I would like to apply motions at the hub and compute the resulting forces at the hub. I am thinking of modifying the Set_Mesh_Motion() function, lines 849-851, to read in orientation, speed and acceleration values from sensors. Are these just one-dimensional scalars? To obtain aerodynamic loads, I would then use the output vector, y, that is a result of AD_CalcOutput() under ADI_Calc_Output() on line 302. The hub forces would then be y%AD%rotors(iWT)%HubLoad%Force(:,1) or %Moment(:,1).
Is this the recommended way of doing so? Thanks!
Best,
Elaine
Dear @Elaine.Liu,
Indeed, it looks like line 823 of AeroDyn_Driver_Subs.f90 has a bug; wt%hub%rotAcc should be set to hubMotion(3).
If you want to specify your own time-varying hub orientation, speed, and acceleration, I would think you’d be able to use the RotMotionType = 1 (time varying rotation) option of the AeroDyn driver as is (after the bug fix), in which case the azimuth, speed, and acceleration of the shaft are specified through RotMotionFileName.
Best regards,
Hi Jason,
Thank you for the prompt reply and noting that bug. The hub motions that I am hoping to assign would need to be from real-time sensory input, which I cannot access ahead of time. Because of that constraint, I am not sure that I can specify motions via a file input. Do you know if I can edit the source code in the manner that I suggested instead?
Best,
Elaine
Dear @Elaine.Liu,
The standalone driver of AeroDyn assumes you know the motions ahead of time and want to figure out the resulting aerodynamic loads (one-way coupled). It sounds like what you want is more of a two-way coupling between AeroDyn and some a physical device in a laboratory, through hardware-in-the-loop (HIL) / software-in-the-loop (SIL) coupling. It would help if you provided more background to provide more specific guidance about that.
Best regards,
Hi Jason,
Yes that is exactly what I want - a two-way coupling for a hardware in the loop approach. Essentially, I would have a force sensor reading forces at a tower base to be fed into a simple structural dynamics solver (OpenSees) to compute structural motion at the hub. This motion would then be an input into AeroDyn to compute aerodynamic forces at the hub. The hub forces are then sent back to OpenSees to compute displacement that is physically applied in a laboratory. This again results in forces at the tower base to complete one timestep of the HiL.
Do you know how I would go about accomplishing this? Thanks!
Best,
Elaine
Hi Elaine,
Thanks for clarifying. In addition to OpenFAST modules and hardware, I also see that you are bringing another software (OpenSees) into the mix. I imagine this to be a complicated development, more involved than simply updating the standalone AeroDyn driver. You can use the driver as guidance for how the AeroDyn module should be called, but as I understand from your description, I now see OpenSees as the code that will call AeroDyn, not the AeroDyn driver. Plus you’ll have to figure out how to get OpenSees to interface to your hardware through HIL/SIL approaches.
Best regards,
Hi Jason,
Your interpretation is correct - OpenSees would need to call AeroDyn. Currently, I have the OpenSees/AeroDyn HiL communications figured out, where AeroDyn is capable of receiving data input from OpenSees and sending data output back via some custom communications functions I made.
The only place I am unsure of is exactly where to modify AeroDyn to replace hub motion with my custom function calls, and where to output hub forces so I can send data back. Would this be modifying the Set_Mesh_Motion() function, lines 849-851, to directly read in orientation, speed and acceleration values from my functions? To obtain aerodynamic loads, I would then use the output vector, y, that is a result of AD_CalcOutput() under ADI_Calc_Output() on line 302 to send back via my custom function.
Would this implementation make sense? I greatly appreciate your insights on this, thanks!
Best,
Elaine
To help clarify, to my interpretation, I would still need the AeroDyn driver to model the blades etc. But I am directly hijacking the hub motion computation to use my function calls from OpenSees. Let me know if this makes sense!
Dear @Elaine.Liu,
Given that you are not changing the AeroDyn module itself, you’ll need OpenSees to send AeroDyn all of the inputs it needs. Considering your focus on hub motion, I presume you are treating the rotor as rigid in the OpenSees-AeroDyn coupling. But AeroDyn still needs motion of all of the blade aerodynamic nodes as input. The AeroDyn driver derives this motion by mesh-mapping from the blade-root motion (the mesh-mapping uses rigid-body kinematics), which itself is mesh-mapped from the hub motion. As I see it, you’ll have to mimic this logic from the AeroDyn driver within OpenSees.
Best regards,
