Data FAQ

Frequently Asked Questions about Argo Data

What is the difference between an “R” and a “D” profile file?

R files contain data that have only passed automated simple QC tests in real time and so may contain temperature, pressure and/or salinity errors. Most of these errors are the result of sensor drifts. D files have passed expert QC inspection and have had sensor drifts removed. They also have statistical uncertainty assigned to each observation based on both the sensor accuracy and the correction accuracy. If your application requires very high accuracy, use the ADJUSTED fields in the D-files and read and inspect their assigned errors and qc flags.

In particular, if you are doing scientific work sensitive to small pressure biases (e.g. calculations of global ocean heat content or mixed layer depth) Argo recommends the following guidelines:

Use the quality flags in the Argo data files and data labeled with QC = 1
Only use delayed-mode data (D files)
Only use ADJUSTED data variables
PRES_ADJUSTED_ERROR should be checked and where values are greater than 20db, these data should be rejected

If your work is not sensitive to small pressure biases, it is probably acceptable to use “R” files. “R” files should be free from gross errors in position, temperature and pressure. Additionally, if there is a known offset in salinity, this is applied and appears in the PSAL_ADJUSTED variable.

How accurate is the Argo data?

The temperatures in the Argo profiles are accurate to ± 0.002°C and pressures are accurate to ± 2.4dbar. For salinity, there are two answers. The data delivered in real time are sometimes affected by sensor drift. For many floats this drift is small, and the uncorrected salinities are accurate to ± .01 psu. At a later stage, salinities are corrected by expert examination, comparing older floats with newly deployed instruments and with ship-based data. Corrections are made both for identified sensor drift and for a thermal lag error, which can result when the float ascends through a region of strong temperature gradients. See Wong, et al 2023 for further information on possible salinity bias in the dataset. *

Following this delayed-mode correction, salinity errors are usually reduced further and in most cases the data become good enough to detect subtle ocean change. The estimated accuracy of the delayed mode quality controlled salinity can be found in the PSAL_ADJUSTED_ERROR fields in the D profile files. If the salinity is found to be questionable even after delayed mode adjustment, the error and the qc flag are adjusted to higher than usual to make users aware of this. Therefore, users should use the *_ADJUSTED_ERROR and *_ADJUSTED_QC fields in the profile files to filter the data set to remove less accurate measurements.

This goes for all the parameters measured. While the temperature and pressure sensors are highly accurate, they may still have errors, leading to higher adjusted error fields and qc flags.

In general, core data that are considered bad and unadjustable are marked with a qc flag of ‘3’ or ‘4’. These bad data should not be used in any scientific applications.

BGC data in real time are often marked with a qc flag of ‘3’ indicating that the data may be adjusted at a later time. This is because the BGC sensors often return data that are out of calibration, but early adjustment methodologies exist that can significantly improve their accuracy. Additional delayed mode quality control occurs when a longer record of float data is available.

Wong, A. P. S., J. Gilson, and C. Cabanes (2023), Argo salinity: bias and uncertainty evaluation, Earth Syst. Sci. Data, 15(1), 383-393, doi: https://doi.org/10.5194/essd-15-383-2023

Is the Argo data set described in a journal paper?

Yes, a paper came out in 2020 describing the Argo data stream, its quality control procedures, problems encountered with sensors, the changing vertical resolution and spatial coverage and sensor accuracies as compared to high quality shipbased measurements. The paper is open access meaning anyone can read it. The citation and DOI are as follows:

Wong, A. P. S., S. E. Wijffels, S. C. Riser, S. Pouliquen, S. Hosoda, D. Roemmich, et al, 2020: Argo Data 1999–2019: Two Million Temperature-Salinity Profiles and Subsurface Velocity Observations From a Global Array of Profiling Floats. Frontiers in Marine Science, 7, https://doi.org/10.3389/fmars.2020.00700

What is the status of RBR 2K CTD data?

The RBR 2K CTD has been piloted in the Argo data stream starting in 2018. Over time, with improvements to the CTD and the development of agreed upon quality control methods, the latest (post April 2021) RBR 2K CTDs will now have real time QC flags of ‘1’, if they pass the real time QC tests, and the data will be distributed on the GTS.

For pre-April 2021 CTDs, if the salinity is adjusted in real time using the method in the Argo QC manual, the ‘PSAL_ADJUSTED_QC’ will be ‘1’ and ‘PSAL_QC’ will be ‘3’.

Can a float have both an “R” and a “D” trajectory file? Which should I use?

