FF: Fix some issues with TurbSim-drive FF case setup

[rthedin]

High-res box needs to be centered around the turbine for TS-driven cases. There was an additional logic moving it to be aligned with the low-res, which is only applicable to LES-driven cases. Thanks to @ptrbortolotti for finding this.

[rthedin]

Suppose we're aiming for 900s of simulated time at 4s low-res temporal resolution and 0.25s high-res temporal resolution. For a certain case, running the low-res with AnalysisTime 900 and TimeStep 4 results in a time-series from time 0 to 908. We can extract the hub-height time-series for the interval [0, 900] and feed that into a constrained TurbSim run with a TimeStep 0.25. The resulting bts spans time [0, 899.75]. Then, if we run FAST.Farm from 0 to 900 s, the high-resolution boxes would not cover the entire simulation time.

Alternatively, if we were to extract the time series spanning [0, 900.25] and set analogous AnalysisTime of 900.25, for some reason TurbSim results are of a flowfield with 899.75 s of total time.

It seems like it will generate solution up to the desired tmax of 900s if we use the time-series of the desired tmax plus one low-res time-step. If, for the high-res, we request AnalysisTime 904 with TimeStep 0.25, the solution obtained will span [0, 902.25]. It is unclear to me how to know ahead of time the exact length of the TurbSim execution.

Having said that, the lines below suggest changing the tmax value (which would then be passed to TurbSim's AnalysisTime for the low-res):

openfast_toolbox/openfast_toolbox/fastfarm/FASTFarmCaseCreation.py

Lines 1668 to 1672 in e0e35a7

	# Ensure that dt low is a multiple of dt high and that tmax is a multiple of both dt low and dt high, and that tmax is larger than tmax_desired
	currentTS.dt = getMultipleOf(currentTS.dt, multipleof=self.dt_high)
	self.tmax = getMultipleOf(self.tmax_desired, multipleof=currentTS.dt)
	if self.tmax < self.tmax_desired:
	self.tmax += currentTS.dt

If the user passes the temporal resolutions, the dt_low and dt_high are already multiples as per this check (let's get back to the possiblity of the user letting the code auto-determine the resolution requirements in a bit)

openfast_toolbox/openfast_toolbox/fastfarm/FASTFarmCaseCreation.py

Lines 517 to 518 in e0e35a7

	if self.dt_low%(self.dt_high-1e-15) > 1e-12:
	raise ValueError(f'The temporal resolution dT_Low should be a multiple of dT_High')

I suggest the following (@ptrbortolotti chime in):

1. take the requested tmax from the inputs as the final FAST.Farm simulation time. That will mean the turbsim files will be slightly longer than that.
2. Create the low-res with an end time of tmax+ds_low. This is what the bit of code above is doing, just in a more convoluted way
3. The high-res AnalysisTime is based on the actual length of the low-res execution- whatever that might be.

Note: This issue has been previously reported by @lucas-carmo in OpenFAST/python-toolbox#67 (comment)

[rthedin]

todo:

• expand on the examples; split between LES and TS. 710b406

[andrew-platt]

In TurbSim, if you set the UsableTime to ALL, it will be marked as a periodic wind file. When the end of the file time series is hit, it will wrap around and use the beginning of the time series (it is a periodic boundary condition with continuity at the start and end times).

[rthedin]

Andy - UsableTime is always set to ALL in my inputs.