You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# TODO: caution, if collaborative environments, will this mean everyone uses the same credentials file?
60
-
# TODO: need to think about how to deal with this for when using collaborative environments AND streaming data via copernicusmarine
59
+
# TODO: caution, if collaborative environments (or the same machine), this will mean that multiple users share the same copernicusmarine credentials file
60
+
# TODO: deal with this for if/when using collaborative environments (same machine) and streaming data from Copernicus Marine Service?
#! TODO: move this to before the loop; determine problem selection based on instruments_in_expedition to ensure only relevant problems are selected; and then instrument problems are propagated to within the loop
148
-
# TODO: instrument-specific problems at different waypoints are where see if can get time savings by not re-simulating everything from scratch... but if it's too complex than just leave for now
149
-
# propagate problems
145
+
#! TODO: need logic for skipping simulation of instruments which have already been simulated successfully in a previous run of the expedition
146
+
#! TODO: and new logic for not overwriting existing zarr files if they already exist from a previous successful simulation of that instrument
"pre_departure": "Hang on! There could be a pre-departure problem in-port...",
38
37
"during_expedition": "Oh no, a problem has occurred during the expedition, at waypoint {waypoint_i}...!",
39
38
"simulation_paused": "Please update your schedule (`virtualship plan` or directly in {expedition_yaml}) to account for the delay at waypoint {waypoint_i} and continue the expedition by executing the `virtualship run` command again.\nCheckpoint has been saved to {checkpoint_path}.\n",
40
-
"problem_avoided": "Phew! You had enough contingency time scheduled to avoid delays from this problem. The expedition can carry on shortly...\n",
41
39
"pre_departure_delay": "This problem will cause a delay of {delay_duration} hours to the whole expedition schedule. Please account for this for all waypoints in your schedule (`virtualship plan` or directly in {expedition_yaml}), then continue the expedition by executing the `virtualship run` command again.\n",
40
+
"problem_avoided": "Phew! You had enough contingency time scheduled to avoid delays from this problem. The expedition can carry on shortly...\n",
Execute the selected problems, returning messaging and delay times.
77
71
78
-
N.B. the problem_waypoint_i is different to the failed_waypoint_i defined in the Checkpoint class; the failed_waypoint_i is the waypoint index after the problem_waypoint_i where the problem occurred, as this is when scheduling issues would be encountered.
72
+
N.B. a problem_waypoint_i is different to a failed_waypoint_i defined in the Checkpoint class; failed_waypoint_i is the waypoint index after the problem_waypoint_i where the problem occurred, as this is when scheduling issues would be encountered.
79
73
"""
80
-
# TODO: integration with which zarr files have been written so far?
81
-
# TODO: logic to determine whether user has made the necessary changes to the schedule to account for the problem's delay_duration when next running the simulation... (does this come in here or _run?)
82
-
# TODO: logic for whether the user has already scheduled in enough contingency time to account for the problem's delay_duration, and they get a well done message if so
83
-
# TODO: need logic for if the problem can reoccur or not / and or that it has already occurred and has been addressed
84
-
85
74
# TODO: re: prob levels:
86
75
# 0 = no problems
87
76
# 1 = only one problem in expedition (either pre-departure or during expedition, general or instrument) [and set this to DEFAULT prob level]
88
77
# 2 = multiple problems can occur (general and instrument), but only one pre-departure problem allowed
89
78
90
-
# TODO: what to do about fact that students can avoid all problems by just scheduling in enough contingency time??
91
-
# this should probably be a learning point though, so maybe it's fine...
92
-
#! though could then ensure that if they pass because of contingency time, they definitely get a pre-depature problem...?
93
-
# this would all probably have to be a bit asynchronous, which might make things more complicated...
94
-
95
-
#! TODO: logic as well for case where problem can reoccur but it can only reoccur at a waypoint different to the one it has already occurred at
96
-
97
79
# TODO: N.B. there is not logic currently controlling how many problems can occur in total during an expedition; at the moment it can happen every time the expedition is run if it's a different waypoint / problem combination
98
80
99
-
general_problems=problems["general"]
100
-
instrument_problems=problems["instrument"]
81
+
#! TODO: what happens if students decide to re-run the expedition multiple times with slightly changed set-ups to try to e.g. get more measurements? Maybe it should be that problems are ignored if the exact expedition.yaml has been run before, and if there's any changes to the expedition.yaml
82
+
# TODO: for this reason, `problems_encountered` dir should be housed in `results` dir along with a cache of the expedition.yaml used for that run...
83
+
# TODO: and the results dir given a unique name which can be used to check against when re-running the expedition?
Calcuates probability of a general problem as function of expedition duration and prob-level.
170
-
171
-
TODO: for now, general and instrument-specific problems have the same probability of occurence. Separating this out and allowing their probabilities to be set independently may be useful in future.
"""Select which problems (selected from general or instrument problems). Higher probability (tied to expedition duration) means more problems are likely to occur."""
0 commit comments