Fix to the computation of blade elements, no interpolation of geometr…

[fcgaleazzo]

…y characteristics. Following the discussion on Issue #301

[petebachant]

Thanks for the contribution! Can you explain the changes and the motivation behind them?

[fcgaleazzo]

Hi Pete, thanks for the reply!
The main problem I worked with is that, in the original code, the full length of the blade is not taken into account. I gave some numbers about it in the Issue #301
To correct this, the function actuatorLineSource::createElements() has to be aware of the root and tip point of the blade. I included this information in the function axialFlowTurbineALSource::createBlades(). With this information, function actuatorLineSource::createElements() computes the begin and end points of the blade element (BEMpoint1 and BEMpoint2). The new behavior considers that the points read from elementData dict are in the middle of each blade element (as usual in the BEM theory).
The new behavior makes difficult to judge how the values from elementData should be interpolated between the blade elements, so I modified also this section of axialFlowTurbineALSource::createBlades(). Now all sub-elements inside a blade element share the same values of elementData from the parent blade element.

[petebachant]

I'm not so sure I agree with the premise that there should be an element at the exact tip of the blade. If we look at this diagram from a SOWFA presentation, it appears to follow the same process of defining geometry points (lines) and putting the elements between them (dots):

What is your reasoning behind needing an element at the root and tip?

[fcgaleazzo]

Hi Pete. This is a nice diagram of the SOWFA presentation, I will explain my modification using it. I am assuming that the yellow bars denote the border of each blade element and the red dots denote the positions where the coefficients are stored and the forces are calculated.
The original behavior assumes that the points in the elemenData dict are the yellow bars, defining the borders of the blade elements. It considers the first and last points as rootPosition and tipPosition (function actuatorLineSource::createElements()), even though these dots are not positioned in the geometric root and tip positions. New points are created between the points in the elemenData dict (red dots). The coefficients are interpolated into these points, and also the forces are calculated there. The SOWFA diagram looks something like this:

My modification (commit fcgaleazzo:fix-blade-length) assumes that the points in the elemenData dict are the red dots. So it calculates the yellow bars for each corresponding red dot, positioning the first yellow bar (BEMpoint1 of the first blade element) at the geometric root position, and the last yellow bar (BEMpoint2 of the last element) at the geometric tip position. There is no need to interpolate the coefficients from elementData. The SOWFA diagram would look like this:

I hope that my reasoning is clearer now :)

[petebachant]

This seems to already have been looked up, no?

Suggested change

	<< normalRefForce() << "," << dict_.lookup("pitch") << endl;
	<< normalRefForce() << "," pitch << endl;

[fcgaleazzo]

You are right, line 507 was committed by accident

[fcgaleazzo]

Regarding the correction of the blade length, results using my modification have been compared to another code (Xcompact3D) in a paper that is already online. The results are nice, but only when applying the correction. Here the link: https://onlinelibrary.wiley.com/doi/10.1002/we.2714