Windows and Linux Binaries has different outputs

[sfruano]

Hi,

I am working with Windows and Linux binaries (version 2.2.0). I took windows binaries from the "releases" section in this web page. After downloading I installed all the necesary ifortran libraries as described in the docs. For the Linux binaries I dowloaded the source code in assests section for the same version than windows binaries and then I compiled them using GNU compilers (version 6.3.0) on a Ubuntu 18.04. For linear algebra, I am using OpenBLAS-0.2.19-LAPACK-3.7.0. There was no compiling errors or warnings.

For the Linux binaries, I run the test suite coming with OpenFAST as indicated in the docs. The results from the test suite are OK, as I discussed with Jason in OpenFAST forum.

I am currently working on a project in which we need to compare Windows and Linux results due to operative reasons of the project. The point is that we started to see that Windows and Linux binaries generates outputs which differs significatively in between them. The case in which I am currently working is wind turbine deacay of a 15M wind turbine desgined by NREL. The wind turbine (which is in onshore conditions) has an initial rotational speed of 9,6 rpm and has not input wind (still condition). There is no controller activated. In this conditions the rotational speed of the rotor should decay due to air drag forces. When, I do the compartive in between both results, I see that the rotational speed is falling down in both cases but in a different rate and seems to converge to a different value. Also, It is possible to see big differences in the thrust generated by the wind turbine. Windows binaries seems to behave correctly as they are generating a bigger thrust and moment when the rpms are higher. In the image below, I show this comparative.

I attach to you a folder with my input files. Inside of it, threre is two folders: shared (wind turbine data and common cases data) and wind_turbine_decay (case specific input files).

input_files.zip

Thanks in advance,

Best Regards,

Sergio

[jjonkman]

Dear Sergio,

As we discussed on the forum, I would generally expect the OpenFAST to give very similar results for this free-decay test when compiled with the same source code on different compilers and run on different platforms. Thanks for providing additional information on the issue.

Can you confirm a couple things?:

• I want to confirm that the results are numerically converged in both versions. Are you using the same compiled precision (single / double) in both versions? Are the results essentially the same if you drop the time step (DT < 0.01 s) or add a correction step (NumCrctn > 0)?

• The BEM (WakeMod = 1) and unsteady airfoil aerodynamic models (AFAeroMod = 2) where developed to function best for an operational rotor, and may not work as well for cases with a parked or idling rotor. Do the results differ between both versions if you disable the wake (WakeMod = 0) and unsteady airfoil aerodynamic effects (AFAeroMod = 1)?

For others following this issue, please note that this issue was discussed previously on our forum (and so, additional background information on the issue is provided there)--see the posts starting on Jul 01, 2020 in the following forum topic: https://wind.nrel.gov/forum/wind/viewtopic.php?f=4&t=642&start=225.

Best regards,

[sfruano]

Dear Jason,

I have done the tests you requested. The big difference in between Windows and Linux versions was coming from the single/double precision. I did a mistake and I was pointing to the OpenFAST single precision solver in my windows launching bat files. So now, differences are quite small in between Windows and Linux.

On the other hand, I have done another test using the most suitable aerodynamic models as you said (WakeMod=0 and AFAeroMod=1). I have found that aerodynamic transient response is sensitive to single/double precision solvers even when the correct aerodynamics models are set up. Also, I have run an inflow wind staircase with the appropiate input set up for inflow velocities and I have found some differences in between single and double precision.

As a general rule, could we say that is better to use double precision solver when transients effects are important and remain single precision solver for steady aerodynamics? I am asking that because the performance difference in between single/double precision solvers is significative, at least for my computer, so we would like to take advantage of that when it is possible.

Thank you very much for your help

Best Rergards,

Sergio

[jjonkman]

Dear Sergio,

OK, thanks for clarifying. So, it appears that the use of single versus double precision was the source of the difference. These differences arise because the DEFAULT tolerance used in the BEM solution (as a result of IndToler = "Default") differ between the single and double precision compilations--this is documented in the AeroDyn documentation--see: https://openfast.readthedocs.io/en/master/source/user/aerodyn/input.html#aerodyn-primary-input-file.

From my experience, single precision is suitable for all engineering applications (load case simulations). As you pointed out, single precision is much faster than double precision and generally accurate enough. Even when compiling in single precision, we've stored the variables that have been demonstrated to require double precision (for accuracy / numerics) in double precision anyway. In your case, the aerodynamic models used were not really intended for shutdown situations and it appears that their solution in this case is sensitive to the precision of the solve. This may point to improvements that could be made to the solve to improve their numerics in cases beyond their originally intended application. Simply overriding the default tolerance may achieve similar results.

Best regards,

[sfruano]

Dear Jason,

I am not a wind turbine specialist but I have experience with BEM methods in hydrodynamics. To be honest, I was surprised that single/double precision had such an influence in the results when the solver is based on potential flow and we are calculating fluid loads (at least from my experience in hydrodynamics). Your explanation makes sense for me, now everything is clear. So, if you want we can close the issue as there is no problem with OpenFAST.

Many Thanks

Best Regards,

Sergio

[Rajainb]

Hi everyone, Can anyone of you help me to find the right link to download ifort (IFORT) 2021.8.0 20221119 for windows 11. Thanks in advance.