Code understanding request (FVW of Aerodyn_driver )

[robytian]

Hi @ebranlard

Recently I tried to understand the code about FVW, I read part of the code and it blew me away, your work is just fantastic. I try to add some models to FVW for my PhD project. So far I have only read some of it briefly and I have some questions for you.

1.Are there other materials available to help understand the code besides the OLAF manual?

2.About VortexTools , Is this section all about algorithms for calculating induced velocity? I would like to know what Tree, Seg and Part correspond to? From reading other code, I understand that Tree represents the tree algorithm, and segments represents the blade segments, which are used to compute the algorithm for each segment. There doesn't seem to be an implementation yet that uses vortex particles to calculate the flow field and update the blade circulation?

3. real(ReKi), dimension(:,:,:), intent(inout) :: LatticeVectors !< nVal x nSpan x nDepth ，The depth in this case refers to the depth along the chord? Or x-axis, downstream?

4.About FVW_Wings , A wing represents a blade right, which is a carry over from wing theory ？Is wing made up of segments?

5.About FVW_Subs, subroutine CountSegments(p, nNW, nFW, iDepthStart, nSeg, nSegP, nSegNW) Shouldn't there be panels where NW/FW shed? Why are segments used?

6.About FVW_Types, Why is the Alpha particle intensity in TPart type is 3 x np, and what does 3 mean here? Shouldn't there be only one unit of intensity? Or is this alpha in the vortex particle method?
Does epsilon in T_Sgmt refer to the vortex core radius?

I'm sorry I have so many questions. Hope you can help answer, thank you very much.
Roby

[ebranlard]

Hi @robytian

Thank you for diving into OLAF's code. Here are some elements of responses:

1. OLAF theory manual is definitely the best reference to get you started. You can also look at the report from van Garrel (2003) listed as a Reference for OLAF. You'll find some more details in my book (Branlard 2017), also listed in the reference, for things like core spreading, tree algorithm, conversion segments/particles, verification cases.

2. OLAF does not have a vortex particle formulation yet, but depending on VelocityMethod it might convert the segments to particles for the induced velocity calculation, becasue it is easier and faster to use particles for a tree-like algorithm. Look at the documentation for VelocityMethod for more details.

3. Span is indeed along the wing/blade span, whereas Depth is along the chordwise direction. The Depth storage will typically contains one panel for the blade, and then all the ather panels in that directions will be in the wake.

4. OLAF does not distinguished between wings and blades (Blades are for wings of a rotors). In the baseline OLAF formulation a wing is represented with a vortex panel. See this figure

5. The internal representation stores panels (both for the blade and wake). These panels can be thought to consists of 4 segments around them. The intensity of a segment is equal to the difference between the circulation of the two panels at the intersection of this segment. The references in point 1 should help.

6. Alpha is the intensity of the particles. It is a vector, indicating the direction and magnitude of the vorticity . The term epsilon is used for "core radius", but the more general term is regularization parameter. The references in point 1 should help.

I hope that helps

[robytian]

Hi @ebranlard

I want to implement Aerodyn_driver to call my C++ code. The sequence I want to implement is that after Aerodyn_driver has done the calculations on the inputfile(aerodyn module test), at this point all the results of the calculations are kept (as far as I know these results are saved, regardless of whether the channel output is set or not), and I pull out from the results obtained from the calculations parameters such as AB1N001Gam and so on, perhaps for multiple blades or for multiple turbines, as well as the segmentation of the blades. I then use these parameters to pass into my C++ function to do the calculation. Making it so that in the end I only had to run the Aerodyn_driver program on the original input file, and get the out that I got from Aerodyn and the out that I got from my C++ program.

Is this achievable? Also where should this part of the C++ code be written? Do I just need to continue my code after the program in AeroDyn_Driver.f90?

Best regards,

Roby

[ebranlard]

Hi Roby,
I'm not sure what your C++ program is doing, so it is a bit hard for me to understand the workflow.

If there is no direct coupling between AeroDyn and your program, then the simplest approach is probably to have your C++ program read the .out file. Alternatively, you can write a python script that reads the .out file and pass it to your program.

If you want to couple both programs (for instance if your program is a structural dynamics solver), then things are a bit more complicated.
We have recently developed a C-interface AeroDyn library, that you can call from Python or any other language. At a given time step you specify the position, velocity, acceleration of all the nodes of the blades of all the rotors, and tell AeroDyn to update its states and calculate aerodynamic forces. This interface is still work in progress, and might require some time to make it work.
You can look at the example py_ad_* in the following folder:
https://github.com/OpenFAST/r-test/tree/main/modules/aerodyn
The interface was recently changed, and you could look/compare with the two examples py_ad* here:
https://github.com/OpenFAST/r-test/tree/dev-unstable-pointers/modules/aerodyn
This would require you to use the dev-unstable-pointers branch of OpenFAST and compile the c-binded aerodyn library.

I hope that helps
Emmanuel

[robytian]

Hi @ebranlard

I'm sorry to bother you again, but could you please tell me if you have written a separate code for the lift line and vortex lattice part before you coupled the olaf module into aerodyn, or could you understand this part of the code from the reading of the blade data to the calculation of the velocities on the blade as well as the flow field information. The large amount of code integrated into aerodyn makes it a bit overwhelming for me to read.

BR,

Roby

[robytian]

Hi @ebranlard

Is this the code you wrote in python based on vorticity and lift line theory? https://github.com/ebranlard/welib/tree/main
Thanks!
BR,
Roby

[ebranlard]

Hi Robytian,
I have written a couple of vortex codes in the past but none are open source. welib contains some vorticity-based tools, but not a full blown vortex code per se. I will likely add one to welib one day, but not in the near future.

[robytian]

Hi @ebranlard

I would like to know how you determine the azimuth and wake age angles in OLAF theory. I know that the azimuth angle can be discretized based on the time step (in degrees), but the wake age angle is obtained from the vector from the origin to the marking point, how should this be valued or how can I get it during the calculation?

I drew this picture.

Thanks
BR，

Roby

[ebranlard]

Hi,
To be fair, OLAF does not really use the "wake age angle". OLAF defines a wake age, as the number of time steps since the vortex was emitted. And element of "wake age" 3 was emitted three time steps ago.

The lattice of vortex elements is stored for each blade. Each point in the lattice has 3 cartesian coordinates (x,y,z). The Points are stored in an array of shape 3 x nSpan+1 x nMaxAge+1 where nSpan is the number of spanwise section of AeroDyn, nMaxAge is the maximum wake age (typically the number of near wake panels).
I hope that helps,

Emmanuel