Trajectory V3.1 File Update

Megan Scanderbeg, J. Gilson, N. Zilberman

Argo Steering Team Meeting

March 2016

Papers using Argo trajectory files

0

2

4

6

8

10

12

14

16

200

3

200

4

200

5

200

6

200

7

200

8

200

9

2010

2011

2012

2013

2014

2015

99+ papers

4 papers focused on global velocity fields

Most are regional studies

10+ papers used YoMaHa

3+ papers used ANDRO

1+ paper used G-YoMaHa

3+ assimilated into models

Number of ‘R’ Trajectory files on the GDAC by DAC and version

DAC Total Version 3.1 Version 2 Float type in V3.1

AOML 5577 0 5577

BODC 420 0 420

Coriolis 2121 789 1332 PROVOR, ARVOR

CSIO 324 10 314 PROVOR, ARVOR

CSIRO 569 375 194 APEX w/ ARGOS

INCOIS 360 57 303 PROVOR, ARVOR

JMA 1392 0 1392

KMA 193 0 193

KORDI 119 0 119

MEDS 398 96 302 APEX, NOVA

NMDIS 19 15 4 ARVOR

Progress 12%

Outline

Trajectory Cookbook updates

Scientific motivation for moving to V3.1 files

Flexibility of V3.1 format

Need to finalize and document b-traj files

Delayed mode quality control for trajectory files

Trajectory Cookbook Updates New, updated tables for all float types except

PROVOR/ARVOR which include all MCs, not just cycle timing ones

Added table on Deep NINJA

Removed all references to STANDARD_FORMAT_ID since this variable was removed at ADMT-16 in November

Moved APEX estimation methods to Annex

Better suited to delayed mode rather than real time

Updated relative measurement codes

Allows for inclusion of more technical data

Float cycle timing information Sending back crucial timing information

Not sending back crucial timing information

APEX APF9i with firmware revision 072314 or later

ARVOR/PROVOR

NAVIS

NINJA from 2002-2007 and Deep NINJA

NOVA

SOLO-II/S2A

APEX APF8, APF9a and t, APF9i with firmware revision before 072314

NEMO

NINJA from 2008

SOLO

These models are mostly older and often not deployed anymore, but still lots of data on GDACs. Don’t know what is happening with APEX and APF11, but Dana Swift is now involved and knows crucial cycle timing information.

Additional timing information Argo’s data policy calls for data that floats send

back to be available in 24 hours

All times are not available unless using V3.1

More timing information can improve velocity estimates

With Iridium, more timing information is becoming available

Where will this be stored?

ARVOR

NAVIS

Nova

SOLO-II

APEX

APF9i

0

200

400

600

800

1000

1200

200

5

200

6

200

7

200

8

200

9

2010

2011

2012

2013

2014

2015

Iridium

Argos

Deployments by year

A user’s prospective of Argo trajectory files

Calculating velocities at 1000m in Southern Pacific

A typical year (2013) of Argo coverage for the 140°E to 70°E and 20°S to 40°S region

Doing extrapolation based on background velocity and inertial current (Park et al, 2004) to estimate location of rise and fall of Argos floats

Using GPS locations for Iridium floats

Profile

pressure

Parking

pressure

Surface

Cycle N

DST DET DDET

AST

AET

TST

TET

Depth

Cycle N-1

Argos/GPS

locations

PET

Extrapolation method relies on knowing AET/TST and

TET/DST and surface locations

• Blue times in V3.1 files only

• TET, PST and PET can help with drift velocity

calculations

PST

Floats in Southern Pacific 140°E to 70°W; 20°S to 40°S

DAC # of floats with at least one profile in region

AOML 927

Coriolis 40

CSIO 3

CSIRO 112

JMA 31

Total 1113

KORDI 1

MEDS 2

Total 1116 365

331

93

56

20 5

SOLO

APEX w/ Argos

SOLO-II

APEX w/Iridium

PROVOR

NAVIS

Used 873 out of 1116 floats

Majority (124) rejected due to <3 cycles close to each other at correct drift pressure

73 APEX Argos floats rejected due to bad AET/TST, bad TET estimation, bad file format

713 have Argos; 160 have Iridium

In East Australian Current (31°S,154°E)

APEX APF8 float

Magenta dots are

actual surface fixes

Blue dots are extrapolated

positions at thirty equal

time intervals from surface

arrival to estimated

transmission end time

TET

Estimated TET

using process in

Trajectory Cookbook

