Reading of Mann Wind in HAWC2 and Other Aeroelastic Codes (OpenFAST/FAST.Farm, etc.)

[adamwise95]

I have sent this inquiry into DTU and the developers of HAWC2, but it is relevant here as well. Per @jjonkman's request, I am also posting this issue to the OpenFAST github site so that it can be discussed with the OpenFAST community.

Bug description

We suspect that the orientation of Mann wind boxes in HAWC2, and therefore OpenFAST/FAST.Farm and other aeroelastic codes, are reversed in the longitudinal direction (x-direction).

To Reproduce

By running OpenFAST/FAST.Farm with the InflowWind module's WindType variable set to 5.

5   WindType       - switch for wind file type (1=steady; 2=uniform; 3=binary TurbSim FF; 4=binary Bladed-style FF; 5=HAWC format; 6=User defined)

Expected behavior

described in detail in the attachment (under Screenshots)

Screenshots

MannComparison.pdf

relevant article: Vertical cross spectral phases in neutral atmospheric flow.pdf

OpenFAST Version

OpenFAST v1.0.0

But this bug extends to previous versions of FAST, the most current version of OpenFAST, other aeroelastic codes used by the wind energy research community, and by extension FAST.Farm.

Additional context

Copied email sent to DTU:

To whom it may concern,

My name is Adam Wise and I’m a visiting student researcher advised by Erin Bachynski in the Department of Marine Technology at NTNU. We are currently using FAST.Farm to investigate wake interaction between multiple floating wind turbines.

We are generating synthetic turbulent inflow using both the Kaimal and Mann turbulence models; however, we have noticed that the Mann wind boxes look opposite to what we would expect. The fluctuations in u, and more clearly in v, arrive first at lower z when they should arrive at higher z as expected in nature and found in LES (Chougule and Mann et. al, 2012). I have provided a short slide deck with figures comparing wind boxes that clearly show this phenomenon.

We have confirmed that FAST/FAST.Farm has implemented the Mann boxes as specified in the OC3 documentation (note that FAST and FAST.Farm read wind in the same way). Additionally, we have run simulations in FAST and HAWC2 and confirmed that they read the Mann boxes identically. After discussions with NREL, we suspect that there may be a bug in the original implementation of reading Mann boxes in HAWC2. It appears that in FAST, based on the documentation and comparison with HAWC2, the Mann box is read assuming that it is written in order of increasing x (decreasing t). The OC3 documentation does not clearly describe whether the box is written in terms of x or t.

Is it possible that there is a bug when reading Mann wind in HAWC2?

Thank you for your attention.

Sincerely,
Adam

[jjonkman]

I have discussed this issue with @adamwise95 and @bjonkman and we agree that this is a bug.

We have in the past generated HAWC-formatted wind data and used the same files in both FAST (now OpenFAST) and HAWC2 and the time series were identical at different points throughout the domain. Our suspicion has been that X is backwards. The original Mann documentation uses X instead of t. When this was coded up in HAWC2 (followed by FAST), X was replaced with t. But the relationship should be X is replaced with minus t. The InflowWind module could certainly be changed to flip the sign of X for HAWC-formatted files, which would fix the look of the Mann wind data, but this would mean that FAST/OpenFAST would differ from HAWC2. Ideally, both software would be fixed concurrently.

[bjonkman]

An alternative explanation is that the Mann wind files could be written backwards in the IEC Turbulence Simulator. The file format description says "The z-direction index is running fastest, then the y-direction, and the x- (or time-) direction is running slowest." It is ambiguous as to what the values of those directions are (is the smallest value first or or the largest first?).

I think it would make more sense to say that the wind file starts with the smallest time (the current assumption in the aeroelastic codes) and have Mann-generated winds start with the largest value in the x direction. The wind files have always been assumed to contain time histories, so storing them in that manner makes the most sense to me.

[adamwise95]

Updates from the email chain:

Dear Adam,

Thank you very much for your detailed input!
I can confirm that the Mann box in HAWC2 is read with increasing x (see attached figure).
We will have a look into it and correct it if it is a bug.

Best regards,
Georg

Hi Georg,

Thank you very much for the response.

