In writing the last post, two floats were identified (coriolis/6902966 and coriolis/6902957) that do an almost perfect loop-the-loop off the coast of Brazil!
library(argoFloats)
full_index <- getIndex()
float1 <- subset(full_index, ID = 6902966)
float2 <- subset(full_index, ID = 6902957)
plot(merge(float1, float2))
lines(float1@data$index[c("longitude", "latitude")])
lines(float2@data$index[c("longitude", "latitude")])
The first question we might want to ask is why!?. Eddies are common in ocean currents but it seems like an awfully big coincidence that these two floats did the exact same loop-the-loop if they weren’t in the same eddy at the same time. Using argodata, we can investigate some of the details. I’ll also use the tidyverse for plotting and data frame manipulation.
The first question we might want to ask is: were these floats in the same place at the same time? We can plot the dates to see if they are at least cycling at the same time:
prof <- argo_global_prof() %>%
argo_filter_float(c(6902966, 6902957)) %>%
argo_extract_path_info()
ggplot(prof, aes(date, file_float)) +
geom_point()
It looks like they are! Using gganimate, we can do a quick visual check if they also align in space.
ggplot(prof, aes(longitude, latitude, group = file_float)) +
geom_path() +
geom_point() +
gganimate::transition_reveal(date) +
labs(title = "{ frame_along }")
It looks like they were released at the same time right next to each other, which explains why they tracked so closely (and why they get farther apart as they move west).
Another curiosity is the distance between profiles, which changes a few times over the course of the float’s lifetime. We could just measure the time between profiles, but to see what the float intended to do we can also check the configuration parameters. In argodata these are available via argo_meta_config_param():
meta <- argo_global_meta() %>%
argo_filter_float(c(6902966, 6902957))
meta %>%
argo_meta_config_param() %>%
argo_extract_path_info() %>%
select(file_float, n_missions, config_parameter_name, config_parameter_value) %>%
pivot_wider(names_from = n_missions, values_from = config_parameter_value) %>%
knitr::kable()
| file_float | config_parameter_name | 1 | 2 | 3 | 4 | 5 | 6 |
|---|---|---|---|---|---|---|---|
| 6902957 | CONFIG_CycleTime_hours | 26.5 | 24 | 240 | 24 | NA | NA |
| 6902957 | CONFIG_ParkPressure_dbar | 200.0 | 200 | 1000 | 1000 | NA | NA |
| 6902957 | CONFIG_ProfilePressure_dbar | 1000.0 | 1000 | 2000 | 2000 | NA | NA |
| 6902957 | CONFIG_DescentToParkPresSamplingTime_seconds | 10.0 | 0 | 0 | 0 | NA | NA |
| 6902957 | CONFIG_Direction_NUMBER | 3.0 | 1 | 1 | 1 | NA | NA |
| 6902966 | CONFIG_CycleTime_hours | 38.5 | 24 | 240 | 24 | 48 | 120 |
| 6902966 | CONFIG_ParkPressure_dbar | 200.0 | 200 | 1000 | 100 | 1000 | 1000 |
| 6902966 | CONFIG_ProfilePressure_dbar | 1000.0 | 1000 | 2000 | 100 | 1000 | 1000 |
| 6902966 | CONFIG_SurfaceTime_HH | 15.0 | 15 | 15 | 15 | 15 | 7 |
| 6902966 | CONFIG_DescentToParkPresSamplingTime_seconds | 10.0 | 0 | 0 | 0 | 0 | 0 |
| 6902966 | CONFIG_InAirMeasurementPeriodicity_NUMBER | 5.0 | 5 | 5 | 5 | 5 | 2 |
| 6902966 | CONFIG_Direction_NUMBER | 3.0 | 1 | 1 | 1 | 1 | 1 |
It looks like these floats were set to sample rapidly (every 24 hours) and changed a few times over the course of the float lifespan. This explains the loop-the-loop more convincingly as an eddy as the usual float cycling time of 10 days would mean it was a very slow eddy (credit to Clark Richards for that observation!).