Thanks a lot @Rafael.Mudafort , for the very useful information.
I already had -DBUILD_TYPE=RELEASE (as ccmake shows now) which sounds like the most suitable for me.
I’ve just read about -march and -mtune. I’m running FAST.Farm in a cluster with different nodes (with different types of Intel CPU’s). For now, all nodes are able to run FAST.Farm with similar performance. Therefore, maybe it’s the best to keep the compilation as it is now
I use FAST.Farm with Mod_AmbWind=2 option, and generate the ambient wind using Turbsim (for NREL 5 MW turbines).
As I understand, it is recommanded to use “the high-resolution discretization values” for inflow wind generation (e.g. DS_high=5 m and DT_high=0.3 s) so I set the Turbsim input file accordingly. That means, for my wind farm with 340 m GridHeight & 1000 m GridWidth, Turbsim grid is 69 x 201.
For such a grid, Turbsim generation takes quite long time. It’s been 4 days and still calculating the u-component (certainly enough RAM is available, so that’s no bottleneck; and AnalysisTime = 600 s).
Therefore, I wanted to double-check: Is there anything that I missunderstood regarding the settings ?
This is the problem with the
Mod_AmbWind = 2 option of FAST.Farm–it takes a long time to generate highly resolved synthetic wind data from TurbSim for large domains. As such, I would recommend to instead use the
Mod_AmbWind = 3 option of FAST.Farm, which requires that you run TurbSim separately for the low- and high-resolution domains. With this approach, the synthetic wind data can be generated from TurbSim much more efficiently. See the “Modeling Guidance” section of the online FAST.Farm User’s Guide and Theory Manual for more information: 220.127.116.11. Modeling Guidance — OpenFAST v3.1.0 documentation.
Thanks a lot @Jason.Jonkman. I will check about the
Mod_AmbWind = 3.
And maybe in the future, we will have a parallelized Turbsim