Looking at the figure you attached, wind is propagating in the negative x direction (which is opposite of how it looks in the FAST-framework). Therefore, there should be no flip in space and time, i.e. the negative x direction and positive time are in the same direction. However, the source code shows that the longitudinal direction of the boxes are read in reverse:

DO IX = NX,1,-1      ! Time is the opposite of X ....

So, to me, it seems as though there is an extra “flip” of space and time. Although, it is still unclear to me how the boxes are written by the Mann turbulence generators.

Thanks,
Adam

---

Not sure if that makes sense to people on here, but to me it seems like there doesn't need to be the flip in the source code I think because of how the IEC Turbulence Simulator writes the box.

[RuiliangWang]

hello,everyone
Is FAST.Farm available?

[jjonkman]

Dear @RuiliangWang,

We have not released FAST.Farm publicly to all, but we have provided a pre-release of FAST.Farm to specific collaborators. And we are working on the public release. We intend to publicly release FAST.Farm after (1) the super controller has been fully implemented; (2) the user documentation has been finalized; and (3) the FAST.Farm source code, documentation, and test cases have been merged with the newest version of OpenFAST.

Best regards,

[adamwise95]

Just a brief follow-up to this issue. We recently completed some work that was submitted to Wind Energy and added a short appendix detailing the reversal of the Mann wind (see PDF below). In addition to what has already been shared in this thread, we calculated the spectral phases of u, v, and w between two neighboring vertical grid points and found that the phases were opposite of what is observed in nature and LES. A plot of the time series also shows that the the velocity components lag instead of lead at the higher vertical coordinate (this is most clear in v). We ultimately flipped the reading of the Mann wind in the longitudinal direction for our work.

MannAppendix.pdf

Relevant references:

[47] Chougule A, Mann J, Kelly M, Sun J, Lenschow DH, Patton EG. Vertical cross-spectral phases in neutral atmospheric flow. Journal of Turbulence 2012; 13: N36. doi: 10.1080/14685248.2012.711524

[48] Passon P, Kühn M, Butterfield S, Jonkman J, Camp T, Larsen TJ. OC3-Benchmark Exercise of Aero-elastic Offshore Wind Turbine Codes. Journal of Physics: Conference Series 2007; 75: 012071. doi: 10.1088/1742-6596/75/1/012071

[14] Jonkman J, DoubrawaP, Hamilton N, Annoni J, Fleming P.Validation of FAST.Farm Against Large-Eddy Simulations. Journal of Physics: Conference Series 2018; 1037: 062005. doi: 10.1088/1742-6596/1037/6/062005

[madsmpedersen]

In the original paper of Jakob Mann, Mann, J. (1994). The spatial structure of neutral atmospheric surface-layer turbulence. Journal of Fluid Mechanics, 273, 141-168. doi:10.1017/S0022112094001886, he has this figure

which indicates that the x axis points in the direction of the wind. This is opposite to the reading in HAWC2 which is as shown in the figure above.

@adamwise95, thank you for finding and sharing this. I am sorry that we have not been able to fix it in HAWC2 yet, it is definitely not forgotten. We are currently investigating the impacts on loads and would like to provide these results together with the fix.
@jjonkman I think it is a great idea to synchronize the fix between OpenFAST and HAWC2.

[pelljam]

Hi all, I just wondered if there was now a consensus on how these Mann turbulence fields should be interpreted?

Thanks,
James

[jjonkman]

Hi @pelljam,

Both NREL and DTU agree that the Mann box has been read incorrectly, with X/t swapped as explained above. But NREL has been waiting for @madsmpedersen to report back so that HAWC2 and OpenFAST can be fixed at the same time.

Best regards,

[pelljam]

@jjonkman, thanks for your (quick) reply. I did read the above, but I confess I found it quite hard to follow! What was not clear to me was if the required longitudinal swap was the result of the difference between using x or t (as I think you suggested above) or if it is the difference of interpreting x to be in the direction of propagation or opposite it (as the most recent comment suggested). Possibly it is both reasons, in the different software.

I thought that might matter, because would it not dictate whether or not you also need to flip the interpretation of the y-axis, which I think you would need to do in the latter explanation to retain a right handed frame?

Anyway, understood the work is ongoing and I will keep an eye out for future updates.

Thank you again,

James