# Issues with pressure data: "missing" data and multiple profiles

**URL:** <https://discourse.oceanobservatories.org/t/issues-with-pressure-data-missing-data-and-multiple-profiles/1043>\
**Category:** HelpDesk\
**Created:** [September 14, 2026, 7:32pm UTC](https://discourse.oceanobservatories.org/t/issues-with-pressure-data-missing-data-and-multiple-profiles/1043 "2026-09-14T19:32:17Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![fogaren](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.oceanobservatories.org/fogaren/32/55_2.png) [@fogaren](https://discourse.oceanobservatories.org/u/fogaren)\
**Post date:** [September 14, 2026, 7:32pm UTC](https://discourse.oceanobservatories.org/t/issues-with-pressure-data-missing-data-and-multiple-profiles/1043/1 "2026-09-14T19:32:18Z")

</div>

Hi @cdobson and team,

I am working with the GI array glider data from 2022-2025 (2022: GI 525 and 538, 2023: GI 486 and 898, 2024: GI 538 and 566, 2025: 486 and 515) that I pulled from the glider DAC. I’ve noticed some interesting “quirks” in the data. I am new to using the glider data from the glider DAC so I apologize if I am making an obvious mistake here.

1. Missing Data: Most (all?) gliders have temperature and oxygen values that alternate in depth space with NaNs. However, I’ve noticed that a lot of the pressure values also have alternating NaN values which results in data to appear missing when plotted in depth space and I don’t think that is the intention. I’ve included an example showing pressure in column 1, temp in column 2, and oxygen in column 3. I’ve also included how data appears missing when plotted in depth space with the plot included in Issue 2.

Column 1: pressure, Column 2: temp, Column 3: oxygen

 ![image](https://canada1.discourse-cdn.com/flex036/uploads/ooidata/original/1X/eec885c535fca7c63cd5e9058b80d4ee509d6de7.png)

1. Multiple profiles in a profile column. For some gliders the pressure values for a profile increase from shallow to deeper and then start over from shallow to deeper again suggesting that multiple glider dives are stored in a data column which is sorted by profile id. Also, the alternating pressure field of NaN makes it appear as though this profile is missing oxygen data when the oxygen data is paired with depth values of NaN.

 ![multiple1](https://canada1.discourse-cdn.com/flex036/uploads/ooidata/original/1X/41d762ee258ab6e5270fc598cbdf869a1250b105.png)

 ![multiple2](https://canada1.discourse-cdn.com/flex036/uploads/ooidata/original/1X/06f5b566fa158492703e860eefa18f3521712788.png)

1. First data point of profile bad: Is this something that is typical?

Thanks for your help in figuring this out!

Kristen

---

<div class="post-metadata">

**Author:** ![cdobson](https://avatars.discourse-cdn.com/v4/letter/c/da6949/32.png) [@cdobson](https://discourse.oceanobservatories.org/u/cdobson)\
**Post date:** [September 14, 2026, 8:23pm UTC](https://discourse.oceanobservatories.org/t/issues-with-pressure-data-missing-data-and-multiple-profiles/1043/2 "2026-09-14T20:23:15Z")

</div>

Hi @fogaren ,

Question #1: That quirk is normal when working with glider data. Due to the precision of the science computer and the sampling frequencies of the instruments, we often end up with slight temporal offsets between measurements. We typically recommend that users use interpolation for time and depth values where possible to line up the measurements. This is typically more of an issue with telemetered data and less of an issue with recovered (full-resolution) data. Are you working with recovered data when available?

Question #2: Periodically we may deviate from the core sampling plan for various reasons and sample both downcasts of a mission segment. Even so, I’d still expect each downcast to be indexed as its own separate profile. It’s possible that the algorithm used to split up and index the profiles may have had a hiccup, but I am not positive. I’m going to dig into this one a bit and get back to you.

Question #3: Yes, sometimes the first data point of a profile can be bad/suspect. As the glider begins sampling while still leaving the surface on a dive, it’s possible for an instrument to briefly hold onto a stale measurement or show artifacts carried over from the previous dive.

Lastly, I see you are using data from the gi\_486-20250720 deployment in your analysis. Not sure if you saw it yet, but I did just process and submit the recovered (full resolution) data for that deployment a few days ago: [ERDDAP - gi\_486-20250720T2044-delayed - Data Access Form](https://gliders.ioos.us/erddap/tabledap/gi_486-20250720T2044-delayed.html)

Thank you for reaching out! I will follow up again once I look into question #2 more.

Collin

---

<div class="post-metadata">

**Author:** ![fogaren](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.oceanobservatories.org/fogaren/32/55_2.png) [@fogaren](https://discourse.oceanobservatories.org/u/fogaren)\
**Post date:** [September 14, 2026, 9:21pm UTC](https://discourse.oceanobservatories.org/t/issues-with-pressure-data-missing-data-and-multiple-profiles/1043/3 "2026-09-14T21:21:34Z")

</div>

@cdobson Thanks for the quick response! I have been downloading the files from the THREDDS server on the gilder DAC here: [TDS Catalog](https://gliders.ioos.us/thredds/catalog/deployments/OOI-CGSN/catalog.html)

 ![image](https://canada1.discourse-cdn.com/flex036/uploads/ooidata/original/1X/3ae14e14a7d5fbf03e45e7486c30720f776759d7.png)

About half the files are delayed mode. I assumed the other gliders were not delayed because they were not recovered. Should I be getting the data a different way? There should be no difference between the files on the THREDDS server and the ERDDAP server correct? I’ll check out the updated file for gi\_486, thanks!

---

<div class="post-metadata">

**Author:** ![fogaren](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.oceanobservatories.org/fogaren/32/55_2.png) [@fogaren](https://discourse.oceanobservatories.org/u/fogaren)\
**Post date:** [September 14, 2026, 9:37pm UTC](https://discourse.oceanobservatories.org/t/issues-with-pressure-data-missing-data-and-multiple-profiles/1043/4 "2026-09-14T21:37:07Z")

</div>

@cdobson I checked out the file you linked and it isn’t indexed in 2D arrays by profile number? Is this the final formatted version?

---

<div class="post-metadata">

**Author:** ![cdobson](https://avatars.discourse-cdn.com/v4/letter/c/da6949/32.png) [@cdobson](https://discourse.oceanobservatories.org/u/cdobson)\
**Post date:** [September 15, 2026, 6:55pm UTC](https://discourse.oceanobservatories.org/t/issues-with-pressure-data-missing-data-and-multiple-profiles/1043/5 "2026-09-15T18:55:41Z")

</div>

Hi @fogaren using the THREDDs server is a good way to access the data. I agree that there should be no difference between those files and the ERDDAP server.

For the gi\_486-20250720T2044-delayed dataset that I linked, the profile\_id values are different due to an update in the code that we use to process these profiles before submitting them to the GDAC. This code is written and maintained by Stuart Pearce at Oregon State University and can be found here [https://github.com/s-pearce/gliderdac](https://github.com/s-pearce/gliderdac) . Prior to processing that 486 recovered dataset, I updated our code to the latest version published by Stuart. This version includes a change to the way profile\_id is handled. Instead of profile\_id being an integer that increments for each profile, the id is now a value that corresponds to the mean timestamp (in epoch seconds) from a given profile. It is still a unique value that indexes the dataset by time, but may require an extra step or two in your processing. Sorry about that confusion. I have attached a Python snippet here that is an example of how you could convert the timestamp back to an incrementing integer, if you’d like to do so.

Thank you,

Collin

```python
import netCDF4
import numpy as np

path = "gi_486-20250720T2044-delayed_6c70_3a60_e126.nc"
nc = netCDF4.Dataset(path, "r+")
profiles = nc.variables["profile_id"]

pid = profiles[:]
mask = np.ma.getmaskarray(pid)
vals = np.ma.filled(pid, -999)

valid_idx = np.flatnonzero(~mask)
v = vals[valid_idx]

# A new profile starts wherever the value changes from the row before it
# This reproduces "1, 2, 3, ..." exactly as long as each profile
# occupies a contiguous block of rows.
change_mask = np.empty(len(v), dtype=bool)
change_mask[0] = True
change_mask[1:] = v[1:] != v[:-1]

new_ids = np.cumsum(change_mask).astype(np.int32)

out = np.full(vals.shape, -999, dtype=np.int32)
out[valid_idx] = new_ids

profiles[:] = out

nc.close()

```

---

<div class="post-metadata">

**Author:** ![fogaren](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.oceanobservatories.org/fogaren/32/55_2.png) [@fogaren](https://discourse.oceanobservatories.org/u/fogaren)\
**Post date:** [September 23, 2026, 3:54pm UTC](https://discourse.oceanobservatories.org/t/issues-with-pressure-data-missing-data-and-multiple-profiles/1043/6 "2026-09-23T15:54:17Z")

</div>

@cdobson and team,

Any update on Issue #2? Thanks!

---

<div class="post-metadata">

**Author:** ![cdobson](https://avatars.discourse-cdn.com/v4/letter/c/da6949/32.png) [@cdobson](https://discourse.oceanobservatories.org/u/cdobson)\
**Post date:** [September 23, 2026, 4:58pm UTC](https://discourse.oceanobservatories.org/t/issues-with-pressure-data-missing-data-and-multiple-profiles/1043/7 "2026-09-23T16:58:24Z")

</div>

Hi @fogaren I was able to dig into this a bit and I can replicate what you are seeing but I do not have a cause or fix yet.

For gi\_486-20250720T2044, I took a look at profile\_id == 110 and see data from two profiles, separated by two months (2025-08-26 and 2025-10-25). In fact, I see about 177 profile IDs in total that have similar large gaps between profile times. This is definitely not expected behavior.

For what it’s worth, I re-ran the same analysis on the recovered dataset (gi\_486-20250720T2044-delayed) and didn’t see this behavior for any profile\_ids. The nature of this profile\_id mismatch could stem from the fact that telemetered data files often arrive out of order due to dropped Iridium calls, and the nature of backfilling missing data when a glider is deployed. This potential out-of-sequence issue with profile\_ids is why Stuart swapped the profile\_id assignment to timestamps. I don’t think backfilling missing data could cause profile\_ids to be this out of whack, but I don’t have any other theories yet.

I need to look into the processing code a bit to determine the source of the bug, but for now I would recommend relying on the profile\_id variable to subset the dataset by time. Did you see this behavior in any other datasets?

Thanks,

Collin

---

<div class="post-metadata">

**Author:** ![fogaren](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.oceanobservatories.org/fogaren/32/55_2.png) [@fogaren](https://discourse.oceanobservatories.org/u/fogaren)\
**Post date:** [September 23, 2026, 8:03pm UTC](https://discourse.oceanobservatories.org/t/issues-with-pressure-data-missing-data-and-multiple-profiles/1043/8 "2026-09-23T20:03:34Z")

</div>

It looks like there are problems with both delayed and non delayed although all the non delayed files had issues and only one of the delayed files had an issue.

 ![datetime_vs_profid](https://canada1.discourse-cdn.com/flex036/uploads/ooidata/original/1X/a9b5e1aee53f91904c138e6364a2b42d1169e9a9.png)

Files with issue:  
gi\_486-20250720T2044  
gi\_515-20250720T1957  
gi\_525-20220628T1658  
gi\_538-20220628T1727-delayed  
gi\_898-20230830T1500