Realistic time for instrument deployment

[ammedd]

Update https://virtualship.readthedocs.io/en/latest/user-guide/assignments/Research_proposal_intro.html
and the code with deployment times for different instruments.

CTD
Add time to lower the vessels speed to zero and set the vessel to the appropriate direction against swell, current, wind, etc = 15 minutes
Add time to deploy the CTD, and to recover = 10 minutes (2*5 min)
Add time for the way down and up, usually at 1 m/s (winch capacity) = twice your maximum depth (in seconds)
Add time to speed up again and set course to the next station = 10 minutes

Drifters and argo floats
It takes about 20 minutes to slow down and speed up the ship before and after the deployment. You may assume that any configurations that need to be made can be done while traveling to the next station.

[j-atkins]

I see two options for adding this e.g. in the CTD case, at two levels of complexity:

1. Simply update the default stationkeeping_time in the CTDConfig model (in expedition.py) from the current 20 minutes to 35 minutes, i.e. stationkeeping_time = 15 (slow and turn ship) + 10 (deploy/recover) + 10 (speed up ship) = 35 minutes. And then in schedule_simulate.py also add on the depth-dependent down/up time, at which point (i.e. at the run stage) it is possible to access the depth at the waypoint location (this is currently not possible currently in the init andplan stages when bathymetry not yet defined).

2. Add new fields to the CTDConfig model, e.g. slow_ship_and_turn_time, deploy_and_recover_time and speed_up_ship_time, which are summed to give the total stationkeeping_time. And then, once again, the depth-dependent down/up time is added in schedule_simulate.py.

Option 2 has the advantage of making more aspects configurable but also requires more changes elsewhere in the codebase (e.g. in the plan tool), so would just take slightly longer.

I feel we shouldn't rush changes in too many places in the codebase in one go. Given the short turnaround time for use in the course tomorrow, shall we go for option 1 for now, and re-visit in a future PR to give more fine control on the config? @ammedd

[j-atkins]

Update: the depth-dependent time for raising and lowering the CTD is actually a bit more involved than I thought. This is because simulate_schedule is executed at the higher _run level across all, whereas the bathymetry for e.g. the CTD is handled within the lower level CTDInstrument subclass simulation/execution, meaning it is not a simple case of feeding the bathymetry downstream into the simulate_schedule.

We could skip adding this logic for now, and just use the stationkeeping_time to add time on in schedule_simulate (as it currently does). Another option could be to base the depth-dependent time addition on the max_depth parameter of the CTDConfig. This would result in a very conservative estimate of the total time associated with raising and lowering the CTDs across the whole expedition but is a quicker way of incorporating some element of depth dependence.

Do you have a preference @ammedd?

In any case we should revisit this in the future and think of a better way to structure how simulate_schedule interacts with the Instruments - this could probably fall under the remit of #236

[ammedd]

Happy to think along when we get to #236. From the first comment I prefer option 1 as I don't think adding parameters is useful.

[j-atkins]

MFP now has an "Export Cruise Data" option which contains depth information for each waypoint, making this enhancement much simpler to implement.