📅 Development Team Meeting Summaries

[iuryt]

Welcome to the Development Team Meeting Summaries thread!

This space will serve as a centralized location for recapping our team meetings, sharing decisions made, outlining action items, and providing updates on project progress. Our goal is to make it easy for all contributors to stay informed about the latest discussions and directions, especially if you weren’t able to attend a meeting in real-time.

[iuryt]

Tuesday Nov 5 (2024)

Short term

• Educational Tutorials
• Discussions Tab
• XBT

Long term

• Project Pythia (how to add new tutorials)
• Animal Behavior

Next year

• Add Gliders
• Biogeochemical (new postdoc to the team)

How students will plan the cruise?
https://nioz.marinefacilitiesplanning.com/cruiselocationplanning#

@ammedd , want to add something?

[iuryt]

Some other ideas would be to add Saildrones, Wavegliders and Wirewalkers.

[ammedd]

While working on the educational tutorials in #87 the possible time range came up. Because it's something good to share ideas about I'll note it here.

**Cruise period** Please state the preferred year, season, and/or month(s) for the cruise, and provide reasons for restrictions to limited periods.

@erikvansebille questioned "this suggests students can plan cruises into the future (also related to lead times), but we will not have hydrodynamic data into the future. Make clear somewhere that the virtual cruises must happen between 2021(?) and 2024, so we can use CMS data?"

Next meeting coming up: December 10 2024

[ammedd]

Hi, we postponed the meeting a week, so hope to talk to you all today!

Things I would like to discuss are:

• PR Add fetch command to download expedition data based on area_of_interest from schedule.yaml #83 and other things to get to a functioning version
• Issue YAML schedule from MFP CSV #61 to be able to use https://nioz.marinefacilitiesplanning.com/cruiselocationplanning#
• Instrument noise Instrument noise #58
• Adding "problems" to actually use ScheduleProblem and ScheduleOk
• Adding weather/wave data to make the problems more realistic

A list of potential problems (that are not too weather related):

• 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.
• The ADCP sound is interfering with nearby operations. You have to turn it off until you are 50 nm away from this location.
• The pump that is needed to sample the underwater data broke down. You can either wait for 2 hours to try and get it fixed, or turn if off for the rest of the expedition. [wait | turn off]
• 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.

[ammedd]

Here are my and Shaivans notes of yesterdays meeting:

Top priority:
Fix fetch command
• define a maximum depth values for the instrument type
• add a warming if the to-be downloaded data exceeds what is needed
• buffer a small (0.1 degree?) area around the waypoints in the Schedule.yml for CTD/ADCP/XBT/Underwater simulations
• buffer a large (3 degree) area around the waypoints in Schedule.yml for Drifter/Argofloat simulations
• Allow for a day or two more time at the end of the scheduled time to allow for delay
Creat a unit test for fetch

We discussed:
How to implement different standard maximum depths for instruments to reduce the amount of data that needs to be downloaded. Probably as a dictionary that can be overwritten by users, if they want to download more layers.

Checking the download folders and configuration to ensure that the data required for the expedition is present and consistent with the instrument requirements. Therefore changing instruments will be understood as starting a new cruise.

I’ll update # with the csv output of the MFP to see how we can continue here. Probably with a init__fromMFPcsv function that reads in the waypoints and creates a Schedule.yml from this.

Things to (possibly) add in future versions:
Instrument noise (specific for each instrument)
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
o create a hash based on (initial) location and time

[VeckoTheGecko]

• buffer a small (0.1 degree?) area around the waypoints in the Schedule.yml for CTD/ADCP/XBT/Underwater simulations
• buffer a large (3 degree) area around the waypoints in Schedule.yml for Drifter/Argofloat simulations
• Allow for a day or two more time at the end of the scheduled time to allow for delay

Is this in the context of virtualship init --from-mfp-csv where the space_time_region isn't known?