Last modified 11 months ago Last modified on 2019-04-04 14:14:52

Wave and burst dimension notes

update April 4, 2019-

We still say that for bursts, the non-time dimension should be "profile" or "sample" (preferred). I thought dimensions had to also be Coordinate vars, so "sample" should be a variable containing 32768 things (1:32768) (based on here note variables are dimensioned (time, profile), and profile is a variable that contains data from 1:3599. BUT, I looked at vector burst from MVCO-15, and it is structured like this file. Old adv bursts are like this too: The attached PNG showing waves file formats also shows that in some cases dimensions aren't also variables. It doesn’t seem to break anything we test for, but My bad for missing it up to now!

We had a meeting with Rich to discuss this in Sept. 3 2014. From Marinna: For the record I heard today…

  • Keep time, depth, lat, lon dimensions, we declare we use EPIC, and thus must keep them to adhere to EPIC’s gridded philosophy.
  • Use the depth dimension where it makes sense, as in data with profiles – e.g. multiple depth positions (PCADP, ABSS, ADCP, Aquadopp)
  • Burst data shall use the dimension sample, so that time indicated the start of the burst (or the middle??? There’s the next debate), for example ADCP, Seaguage, AWAC, Sontek, ADV, etc.
  • There’s also direction and frequency dimensions for wave spectra
  • I think I can adapt my browser tools to identify things based on the size and presence of the dimensions frequency, depth, sample and direction

From Ellyn: I heard what you heard, and was writing my list as I got yours.

The only exception I am currently aware of is your statement that burst data shall have a "sample" dimension.

The ADCP and AQD burst data from Hatteras has a "profile" dimension instead of "sample".

Here's my list from the discussion to add to Marinna's

  • Seaguage data is fine with the dimensions it has.
  • Pspec in the -p file opens fine in browseWaveStatsNative
  • We have enough variety of instruments that making all exactly the same is impossible
  • We need to keep something resembling a EPIC grid (time, depth, lat, lon) when suitable. For burst data, and spectra, try to make the form resemble something existing.
  • Files may contain lat, lon, depth dimensions that are never used in variables
  • The dimension is more about providing the right shape container for the data than it is about enabling discoverability *having 5-6 dimensions is OK, if needed to properly describe the data
  • We want browseBurstCdfNative to work on all forms of burst data- profile, or single depth. This means ADV, PCADP, ABS, wave (ADCP and AQD) bursts, SG -r files... (I think the ability to pick a single bin out of profile data is as important as displaying the pcolor chart, too) We need to incorporate changes in browseWavesAdqNative to allow aqd and sg data to be displayed
  • the information needed for discovery is in the metadata of our files, and is harvested into the ncML that converts data to CF.

As long as we have lon and lat attributes, we don't really need them as dimensions for discovery, but they are needed to keep EPIC grid representation.

See the attachments on this page for more details'''