[ ] Replace manual specification of rotor speed and blade pitch in bins from _setRotorParameters
[ ] Add support for MoorDyn template/input file
[ ] 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.
[ ] 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
[ ] 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.
[ ] Pass all the template files in a dictionary instead of all of them individually like here.
[ ] Add ability to generated placement of high-res boxes related to rotated farms on the AMR-Wind class
[ ] Make the class independent of the OpenFAST version of the input files by never completely re-writing any file, but rather modifying specific lines
Long term to-do, will-not-be-fixed-soon:
[ ] Switch to support the unique modeling guidance between Mod_AmbWind = 2 (one InflowWind instance) and 3 (multiple instances of InflowWind)
[ ] 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)
[ ] If there is enough user base, we could create regular batch scripts in addition to the SLURM ones
[ ] 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)
[ ] Lucas: 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.
[x] ~bugfix: give the spatial resolution input to TSCaseCreation for the high-res boxes~
Will not fix. 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.
Desired fixes, including prior list discussed in https://github.com/OpenFAST/python-toolbox/discussions/67
binsfrom_setRotorParametersLESpathand add a way to specify what type of inflow will be executed (see here). We could potentially create an inflowType with options beingLES,TS, orMann.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.roundfunction to offset parameters, like here and hereCompSubon turbine models)Mod_Wake, the code will break when it tries to modify it. Needs a check ahead of timeLong term to-do, will-not-be-fixed-soon:
Mod_AmbWind= 2 (one InflowWind instance) and 3 (multiple instances of InflowWind)Unlikely to be done, unless users submit PRs
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 matchesAnalysisTime. 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 theAnalysisTimespecified to the high-res.inpto 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.Completed
nSeeds!=6nSeedsto the example input. People seem to not be checking all the inputs toFFCaseCreationpartitionoption to*slurm_submitmethodsTSCaseCreationfor the high-res boxes~TSCaseCreationclass 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 variableds_high_leswithin 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 theds_high_lesvariable. Note that this variable is only used for checks on LES-driven cases, to ensure specifications are consistent. The variable is never directly used.TS_high_create_symlinksomewhere inFF_setup_TSMod_Wake= 1 (polar) and 2 (curled, Cartesian) wake