I tend to ignore the results for tests 15-17, which are models of the SWRT, which is a furling turbine with a tail fin that is not currently supported in OpenFAST. These tests worked fine in FAST v7, but with the furling and tail-fin capability currently absent from OpenFAST, these models are ill formed. We hope to add back furling capability and tail-fin aerodynamics in a future version of OpenFAST.
I’m a bit surprised about test 9, but I’d probably have to understand what you mean by “failure”. Perhaps the time series are still quite close?
With “failure” I mean that the test is not passed because the error norm criterion in between calculated signal and reference values was not satisfied. So, with “failure” I don’t mean that the program blows up and the simulations stops.
Furthermore, I have compared time signals by plotting them and inspecting them visually. For the most of them there is no visual difference although they don’t satisfy error criterion, but for the signals from 6 to 12 it is possible to see some peaks or areas with clear differences. Some of the peaks have relative errors up to 10%.
Just to clarify, I did the comparison of my Ubuntu 18.04 GNU compiled OpenFAST and the results in the folder: “openfast\reg_tests\r-test\glue-codes\openfast\UAE_Dnwind_YRamp_WSt\linux-gnu” of the OpenFAST repository.
From my experience, the pass/fail criteria in the r-test is too strict (and dependent on compiler and platform) and cases fail even when the results are very close, certainly within engineering accuracy. Other than some of the “peaks” are you describing, this certainly seems to match what you are saying. But I’m not sure I can judge whether the “peaks” should be a concern without seeing them.
Sorry for my late answer, I have been doing some additional checks. First, I agree with you that maybe r-test faillure criteria is too strict for engineering purposes, because most of the signals fail even when the local differences are quite small. For the test case 9, I have installed a new toolchain for GCC-7.3.0 and compared the results. It seems like there is some differences in between GCC-6.3.0 and GCC-7.3.0 for the same computer and platform (I put the image on the attatchments section, “openfast_comparative.png”). Additionally to this comparison, I did a comparison for all the OpenFAST reference values (Windows/Intel, Linux/Intel, Linux/GNU) and seems that for the “accelleration” channels the differences are on the same order than the presented on “openfast_comparative.png”. So, it seems that this differences in case 9 are compiler dependent and they are not from my compilation.
On the other hand, I have done an additional test. It is a fixed wind turbine which has an initial rotational speed of 9,6 rpms and there is zero inflow wind velocity (Still condition). There is no controller. In this conditions the wind turbine should slow down its rotational speed due to air drag forces. I run this case in Windows (Github binaries) and Linux (GCC-6.3.0). When I compared the results I saw that the rotational speed and the Thrust curves has a significant difference and behaviour. I have put an attatchment (“wind_turbine_decay.png”) where I show this results. Input data are exactly the same, I copied the input folder.
Just to clarify, I do not want to find any bug in OpenFAST, it is simply that for operative reasons of the current project we are working on, we need to compare windows and linux results and we are having some differences that we need to check.
I’m a bit surprised by your rotor speed slow down test. I would not expect such differences only as a result of differing compilers or platforms. Are you sure your using the same source code in both cases?
The versions used for the comparative are taken from the “release” section in OpenFAST GitHub web page. I downloaded the assests (v2.2.0): “windows_openfast_binaries.zip” for Windows binaries and “Source code.zip” for the case of linux.
OK, thanks for confirming. And I’m assuming you are using the same input files with both versions? If so, please post these results, including your input files, as an issue on the OpenFAST github page: github.com/OpenFAST/openfast/issues. I think someone will need to debug why the different platforms/compilers are producing different results for this case.
Hi all,
I am a new user of OpenFAST. There were some errors when the first time I build the program. With guidance of Bonnie.Jonkman, I could reduce my errors but there are still some errors which I have attached here.
I don’t see that you included an attachment. Regardless, I would suggest posting all OpenFAST compiling-related questions on the OpenFAST issues page rather than here: github.com/OpenFAST/openfast/issues.
I was trying to recompile the FAST library and FAST_SFunc Mex file in the Linux system (CentOs 7), in order to run FAST v8-Simulink. By the way I commented out the line 173 of FAST_SFunc.c when I create the mex file following this answer S-Function Compiling.
I got both of them successfully in the bin folder: libFAST_Library_glin64.so and FAST_SFunc.mexa64. When I run the S-function in Simulink, Matlab got crashed and I received this segmentation error. I don’t know how to deal with this? Can you help me? Thank you so much!
I’m sorry, but I really have no idea about this. I suggest posting your compiling-related question in OpenFAST issues on github: github.com/OpenFAST/openfast/issues.
I have recently downloaded the latest version of OpenFAST from github.com/OpenFAST/openfast. I have made some minor modifications to the ServoDyn submodule and compiled for 32 bit application. All simulations run fine from command line with dll controller. I then compiled for 64 bit matlab release and made an SFunction for use with Simulink controller. However, when I attempt to run the generated SFunction with the newest input files it fails to run. When I revert the input files to a previous releases state that does not include my additional parameters implemented in ServoDyn and the most recent official OpenFAST parameter update, the SFuction then works. Are there any known bugs with generating an SFunction from the most recent source code update, or with generating an SFunction with custom source code modifications?
