How to get OpenDAP working for ROMS model output

Rich Signell sent me this advice on getting DODS/OpenDAP working for my model output:

The 5 step program to a blissful OpenDAP Life

• Inspiration: grab the mexcdf_dap binary for your platform
  and "get_roms_dap.m" at:
  http://cove.whoi.edu/~rsignell/mexcdf_dap Make sure that
  "which mexcdf53" points to your new OpenDAP-enabled mexcdf53
  mex file, and then run the "get_roms_dap" demo script.
  
  
• Kick Ass: Get the IDV http://my.unidata.ucar.edu/content/software/idv/.
  Replace the "idv.jar" file in your IDV installation
  directory with this updated "idv.jar":
  ftp://ftp.unidata.ucar.edu/pub/idv/untested/idv.jar
  Then get http://cove.whoi.edu/~rsignell/john/DefaultIdv_rps.tar.gz
  and unpack it from your "~/.metapps" directory so that it
  overwrites the files in the ~/.metapps/DefaultIdv directory. Start IDV,
  and in the Displays menu, select: Displays=>Favorite
  Bundles=>Adriatic=Test01
  
  
• Good Citizen: Serve your netcdf data via OpenDAP: Grab the "CGI Server
  Base" and "CGI Server NetCDF module" for your web server from
  http://opendap.org/download/index.html and then follow the install
  instructions at: http://opendap.org/server/install-html/install.html
  Basically all you do is unpack the binaries into your cgi-bin directory, edit
  a conf file to point to the places where you have netcdf files, and who can
  have access. It took me 35 minutes to get our OpenDAP server going!
  
  
• Ultimate Citizen: Make a THREDDS catalog
  http://my.unidata.ucar.edu/content/projects/THREDDS
  of your DODS-served data so folks can view it with tools like the IDV.
  These are simple XML files that just tell tools like IDV the protocol and
  location of the data. Check out an example at:
  http://cove.whoi.edu/~rsignell/adria-models.xml
  
  
• Go Uptown: If you want to get a bit fancier, install an aggregation server.
  http://www.opendap.org/server/agg-html/, which just makes it possible for
  groups of files to appear as one.
  

Office of Coast Survey - Historical Maps and Charts

A huge array of historical charts are available online:

Office of Coast Survey - Historical Maps and Charts

They use a goofy format, called MrSid, that must be decoded into something more sensible to use. I use the linux decoder created by Lizardtech found here. Once you decompress the image, you see why they use this format which compresses the image using wavelets.

Below is an image of a historical chart of the Mississippi River Delta first published in 1874 found by searching for key word 'Mississippi'. Click the image for a higher resolution image (still only 1/4 of full resolution).

TGLO skill estimates

Skill estimates for the mooring locations were calculated from a simulation lasting one year: summer 2001 to summer 2002. The largest skill is for buoy D, away from the Mississippi, and near the coast. Most of the skill estimates are around, or beneath zero, indicating that the model error is of a similar magnitude to the variance. The first two columns of numbers are the skill for the east-west and north-south velocities. The third column is the skill for speed. This particular model run had no buoyancy forcing, and represents the 'base' model skill, to which future, improved runs will be compared.

All timeseries use the mean of the data for the 'climatology', which produces the lowest skill estimates (see paper on skill linked below). Also, if the timeseries are filtered more, say with a 3-day boxcar, the skill is increased so that 4 to 5 of the skill estimates are positive.

B : -1.3335 : -0.3682 :-1.4042
D : -0.5348 : 0.2566 :-0.2602
F : -1.2726 : -2.9699 : -2.0598
J : -4.2723 : -0.9684 : -3.1124
K : -0.5815 : -1.4996 : -1.5841
N : -2.9575 : -1.5863 : -0.5991
R : -0.0772 : -0.5407 : -0.3376
S : -2.9290 : -1.9349 : -9.9881
V : -3.6531 : -5.8301 : -0.9598
W : -0.4621 : -0.3207 : -0.3583

Skill paper.

I just submitted this paper to Ocean Modelling. The paper discusses estimating model skill when the primary feature is a descrete event.

yugop.com

This guy makes some very interesting animations.

Surface fluxes added to TGLO/TABS model

We will use monthly averaged, global surface flux data to improve the mixed layer calculations in the TGLO/TABS model. Hopefully, this will improve estimates of mixed layer depth, and estimates of inertial oscillation phase with respect to diurnal wind forcing. Data are available here.

Hurricane Ivan surface currents

Ivan ran through the Gulf, and stirred up some strong currents. Click below to see an animation


MOVIE - whole Gulf [31 MB]
MOVIE - Texas/Louisiana shelf [3 MB]

Summertime TABS model skill assessment

