Argo Technical Parameter Naming Convention

advertisement
Argo Technical Parameter Naming Convention
We propose construction rules for the technical parameters names reported in the
tech.nc files held at the Argo GDACs. These rules are flexible, expandable and allow
different floats to report different technical parameters.
We wish to thank Vito Dirita for devising the naming scheme and both Vito and
Serge Reste for their input to this document.
Standardizing names, to the extent possible given the varieties of both hardware and
software in the field, will make the job of using these files simpler. This will lead to
benefits in float failure analyses and statistical analysis of the performance of the
Argo array.
Because we are using a set of rules for name construction, names are not limited to
those found in any one table. We define several tables of commonly used names and
encourage data managers to use these names as the basis for their technical parameter
files. The tables should be maintained so if you need a new UNIT, for example, it
should be sent to the Argo Information Centre with full definition for inclusion in the
relevant table.
Proposal for the tech file format:
Currently the names of the variable are repeated for every value. In addition we are
mixing the parameter names from cycle 0 with those from the other profiles. The
disadvantages of the latter are that:
(1) Some variables with the same name could have different meanings in cycle 0 than
in the other cycles (CONFIG in cycle 0, DIAGNOSTIC in the other cycles).
(2) Variables that only exist in cycle 0 needlessly inflate the matrices.
Currently:
TECHNICAL_PARAMETER_NAME(N_CYCLE,N_TECH_PARAM,STRING32)
TECHNICAL_PARAMETER_VALUE(N_CYCLE,N_TECH_PARAM,STRING32)
Proposed:
TECHNICAL_PARAMETER_NAME0(N_TECH_PARAM0,STRING128)
TECHNICAL_PARAMETER_VALUE0(N_TECH_PARAM0,STRING128)
TECHNICAL_PARAMETER_NAME(N_CYCLE,N_TECH_PARAM,STRING128)
TECHNICAL_PARAMETER_VALUE(N_CYCLE,N_TECH_PARAM,STRING128)
CYCLE_NUMBER(N_CYCLE) – as suggested below
Two names will become mandatory for ALL floats:
1. All technical files must have a field containing the Cycle number. This is
currently implicit given the position in the array but making it explicit will
help users.
2. All floats report a surface pressure measured just before descent and this will
be reported in one of two ways – either with negative values truncated to 0
with 5m added (the current Apex floats with APF8 controller boards) or as +/offsets with no added value (all other profilers, including Apex floats with
APF9 controller boards and newer APF8 Apex floats). We need to
distinguish between these two types of measurements and they will become:
PRESSURE_SURFACE_OFFSET_TRUNCATED_plus5m_dBAR and
PRESSURE_SURFACE_OFFSET_UNTRUNCATED_dBAR
respectively (see below for the rules used to create these names). This will be
critical for use of the data before delayed mode QC, particularly when APF8s
are deployed with the second type of surface pressure measurement.
The construction rules are:
1. The names consist of fields arranged in a hierarchy:
2. The first field is always WHAT IS MEASURED (VOLTAGE, PRESSURE,
TIME, etc)
3. The last field is always UNITS
4. Fields in between are modifiers telling WHEN or WHERE the variable is
measured (SURFACE, PUMP, BATTERY, etc)
5. All fields are delimited by “_” (underscore); blank characters are invalid
6. All fields may not contain mathematical symbols (e.g. +, -, *, / =) since they
can cause problems with software (e.g. matlab)
7. The number of fields should be the minimum which fully describes the
parameter
8. The full parameter name must fit into 128 characters
9. Allowable names in field 1 will be defined in the technical parameter table
(table 3.14.a)
10. UNITS are standard with the following rules, and are defined in table 3.14.b
a. Units preceded by lowercase ‘m’ refer to milli (10-3) ex: milliAmps,
mMOL/L etc.
b. Units Preceded by lowercase ‘d’ refer to deci (10-1) ex: dBar
c. Units preceded by lowercase ‘u’ refer to micro (10-6) ex: uMOL/L etc
11. Fields between the first field and the units field can be more flexible but we must
make sure that everyone is using the same name for the same technical data.
Standardized names for some fields or variables will be defined in sub-table 3.14.c.
As more names are needed, they should be submitted to the data management team
for inclusion in the table. This will ensure that everyone uses the same basic names
for the same data and the people using these files can more easily use the data.
12. Electrical currents must be converted from counts if possible – counts are
meaningless from an engineering perspective.
13. We have attempted to make names unambiguous but they must be used as intended –
so, for instance, don’t confuse CURRENT (electrical measurement) with NOW
(measurement of time), distinguish between CLOCK (decimal hours) and TIME (how
long something lasted) and don’t use BOTTOM or DRIFT if you mean PROFILE or
PARK.
14. A table of name equivalents (as far as we can determine) is also provided.
This is not exhaustive and some names might be redundant. We don’t
necessarily need to include everything as long as we’re consistent when we
generate new names. Some names might not be as clear as they need to be
and we would appreciate input for the final table as people begin the
conversion. Definitions would be useful but we haven’t attempted to define
all terms. Again, help to make this table better would be appreciated. Some
variables have questions in the comment/definition field. Those who use these
variables are asked to answer the questions so people who use these files know
what the variables mean. We have had to guess at some units and would
appreciate it if we could be notified of corrections. Some float types are not
well represented (Ninja, for example) and more work will be required to get
these names to conform to the new rules.
Table 3.14.a – Technical parameter names for Field 1 – WHAT is being
measured or reported
Technical Parameter
NAME
VOLTAGE
CURRENT
PISTON_POSITION
PRESSURE
VALVE_ACTIONS
PUMP_ACTIONS
FLAG
STATUS
IDENT
TIME
CLOCK
DATE
COUNTER
DIAGNOSTIC_BIT
CONFIG
TEMPERATURE
SALINITY
CONDUCTIVITY
Example
VOLTAGE_BATTERY_PARK_VOLTS
CURRENT_BATTERY_NOLOAD_PARK_mAMPS
PISTON_POSITION_PARK_COUNTS
PRESSURE_INTERNAL_VACUUM_SURFACE_mBAR
VALVE_ACTIONS_SURFACE_NUMBER
PUMP_ACTIONS_DESCENT_NUMBER
FLAG_PROFILE_TERMINATION_FLAG2_BYTE
STATUS_LIMIT_SWITCH_HEX
IDENT_DEPTH_TABLE_NUMBER#
TIME_PUMP_MOTOR_SECONDS
CLOCK_FLOAT_HOUR
DATE_PARK_FIRST_SAMPLE_DDMMYYYY
COUNTER_NUMBER_VALVE_ACTIONS_SURFACE_COUNTS
DIAGNOSTIC_BIT_PRESSURE_OFFSET_AFTER_RESET_dBAR
CONFIG_ARGOS_REPETITION_PERIOD_SECONDS*
TEMPERATURE_INITIAL_PRE_ASCENT_DEGREES^
SALINITY_INITIAL_PRE_ASCENT_PSU^
CONDUCTIVITY_INITIAL_PRE_ASCENT_MS/CM^
# identification information – format numbers, hull IDs, block message counters,
etc.
* configuration information sent as part of the test message – these are mission
specific and can be reprogrammable - reported as technical data for cycle ‘0’
^ generally restricted to Solo floats at present
Table 3.14.b UNITS of the variable – always in the last field of the name
UNITS:
VOLTS
AMPS
mAMPS
dBAR
inHG
PSU
DegC
mHOS/M
mMOL/L
uMOL/L
HOURS
DECIMAL_HOUR
MINUTES
SECONDS
HHMMSS
(hours/minutes/seconds)
DDMMYYYY (day/month/year)
STRING (character string)
COUNTS
NUMBER
HEX
LOGICAL (true/false)
Table 3.14.c Additional names in standard form:
Mission Cycle names:
Description:
SURFACE
Measured at the surface
PARK
Measured during park phase (= DRIFT
which is no longer to be used)
PROFILE
Measured at the deepest point of the
profile
DESCENT
Related to the descent phase of the
cycle
ASCENT
Related to the ascent phase of the cycle
What or when measured: (may take up Additional modifiers and notes:
more than one field) – this list is not
intended to be complete…
BATTERY
PISTON
PERIOD
INTERNAL_VACUUM
AIR_BLADDER
SERIAL_NUMBER
FORMAT_NUMBER
DEPTH_TABLE_NUMBER
REVISION_NUMBER
ERROR_CODE
PROFILE_TERMINATION
_FLAG1/_FLAG2/_SOLO
STATUS
_SBE/_SYSTEM/_WORD
LIMIT_SWITCHES
(Solo Floats)
START_DESCENT
END_DESCENT
START_ASCENT
END_ASCENT
AFTER_RESET
TRUNCATED_plus5m
(surface pressure measured by Apex
floats with APF8 controller boards –
these boards add 5m to prevent ctd
operation in air and this value has
NOT been removed from the reported
surface pressure)
UNTRUNCATED
(surface pressure measured by all other
floats or new Apex floats with APF8
boards that do not truncate surface
pressure)
SHALLOW
Used by PROVOR floats
DEEP
Used by PROVOR floats
NOW
Replaces “current” for time
Download