The scripts in this repository fall into the following categories:

• Generate tidal current predictions along drifter trajectories using GOT, TPXO, FES, or HRET:

  • drifters_predict.sh: Driver script to compute tidal currents for all trajectory files in a given directory. The script uses GNU Parallel.
  • drifters_predict_<model>.jl: The worker script that actually synthesizes the requested tides.

• Compute statistics such as residual variance, explained variance, etc., to compare observed currents and predictions for the different models: drift_tide_expl_<ver>.jl.

• Plot maps of residual current variances, etc., using some Wagner projections: drift_tide_expl_show.jl.

• Perform test analyses or non-global example calculations: test.jl, testsmall.jl, testEx1.jl.

• See if one can usefully compute drifter pair statistics: driftpairs.jl.

Usage:

• Prediction of tidal currents from a given tidal current model: Take a look at predict_tide_GOT.jl, and notice how we read the harmonic constants for the currents and then call the HA library to compute the sines and cosines to synthesize the currents at the requested times and locations. The HA library can be downloaded here. I usually install the HA library in its own directory, e.g., at ${HOME}/HA/.

• Prediction of tidal currents from baroclinic tidal SSH: Take a look at predict_tide_HRET.jl. This script goes through the extra work of computing velocity from the surface pressure (SSH), but otherwise it is similar to the other predict_tide scripts.

• Note on generating predictions: The predict_tide scripts are designed to write the predicted currents in a format that mimics the original drifter files. They write currents from different models and constituents to fields with unique names, e.g., u_hret_M2. There is a problem with this, though, in that the files become progressively fragmented on the filesystem as more individual fields are added. At a certain point this will noticeably reduce the performance of i/o on the files, and lead to longer-than-necessary processing times. The easiest solution to this is to copy the files to another filesystem with a lot of free space, delete them from their original locations, and then copy them back. Eventually, it may be worthwhile to think up a better way of organizing the files to make it easier to prepopulate them with empty fields when they are created so that they don't fragment.

• The drift_tide_expl scripts don't do anything fancy, they just loop through the files and fields and accumulate statistics on a 1/4 by 1/4 degree lat/lon grid. Because we want to accumulate statistics for sets of tides, e.g., M2, S2, K1, O1, there is some funky stuff to accumulate the requested sets as it loops over the constituents. Thus, it is important to list the constituents in a particular order so that they are summed into the desired sets.

• The drift_tide_expl_show scripts also don't do anything too fancy, but the vector graphics generated by the pcolorgeo routine can be complex, and will use a lot of bandwidth if you are displaying these on a remote X-window. It is best to get to know these scripts by initially plotting with the default Winston imagesc command, and then use imagegeo. These are much faster than the pcolorgeo.

• Look at the test scripts to see how to analyze individual trajectories or groups of trajectories within small geographic regions.

• Final tips:

  • I often insert stophere which causes the script to fail with a syntax error when I want it to exit at a certain point. I typically code this in a Julia REPL inside an emacs shell, so when the code fails, it is still sitting in the REPL.
  • Look out for code blocks delimited with if (1 == 0) ... end. I use this to comment out large blocks of code.
  • Generally, the most useful computations will occur near the top of a script, and less useful, experimental, or esoteric computations tend to fall to the bottom of a script. The freshest code is usually at the top of the file, before the first stophere.