Extrapolation

method from Park,

et al 2004

Estimated additional

10 km traveled on

surface by float –

surface velocity

increases by a

factor of 2

Meridio

nal dis

pla

cem

ent

in k

m

zonal displacement in km

Magenta dots are actual

surface fixes

Blue dots are

extrapolated positions at

thirty equal time intervals

from estimated surface

arrival to estimated

transmission end time

In East

Australian

Current

(15°S,150°E)

Dmoded SOLO float

Extrapolation method

from Park, et al 2004

Estimated additional

25 km traveled on

surface by float –

changes subsurface

velocity calculation

by 25%

Meridio

nal dis

pla

cem

ent

in k

m

zonal displacement in km

Flexibility of V3.1 format V3.1 format identifies where each measurement

occurred within cycle, even if no time is available

Allows for additional timing estimates to be inserted in delayed mode

Allows some information previously stored in tech files to be in traj files, but need to focus on keeping scientifically useful data, not everything float sends back

Need to think about when to include information in trajectory file or another file – users may need to get comfortable using traj files

B-trajectory files

Format needs to be finalized and well documented

Mathieu lists 672 floats as having DOXY

Time consuming and needs an expert to liaise between Bio-Argo community and ADMT

Separate b-Trajectory Cookbook will likely be needed

Agreed on how to store surface in-air measurements needed for calibration of oxygen sensors

Agreed on how to store RAFOS timing information

Location of all

b-profiles on GDACs

462 floats

Delayed mode trajectory files John Gilson has 1317 ‘D’ trajectory files

Some are for SOLO floats: dmoded as they die

Some are for active SOLO-II floats so that additional information float sends back can be sent out in real time

Working with Annie Wong to start discussions on delayed mode trajectory files with current dmode operators & considering a workshop in 2017

Some dmode procedures will apply to all float types and some will be float type specific

Some dmode operators may choose to use ANDRO V3.1 trajectory files for dmode

Conclusions Conversion to V3.1 format is starting; DACs need help with

this transition

V3.1 format has possibility of improving velocity calculations and opening up other areas of study if more timing information is included

Need to focus on putting scientifically useful information in V3.1 traj files even though it is flexible enough to handle many types of data

Could use a b-trajectory file expert to help describe and document a b-trajectory cookbook

Need to start developing a dmode quality control process for trajectory files

Possible dmode procedures Applying PRES/PSAL corrections from profile dmode

to trajectory files

Quality controlling cycle number

Quality controlling surface times and positions

Estimate additional timing information

Check that measurement codes are applied correctly

Apply the grounded flag

Calculate the best drift PRES/TEMP/etc.

Recent papers where Argo trajectory files used to calculate velocities • Gray & Riser, 2014 – global mean velocity field • Ollitrault & Colin de Verdiere, 2014 – ANDRO • Ollitrault & Rannou , 2013 – ANDRO • Katsumata, 2010 – Gridding of YoMaHa

• Castellanos et al, 2015 – Tropical Atlantic • Chiswell et al, 2015 – near New Zealand (used YoMaHa) • Cravatte et al, 2015 – South Pacific • Liu et al, 2015 – Luzon Straight • Ohde et al, 2015 – North Atlantic • Park et al, 2015 – East Sea • Ponsoni et al, 2015 – East Madagascar (used ANDRO) • Bowen et al, 2014 – near New Zealand • Carrier et al, 2014 – assimilating traj file into NCOM-4DVAR • Chiswell et al, 2014 – assimilating traj file into BRAN; compared to YoMaHa • Dong et al, 2014 – South Atlantic (used G-YoMaHa) • Giglio, 2014 (thesis) – North Pacific • Koenig et al, 2014 – surface velocities in Drake Passage • Kosempa et al, 2014 – Southern ocean (compared to YoMaHa) • Perez et al, 2014 – Atlantic (used YoMaHa) • Schmid, 2014 – South Atlantic • Zilberman et al, 2014 – South Pacific

Where to keep profile times As a new parameter in the core profile files?

Works best if times accompany all profile measurements How would dmode be done on times in conjunction with

trajectory files?

In V3.1 trajectory files? Works best if a sparse snapshot of times Already included for SOLO-II, PROVOR/ARVOR

In the B files? Might require a B file even if it is a core float Not favored

Keep this data at the DACs and not in distributed files? Is this information useful? Or only used by DM

operators for specific calculations? If more generally useful we need a cost/benefit assessment…