A little less rolling and heaving than the ship, but equally air-conditioned and packed with new information, Friday was my first full day in the office. I spent it trying to understand the processing through which the raw data from the ship must go in order to mean something in a language closer to English. First, Fernando, who was kind enough to let me abduct the back desk of his office, explained it to me conceptually. Next I tried to retain this comprehension as I watched Branden, a Computer Science major light-years beyond me in the language of the keyboard, type code into Matlab to execute this processing. Later on, I even tried my hand at Matlab, under Cammy’s supervision. Though I am not a natural born whiz at the keyboard, with a little training I may be able to rapidly type streams of gibberish with the best of them.
What come from the ship are many columns of numbers in engineering language – volts. Every electronic signal from the instruments indicates a value in degrees Celsius, decibars, practical salinity units or micromoles per kilogram. Scripts in Matlab are designed to perform the translation from engineering units to scientific units. While they do this, they also scan for errors in the data. A temperature that reads higher than 40°C, for instance, is an error that would be deleted. If that were a feasible temperature to encounter at sea, I would be in trouble.
After that translation and error screening is complete, you have columns of numbers in a familiar language but they are speaking much too rapidly to comprehend their meaning. Underwater, the CTD records data at a frequency of 24 Hz, or 24 times a second. For practical purposes, this is TMI (too much information.) Run again through a script in Matlab, the data is averaged to a frequency of 2 Hz.
Next you must account for the inherent skewing of data over the course of each cast. The skewing comes from the differences in pressure on the instrument between the downcast and upcast, giving you two slightly different data strings. Some calculations, which the computer seems to find quite simple but I’m sure I would not, match the two lines to the best fit giving you close to one single data string.
Similarly inherent to the operation of the instruments is a time lag between the moments in which each variable are measured. The CTD works like a water slide with several loops through which water must flow. First the water enters through a pump that sends it to the temperature sensor. Next it loops the loop to the conductivity sensor and swirls on to the oxygen sensor before exiting the slide. In order to know that you are looking at the temperature, salinity and oxygen values for the same parcel of water, you must account for the time it takes for the parcel to travel from sensor to sensor. In addition, there is a secondary slide for every variable that must be aligned temporally with the first. There is a Matlab script for this too.
There are many more alterations to the data that were explained to me – some of which I chose not to explain in favor of the more intriguing and understandable processes, many of which escape my memory. Today challenged my capacity to follow computer commands and I am proud of what the steel trap still contains, two days later.
Matlab language lesson for today:
‘Exit’, followed by ‘enter’ means ‘close Matlab, please’
‘y’ means ‘yes’
More to come, I’m sure.
No comments:
Post a Comment