Missing dimension for Depth Average Current (DAC)

[vturpin]

After some discussions within the working group, it appears that a dimension is missing for integrated value like depth_average_current. This issue could be discussed here now I think.

[vturpin]

Current suggestion is to add "N_SURFACING" dimension that will be usefull for DEPTH_AVERAGE_CURRENT but also for other variable like ATMOSPHERIC_PRESSURE, WIND, WAVE, etc.

[justinbuck]

Issue: Gliders can provide an estimate of depth averaged velocities. It wouldn't make sense to be a N_MEASUREMENT dimension, but one estimate per full dive. I think we are missing another type of PARAM here.

Status: Indeed, we do not have a dimension for this variable. N_DIVES may not make sense of a dimension either though, hybrid gliders with thrusters break the concept.

Depth average current is computed only between 2 GPS locations. So dimension for depth average velocity should be equal to the number of surfacing.

Proposal: Add a dimension name : N_SURFACING, definition : N_SURFACING = unlimited, comment : Number of surfacing

• Add a section "average variable" (like "geophisical variables" section) in the document to define the depth average velocity

[justinbuck]

I am reaching out to Ben Allsup to get more details on Slocum gliders to porgress this, could others get more information for other glider types,please?

• Dan Hayes (@glidermann), Seagliders?
• @castelao Spray gliders?
• Not sure who is best for sea explorers

[soerenthomsen]

@AlicePietri, @AnthonyBosse and @rtodd-WHOI are preparing an SOP for depth averaged currents and might be able to help. Or @bastienqueste

[glidermann]

Seaglider uses an axis "dive" in the mission file for DAC variables (see below). The per-dive nc files have non-dimensional variables for these (e.g. depth_avg_curr_north(dive) and depth_avg_curr_north, respectively). There are other variables using "dive" axis in the merged file: start, stop, and average time, latitude, longitude, as well as time of deepest sample, month day of dive, decimal day of dive and dive number itself which are NOT in the individual dive nc file.

dimensions: sg_data_point = 10478 ; gps_info = 87 ; dive = 29 ; trajectory = 29 ; string_12 = 12 ; string_7 = 7 ;

  char depth_avg_curr_qc(dive) ;
            depth_avg_curr_qc:flag_meanings = "QC_NO_CHANGE QC_GOOD QC_PROBABLY_GOOD QC_PROBABLY_BAD QC_BAD QC_CHANGED QC_UNSAMPLED QC_INTERPOLATED QC_MISSING" ;
            depth_avg_curr_qc:comment = "Whether to trust the dive depth-average current values and displacements" ;
            depth_avg_curr_qc:flag_values = "0 1 2 3 4 5 6 8 9" ;
    double depth_avg_curr_north(dive) ;
            depth_avg_curr_north:units = "m/s" ;
            depth_avg_curr_north:comment = "Northward component of the dive depth-average current based on hdm" ;
            depth_avg_curr_north:standard_name = "northward_sea_water_velocity" ;
    double depth_avg_curr_east(dive) ;
            depth_avg_curr_east:units = "m/s" ;
            depth_avg_curr_east:comment = "Eastward component of the dive depth-average current based on hdm" ;
            depth_avg_curr_east:standard_name = "eastward_sea_water_velocity" ;

[castelao]

It is "legal" to store GPS fix on the time series of the trajectory, but it is strange to have all those missing values.

Spray also uses a dive dimension similar to described by @glidermann . In some products, we have the nominal fix (time, lat, lon), and others we have on the top of the dive dimension, a start plus end of a dive.

[glidermann]

just to clarify @castelao that there are also latitude longitude variables along the trajectory time series (axis "sg_data_point") which are flight model estimates, linearly corrected by actual fixes, so no missing values normally. A problem I have not solved is that for subsurface finishes (no gps fix), there is no DAC (in fact that dive is not processed at all, clearly I am missing something). The dive axis just skips that value.

[castelao]

@glidermann, thanks! Yes LATITUDE vs LATITUDE_GPS. My comment on the GPS fix is that those can technically fit in the time-series, but it results in 99+% of the LATITUDE_GPS as fillvalue (while diving). So I agree with having a new dimension, whatever is the name, to cover this.

About the subsurface finishes that you mentioned, I don't know why the DAC is not processing them.

[justinbuck]

@glidermann @castelao Storing the gps fixes makes the format simpler for users and DACs, as the position information are all in the same dimension so no merging is needed fro processing. Under NetCDF 4 the fiels are not bloated by the absent values either. Under NetCDF 3 the extra dimension was a pain with the file only being able to have a single unlimited dimension so had to rewrite the entire file every time new data arrived (this is not an issue under netcdf 4 though).

[justinbuck]

I have spoken to Ben Allsup about the Slocum depth average currents. They will fit in a dimension for n_surfacing, there may be missing values is the glider fails to get a gps fix (in rough seas etc) though. I can share the information from Ben with the best practice team too.

[vturpin]

@justinbuck it seems that there is an agreement there to add an new dimension (as we also agree on NETCDF4). Could you suggest a modification in the document in that sense ?