Yes, a float can have both an “R” and a “D” trajectory file with the trajectory 3.0 file format and higher. If both types of files exist, that means that only part of the float’s trajectory has been delayed mode quality controlled. A user will have to look in the “D” trajectory file for the delayed mode quality controlled cycles and then in the “R” trajectory file for the additional cycles that have not yet been looked at in delayed mode. This means that users may need to look in two trajectory files to get all of a float’s trajectory information.

For example, a float might have its first 35 cycles delayed mode quality controlled and that information is contained in the “D” traj.nc file. To get information for the next 20 cycles, one must open the “R” file and look for cycles after the first 35 that have been quality controlled.

As with profile files, if a “D” file is available, that data should be used instead of the “R” data since it has been quality controlled by an expert. If no “D” data is available, “R” data can still be used with the knowledge that only a few of the real time qc tests apply to the trajectory files.

What timing information is available in the trajectory files?

There are many points within a float’s cycle where it would be helpful to know the timing information in order to calculate velocities at depth or rates of ascent and descent, etc. The V3+ trajectory file formats allow for timing information to be associated with some critical parts of the float’s cycle, if it is available. Argo has identified a handful of critical times that all Argo floats should send back and these include times when the float leaves the surface to start its descent, when it reaches its drift depth, when it leaves drift depth, when it begins its profile, when it hits the surface and its location. The modern floats send most of this timing information back. Older floats do not, but some of the times can be estimated based on known float behavior. To learn more about how to access this cycle timing information in Argo floats, click here.

Two-way communication and the Argo dataset

The majority of floats deployed in 2017 and beyond use the two-way communication system Iridium. With two-way communication, floats will be on the surface for a much shorter amount of time (~15 minutes to 2 hours instead of 8 to 24 hours) and their position will usually be fixed by GPS. Sometimes GPS fixes are not available and other, lower quality fixes from the Iridium system are sometimes used.

Additionally,there is the possibility for the floats to send back a much larger volume of data. Therefore, profiles from Argo floats using two-way communications will likely include many more CTD measurements; the frequency of measurements might increase to every couple of decibars in some areas and parts of the profile. The other files may also include more data.

Finally, float owners may choose to send a signal to their float to change its mission due to the status of the float, an impending event like a tropical cyclone, etc. These changes in mission are recorded in the CONFIG_XXXX variables in the Metadata file.

Do all Argo floats vertically sample pressure, temperature and salinity the same way?

There are mainly two types of CTDs used on Argo floats – one that spot samples and one that continuously samples.
The spot sampled CTDs return one spot sample per bin while the continuously sampled CTDs return an average sample per bin. These two methods of sampling can influence heat content calculations and so the new V3 profile format includes a variable that describes the vertical sampling method. It is called “VERTICAL_SAMPLING_SCHEME” and is described in Reference Table 16 in the USer’s Manual on the ADMT Documentation page.

How accurate is Deep Argo data?

As part of pilot deployments, Argo profiles reaching below 2000dbar are in the Argo data system.

The accuracy of the data below 2000dbar is not yet well understood and so Argo is currently labeling these data with lower quality flags (2 or 3) in real time.

Work has been done lately to use a more accurate CPcor correction, and if applied in real time, data deeper than 2000db will be labeled with QC flags of 2. If not applied in real time, the TEMP and PRES QC flags will be 2, but the PSAL QC flag will be 3.

We warn users to treat these data with care and recognize that we cannot guarantee they have the same accuracy as Argo data collected above 2000dbar. As more is learned about sensor performance below 2000dbar, the flags and an accuracy
assessment will be updated.

