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

[jjonkman]

Dear @pelljam,

I would say both of your interpretations or two sides of the same coin. My understanding is that the Mann boxes should be read in backwards, which is the same as relating t to negative X. Y need not be flipped in the process.

Perhaps @madsmpedersen or @adamwise95 want to comment further.

Best regards,

[davidovitch]

@jjonkman @pelljam we looked into the effect on loads of reversing the box in a student project but the results where inconclusive. Since this has been "wrong" for so many years, and many load validation campaigns have been executed in this fashion, from the DTU side we would like to accompany such a change with some clear guidance and advice. We are close to releasing a new HAWC2 version but it will not contain a switch to flip the turbulence box just yet. I hope we can investigate this with the necessary attention to detail somewhere this year.

I would interested to hear in case you are aware of in interesting study that can demonstrate what this really means for the loads.

Note that it is trivial to reverse the box on the user side: simply load the box in for example Python, flip it, and save again.

[jjonkman]

Dear @davidovitch,

Thanks for the response. It is nice to hear that you have been studying the influence of this bug. I'm not aware of studies that directly address this issue, but I agree that it would be good to provide some clear guidance and advice to users once this issue is fixed.

Regardless, it sounds like you feel adding a "switch" to flip the turbulence box may be the best solution--so that you can get back results from prior analyses with the bug present and use the correct model for newer applications. We should consider adding this switch to OpenFAST as well. Before this feature is released, thanks for noting a trivial preprocessing workaround.

Best regards,

[jjonkman]

Just an update:

@davidovitch has now indicated that DTU's pending release of HAWC2 version 13.0 will include an option to flip the turbulence box. The option uses the configuration command reverse_mann_box that by DEFAULT is True to indicate that in the past we have always read the box in the reverse (or backward) direction. This is a change made within HAWC2 rather than within the Mann box generator.

NREL should mimic this change on the OpenFAST side by introducing a reverse_mann_box flag (DEFAULT = True) in InflowWind within the WindType = 5 (HAWC/FLEX-format) section of the input file.

@deslaughter / @andrew-platt -- Can you look into adding this feature within the set of changes to InflowWind that you are implementing now?

Best regards,

[davidovitch]

We have just released HAWC2 13.1 (release notes available here) and moving forward we will read the Mann turbulence as originally intended by default. We have added the following keyword that allows a user to control how to read the turbulence box:

• box_front first_plane; default in HAWC2 <= 13.0 (results in reading the Mann box backwards and which is incorrect)
• box_front last_plane; default in HAWC2 > 13.0 (read the Mann box as it is intended)

We had many discussions on what keywords to use and in the end thought that an explicit description was better than using a generic reverse we thought of using first. We also need to consider that users could be using any other kind of turbulence box, and not only those created by the Mann model. In that context a reverse command is confusing, and an explicit instruction on what to read first form the file hopefully is more helpful.

We've made a more explicit description of the HAWC2 turbulence format and looked at the load consequences using 100 seeds (see here). An assessment using the DTU10MW reference turbine shows that in most cases the "backwards" Mann turbulence box is slightly conservative in terms of loads compared to the "real" and physical way pushing the box through the simulation.

[jjonkman]

Thanks, @davidovitch, for the update!

@deslaughter / @andrew-platt -- Sounds like now is a good time to add this box_front switch to InflowWind.

Best regards,