Fixes to find_yo_extrema

[kwilcox]

@kerfoot can you point me to the updated find_yo_extrema method you modified?

[kerfoot]

@kwilcox: sent it to your axiom address.

[kwilcox]

You sent the gps coordinates function not find_yo_extrema!

[kerfoot]

Oops. Looks like I haven't quite gotten back mentally from the weekend. I'm putting the finishing touches on a repo that builds on the glider_utils and your GUTILS package to write NetCDF files from raw glider data files (or others) as both Trajectory and TrajectoryProfile DSGs:

https://github.com/kerfoot/gncutils

The yo indexing stuff can be found here:

https://github.com/kerfoot/gncutils/tree/master/gnc/yo

[kwilcox]

@kerfoot I've re-implemented the profile identification and filters in GUTILS. Can you run your process on this attached ASCII file and let me know what you get for the total number of profiles and how many NetCDF files you eventually export and would upload to the GliderDAC after the default filtering?

usf_bass_2016_253_0_6_sbd.dat.zip

[kerfoot]

@kwilcox 32 indexed profiles. the first 30 have a max depth of about 30 meters and the last 2 have a depth of about 12 meters.

[kwilcox]

Thanks! I'll have to poke around. I'm getting 15 profiles before filtering and 8 after the default filters.

[kerfoot]

@kwilcox Here's a png of the yos and the indexed profiles:

[kwilcox]

Data looks to match, ill keep looking at the yo extrema identification code.

[kwilcox]

@kerfoot OK, number of profiles look good on my end. Can you send the resulting netCDF file from the ASCII file? The few lingering questions I have are:

• Computing/creating the extra *_uv variables time_uv, lon_uv, and lat_uv. It looks like the old code was setting these to the first data index where v (m_water_vx) is not null? Should we still be doing this?
• Computing/creating the extra profile_* variables profile_time, profile_lat, and profile_lon. Seems like one of two choices. Which is correct?
  1. time, lon, lat: set to the median
  2. time: set to the minimum; lon, lat: set to the average

[kerfoot]

@kwilcox Not quite there with the NetCDF yet, but will get it to you asap.

As for the other questions:

1. Currents with the slocum glider are a bit tricky. After the glider surfaces at it's dead-reckoned position, it gets a gps fix, then calls in to shore. While it's connected via iridium, it's using the DR location and the GPS fix to calculate the error in the DR, which it assumes is due to current. The problem is that the current calculation is not typically finished by the time the user asks for the file to be sent to shore. The net effect of this is that the current measurement is almost always included in the NEXT file, which does not get transferred until the next surfacing. TWRC's detailed doco on this can be found here: https://marine.rutgers.edu/~kerfoot/slocum/data/readme/wrc_doco/water-velocity-calculation.txt. So, technically speaking, we should be using either the second non-null m_water_vx/vy or m_final_water_vx/vy.

2. profile_* variables: I don't think either of your suggestions are incorrect, but I use mean profile time, lat and lon for these values.

[kwilcox]

1. Excellent info, thanks. I'll use the second non-null value.
2. Sound good, I'll use mean as well.