In summertime, the TGLO model does a much poorer job at predicting coastal sea-level. We attribute this primarily to fresh water run off from the Mississippi and other local rivers. Note how the time series diverges in late May, with the measured values higher than the simulated values. Also the simulated SSH seems to 'ring' too much, indicating that the drag in the model is too low, so that the coatally trapped waves are not damped out quickly enough. This seems to be a problem only for very strong storms (compare this figure to the late 2001 figure -- the variations here are much larger due to the magnitude of the blue northers that pass by).


PDF

Comparison of ETA winds and met buoy winds

Les Bender did a very careful study of wind observations as compared to the ETA wind forcasts. The bottom line is that correlation coefficients are between 0.8 and 0.9, meaning that we will not be able to improve this much. This is good news, however, since the correlation is better than we were thinking it might be. It seems that the modeled winds are indeed capturing most of the sea breeze signal.


Les writes:

Here are the preliminary results of analyzing the ETA-12 model winds and
observations taken from 5 TABS buoys, 6 NDBC buoys, and 3 CMAN stations. I
used the ETA-12 hindcast winds, provided by Matt, for the period from
15-Feb-2003 to 31-Oct-2003.

Bottom line: There is room for improvement, though it appears to me that the
NDBC and CMAN winds are already being assimilated.

The Kundu vector correlations and angle of rotation between model and
observations are as follows:

Buoy Correlation Angle, deg Comments
---- ----------- ---------- --------
TABS B 0.858 +1.73
TABS J 0.686 -34.57 The TABS wind sensor is highly suspect during this
period.
TABS K 0.816 +6.06
TABS N 0.832 +10.89
TABS V 0.763 -18.76
NDBC 42001 0.810 -2.91
NDBC 42002 0.800 -15.79
NDBC 42019 0.889 -6.24
NDBC 42020 0.900 -5.20
NDBC 42035 0.893 -5.59
NDBC 42041 0.851 -6.30
CMAN BURL1 0.858 +1.59
CMAN PTAT2 0.885 -17.81
CMAN SRST2 0.848 -4.27

The difference between N and V is striking. It could indicate that one or
both of the wind sensors was faulty.

I have attached a map showing the LATEX region, the model grid points, and
the observation sites. Each of the other figures are, I hope, self
explanatory.

Images are available for comparisons between the winds at these station positions.

NDBC buoy 42001
NDBC buoy 42002
NDBC buoy 42019
NDBC buoy 42020
NDBC buoy 42035
NDBC buoy 42041
NDBC buoy BURL1
NDBC buoy PTAT2
NDBC buoy SRST2

TABS buoy B
TABS buoy J
TABS buoy K
TABS buoy N
TABS buoy V

Running ROMS on clusters - speed comparison

From Rich Signell's Blog, a comparison of clustered computers. Our cluster comes out pretty well.

ROMS "small" benchmark


Here's what I've got so far for the ROMS "BENCHMARK1" test:
(ROMS/TOMS 2.1 - Benchmark Test, Idealized Southern Ocean
Resolution, Grid 01: 0512x0064x030):

8 cpu, 8 node, Scott Doney's 2.8 GHz Xeon cluster (MPI/MPICH, Linux,Myrinet) 2.37 minutes
8 cpu, 8 node, Rob Hetland's 2.8 GHz P4 cluster (MPI/LAM, Linux,Gigabit) 3.95 minutes
8 cpu, 4 node, Scott Doney's 2.8 GHz Xeon cluster (MPI/MPICH, Linux,Myrinet) 4.38 minutes

4 cpu, 4 node, Rob Hetland's 2.8 GHz P4 cluster (MPI/LAM, Linux,Gigabit) 7.43 minutes
4 cpu, 1 node, USGS Alpha ES40 (MPI/HP, Tru64) 9.83 minutes
4 cpu, 1 node, USGS Alpha ES40 (OpenMP, Tru64) 9.53 minutes
4 cpu, 1 node, ERDC Alpha SC40 (MPI/HP, Tru64) 9.83 minutes

2 cpu, 1 node, Sandro Carniel's Dual 1.3 GHz Itanium II (OpenMP, Linux) 10.82 minutes
2 cpu, 2 node, Rob Hetland's 2.8 GHz P4 cluster (MPI/LAM, Linux,Gigabit) 12.53 minutes
2 cpu, 1 node, John Warner's Dual 3.0 GHz Xeon (OpenMP, Cygwin) 16.56 minutes
2 cpu, 1 node, USGS Alpha ES40: (OpenMP, Tru64) 17.68 minutes

Subtidal sea level data skill

A quick look at a hindcast shows pretty good skill when predicting coastal sea level (skill = 0.61). This is surprising, since there seem to be essentially no loop current effects. The errors that are there are most likely due to buoyancy forcing. Take a look (grey line is unfiltered sea level measurements, black is lowpassed (33 hr) measurements, and red is lowpassed model sea level. All time series are demeaned over the time interval shown, but not detrended):


PDF