Catch invalid schedule.yaml files

[erikvansebille]

Some students end up with a schedule.yaml file that looks like below

space_time_region:
  spatial_range:
    minimum_longitude: -5
    maximum_longitude: 5
    minimum_latitude: -5
    maximum_latitude: 5
    minimum_depth: 0
    maximum_depth: 2000
  time_range:
    start_time: 2023-01-01 00:00:00
    end_time: 2023-01-10 00:00:00
waypoints:
  - instrument:  # Should be -instrument: XBT
    - XBT
    location:
      latitude: 0.03
      longitude: 0.03
    time: 2023-01-01 03:00:00

This throws an error

  File "/Users/erik/Codes/virtualship/src/virtualship/expedition/do_expedition.py", line 37, in do_expedition
    waypoint.instrument.name
AttributeError: 'list' object has no attribute 'name'

Is there a way to validate the schedule.yaml file immediately after/when the schedule is loaded?
https://github.com/OceanParcels/virtualship/blob/e71d1d9bd33e9607b64fae9e43eedb23286be88a/src/virtualship/expedition/do_expedition.py#L33

And then catch these invalid schedules with a more informative error?

[diogomatoschaves]

@erikvansebille I would also add that, since the fetch step uses the schedule to download the relevant data based on the start and end dates of the trip, the verify_schedule function should happen as the first step of fetch, and not down the line on the run step.

[diogomatoschaves]

I also think that the user, apart from minimum_depth and maximum_depth, should not need to input any of these fields, as those values can be taken directly from the waypoints.

space_time_region:
  spatial_range:
    minimum_longitude: -5
    maximum_longitude: 5
    minimum_latitude: -5
    maximum_latitude: 5
    minimum_depth: 0
    maximum_depth: 2000
  time_range:
    start_time: 2023-01-01 00:00:00
    end_time: 2023-01-10 00:00:00

[erikvansebille]

I also think that the user, apart from minimum_depth and maximum_depth, should not need to input any of these fields, as those values can be taken directly from the waypoints.

space_time_region:
spatial_range:
minimum_longitude: -5
maximum_longitude: 5
minimum_latitude: -5
maximum_latitude: 5
minimum_depth: 0
maximum_depth: 2000
time_range:
start_time: 2023-01-01 00:00:00
end_time: 2023-01-10 00:00:00

Well, the minimum and maximum may need some reconsideration anyways, as they should(?) also take into account the advection of drifters and Argo floats. We now hardcode an extra halo for these advected instruments, but that might need to be implemented more smartly?

[ammedd]

@iuryt gave this some thought in #111 e.g. with

 # Define maximum depth and buffer for each instrument
    instrument_properties = {
        "CTD": {"depth": 5000, "buffer": 1},
        "DRIFTER": {"depth": 1, "buffer": 5},
        "ARGO_FLOAT": {"depth": 2000, "buffer": 5},
    }

Good to implement that now?