Status of Trajectory Files

Megan Scanderbeg

Argo Steering Team Meeting

March 2014

Outline

• Progress on V3.0 trajectory files since AST-14

• Update on status of current traj files in North Pacific Ocean from viewpoint of calculating velocities

• Thoughts on real time and delayed mode traj files

Trajectory V3.0 since AST 14

• Trajectory V3.0 format was approved and is in User Manual

• Agreed upon using two-file trajectory system –

WMO_Rtraj.nc and WMO_Dtraj.nc files

• Agreed to split into Core-Argo and B-Argo trajectory files in a

similar fashion to profile files

• DAC cookbook has been published with instructions on how

to create trajectory V3.0 files, including what Measurement

Codes should be included for all current float types

• Webpage created with explanation of new trajectory V3.0 file

format (http://www-argo.ucsd.edu/Traj3files.html)

Timeline for Traj V3.0 to get to GDACs

• Some DACs/PIs have begun creating both real time and delayed mode V3.0 trajectory files in preparation for uploading to DACs/GDACs – BODC, CSIRO, J-P. Rannou, J. Gilson have all created

test files

– Test files for Provor floats done by Rannou can be found at: ftp://ftp.ifremer.fr/ifremer/argo/etc/coriolis-custom/argo-andro-data/

• Most DACs are focusing on switching prof and meta files to V3.0 and then will work on traj files

• Waiting until GDACs can accept V3.0 trajectory files

Creating D V3.0 traj files from ANDRO • What Rannou does to create “D” files from ANDRO

(through 2009): – Checks positions through re-decoding hex messages, additional

qc to remove bad positions – Checks cycle number – Checks Pres/Temp measurements collected during drift phase;

no flagging has been done if determined “bad” – Checks cycle timing variables – Checks of available Pres vs Time information during vertical

phase

• What still needs to be done by PI or Rannou with specific instructions: – Check salinity and adjust if necessary – Flag bad Pres/Temp/Psal during drift – Apply surface pressure adjustments on non auto-correcting

floats ( must be consistent with prof files?? ) – Figure out how to add back in recovered cycles – will DAC create

new prof and traj files to accommodate this? J-P says that 2-3% of cycles are lost in the current netcdf files

Recent Research Papers where Argo traj files used to calculate velocities

• Ollitrault & Colin de Verdiere, 2014 – ANDRO • Ollitrault & Rannou , 2013 – ANDRO • Katsumata, 2010 – Gridding of YoMaHa

• Bostock, 2013 – South Pacific • Kessler, 2013 – Coral Sea • Park, 2013 – Japan/East Sea • Cravatte, 2012 – South Pacific • Czeschel, 2011 – South Pacific • Menna & Poulain, 2010 – Med Sea • Thaillandier, 2010 – assimilating traj files into

Med Sea forecasting • Voet, 2010 – Nordic Seas

Approaching trajectories from user perspective

• Calculating velocities at 1000m in North Pacific Ocean

• Right: A typical year (2010) of Argo coverage

• Doing extrapolation

based on background velocity and inertial current (Park et al, 2004) to estimate location of rise and fall of float • Extrapolation method relies on knowing the times of the rise and fall (AET/TST and TET/DST) and the surface locations

Floats in North Pacific Ocean

– 1393 APEX ( 1217 with Argos, 176 with Iridium )

– 336 SOLO ( 262 SOLO, 74 SOLO-II with Iridium )

– 154 PROVOR

– 103 ARVOR

– 74 NAVIS with Iridium

– 40 Other – NEMO, NINJA, PALACE, ALACE

DAC # of floats

AOML 1135

Coriolis 25

CSIO 50

CSIRO 5

JMA 878

Total 2097

KMA 73

KORDI 38

MEDS 71

NMDIS 2

Total 2285

• JMA float

29047

• Cycle # 2

has cycle

#2 plus all

of cycle 7

and parts

of cycles

8-12

• JULD,

LATITUDE,

LONGITUDE

exactly

the same

• Found

similar

situation

for

several

JMA

floats

Example of erroneous data in a traj file

Cycle 1

Cycle 1

Cycle 2

Cycle 1

Cycle 2

Cycle 3

Cycle 1

Cycle 2

Cycle 3

Cycle 4

Cycle 1

Cycle 2

Cycle 3

Cycle 4

Cycle 5

Cycle 1

Cycle 2

Cycle 3

Cycle 4

Cycle 5

Cycle 6

Cycle 1 Cycle 6

Cycle 2 Cycle 7

Cycle 3

Cycle 4

Cycle 5

Cycle 1 Cycle6

Cycle 2 Cycle 7

Cycle 3 Cycle 8

Cycle 4

Cycle 5

Cycle 1 Cycle 6

Cycle 2 Cycle 7

Cycle 3 Cycle 8

Cycle 4 Cycle 9

Cycle 5

Cycle 1 Cycle 6

Cycle 2 Cycle 7

Cycle 3 Cycle 8

Cycle 4 Cycle 9

Cycle 5 Cycle 10

Cycle 1 Cycle 7

Cycle 2 Cycle 8

Cycle 3 Cycle 9

Cycle 4 Cycle 10

Cycle 5 Cycle 11

Cycle 6

Cycle 1 Cycle 7

Cycle 2 Cycle 8

Cycle 3 Cycle 9

Cycle 4 Cycle 10

Cycle 5 Cycle 11

Cycle 6 Cycle 12

Cycle timing by float type • For PROVOR, ARVOR, SOLO-II, NAVIS, NOVA

and recent APEX with Iridium, most cycle timing information is transmitted and clock drift is minimized

• For SOLO, surface time is constant and well known. Calculate additional time not accounted for in surface fixes and split it, adding half to both sides works fairly well

• For APEX floats with Argos, it becomes more difficult as the surface time is not constant. Must rely on DACs filling the AET and TET or do an estimate of TET independently

• For floats with Iridium, extrapolation is not always possible as sometimes only one location is received. Since GPS fix is fast and accurate, not as critical right now

😊

Applied first algorithm from DAC cookbook to estimate TET from

maximum envelope of Last Message Time for APEX Argos floats

AET is

magenta

TST is cyan

FMT is red

Fixes are blue

LMT is red

TET is cyan

Cycle

nu

mb

er

JULD referenced to cycle #1

5901015

Gives a surface

time that varies

from ~ 9 to 13

hours

Cycle

num

ber

JULD referenced to cycle #1

AET is magenta

TST is cyan

FMT is red

Fixes are blue

LMT is red

TET real time estimate by DAC is magenta

TET by envelope method is cyan

Two different examples of real time

TET estimates currently done by

DACs

One to the right clearly isn’t correct as

it occurs before the last surface fix.

One below is clearly too long after last

surface fix

Examples of anomalous APEX ARGOS floats Odd AET and TST

Cycle

num

ber

JULD referenced to cycle #1

AET is magenta

TST is cyan

FMT is red

Fixes are blue

LMT is red

TET is cyan

5901358

Gives surface

times ~16

hours

Largest

surface time is

~60 hours

• 23 out of 210 cycles are > 16 hours

• Think a decoding error led to anomalous AET and TST

• TET estimation is unaffected, but erroneous surface times for those cycles become clear with visual inspection

• 34 cases like this at

AOML

• 4 cases like this at JMA

• Started removing AET

more than 6 hrs

ahead of first msg

received

• Suggest AOML look at

coding to see if this can

be improved upon since

not as big a problem at

JMA where a large

number of floats

were also analyzed

Bad theoretical cycle time?

• ANDRO work detected an incorrect cycle time in meta.nc

• ANDRO suggests 244 hours, not 245

• If I change it to 244 hours, negative clock drift disappears and the surface times are ~11 hours

Gives a surface

time that varies

from ~10 to 208

hours. Negative

clock drift.

Gives a surface

time ~11 hours.

Still slight clock

drift.

Cycle

num

ber

5901746

JULD referenced to cycle #1

AET is magenta

TST is cyan

FMT is red

Fixes are blue

LMT is red

TET is cyan

• 19 cases like this at

AOML

• 3 cases like this at JMA

• Already check J-P’s

corrected cycle time

•Make sure cycle time is

correct in metadata

Cycle duration anomaly? Clock jump?

Cycle

num

ber

JULD referenced to cycle #1

AET is magenta

TST is cyan

FMT is red

Fixes are blue

LMT is red

TET is cyan

5900634

Gives surface times

that varies from ~ 10 to

14 hours for top section

and ~260 hours for

bottom section

• ANDRO suggests this should be processed by slices to get two separate TET envelopes

• When split into slices, surface times are ~10 to 14 hours

• 3 cases like this at

AOML

• 10 cases like this at JMA

• Not a frequent problem,

but severely bad

estimates of TET

when it occurs

• Stop filling TET in real

time?

• Keep track of these

floats and adjust

break points in real

time?

• Allow DAC to choose?

Anomalous cycle?

Cycle

num

ber

JULD referenced to cycle #1

AET is magenta

TST is cyan

FMT is red

Fixes are blue

LMT is red

TET is cyan

5901685

Surface time for

odd cycle is ~12

hours. Surface

times for all

others is ~24

hours

• TET estimate determined by one odd cycle

• Removed that cycle and reprocessed – gives surface times ~12 hours

• J-P suggests this is a problem with the float and not with decoding

• 6 cases like this at

AOML

• 8 cases like this at JMA

• 3 cases like this at

CSIRO (only had 5

floats in region)

• More investigation

needed as to why this

occurs

Overall APEX floats stats from North Pacific

• 6 floats not used because of bad data in file • 22 floats had major clock drift which wasn’t easily

correctable

• 30 needed extra attention due to clock jump or bad points setting the TET env

• 38 had bad AET times needing attention

• Overall, ~30 floats (2%) excluded, ~70 floats (%6) needing extra help/time

• Still need to look at each float TET estimation plot by eye to ensure it is ok – delayed mode procedure

Zonal velocities at the equator ± 2° in Pacific Ocean 9275 velocity estimates

based on:

213 floats in the region

- 142 APEX ( 78

Argos, 64 Iridium)

- 38 SOLO

- 22 NAVIS with

Iridium

- 11 PROVOR

Excluded 5 out of 78

APEX floats w/ Argos

Removed individual cycles

from 3 other APEX Argos

floats

Mean of 55 estimates per

10° x 1 month bin

Thoughts on Real Time Traj V3.0 files

• Should make files easier to use – clearly labeling each measurement with a code indicates which cycle the measurement belongs in and where in the cycle it occurs

• Encourage DACs to begin creating 3.0 files, even if no additional cycle timing information is added for APEX ARGOS floats

• Consider adding some additional real time tests to prevent ghost messages from becoming part of the file and to prevent data from several cycles being included in one cycle

• Newer float models have the additional cycle times available and they are not included in V2.3 traj files – we are losing valuable information

• Cycle timings will improve as newer float models and high speed communications become a larger part of the Argo data stream

Thoughts on delayed mode for traj files

• Need to start delayed mode quality control on trajectory files

• What needs to be done in dmode and how will it be done? – Some things will vary with float type; others will be the same

– Form a working group to begin documenting dmode process for traj files

• Who will do this dmode on trajectory files? – Float’s owner

– Float expert who understands the float behavior (ie ANDRO work)

– Combination of the two?

• When will it occur? – Yearly when dmode is done on the prof file to apply salinity and pres

adjustments?

– Cycle timing estimates may vary depending on float type

• Look at APEX ARGOS floats yearly to estimate TET?

• Wait until SOLO floats die to estimate cycle times