Trajectory V3.1 File Update Megan Scanderbeg, J. Gilson, N. Zilberman. Argo Steering Team Meeting March 2016

Transcription

1 Trajectory V3.1 File Update Megan Scanderbeg, J. Gilson, N. Zilberman Argo Steering Team Meeting March 2016

2 Papers using Argo trajectory files 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 2 0

3 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 BODC Coriolis PROVOR, ARVOR CSIO PROVOR, ARVOR CSIRO APEX w/ ARGOS INCOIS PROVOR, ARVOR JMA KMA KORDI MEDS APEX, NOVA NMDIS ARVOR Progress 12%

4 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

5 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

6 Float cycle timing information Sending back crucial timing information APEX APF9i with firmware revision or later ARVOR/PROVOR NAVIS NINJA from and Deep NINJA NOVA SOLO-II/S2A Not sending back crucial timing information APEX APF8, APF9a and t, APF9i with firmware revision before 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.

7 APEX APF9i NAVIS ARVOR SOLO-II Nova 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? Deployments by year Iridium Argos

8 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

9 Extrapolation method relies on knowing AET/TST and TET/DST and surface locations Surface AST DST DET PST PET DDET AET TST TET Argos/GPS locations Parking pressure Cycle N Profile pressure Cycle N-1 Depth Blue times in V3.1 files only TET, PST and PET can help with drift velocity calculations

10 DAC AOML 927 Coriolis 40 CSIO 3 CSIRO 112 JMA 31 Total 1113 KORDI 1 MEDS 2 Total 1116 # of floats with at least one profile in region Floats in Southern Pacific 140 E to 70 W; 20 S to 40 S 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 SOLO APEX w/ Argos SOLO-II APEX w/iridium PROVOR NAVIS

11 Meridional displacement in km APEX APF8 float In East Australian Current (31 S,154 E) 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 additional 10 km traveled on surface by float surface velocity increases by a factor of 2 Estimated TET using process in Trajectory Cookbook Extrapolation method from Park, et al 2004 zonal displacement in km

12 Meridional displacement in km 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% 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 zonal displacement in km

13 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

14 B-trajectory files Location of all b-profiles on GDACs 462 floats 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

15 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

16 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

17 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.

18 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

19 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