FAST.Farm case generation improvements

[rthedin]

I've been chatting with people offline about the scripts for FAST.Farm case generation and after PRs #64 and #66 I think it could be worthwhile start a discussion to understand the need of those using it and how to make it better. That piece of code is still very much a work in progress.

Here's a running list of bug fixes, improvements, and general ideas I compiled (in no particular order) after talking to @lucas-carmo and @MYMahfouz

• Give the ability for the user to specify the TurbSim and Mann binaries, in addition to the FAST.Farm one, here.
• Replace the specification of LESpath and add a way to specify what type of inflow will be executed (see here). We could potentially create an inflowType with options being LES, TS, or Mann.
• Conditions for floating turbines are very much hardcoded at this point, here. We can make that bins variable an input. The presence of that input can mean that this is a floating turbine case, or we can have an explicit entry floating=<bool> like suggested in the PRs linked above. The amount and input entries on the array of bins can be freely modified by the user and wouldn't be restricted to the ones in the example.
• Given that now we can know ahead of time whether the turbines are floating or not, we may want to change the default of the high-res boxes extent here. 1.2 diameters may not be enough for floating.
• dbad087 Fix hardcoded IW filename here
• Add a SLURM script for the Mann boxes, similar to what is being done here, but in a format that is more clear and less hardcoded
• Mooring systems need to be properly handled (and rotated depending on what wind conditions)
• If there is enough user base, we could create regular batch scripts in addition to the SLURM ones
• It would be great to make the examples runnable as unit tests. Right now the user needs to wait until the low-res boxes are done before moving forward with the setup (if TurbSim inflow)
• The high-resolution boxes around turbines are not centered around the turbine, but actually slightly off, so that it matches the background low-resolution grid. This might need a fix.

This is what I have on the top of my head, but I wanted to get opinions/feedback/suggestions on priority and needs before moving forward.

@jjonkman

Edit:
Adding items:

• 41d829c Remove need to specify seed value if nSeeds!=6
• 3a27861 Add specification of nSeeds to the example input. People seem to not be checking all the inputs to FFCaseCreation
• Add a round function to offset parameters, like here and here
• Add partition option to *slurm_submit methods
• Add ability to run without specifying SubDyn (change CompSub on turbine models)
• ff9584c bugfix: fix selection algorithm of unique high-res boxes here. It breaks on custom sweeps
• bugfix: give the spatial resolution input to TSCaseCreation for the high-res boxes
  • Not a bug. In the TSCaseCreation class the resolution of the high-res boxes is determined by the modeling guidelines, which is the max chord (e.g. 5 m for the IEA 15 MW). Sometimes, we may want to pass a more coarse value, but there is no need as the high-res TurbSim boxes generation is not a bottleneck ever. The variable ds_high_les within the class is not used at all when setting up TurbSim-driven cases. The grid specs written to the FAST.Farm input file are obtaining by reading outputs of TurbSim, so the grid information comes from there, not the ds_high_les variable. Note that this variable is only used for checks on LES-driven cases, to ensure specifications are consistent. The variable is never directly used.
• 6e57963 Include automatic call to TS_high_create_symlink somewhere in FF_setup_TS
• 672b73f Add a plot of the farm layout for sanity-check reasons
• From Add functionality to create AMR-Wind sampling planes for FAST.Farm #59 (comment): Create the wind direction sweep and make the refinements general, removing the 0deg hardcoded string here
• aac727c Add a check for all FAST.Farm output
• Make the extension of the controller depend on the OS (see Changes on FAST Farm case creation pull request #66 (comment))
• bugfix: if the user gives old template files without mod_wake, the code will break when it tries to modify it. Needs a check ahead of time

[jjonkman]

This is a great list! In addition, I would add:

• 4ed2a24 Switch to support the unique modeling guidance between Mod_Wake = 1 (polar) and 2 (curled, Cartesian) wake
• Switch to support the unique modeling guidance between Mod_AmbWind = 2 (one InflowWind instance) and 3 (multiple instances of InflowWind)

Thanks!

[MYMahfouz]

Thanks for opening this discussion, I will start a comment here and will keep adding to it whenever I have something:

• The time step value in the .fst file needs to be a multiple of the time step value in the .fstf file. This is currently not done properly.

[lucas-carmo]

Adding a few:

• 3a27861 The inflow files created by the scripts are always named InflowWind.dat (here), but the InflowFile parameter in the .fstf file uses the name of the template file specified by the user (here).
• I have faced some problems to compute the inflow in the high-resolution domain due to a mismatch between the total simulation time specified to TurbSim (variable AnalysisTime) and the actual total simulation time that is output by the software. It looks like TurbSim rounds up the number of time steps to speed up the calculations, so that it is not guaranteed that the resulting time series matches AnalysisTime. The problem is that the high-res inflow, which is computed based on a time series extracted from the low-resolution domain, is assuming the same AnalysisTime used for the low-res. I think we should either change the AnalysisTime specified to the high-res .inp to be the total time in the user input file OR round up the total simulation time specified in the scripts using the same procedure as TurbSim.

[ebranlard]

pyFAST has been renamed to openfast_toolbox and migrated here: https://github.com/OpenFAST/openfast_toolbox .

Please continue the discussion in this new repository. Sorry for the inconvenience.