Such floats can be easily identified from metadata files, using PLATFORM_FAMILY=’FLOAT_DEEP’ and PLATFORM_TYPE ( Please note that this reference table is frequently updated to include new sensor and float models. You can find the latest version at: http://tinyurl.com/nwpqvp2 ). This is also explained in the latest version of the User’s Manual found in the Documents section of the ADMT website.

Alternatly, WMO IDs of deep Argo prototypes can be found on the EuroArgo dashboard by selecting the ‘Deep’ network.

“Abrupt Salty Drift (ASD)” in SeaBird CTDs

Starting in 2015, an increased number of Sea-Bird conductivity cells used on Argo floats have drifted salty. The salty drift occurs earlier in the float lifetime than average and proceeds to become uncorrectable very quickly. The Argo community, together with SeaBird, has identified that the affected cells lie within serial number ranges of 6300 – 7100, 8100 – 8700 and 10000 – 11100.

Sea-Bird Scientific has implemented a manufacturing change to rectify this problem at the end of 2018, and has issued a recall in 2021 on one of the more recent batches of affected CTDs (https://argo.ucsd.edu/sea-bird-sbe41cp-and-sbe61-ctd-quality-concern/). Since the manufacturing change in 2018, the number of new Sea-Bird conductivity cells drifting salty within the first year after deployment has decreased, and the Argo community is cautiously optimistic that the situation is improving.

Despite the manufacturing change in 2018, the current Argo array still includes many affected Sea-Bird CTDs that were deployed prior to the manufacturing change. These potential salty drifting floats are actively monitored. Once sensor drift is detected, the salinity data from the offending floats will be flagged by the Argo QC processes in real-time, and adjusted in delayed-mode. In the Argo profile files, the raw (original) salinity values PSAL are flagged with a quality control flag of ‘3’ or ‘4’ if sensor drift is present. The delayed-mode adjusted values are recorded in PSAL_ADJUSTED. Please note that delayed-mode adjusted values may not be available until about 1 year after a profile is collected.

This FAQ is to alert Argo data users that if the affected raw salinity data are not excluded from their data analyses, then their analyses may be biased salty. See Wong, et al 2023* for detailed information on the possible salinity bias. We encourage all Argo data users and Argo data producers to frequently sync their data holdings with the Argo GDACs to obtain the most up-to-date quality control flags and salinity adjustments and errors. In particular, Argo delayed-mode adjusted values, when available, should be used in scientific analyses. For more information, please email the Argo Program Office at argo@ucsd.edu.

Examples of papers published with affected raw salinity data include:

Liu, C., Liang, X., Ponte, R. M., & Chambers, D. P. (2024). “Salty Drift” of Argo floats affects the gridded ocean salinity products. Journal of Geophysical Research: Oceans, 129, e2023JC020871. https://doi.org/10.1029/2023JC020871

*Wong, A. P. S., J. Gilson, and C. Cabanes (2023), Argo salinity: bias and uncertainty evaluation, Earth Syst. Sci. Data, 15(1), 383-393, doi: https://doi.org/10.5194/essd-15-383-2023

Garmin GPS Units on Navis and APEX floats

In August 2019, a problem with floats having a GPS unit manufactured by Garmin was discovered. This problem affects Teledyne/Webb Apex floats and SeaBird Navis floats. The problem does not affect SIO or MRV SOLO floats or floats manufactured by NKE. It is unknown how this problem affects floats produced by other manufacturers.

All Teledyne/Webb and SeaBird floats presently deployed are affected. In the worst-case scenario, the result of the problem is that these floats will be unable to obtain a GPS fix at some time in the future. It is unknown when that time might be; it could be months, years, or possibly not at all. Groups within Argo and at SeaBird are working on understanding the problem better.

It is worth noting that this bug was triggered in April of 2019 and has now been active for several months, but we know of no floats that have yet been affected. There is a straightforward fix for the Garmin bug for floats that have not yet been deployed and Argo groups with these floats are working to implement the fix prior to float deployment. Both Teledyne and SeaBird are now fixing the GPS on floats prior to delivery.

The Argo Program has been tracking these floats in the data system over time and has only affected a small number of floats. For more detailed information on the nature of the Garmin GPS bug, click here.

SBE CTD pressure calibration error

In September 2015, a firmware bug was introduced in the development of the SBE41plus sensor that extended to the SBE 41N and the SBE 61. The bug is confined to one operating command, “tpr”, which causes the CTD to output raw pressure sensor analog to digital counts.

The “tpr” command is used in pressure sensor calibration. The result of the bug is that pressure calibration coefficients are calculated with raw pressur data that is in error. The magnitude and sign of the error depends on each individual analog to digital converter. Most analog to digital converters produce little or no error and are within the pressure accuracy specification.

The table below lists starting and ending CTD serial numbers that are affected by the pressure calibration error. Note that SBE 41plus and SBE 41N share the serial number sequence.

	Starting Serial Number	Ending Serial Number
SBE 41plus / 41N	41-7504	11055
SBE 61	61-5578	5645

Float original equipment manufacturers (OEM) and Navis floats use the 41plus, Biogeochemical and deep pH Navis floats use the 41N, and Deep Argo floats use the SBE 61.

A work around implemented in Sea Bird’s pressure calibration process was put in place on 18 June 2018. Pressure calibrations done after that date are correct even if they are within the serial number range shown above.

Impact to the Argo fleet

An estimation of the number of effected CTDs can be made from Dana Swift’s SBE 41 acceptance testing data. These data are gathered by placing the CTD in a temperature controlled environment and measuring the CTD pressure accuracy at full range (2000 decibars). The table below shows the percentage of CTDs that are out of specification at cold temperatures and full range for the SBE 41 and SBE 41plus CTDs.

	SBE 41	SBE 41plus
Average error in decibars	-1.52	-0.48
Standard deviation	1.13	1.40

Total tested	391	210
Total out of spec	35	12
Percent out of spec	9%	6%

For more information on this error, see the error notice from Sea Bird.

APEX truncated negative pressure drifts

APEX floats do not self-correct their pressure measurements, and so the raw pressures returned by APEX floats can contain errors as a result of pressure drifts. Historically, APEX floats have used pressure sensors from Paine, Amatek and Druck, all of which have exhibited pressure drifts of various magnitudes. Therefore APEX pressures are corrected to surface pressure offsets (SP) in real-time by the DACs and in delayed mode by float experts.

Unfortunately, it is not always possible to correct the raw pressures from APEX floats. Some APEX controller boards, APF5-8, restrict SP to values greater than zero with negative SP values truncated to zero. Thus, if a pressure sensor develops a negative pressure drift on floats with an APF8 or earlier series controller, the reported SP values are always zero. Profiles from these periods are labeled as having “Truncating Negative Pressure Drifts” or TNPDs and are not correctable. Given the fast changing nature of Argo data, it is best to identify TNDP affected profiles by looking for the PRES_ADJUSTED_ERROR = 20 dbar.

Before the data set was corrected and these floats identified, the effect of the APEX pressure biases was to overestimate the temperature in the oceans and to create errors of about 10% of the magnitude of salinity differences between Argo and WOA01 datasets. The largest temperature errors occurred in the upper 200 m of the water column (due to the steep thermocline gradient), prior to 2005. This, in turn, incorrectly implied a smaller global mean upper-ocean warming and thermosteric sea level rise from 2003 to 2008. (Barker et al, 2011).

Argo now audits the treatment of pressure biases in the global data set. Most data are now corrected. TNPD affected profiles can be identified in profile files through the character string “TNPD” in the SCIENTIFIC_CALIB_COMMENT field for PRES. TNPD data are labeled with *_ADJUSTED_QC = ‘2’. The more severe ones have PRES_ADJUSTED_ERROR = 20db.

The following two papers describe in more detail the pressure biases for APEX floats:

Barker, P. M., J. R. Dunn, C. M. Domingues, and S. E. Wijffels, 2011: Pressure Sensor Drifts in Argo and Their Impacts. Journal of Atmospheric and Oceanic Technology, 28, 1036-1049, http://dx.doi.org/10.1175/2011JTECHO831.1

Abraham, J. P., M. Baringer, N. L. Bindoff, T. Boyer, L. J. Cheng, J. A. Church, J. L. Conroy, C. M. Domingues, J. T. Fasullo, J. Gilson, G. Goni, S. A. Good, J. M. Gorman, V. Gouretski, M. Ishii, G. C. Johnson, S. Kizu, J. M. Lyman, A. M. Macdonald, W. J. Minkowycz, S. E. Moffitt, M. D. Palmer, A. R. Piola, F. Reseghetti, K. Schuckmann, K. E. Trenberth, I. Velicogna, and J. K. Willis, 2013: A review of global ocean temperature observations: Implications for ocean heat content estimates and climate change. Reviews of Geophysics, 51, 450-483, http://dx.doi.org/10.1002/rog.20022

SOLO FSI CTD pressure offset errors

In early 2007, it was discovered that Argo profiles from SOLO floats with FSI CTD (Argo Program WHOI) may have incorrect pressure values. The problem did not affect any other combination of instrument and sensor. In GTS TESAC messages, potentially affected instruments can be identified by instrument type 852 (SOLO FSI, see WMO Code Table 1770).

Some profiles can be corrected automatically and some need additional study. The automatic fix for these profiles was instituted on 10 October, 2007. For profiles need additional attention, the float will stay on the greylist until the profiles have been fixed.

While studying the pressure offset errors, a related problem was discovered in a group of WHOI/SBE profiles. For the affected WHOI/SBE instruments, all profiles have been corrected and are available on the GDACS as of 14 September 2007.

To learn more details about the pressure problems, click here and to learn which floats have been fixed, click here.

Druck pressure sensor micro-leak problem

In early 2009, it was discovered that a large number of Druck pressure sensors were experiencing oil micro-leak problems. See the notice for more details. Druck pressure sensors were in most of the active Argo floats, making all float models potentially affected. The negative pressure drift resulting from this oil micro-leak can happen either gradually or quickly and the size of the drift can also vary, but goes up to tens of dbars.

To fix this problem, the manufacturing process of the Druck pressure sensor was modified and additional tests are done on the sensors. Sea-Bird has also begun using a new pressure sensor made by Kistler. Floats with fixed Druck sensors or
Kistler sensors were being deployed by late 2009.

The three major types of Argo floats (APEX, SOLO, and PROVOR/ARVOR) treat pressure sensor drifts differently. APEX floats report the raw pressure sensor output at the end of their surface satellite transmission without any self correction. This means that raw APEX pressure data must be corrected in real-time by the DACs and in delayed-mode by float experts. Please refer to the section on “APEX truncated negative pressure drifts” for more information.

SOLO and PROVOR/ARVOR Argo float models are programmed to auto-correct for pressure drift on board the float using the measured surface pressure offset. For these self-correcting floats, only when the offset correction is insufficient do the data need to be flagged as questionable.

The following two papers describe in more detail the pressure biases within the Argo dataset:

Kistler pressure sensor problem

In June 2016, a defect mode was discovered in Kistler pressure sensors. Click here for more details directly from Sea-Bird. The problem consists of a sudden jump shift in the pressure span (the calibration slope of pressure). The root-cause of the defect, found by Kistler, is an electrical component in the pressure bridge circuit that becomes disconnected from the circuit board. The pressure span shift results in a higher reported pressure than actual pressure. For example, a defective sensor reporting 1200 dbars at 1000 dbars depth, reports +2 dbars at the surface.

The effect of pressure error is that all variables will plot incorrectly in pressure space, and calculations involving pressure will be wrong. CTD temperature is correct, but computed salinity values will be systamtically low of correct.

Sea-Bird feels that they have identified most of the sensors during routine manufacturing processes and have thus prevented most of them from being deployed on floats. Argo float providers are being asked to review their data from CTDs with Kistler pressure sensors to identify any other possible problems.

Are these sensor problems documented in a journal paper?

Another paper came out in 2022 focusing on salinity in the Argo data stream:

Wong, A. P. S., J. Gilson, and C. Cabanes (2023), Argo salinity: bias and uncertainty evaluation, Earth Syst. Sci. Data, 15(1), 383-393, doi: https://doi.org/10.5194/essd-15-383-2023

I have downloaded a “D” profile file. Will I ever need to download this file again?

The Argo dataset is always changing and a “D” profile file or trajectory file may be modified after it is first created. If you are maintaining your own mirror of the Argo GDAC, it is important to keep this up to date. If you are only using a selection of Argo profiles, it is still important to regularly check the GDAC to see if the file has been updated.

Are there archives of the Argo dataset?

US NCEI maintains the Global Argo Data Repository (GADR) for Argo data and is responsible for managing updates to Argo data from reanalysis.
Even with this archive, it is strongly recommended that users obtain Argo data from the Argo GDACs as they are updated and improved daily.

Does the Argo dataset have a DOI?

Yes, Argo is now generating DOIs based on monthly snapshots of data at the GDACs. There are also DOIs for the Argo User’s manual and the Argo GDACs. To find all the Argo DOIs, click here.

Authors are encouraged to use the Argo DOIs as well as the acknowledgment stated here:
Acknowledging Argo

What is the status of the new V3 & higher data format roll-out?

Currently, most DACs are producing a majority of all file types in V3.1.

What is new in the V3 & higher profile file?

The major change in the format of the V3 & higher profile files is the ability to accommodate multiple profiles from a sincle cycle. As floats begin performing increasingly complex missions, it is necessary to be able to differentiate the vertical sampling scheme for the various parameters. A detailed explanation is available here. A brief description follows.

Some specialty floats collect additional profiles per cycle which contain parameters measured at different pressure levels from the CTD and might be at different locations and times than the core profile. Examples of specialty profiles include high resolution near-surface observations, bouncing profiles, etc.

The number of profiles is indicated by the N_PROF dimension where the N_PROF = 1 profile must have the Primary sampling profile. Other profiles with different vertical sampling schemes will have N_PROF > 1. A new variable, VERTICAL_SAMPLING_SCHEME, differentiates the various vertical sampling schemes which can change between cycles to accommodate floats with two-way communication. Reference table 16 gives the formats of the different string codes that may appear in the variable. The number of pressure levels is indicated by the N_LEVELS dimension.

More detailed information on the changes can be found in the Argo User’s Manual found at the Argo Data Management website.

The V3.1 profile files will be split into core, B- and S-Argo profile files. The core- and S-Argo profile files contain the CTD sensor parameters (pressure, temperature, salinity, conductivity) that are measured with the same vertical sampling scheme and at the same location and time in the N_PROF = 1 dimension. Additional parameters from other sensors are stored in a B-Argo profile file. A float that performs only CTD measurements will not have B-Argo files. The link between the core- and B-Argo files is PRES.

These files with the additional parameters can be identified by the “B” that precedes the WMO ID in the file name. In addition, the GDACs are planning to implement a file merging procedure that will add the derived parameters from the B-file to the core data so you can acquire the full set of data from a float without downloading the raw parameters from the B-files. These will be identified by ‘S’ so it will be necessary to consider carefully what files to download.

What is new in the V3.1 traj file?

The new V3.1 traj files have been modified to include more information about the events during a cycle and the times
associated with these events. A detailed explanation is available here. A brief description follows.

One major difference is the new MEASUREMENT_CODE variable that indicates what type of measurement is occurring and
the codes can vary significantly from one float type to the next. The codes are all explained in Reference table 15
of the User’s Manual.

Another change is the addition of the JULD_ADJUSTED variable which contains the best estimate of the float timing
available for that float. This may or may not be filled in real time.

Some additional cycle timing variables are included in the N_CYCLE array to more completely describe the timing of
events in each cycle.

Finally, there will be a two-file system for trajectory files; there will be Real Time (R) and Delayed Mode (D) trajectory files. R files will contain only real time data and will be created by DACs. D files will contain all data, ie both real time and delayed mode data, and will be created by the scientist responsible for the float.

It is possible that a float may have both an R and a D traj file and a user must look at both files to get the entire
trajectory information for that float.

In V3.1 traj files, it is possible to store changing resolutions for the various <PARAM> variables. If the
resolution does not change, look for the “resolution” attribute for the variable (usually PRES). If the resolution
does change throughout the cycle, no “resolution” attribute exists and one must look at the “comment_on_resolution” attribute to find the resolution.

What is new in the V3.2 traj file?

The new V3.2 trajectory files have been introduced and they are built upon the v3.1 trajectory files, but are adapted to accommodate both core and BGC Argo data. The decision to combine the core and b-trajectory files was made because:

the structure of the trajectory file requires that placeholders for BGC data would need to be in the core trajectory file
the file size would likely be reduced if the two files are combined rather than kept separate
all information is contained in one file

A detailed explanation is available in the Argo User Manual available on the ADMT website. A brief description follows.

TRAJECTORY_PARAMETERS has been changed to (N_PARAM,STRING64) instead of (N_PARAM,STRING16).

TRAJECTORY_PARAMETER_DATA_MODE (N_MEASUREMENT,N_PARAM) has been added to indicate the mode of each individual parameter in the file.

A SCIENTIFIC CALIBRATION section was added to store information on parameter calibration during park, descent to profile or surface drift.

JULD_DATA_MODE (N_MEASUREMENT) has been added to indicate the availability of adjusted and estimated Julian day of the measurement.

What is new in the V3 & higher meta file?

The V3.0 meta files contain two new variables to help document a float’s mission and possible change in mission during the float’s lifetime. A detailed description is available here. A brief description follows.

The new variables are CONFIG_MISSION_NUMBER and CONFIG_PARAMETER_VALUE. Users can determine the mission number a float is performing for that cycle using the CONFIG_MISSION_NUMBER variable in the new V3.0 traj and profile files.

Many floats perform only one mission their entire lifetime and so will always have a mission number of 1. However, with the addition of two-way communication and more sensors, some floats are changing their mission during their lifetime or have more than one mission from the beginning. Reference table 16 in the User’s Manual explains the configuration parameter names.

The V3.1 meta files have an N_SENSOR dimension indicating the number of sensors a float carries as well as an N_LAUNCH_CONFIG_PARAM dimension indicating the number of pre-deployment or launch configuration parameters. There is a new set of LAUNCH_CONFIG_XXXX variables that contain all the pre-deployment or launch configurations.

There is also a new series of variables related to float parameters which help to identify which sensor is measuring which parameter.

What is a core-Argo file? What is a B-file? What is an S-file?

There will now be core-Argo, B-Argo and S-Argo profile and trajectory files. The core-Argo profile and trajectory files will look very similar to files previously on the GDACs. In fact, if the float only has a CTD, there is no difference between the old file and the new core-Argo profile and trajectory file. The names of the files remain the same and the parameters within them remain the same. The parameters included in a core-Argo file will be pressure, temperature, salinity, and perhaps, conductivity.

The B-files will include any Argo parameter except temperature, salinity and, if applicable, conductivity. They will also include any intermediate parameters that are necessary to calculating ocean state parameters.

The S-files, where “S” means synthetic, will contain all ocean state variables that a float measures aligned to a common vertical pressure axis. Examples of additional ocean state parameters that might be present in an S- file are DOXY, CHLA, etc. This file will be a combination of the core parameters and any other ocean state parameters found in the B-file.

For more information on these files, including their naming conventions and the list of parameters, look in the Argo User Manual on the Argo Data Management website’s documentation page.

The split into core-, B- and S-Argo files starts with V3.1. Earlier format versions will contain biogeochemical data in the profile and trajectory files.

What are the main differences between S-profile files and the separated core- and B-profile files?

The current V3.1 Argo netCDF format that produces a pair of core- and b- profile files per cycle, allows storage of all profile information returned from BGC floats, in a manner that is as close to float output as possible. These can include multiple full-depth profiles with different pressure levels, multiple shallow profiles with different pressure levels, and recording of spatial and/or temporal delays between the CTD and various BGC sensor outputs. The advantage of this data management approach is that float outputs are faithfully recorded, so that any reprocessing demands that require access to the raw data can be met with ease. However, when measurements from multiple sensors are not aligned during onboard processing by the floats, they are recorded in their raw pressure locations. This makes it difficult to study these BGC parameters as co-located measurements, since some data manipulation to align them needs to be done before scientific studies can be carried out. To learn about how Sprof files are constructed, click here.

When should I use an S-file instead of a B-file?

The S-files contain both the core Argo temperature and salinity data as well as the ocean-state BGC parameter data interpolated onto one pressure axis (Bittig et al, 2019). They are easier to use for multi-parameter analysis while the pair of core- and B- profile files are more applicable to use by data managers or users deeply interested in a single parameter.

What cycle timing information should Argo floats send back?

Each Argo float cycle is composed of programmed events. Depending on float type, some of these events can be dated and sent back by the float to aid in the calculation of velocities. The Argo Program has highlighted several cycle timing variables that it would prefer that floats send back timing information. This cycle timing document explains the variables and how they fit into the trajectory file.

How do I search for data in a specific time and location?

The answer to this question depends on many things such as much Argo data you are looking for, how frequently you anticipate looking at the data, how you want to access the data and what sort of a computer programmer you are. A full guide is available on this Argo data access webpage.

As a way to get started, both GDACs offer ways to search for data in a specific time and location and then download that data. The US GDAC has a GUI data browser that allows one to look for profile or trajectory files using date, location, DAC, real or delayed mode data and float ID as search criteria. The link is: http://www.usgodae.org/cgi-https://nrlgodae1.nrlmry.navy.mil/cgi-bin/argo_select.plbin/argo_select.pl. It is possible to download the NetCDF files right away as a tar file.

EuroArgo has a data selection tool based on the Coriolis GDAC which allows one to search for Argo profile or trajectory data using date, location, real or delayed mode data, parameter, Argo Mission, deployment date, float ID and data quality as search criteria. The link is: https://dataselection.euro-argo.eu/. You can request to have the files emailed to you in Argo NetCDF, Copernicus NetCDF or csv.

Another possibility is to access Argo’ monthly DOI snapshot which contains a copy of the Argo dataset for that month. Then, you can use the index files to search for data within a time and location. There is an index file for profile files, b-profile files, S-profile files, trajectory files, and meta files. Each index file has one line for each Argo file that exists along with metadata about time, location, DAC, etc. The index files can be found on the FTP sites at both GDACs and in the monthly DOI snapshots: Coriolis and US GODAE.

There is also an Argo API available via Argovis through which you can make selections in time and space and have the data returned in your programming language of choice.

How do I download BGC-Argo data? Can I get only the BGC-Argo parameters of interest?

Via index lists on the GDACs

You can use the S-prof index list which lists each synthetic Argo profile available (includes CTD and BGC data adjusted to similar pressure levels) or the b-prof lists which lists each b-profile available (includes only BGC data, including intermediate parameters).

The S-prof index list include all the profile file names, date, latitude, longitude, ocean, profiler type, institution, ocean state parameters such as TEMP, PRES, DOXY, CHLA etc., the data mode of each parameter, and the date of file update. This list can be searched, just like the simple argo_profile_index.txt list, for floats in the region of interest with the desired ocean state parameters. Refer to Reference Table 3: Parameter code table in the Argo User’s Manual for the name of the different parameters to search for.

To find the intermediate parameters, like TEMP_DOXY, etc, the argo_bio-profile_index.txt on the Argo GDAC ftps must be searched. The same information is included except that the intermediate parameters are listed instead.

Via float WMO numbers

Another way to identify the BGC floats is to use the OceanOPS Dashboard to search for floats within the BGC Argo Network. Click on the search button and under ‘Network’, choose, ‘Argo BioGeoChemical’. Once the WMO numbers are identified, you can find and download the appropriate S-prof or b-prof files on the GDACs.

Via DOI tarball

Each month, a snapshot of the entire Argo GDAC and just the BGC Sprof data files is taken and assigned a DOI. The tarball of the entire GDAC data separates the BGC data from the core data, but it is a much larger file size (~50GB). If you are looking for just the BGC Sprof files, you can download just that tarball which is smaller (~2GB). Both of these files are structured like the GDAC, so this would provide you with a mirror of the BGC data on the GDACs. You may still want to use the S-prof index list to help pick out the parameters of interest. Please use the same DOI and citation as the global Argo data snapshot.

Via GUIs or APIs

You can use the EuroArgo Data Selection Tool to search for Argo biogeochemical data by float and by parameter. When you’ve made your selection, the data can be exported using the ‘export’ button at the bottom of the page. A variety of export options are available including the standard Argo netCDF files, Copernicus netCDF files and CSV files.

You could also search Argovis for BGC profiles in a selected region and from there, download the data through links provided. This can be done in a more automated way through the Argovis API which allows you to select BGC data in a region and time period of interest and import it into your programming environment of choice.

Note that not all ‘additional sensor’ data in Argo have undergone quality control and thus may require the user to do this.

Also note that these search methods may offer slightly different results based on how they are compiled. To learn more about this, study the metadata status on the BGC-Argo tools webpage.

In V3.1 profile files, oxygen data will reside in the B-Argo profile files and the S-Argo profile files. The B-Argo profile files will contain all parameters a float measures expect temperature, salinity and conductivity. This includes DOXY plus intermediate parameters like TEMP_DOXY, BPHASE_DOXY, etc. The S-Argo profile files will contain all ocean state parameters, so will contain DOXY plus TEMP, PRES, and PSAL. A link to an explanation of the S files can be found here.

In V2 profile files, oxygen data is stored as <PARAM> or <PARAM>2 depending on whether there is more than one oxygen measurement taken each profile.

In V3.0 and higher files, oxygen data resides in the N_PROF =1 dimension if taken using the same vertical sampling scheme as the CTD and in the N_PROF = 2 dimension if taken using a different vertical sampling scheme from the CTD. So, users must search all N_PROF dimensions in the V3 and higher profile files to ensure they find all the oxygen data. This is explained in the documentation on the ADMT website.

The majority of profile files available on the GDACs are in V3, but there still remain some V2 files.

Are there gridded or other data products based on Argo available?

Yes, there are various gridded fields and other data sets available using only Argo data or Argo data plus others. Most of these files are NetCDF files and all are freely available for download, although some require an account. There are gridded temperature, salinity and velocity files as well as other velocity products, mixed layer depth products, and Standard Depth Level products.
The Argo Program does not create these files, but maintains a database of the known products. See the Data Products page for more information.

Are there collections of profiles that have been curated?

Yes, there are collections of profiles that have all been interpolated to standard depth levels and profiles that have had additional quality control done on them.

Is there an easy way to view Argo data?

Yes, there are several different data visualizations, all of which are described here. Some are available through your web browser like Argovis, OceanOPS, and the EuroArgo dashboard, while others are downloaded onto your computer like the Global Marine Argo Atlas and the Google Earth layer. All these visualizations allow people to quickly look at profile data and/or gridded data from Argo floats without having to work with the netCDF Argo profile files. Each one has a different focus, so please read the descriptions and look at the visualization comparison table to help decide which ones to try.

Are there any resources for using Argo data in the classroom?

Yes, there are ways for students to access Argo data in the classroom. There is an education page with curriculum and website resources with target audience level and themes. In addition, there are many ways to visualize Argo data now, including through your internet browser without needing to download it or understand the format. Click here to learn about the different visualizations and which would work best in your classroom.

Is there a way to display data in Google Earth?

Not reliably anymore. Instead, there are other options to view Argo data through your browser available here.

Does Argo have an API?

Yes, there is an Argo API available via Argovis through which you can make selections in time and space and have the data returned in your programming language of choice. There are also API calls to look at individual profiles, entire floats and global metadata.

What if I have questions about Argo or the data?

If you have general questions about Argo, please send them to argo@ucsd.edu
If you have more technical questions about the data, please e-mail the support desk (support@argo.net)