Adding problems during expedition

[ammedd]

I'd love to add some authenticity by adding some problems, e.g. instrument failures.

A list of potential problems (that are not too weather related) and easy to implement (i.e. they only cause a time delay):

• The CTD cable got jammed during readying for deployment and needs to be replaced. You are delayed by 3 hours.
• The temperature sensor in the CTD is malfunctioning. You can attach an extra one, but you will be delayed by 2 hours. (optional: you need to do a calibration cast at a depth of at least 1000 m before you can continue.)
• (In de tropics) There is a venomous centipede onboard. One person got sick and you are delayed by 2 hours because of a search action for it.
• The drifter/argo float won’t turn on… (You’ll have to use a spare one or skip one of the deployment locations). You are delayed by 1 hour.
• There turns out to be a miscommunication with the captain. They have to do a safety drill and lower the emergency vessel while stationary. You have to stay in position for 2 hours.
• The ADCP is malfunctioning. The cable might have gotten damaged during maintenance yesterday. You'll have to stop the ship for someone to crawl into the cable space and check on it. You have to stay in position for 1 hour.

I had a quick brainstorm about it with @VeckoTheGecko last week that he might be able to share some notes from on how to implement.

[ammedd]

• Misschien een Marine Mammal Observation erbij betrekken? Dat de dolfijnen/walvissen het wel heel interessant allemaal vinden zodat de MMO steeds weer niet slaagt, en sommige dingen dus vertraging oplopen.
• Er is niet goed gecommuniceerd tijdens de science meeting met de kapitein en de rest van de crew in de ochtend. En er is een belangrijke oefening (zoals een safetydrill), waardoor de crew 2 uur niet beschikbaar is om (bijvoorbeeld) de ctd te bedienen.
• Misschien dat je na de calibratie van de salinity bottles erachter komt dat de afgelopen 5 CTD stations mislukt zijn. Ga je die gaten in het transect zo laten of ga je terug om hem op te vullen?

[ammedd]

From Shaivans notes in discussions:
Adding problems
• wave, and wind data (instrument issues) (life on vessel issues) (weather related)
• instrument issues
• scheduling problems (+/delays)
have to update schedule (modify based on schedule checker)
checkpoints to allow simulation to leave and return (and then continue)
Register problems
• average occurence (frequency based)
• random number generator
• buffer between encountering problems
• option to add problems and remove all problems (without added problems)
• adding a seed to encouter the same issue if user restarts/re-runs
• create a hash based on (initial) location and time

[VeckoTheGecko]

Re. the generating of the problems:

We should make sure that we correctly seed the random number generator so that the same problems are encountered so that when they re-run the simulation (with their "fixes").

To find out this seed, we can generate a hash based on the parts of the config that are expected to remain the same for the expedition (the parts of the config these are are still TBD) . Once we have the hash, this can be broken down to a seed for pythons or numpys random module

Note: To some extent students will be able to look at the seeding algorithm and reverse engineer it (e.g., generate a new set of problems until they encounter an easy set - and then run with that expedition). This is unavoidable since this code is open source, and I don't think we should spend effort obfuscating the code to hide our seeding behaviour.

[j-atkins]

Some thoughts @ammedd and I discussed offline:

• Post verification of schedule in _run.py:
  • There will be a problem in the expedition, and the problem is tied to an instrument type
  • assume it's assigned to be a problem at waypoint e.g. 4 (can get more creative with this later; and e.g. some that are only before waypoint 1, delays with food, fuel)
  • extract from schedule, way the minimum amount of time required to get to the next waypoint (based on speed and distance)
  • compare to the extracted value of what the user has scheduled,
    • if they have not scheduled enough time for the time associated with the specific problem, then we have a problem
    • if they have scheduled enough time then can continue and give a message that there was a problem but they had enough time scheduled to deal with it - well done etc.
  • return to virtualship plan [with adequate messaging to say waypoint N AND BEYOND need updating to account for x hour/days delay]
    for user to update schedule (or directly in YAML)
  • once updated, run virtualship run again, will check from the checkpoint and check that the new schedule is suitable (do checkpoint.verify methods need updating?)
  • if not suitable, return to virtualship plan again etc.
  • Also give error + messaging if the user has made changes to waypoints PREVIOUS to the problem waypoint
  • proceed with run etc

---

• Also incorporate ability to turn on and off problems
  • Potentially by setting a problem_level (--problev) flag, where e.g. 3 = always encounter at least one problem, 2 = encounter 80% of the time, 1 = 30% of the time, 0 = no problems
  • can be more creative with this

---

New branch problems currently has pseudo code for first thoughts on where the logic can live

[ammedd]

Some extra ones:

• The food delivery that was planned before departure hasn't happened yet. You'll have to wait for the delivery, unloading and packing of the food. You are delayed for 5 hours.
• The fuel tanker that was supposed to deliver the fuel to your ship hasn't come yet and port is unclear in their communication of when it might happen. You are given the option to wait for delivery here or arrange a harbor pilot to guide you to the dock to bunker the fuel there. [w]ait/[g]et it. After few hours give the choice again etc?
• One of the engines overheated. The ship speed will need to be reduced to prevent it from happening again until it can be inspected and repaired in port. Your ship speed is reduced to 8.5 kts.
• The drifter/argo float you are planning to deploy hasn't connected to satellite yet. You'll have to move it to a location higher on the ship with less interference and wait for the signal to come through. You are delayed by 2 hours.

[j-atkins]

Hi @ammedd and @erikvansebille, maybe you can think along with me on the following topic as I work on the problems module...

We discussed previously that in teaching the students should definitely encounter one problem. However, it is possible* that problems can be encountered but no re-scheduling required if i) enough contingency time is planned between waypoints in the original schedule and ii) the problem encountered is not a pre-departure problem (where the contingency time cannot mitigate delays associated with the problem).

There are a couple of ways to address this I've thought of so far...

1. Simply accept that the user has planned enough contingency time and 'reward' them for this. The log would explain that problems were encountered but did not end up making a material difference because of the contingency. For the DyOc rubric at least we then make clear that in the presentations they need to explain that they encountered problems but had planned enough time within the allocated ship time.
2. Logic is included whereby if no problems are avoided by contingency time then a pre-departure is forced instead. This slightly complicates the chronology of the way problems are propagated through the simulations but I suspect would be doable without being too messy...

Can you think of any alternative approaches which might be more suitable?

---

*albeit probably rare given we will limit the available ship time

[ammedd]

From the meeting I gathered that we would go for 1. But if you feel other approaches are more suitable, please go ahead.

[erikvansebille]

I agree, let's stick with 1 for simplicity. But indeed make sure students realise they did "encounter' a problem (albeit non-impactful), so that they can mention it in the presentation (for the rubric)