Historical notes on using DataViewer and
Diagnostic Test Tools (version 1.2 and earlier)
with data on disk

Peter Shawhan
January 31, 2002

Dataviewer, and the Diagnostic Test Tools suite, were designed to get their data directly from a server using LIGO's "NDS" (Network Data Server) protocol. Neither one has the ability to read data from disk. However, Daniel Sigg has implemented a scheme to allow data to be read from disk, by starting up a "mini-NDS" process in the background in such cases. In the future, one or both programs will be upgraded to be able to read conveniently from disk.

The "mini-NDS" is really just a special version of the LIGO "daqd" data acquisition program, using only its playback capabilities. This scheme requires a rather specific organization for the data on disk: it must be stored in frame files, each containing one second of data, and with the GPS time indicated in the filename, e.g. "H-659554975.F". (Note that names containing other numbers, e.g. "NORMAL1234-H-659554975.F", are not allowed. Also, it seems that the suffix cannot be arbitrarily long--for instance, files ending in .NORMAL don't work.) The files must be stored in directories with a specific naming convention: the first one must have a name of the form something.0, and if there are more in the sequence, they must be named something.1, something.2, etc. (Here, "something" can be replaced by any name you want.) For example, in my /home/pshawhan/data directory I might create the subdirectories e2data.0, e2data.1, and e2data.2, and put the files
H-657760000.F, H-657760001.F, ... through H-657760999.F into e2data.0 ;
H-657761000.F through H-657761999.F into e2data.1 ; and
H-657762000.F through H-657762999.F into e2data.2.

The reduced data sets (RDS's) written to disk during the engineering runs (at least through E3) are stored on fortress (at LHO) and decatur (at LLO) on the /export/raid* disks according to this convention, so if you are logged into one of those machines and want to look at the RDS data, skip the following two paragraphs and go directing to starting up dtt.

Note added following the E7 run: Beginning with version 4.3 of the dataflow package, you can use the getFrames utility to retrieve remote data and write it to disk as 1-second-long frame files in a subdirectory, by using the '-1' flag. This saves you the step of splitting up a big frame file as described in the following paragraph.

If you have a single frame file containing many one-second frames (for instance, if you used getFrames to retrieve a stretch of data from the central archive or from some other LARS server), then there is a utility called FrSplit which splits the data into individual one-second frame files. For example, if the file is called bigfile.F and contains 3000 frames, then:
  FrSplit -i bigfile.F -o datadir -n 1000
creates three directories, datadir.0, datadir.1, and datadir.2, and puts 1000 one-second frame files with appropriate names (H-667560000.F, H-667560001.F, etc.) into each directory. This is the proper organization for the next step.

To analyze this data with Dataviewer or with one of the DTT utilities (e.g. Fourier Tools), do the following:

For Dataviewer, use the "Playback" menu choice to view the data. Here are a few things to remember:

For DTT clients (Fourier Tools and Triggered Time Series), choose the desired channels and parameters and enter the start time, in GPS seconds or UTC date/time, for the data interval you want to look at. Also remember to click on the circle next to the time you specify. (If you get the status message "Test timed-out", you probably forgot to do this.) Finally, be sure to hit Return after you enter the time--otherwise, it may not register! (If you get a "Data receiving error" or "Synchronization error", it is probably because the frame file directory you are currently pointing to does not contain data for the time you specified, or else you forgot to hit Return to register the time you entered.)