Status of Trajectory Files. Megan Scanderbeg

Transcription

1 Status of Trajectory Files Megan Scanderbeg Argo Steering Team Meeting March 2014

2 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

3 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 (

4 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/corioliscustom/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

5 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

6 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

7 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

8 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

9 JMA float 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 11 Cycle 77 Cycle Cycle 1 Cycle 1 Cycle6 Cycle 1 6 Cycle Cycle 1 Cycle 21 Cycle Cycle Cycle Cycle Cycle Cycle 2 Cycle Cycle Cycle Cycle 2 Cycle Cycle 32 Cycle Cycle Cycle Cycle Cycle 3 Cycle Cycle Cycle Cycle 3 Cycle Cycle Cycle Cycle Cycle Cycle 4 Cycle Cycle 4 9 Cycle Cycle 4 Cycle Cycle Cycle Cycle Cycle 5 Cycle 10 Cycle Cycle 5 Cycle Cycle Cycle 12

10 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

11 Applied first algorithm from DAC cookbook to estimate TET from maximum envelope of Last Message Time for APEX Argos floats Cycle number AET is magenta TST is cyan FMT is red Fixes are blue LMT is red TET is cyan Gives a surface time that varies from ~ 9 to 13 hours JULD referenced to cycle #1

12 Cycle number 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 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

13 Cycle number Examples of anomalous APEX ARGOS floats 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 Odd AET and TST Gives surface times ~16 hours Largest surface time is ~60 hours AET is magenta TST is cyan FMT is red Fixes are blue LMT is red TET is cyan 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 JULD referenced to cycle #1

14 Cycle number 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 AET is magenta TST is cyan FMT is red Fixes are blue LMT is red TET is cyan Gives a surface time ~11 hours. Still slight clock drift. 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 Gives a surface time that varies from ~10 to 208 hours. Negative clock drift. JULD referenced to cycle #1

15 Cycle number Cycle duration anomaly? Clock jump? 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 AET is magenta TST is cyan FMT is red Fixes are blue LMT is red TET is cyan 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? Gives surface times that varies from ~ 10 to 14 hours for top section and ~260 hours for bottom section JULD referenced to cycle #1

16 Cycle number Anomalous cycle? 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 cases like this at AOML AET is magenta TST is cyan 8 cases like this at JMA FMT is red 3 cases Fixes like are this blue at CSIRO LMT (only is red had 5 TET is cyan floats in region) More investigation needed as to why this occurs Surface time for odd cycle is ~12 hours. Surface times for all others is ~24 hours JULD referenced to cycle #1

17 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

18 Zonal velocities at the equator ± 2 in Pacific Ocean 9275 velocity estimates based on: 213 floats in the region 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

19 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

20 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