read.argo is used to read an Argo file, producing an argo object.
The file must be in the ARGO-style NetCDF format described
in the Argo documentation (see references 2 and 3).
read.argo( file, encoding = NA, debug = getOption("oceDebug"), processingLog, ... )
A character string giving the name of the file to load.
A flag that turns on debugging. Set to 1 to get a moderate amount of debugging information, or to 2 to get more.
If provided, the action item to be stored in the log. (Typically only provided for internal calls; the default that it provides is better for normal calls by a user.)
additional arguments, passed to called routines.
An argo object.
See the Argo documentation (see references 2 and 3) for some details on what files contain.
Many items listed in section 2.2.3 of reference 3 are read from the
file and stored in the
metadata slot, with the exception of
latitude, which are stored in the
data slot, alongside hydrographic information. The details of storage
in the return value are somewhat complex, although the following notes
might be helpful to readers seeking to learn more.
1. Variable renaming.
The names of several data parameters stored within the netCDF file
are altered to fit the oce context. For example,
matching the name of this variable in other oce data types.
The original names are reported by
data may be extracted with
[[,argo-method using those names, so
the renaming should not be too inconvenient to Argo experts who
are new to oce.
Argo netcdf files employ a
"SNAKE_CASE" naming scheme (sometimes
using lower case) that is inconsistent with the
used in oce. Since argo objects are just a small part of oce, a decision
was made to rename argo items. For example,
"CYCLE_NUMBER" in the netcdf file
"cycleNumber" in the oce object returned by
[[,argo-method also accepts
"cycle" for this item.)
The conversion for objects in the
data slot often also involves
expanding on argo abbreviations, e.g.
The renaming work is carried out with
handles both name expansion for several dozen special cases,
snakeToCamel() with the
"QC". While this results in variable names that should make
sense in the general oce context (where, for example, salinity is expected
to be stored in a variable named
"salinity"), it may be confusing
to argo experts who are just starting to use oce. Such people might
find it helpful to use e.g.
sort(names(x[["metadata"]])) to get a list
of all items in the
metadata slot (or similar with
"data"), since working
in reverse may be easier than simply guessing at what names oce has chosen.
(Note that prior to 2020 June 24, some metadata items were stored in
Several of the netCDF global attributes are also renamed before
placement in the
metadata slot of the return value. These include
These names are derived from those in the netcdf
file, and mainly follow the pattern explained in the
“Variable renaming convention” section.
For profile data (as indicated by the NetCDF global attribute
"featureType" being equal to
the NetCDF item named
whether variables in the source file will be stored in the
data slot of the returned object.
STATION_PARAMETERS is not present, as is the case for
trajectory files (which are detected by
"trajectory"), some guesses are made as to what goes in
3. Data variants.
Each data item can have variants, as
described in Sections 2.3.4 of reference 3.
For example, if
"PRES" is found in
PRES (pressure) data are sought in the file, along with
PRES_ERROR. The same pattern works for other profile data. The variables
are stored with names created as explained in the
“Variable renaming convention” section below. Note that
flags, which are stored variables ending in
"_QC" in the netcdf
file, are stored in the
flags item within the
of the returned object; thus, for example,
PRES_QC is stored as
4. How time is handled.
The netcdf files for profile data store time in an item named
which holds the overall profile time, in what the Argo documentation
calls Julian days, with respect to a reference time that is also stored
in the file. Based on this information, a POSIXct value named
is stored in the
metadata slot of the returned value, and this
may be found with e.g.
a is that returned value.
Importantly, this value matches the time listed in profile index files.
In addition, some profile data files contain a field called
which holds the offset (in days) between the time of individual measurements and the
overall profile time. For such files, the measurement times may be
a[["time"]]+86400*a[["mtime"]]. (This formula is used by
as.ctd(), if its first argument is an argo object created
read.argo() with such a data file.)
5. Data sources.
Argo data are made available at several websites. A bit of detective work can be required to track down the data.
Some servers provide data for floats that surfaced in a given ocean
on a given day, the anonymous FTP server
usgodae.org/pub/outgoing/argo/geo/ being an example.
Other servers provide data on a per-float basis. A complicating
factor is that these data tend to be categorized by "dac" (data
archiving centre), which makes it difficult to find a particular
float. For example,
https://www.usgodae.org/ftp/outgoing/argo/ is the top level of
a such a repository. If the ID of a float is known but not the
"dac", then a first step is to download the text file
and search for the ID. The first few lines of that file are header,
and after that the format is simple, with columns separated by slash
/). The dac is in the first such column and the float ID in the
second. A simple search will reveal the dac.
data(argo) is based on float 6900388, and the line
containing that token is
which the dac is seen to be the British Oceanographic Data Centre
bodc). Armed with that information, visit
and see a directory called
profiles that contains a NetCDF
file for each profile the float made. These can be read with
read.argo. It is also possible, and probably more common,
to read a NetCDF file containing all the profiles together and for
that purpose the file
should be downloaded and provided as the
file argument to
read.argo. This can be automated as in Example 2,
although readers are cautioned that URL structures tend to change
Similar steps can be followed on other servers.
# Example 1: read from a local file library(oce) d <- read.argo("~/data/OAR/6900388_prof.nc") summary(d) plot(d) # Example 2: construct URL for download (brittle) id <- "6900388" url <- "https://www.usgodae.org/ftp/outgoing/argo" if (!length(list.files(pattern="argo_index.txt"))) download.file(paste(url, "ar_index_global_meta.txt", sep="/"), "argo_index.txt") index <- readLines("argo_index.txt") line <- grep(id, index) if (0 == length(line)) stop("id ", id, " not found") if (1 < length(line)) stop("id ", id, " found multiple times") dac <- strsplit(index[line], "/")[] profile <- paste(id, "_prof.nc", sep="") float <- paste(url, "dac", dac, id, profile, sep="/") download.file(float, profile) argo <- read.argo(profile) summary(argo)
Argo User's Manual Version 3.2, Dec 29th, 2015, available at
User's Manual (ar-um-02-01) 13 July 2010, available at
which is the main document describing argo data.
The documentation for the argo class explains the structure of argo objects, and also outlines the other functions dealing with them.
Other things related to argo data: