TCCON > Sites > Bremen > Instrument History

Instrument History

Table of contents
  1. 1. Ghost correction

This is a belated attempt to fill in some of the history of the instrument. It will form over time with re-processing of spectra and so forth.

 

August 7, 2013

Upon start-up this morning, the tracker attempted suicide by self-strangulation, and made at least two laps over the limit switches in the wrong direction. We bent the limit switches levers back to something resembling normal position, and followed the instructions for re-setting the zero of the tracker encoder. This seemed to work okay, but we are waiting for new limit switches and then will re-test the tracker performance.

July 24, 2013

A repeat of the beamsplitter troubles described below. This time, we measured the width of the beamsplitters and found that there are actually the same width. We did, however, notice the the lever was going far enought to cause the gate to start to open again. We adjusted the screw that limits the lever so that it reached maximum leverage/minimum distance - i.e. clamping the beamsplitter most strongly. So far (to August 9) we have had no further problems.

July 11-12, 2013

After a beamsplitter change, the instrument failed to recognise the beamsplitter or start the scanner. Returning to the previous (KBr) beamsplitter didn't solve the problem. With the KBr, there was a range of spots with the lever not fully closed, where it was recognised. In the end, it seemed to be a contact problem, and some fiddling with the contacts on the beamsplitter door caused the problem to be resolved. It's possibly caused by the different widths of the KBr and CaF2 beamsplitters causing some deformation of the contacts. The CaF2 beamsplitter will be effectively widened with some spacers behind the contact board to try to eliminate this problem. For now the instrument is working okay.

August 3, 2012

First measurements after the replacement of the failing SIOS laser.

 

 

Ghost correction

The Bremen record is affected by ghosts, and cannot be corrected using the i2s correction method, because there are no simultaneous Si spectra. Therefore, we implement the Dohe et al method to derive and correct for ghosts. This means determining spectra with sufficient H2O line of sight columns, and averaging enough to be able to see the ghosts (in the 7290-7360 region, mirroring 8438-8508).

We run this in an automated fashion, using a python program and calling 'resample-opus', which increments the imposed LSE correction in order to see at which value a minimum is reached. This is used to generate a time series of necessary LSEs. These are then implemented via the opus-i2s.in file, in the final two columns for each spectrum (value, uncertainty).

After correcting, we visually inspect the averaged spectra for all days when there exist enough with sufficient H2O. This provides a secondary check on the efficacy of the correction. In some cases, the derived sign of the correction is incorrect - this shows up obviously, and can be easily fixed. Generally, after this process, the correction appears to work well. There are, however, some days where some evidence of ghosts remains. These appear to be due to ZLOs and possibly other effects.

In summary, the current state of the LSE corrections applied is:

STARTDATE ENDDATE  LSE              Uncertainty Approved (Yes/No)
20060101 20060213 -0.0040 0.0005 No (some remaining ghost) - suggest discarding
20060320 20060930 -0.0040 0.0005 Yes
20061001 20080724 -0.0030 0.0005 Yes
20080725 20080911 -0.0020 0.0002 Yes
20080912 20080912 -0.0020 0.0002 No (obvious ghost, undercorrected)
20080913 20090617 -0.0020 0.0002 Yes
20090623 20131231 0.0000 0.0000 Yes
20140127 20141127 -0.0010 0.0005 Yes
         

 

 GFITting is done...

 

Some interesting features crop up... particularly when trying to use generate_qc_flag. Numerous spectra trigger the qc code ordering assumption violated STOP in the code. This occurs when two spectra in the runlog are too close together in time (<0.0025 hours = 9 seconds). Sometimes that happens with short scans (e.g. 4.51 cm instead of 45.01 cm), but other times there appears to be nothing unusual about the spectra. E.g. on 20080925, spectrum 062 appears before 061. 062 is the reverse scan of the spectrum where 061 is the forward scan

Days in 2007 also trigger this. E.g. 20070716, where some spectra are apparently only 0.0011 apart. Some of the short times are due to 20kHz sampling rate and a coarse phase resolution (55cm-1).

I implemented some date filtering, to remove early 2006 (before 20060213 inclusive) and 20080912, hence the use of generate_qc_flag. Without this, these timing issues would not have been easily seen. collate_results assumes because of the close times that these are not independent spectra, and simply generates an entry for every 2nd spectrum.

So the question remains - how to handle this? For now, I will remove the offending spectra, but a solution should be found and implemented.

The following are the spectra that I have removed to get this all to work:

br20070716, br20070718slh0va.001-010 (lots of delta_t of around 0.0012 hours (4 seconds or so), with low PHR and 20kHz).

br20080623slh0va.013-026 (short scans)

br20080623slh0va.031-044 (short scans)

br20080925slh0va.061-062 (rev ZPD time before fwd)

 

Once those few are removed, all collate_results and qc-flagging runs fine, for all year (2006 to 2014 inclusive).

Some other notes on the data, from examining the xAIR time series:

  • early May 7, 2011 contains outliers (xAIR = 0.975 and below). These correspond to pressure jumps of 0.5% (also in Air column), but O2 retrieval jumps of ~2%. The fit errors are also just below the qcflag criterion of 2% of the VSF, along with poorer signal (CL) and larger tilt (CT).
  • late May 5, 2010 also contains outliers. reason to be investigated
  • large scatter from May 19 0800 to May 23, 2009. reason to be investigated
  • 2008 is relatively noisy, but there does not appear to be any timing errors there. 2008 was a year were there was lots of "Investigation" with the instrument (i.e. the Macatangay effect)
  • Jan 22, 2008 is high
  • Aug 01, 2007 from 0900 has high xAIR values
  • Apr 4, 2007 is noisy
  • Nov 16, 2006 noisy
  • Oct 25, 2006 noisy
  • Aug 7, 2006 noisy
  • there are also a lot of seemingly random outliers in the xAIR time series

 

 I noticed that the FVSI (VDC) filter was not being applied. I set this to filter out spectra where FVSI > 5%, and that improves things greatly. Unfortunately before (and including much of) 2007, no VDC is calculated, so these data are still reasonably scattered. Therefore we need to find an alternative filter, such as the CL or RMS/CL or fractional VSF_error.

There is also a step change in FS at 20061011 to 20061016. Prior, the FS is always 13.6, whereas after it varies and is more reasonable. The fits also become better. Comparing the spectra there is no visible difference in the x-axis (frequency). However, in the earlier spectra pins=0, whereas afterwards pins=pout. This originates from PIM=0 vs PIM>500. I am re-running with pins=pout for all days before 2008 (this should only affect 2006).

 2006 is now re-fitting with updated pins values.

Tag page