Then I summed an ECD gust with the previous loaded array.
Wrote back the results to a BTS file
Run two fast simulations: one with the baseline wind and the other with the modified wind file.
The results are the following:
blue: modified file
orange: baseline turbulent file
The ECD gust I superimposed starts only at 50s, so I was expecting the the Wind1VelX and Wind1VelY signals were exactly the same until that time and the Z component to be equal at all times, since I didn’t modified it. But I got this kind of “noise” in the velocity signals. I’ve already checked the Vslope and Voffset parameters to convert the wind speed from float to int when writing the binary file, and I can assure they´re not the problem.
The other check I made was to compare the velocities read directly from the bts file with the output from fast. The following fig. shows this for the baseline turbulent file I’m using:
These are the x-component of the grid point (14,14) and the openfast Wind1VelX channel configured at hub-height. My grid is 30x30 points, 0.05 s time step and the fast outputs are 0.025s. Again we see the “noisy” signal. I was not expecting the two lines to be exactly equal in this case, since the output from fast is a interpolation between various grid points, but the magnitude of that difference surprised me.
Is this behaviour expected? There is something fundamentally wrong with the approach I followed to modify the turbulent wind file? Is there a better way to do it?
I’m not familiar with the synthetic.py Python script you are using, so, I can’t really comment on that.
But I do question what you are trying to do. Normally the Extreme Coherent Gust with Direction Change (ECD) load case 1.4 is run with deterministic wind rather than with turbulent wind. That is in OpenFAST, one would generally use the uniform wind file format, WindType = 2, in InflowWind based on a uniform wind file generated, e.g., with NREL’s IECWind preprocessor. Is there a reason you are not simulating DLC 1.4 this way?
I have not used the python tools in the way that you’ve described either. I wrote the TurbSim class to read inflow data into a convenient python format. If I had to wager a guess, I would think that your original input data were periodic and your modified file with the coherent gust did not account for this. I never wrote a BTS writer because it was easier to write out HAWC-style full-field files as described in the InflowWind manual.
Good luck with your problem if you haven’t yet resolved it!
My reason for simulating DLC 1.4 with turbulent wind is because of section 7.4.1 of IEC61400-1 (2019) :
In my case the gust causes the controller to fire a shutdown due to reaching maximum yaw error. So I need to simulate with a turbulent wind to be sure that the shutdown behaviour will be the same as in the deterministic wind.
Are you aware of another mean of compliance with this paragraph?
Eliot: Unfortunately I did’nt solve solve this problem yet. Currently it’s on hold, but if sometime I overcome it I’ll come back here to register the solution
Interesting; I don’t recall seeing that stated in the -1, but there it is stated clearly (also in the 2005 version and offshore -3, which I’m more familiar with). I’m not actually sure how this is normally handled because I’m not aware of any aero-elastic tool that supports the simulation of discrete wind direction gusts or direction changes together with full-field turbulence. This would be a good question for a certification body.
I have not followed up yet, but I support the development of the IEC 61400-3-2 floating wind design standard and I’ll ask that question at an upcoming meeting.
