As of now, the regular LSC DoF triggers work, just as they used to.  There is a problem with the filter module triggers that I haven't figured out yet. 

We can't send integers (like control words for the filter banks) through Choice blocks, since those pass doubles by default.  I fixed that by removing the choice block, but the triggering still isn't happening properly.

We are now locking the arms reliably, with reasonable transmitted power.  We zeroed the LSC offsets with script, since they were apparently not being reset with either the overall burt restore or the arm restore scripts.

We have lost a bit of power through the mode cleaner.  However, we have opted not to tweak it up just yet, so that we don't have to realign to the arms.

I'm leaving the iFO now. It is left with the IR arm mode.

I pretty much messed up LSC configurations for my DRMI locking. If one needs to recover the previous setting, use burtrestore.
I have all records of my LSC settings, so you don't need to preserve it. (Of course we can always use the hourly snapshots
to come back this DRMI setting)

Masayuki was concerned that some LSC channels were giving him all zeros.  After seeing the error in the terminal window running dataviewer (it said something like 'daqd overloaded'), I checked the lsc model, and sure enough, all the test points were used.

So, I found an entry by Jamie (elog 8431) where he reminds us how to clear the test points.  I followed the instructions, and now we're seeing real data (not digital zeros) again.

Today I made a measurement to research the LSC timitng issue as mentioned on Oct.16th.

*method

I put the triangular-wave into the OMC side (OMC-LSC_DRIVER_EXT) by AWG,

then looked at the transferred same signal at the LSC side (LSC_DARM_IN1) by using tdsdata.

I have compared these two signals in time domain to check whether they are the same or not.

In the ideal case it is expected that they are exactly the same.

*preliminary result

The measured data are shown in attached fig.1 and 2.

In the fig.1 it looks like they are the same signal.

However in fig.2 which is just magnified plot of fig.1, it shows a time-delay apparently between them.

The delay time is roughly ~50 micro sec.

The surprising is that the LSC signal is going beyond the OMC signal, although the OMC signal drives the LSC !!

We can say it is "negative delay"...

Anyway we can guess that the time stamp or something is wrong.

*next plan

Tomorrow I'm going to measure the transfer-function between them to see the delay more clearly.

( And I would like to fix the delay. )

You yourself told me that tdsdata uses some downconversion from 32k to 16k!

So, how does the downconversion appears in the measurement?
How does the difference of the sampling rate appears in the measurement?
If you like to understand the delay, you have to dig into the downconversion
issue until you get the EXACT mechanism including the filter coefficients.

AND, is the transfer function the matter now?

As far as the LSC and OMC have some firm relationship, whichever this is phase delay or advance or any kind of filering,
this will not introduce any noise. If so, this is just OK.

In my understanding, the additional noise caused by the clock jitter is the essential problem.
So, did you observe any noise from the data?

I measured the noise spectrum of LSC_DARM_IN1 and OMC-LSC_DRIVE_EXC by using DTT,

while injecting the sin-wave into the OMC-LSC_DRIVE by AWG.

The attached are the results.

No significant differences appears between OMC and LSC in this measurement.

It means, in this measurement we can not figure out any timing noise which might be in LSC-clock.

In addition there are the noise floor, whose level does not change in each 3-figures. The level is about ~4*10^{-8} count/sqrt[Hz]

(The source of the noise floor is still under research.)

I modified the lsc model (after Jamie finished) to use a new triggering scheme.  It HAS NOT yet been compiled and tested, since it's way past time for us to start beatnote-ing.  I will compile, test, debug, etc. tomorrow. Don't compile the LSC model tonight. 

Now we also have (assuming no bugs.....) triggering capability for the filter modules in the filter banks.  Yay!  Testing, etc will commence tomorrow.

The LSC triggers for the individual filter modules in a filter bank now works.  This is handy so that boosts can come on as soon as a cavity is locked, but will turn off when the cavity unlocks.

You choose which filter modules you want to be triggered, and which ones you want to be manually controlled. 

Example:  LSC-YARM    FM4 and FM5 should always be on, but FM2 and FM3 are controlled by the trigger.  You can set the trigger thresholds for the filter modules independently of the main DoF enable trigger thresholds.

I though that the "C1LSC_TRIG_MTRX" MEDM screen completely controls the triggring of LSC signals. But today while trying to trigger the X-arm locking servo on AS110 instead of TRX, I found some strange behaviour. Summary of important points:

1. Even though the servo was supposed to be triggered on AS110, the act of me blocking the beam on the EX table destroyed the lock. I verified the correlation between me blocking the beam and the lock being destroyed by repeating the blocking at least 10 times at different locations along the beam path (to make sure I wasn't accidentally clipping the Oplev beam for example).
2. Investigating further, I found that me turning off the TRX signal digitally also deterministically led to the X arm lock being lost. To be clear, the TRX DC element in the trigger matrix was 0.
3. Confirmed that TRX wasn't involved in any way in the locking servo (I was checking for normalization of the PDH error signal by the DC transmission value, but this is not done). To do this, I locked the arm, and then turned all elements corresponding to TRX in the PowNorm matrix to 0. Then I disabled the locking servo and re-enabled it, and the lock was readily re-acquired readily.

All very strange, not sure what's going on here. The simulink model diagram also didn't give me any clues. Need's further investigation.

The 40m lab was visited by  ~ 30 LSC members  the end of last week.

The big hold-up with getting the LSC whitening triggering ready has been a problem with running the c-code on the front end models.  That problem has now been solved (Thanks Alex!), so I can move forward.

The background:

We want the RFPD whitening filters to be OFF while in acquisition mode, but after we lock, we want to turn the analog whitening (and the digital compensation) ON.  The difference between this and the other DoF and filter module triggers is that we must parse the input matrix to see which PD is being used for locking at that time.  It is the c-code that parses this matrix that has been causing trouble.  I have been testing this code on the c1tst.mdl, which runs on the Y-end computer.  Every time I tried to compile and run the c1tst model, the entire Y-end computer would crash.

The solution:

Alex came over to look at things with Jamie and me.  In the 2.5 version of the RCG (which we are still using), there is an optimization flag "-O3" in the make file.  This optimization, while it can make models run a little faster, has been known in the past to cause problems.  Here at the 40m, our make files had an if-statement, so that the c1pem model would compile using the "-O" optimization flag instead, so clearly we had seen the problem here before, probably when Masha was here and running the neural network code on the pem model.  In the RCG 2.6 release, all models are compiled using the "-O" flag.  We tried compiling the c1tst model with this "-O" optimization, and the model started and the computer is just fine.  This solved the problem.

Since we are going to upgrade to RCG 2.6 in the near-ish future anyway, Alex changed our make files so that all models will now compile with the "-O" flag.  We should monitor other models when we recompile them, to make sure none of them start running long with the different optimization. 

The future:

Implement LSC whitening triggering!

[Jenne, Koji]

We have tested the LSC whitening filters. In summary, they show the transfer functions mostly as expected (15Hz zerox2, 150Hz pole x2).
Only CH26 (related to the slow channel "C1:LSC-PD9_I2_WhiteGain. VAL NMS", which has PD10I label in MEDM) showed different
phase response. Could it be an anti aliasing filter bypassed???

The 32 transfer functions obtained will be fit and summarized by the ZPK parameters.

Method:

The CDS system was used in order to get the transfer functions
- For this purpose, three filter modules ("LSC-XXX_I", "LSC-XXX_Q", "LSC-XXX_DC") were added to c1lsc
in order to allow us to access to the unused ADC channels. Those filter modules have terminated outputs.
The model was built and installed. FB was restarted in order to accomodate the new channels.

- Borrow a channel from ETMY UL coil output mon. Drag the cable from the ETMY rack to the LSC analog rack.
- Use 7 BNC Ts to split the signal in to 8 SMA cables.
- Put those 8 signals into each whitening filter module.

- The excitation signal was injected to C1:SUS-ETMY_ULCOIL_EXC by AWGGUI.
- The transfer functions were measured by DTT.
- The excitation signal was filtered by the filter zpk([150;150],[15;15],1,"n")
   so that the whitened output get flat so as to ensure the S/N of the measurement.

- For the switching, we have connected the CONTEC Binary Output Test board to the BIO adapter module
   in stead of the flat cable from the BIO card. This allow us to switch the individual channels manually.

- The whitening filters of 7 channels were turned on, while the last one is left turned off.
- We believe that the transfer functions are flat and equivalent if the filters are turned off.
- Use the "off" channel as the reference and measure the transfer functions of the other channels.
- This removes the effect of the anti imaging filter at ETMY.

- Once the measurement of the 7 channels are done, switch the role of the channels and take the transfer function for the remaining one channel.

Result:

- We found the following channel assignment

• The ADC channels and the PDs. This was known and just a confirmation. 
• The ADC channels and the WF filter on MEDM (and name of the slow channel)

- We found that the binary IO cable at the back of the whitening filter module for ADC CH00-CH07 were not connected properly.
This was because the pins of the backplane connector were bent. We fixed the pins and the connector has been properly inserted.

- CH26 (related to the slow channel "C1:LSC-PD9_I2_WhiteGain. VAL NMS", which has PD10I label in MEDM) showed different
phase response from the others although the amplitude response is identical.

Summary of the channel assignment (THEY ARE OBSOLETE - SEPT 20, 2011)

ADC                    Whitening Filter
CH  PD                 name in medm   related slow channel name for gain
---------------------------------------------------------------------------
00  POY11I             PD1I           C1:LSC-ASPD1_I_WhiteGain. VAL NMS
01  POY11Q             PD1Q           C1:LSC-ASPD1_Q_WhiteGain. VAL NMS
02  POX11I             PD2I           C1:LSC-SPD1_I_WhiteGain. VAL NMS
03  POX11Q             PD2Q           C1:LSC-SPD1_Q_WhiteGain. VAL NMS
04  REFL11I            PD3I           C1:LSC-POB1_I_WhiteGain. VAL NMS
05  REFL11Q            PD3Q           C1:LSC-POB1_Q_WhiteGain. VAL NMS
06  AS11I              PD4I           C1:LSC-ASPD2_I_WhiteGain. VAL NMS
07  AS11Q              PD4Q           C1:LSC-ASPD2_Q_WhiteGain. VAL NMS
08  AS55I              AS55_I         C1:LSC-ASPD1DC_WhiteGain. VAL NMS
09  AS55Q              AS55_Q         C1:LSC-SPD1DC_WhiteGain. VAL NMS
10  REFL55I            PD3_DC         C1:LSC-POB1DC_WhiteGain. VAL NMS
11  REFL55Q            PD4_DC         C1:LSC-PD4DC_WhiteGain. VAL NMS
12  POP55I             PD5_DC         C1:LSC-PD5DC_WhiteGain. VAL NMS
13  POP55Q             PD7_DC         C1:LSC-PD7DC_WhiteGain. VAL NMS
14  REFL165I           PD9_DC         C1:LSC-PD9DC_WhiteGain. VAL NMS
15  REFL165Q           PD11_DC        C1:LSC-PD11DC_WhiteGain. VAL NMS
16  NC (named XXX_I)   PD5I           C1:LSC-SPD2_I_WhiteGain. VAL NMS
17  NC (named XXX_Q)   PD5Q           C1:LSC-SPD2_Q_WhiteGain. VAL NMS
18  AS165I             PD6I           C1:LSC-SPD3_I_WhiteGain. VAL NMS
19  AS165Q             PD6Q           C1:LSC-SPD3_Q_WhiteGain. VAL NMS
20  REFL33I            PD7I           C1:LSC-POB2_I_WhiteGain. VAL NMS
21  REFL33Q            PD7Q           C1:LSC-POB2_Q_WhiteGain. VAL NMS
22  POP22I             PD8I           C1:LSC-ASPD3_I_WhiteGain. VAL NMS
23  POP22Q             PD8Q           C1:LSC-ASPD3_Q_WhiteGain. VAL NMS
24  POP110I            PD9I           C1:LSC-PD9_I1_WhiteGain. VAL NMS
25  POP110Q            PD9Q           C1:LSC-PD9_Q1_WhiteGain. VAL NMS
26  NC (named XXX_DC)  PD10I          C1:LSC-PD9_I2_WhiteGain. VAL NMS
27  POPDC              PD10Q          C1:LSC-PD9_Q2_WhiteGain. VAL NMS
28  POYDC              PD11I          C1:LSC-PD11_I_WhiteGain. VAL NMS
29  POXDC              PD11Q          C1:LSC-PD11_Q_WhiteGain. VAL NMS
30  REFLDC             PD12I          C1:LSC-PD12_I_WhiteGain. VAL NMS
31  ASDC               ASDC           C1:LSC-PD12_Q_WhiteGain. VAL NMS
---------------------------------------------------------------------------

On the back side of 1Y2 rack I found a cable, CAB-1X2-LSC_7, which is supposed to be connected to the whitening filter was disconnected.

I plugged it back and confirmed that the whitening filter is under control of EPICS.

Now all the gain sliders seem to be working because I can change the amplitude of signals with the sliders.

(method)

  To check if the gain sliders are working or not, I intentionally disconnected all the inputs to the whitening filter.

Then I brought a gain slider of interest to the maximum. Due to the big gain I was easily able to see noise lying above ADC noise.

Also if the gain slider is 0 dB, which is the minimum value, the spectrum becomes just ADC noise.

In this way I checked all the gain sliders from PD1 to PD4. The picture below is just an example screenshot when I was doing this test.

Note that each filer is designed to have two poles at 150 Hz and two zeros at 15 Hz.

[Jenne, Annalisa]

We have started working on writing the c-code to parse the LSC input matrix, to see which PD is used for what degree of freedom, and to output a trigger for the PD.  The code is in ..../isc/c1/src, and there is a little block in the LSC code to the left of the triggering stuff.  Right now, the output of the c-code just goes to some temporary EPICS channels, so that we can see if things are working before we actually implement it.  At this time, there is no change to how the LSC model runs.

I can't figure out a bug in my c-code though.  Right now it's all commented out, so that the LSC model would start, but if I try to sum all of the elements in an array, the model compiles fine, but it won't start running.  I'm going to ask Jamie about it tomorrow.  I have a less-tidy backup plan if we can't get this figured out.

If I have time on the IFO to check that this works tomorrow, I expect another few hours of work (2?  3?), and then we'll have whitening filter triggering.

  How about posting a logic flow diagram? Is the idea to trigger only on the power signals to determine the lock state? Is the hysteresis going to be done in the same way as the main filter bank triggers?

More effort at debugging the LSC whitening. 

Today I tried moving things over to the c1tst model, which runs on the y-end computer, but I crashed c1iscey.  I rebuilt the TST model to a known good state, then cycled the power on c1iscey, and the computer came back up fine. 

I have now backed off and am just writing the code inside a little wrapper script, so that I can just compile and test the code completely independent from the realtime system.  Then once I get all the bugs out, I can try again installing on the actual system.

Still, there are no changes to the functionality of the c1lsc model.  There will not be until I get the c-code for matrix parsing debugged.

The logic, in non-diagram form (I'll make a diagram, but so you can read without waiting):

*** C-code

* Inputs is an array of degree of freedom triggers, the same schmidt triggers used for main LSC locking. (This means it also uses the same thresholds as main triggers.  Side note, now that the WAIT command (see below) works, I want to change the filter module triggers to use the same main trigger, and then just wait a specified time before turning on.)

* Parse the LSC input matrix (internal to the c-code).

     * This tells you which photodiode is being used to control which degree of freedom.

* Multiply rows of the LSC input matrix by the degree of freedom triggers (the same trigger as the main LSC triggers, which is a schmidt trigger).

     * This gives a matrix, where non-zero elements indicate that a photodiode is supposed to be used for a degree of freedom, AND that DoF has been triggered (is locked or has flashed).

* Sum along the columns of the matrix.

     * If a column has a non-zero element, that means that that PD quadrature is used, and has been triggered (by any DoF).

* Apply OR to I and Q quadratures of each PD. 

      * Since the phase rotation happens after whitening and dewhitening, if either I_ERR or Q_ERR is requested (used and triggered), we need to turn on the whitening for both channels.  I am hopeful that this doesn't cause problems for cases when we want to use both quadratures of a PD to control 2 degrees of freedom, but I haven't yet put much thought into it.  COMMENTS WELCOME on this point.

*  Output of c-block is array of PD triggers.  So if either AS11I or AS11Q is triggered, output a "1" for the first element, which corresponds to AS11, etc.

*** LSC model

* Give GoTo/From flag for each DoF trigger to the mux of inputs.

* Go through c-code

* Demux outputs into GoTo/From flags, one per PD (one flag for AS11, one for AS55, and one for ASDC...DC elements count separately, even though they're derived from the same physical PD).

* For each PD, trigger flag goes through WAIT c-code

   * This allows you to define a wait time, in seconds, with an EPICS variable. 

   * Starts counting the wait time as soon as it receives a "1".  Resets counter each time it receives a "0".

    * Output of wait function is ANDed with the current (non-delayed) trigger.

         * This allows for cavity to flash, but if it's not still locked after the wait time, don't actually flip any switches.

* Use delayed ANDed trigger to flip the FM1 switch on both the I and Q filterbank for that PD.

I have implemented automatic triggered switching of the analog whitening (and digital dewhitening). 

The trigger is the same as the degree of freedom trigger.  On the LSC RFPD screen there is a space to enter the amount of time (in seconds) you would like to wait between receiving a trigger and actually having the whitening filter switch. 

The trigger logic is as follows: 

* For each column of the LSC input matrix (e.g. AS11 I), check if there is a non-zero element.  If there is a non-zero element (indicating that we are using that PD as the error signal for a degree of freedom), check if the corresponding DoF has been triggered.  Repeat for all columns of the matrix. 

* If either the I or the Q signal from a single PD is being used, send a trigger in the direction of the PD signal conditioning / phase rotation blocks.  (Since the whitening happens before the phase rotation, we want to have the whitening state be the same for both the I and Q signals coming from the demod boards.

* Before actually changing the whitening state, wait for the amount of time indicated on the RFPD overview screen.

* Switch the digital dewhitening.  If the digital dewhitening is on, send a bit over to the binary I/O to switch the analog whitening on.

This required changing the LSC RF_PD library part so that you can send the trigger to the filter bank from outside that part..  This part is in use by all LSC models, so I'll make sure the LLO people are aware of this change before I commit it to the svn.

While I was working on the LSC model, I also put in a wait between the time that the filter module trigger is received, and when it actually switches the filter modules.  So far, this time is defined for a whole filter bank (so all filters for a given DoF still switch at the same time).  If I need to go back and make the timing individual for each filter module, I can do that.  This new EPICS variable (the WAIT) defaults to zero seconds, so the functionality will not change for anyone who uses this part.

These changes also require 2 pieces of c-code:  {userapps}/cds/common/src/wait.c and {userapps}/isc/c1/src/inmtrxparse.c

I'm ~30% of the way through implementing LSC whitening filter triggers.  I think that everything I have done should be compile-able, but please don't compile c1lsc tonight.  I haven't tested it, and some channel names have changed, so I need to fix the LSC screen when I'm not falling asleep.

Also, Rana pointed out that we may not want the whitening to trigger on immediately upon acquiring lock - if there are other modes ringing down in the cavity, or some weird transients, we don't want to amplify those signals.  We want to wait a second or so for them to die down, then turn on analog whitening.  Jamie - do you know how long the "unit delay" delays things in the RCG?  Do those do what I naively think they do?  I'll ask you in the morning.

The unit delay delays for a single cycle, so I think that's not what you want.  I'm not sure that there's an existing part to add delays like that.

We also need to be a little clever about it, though, since we'll want it to flip off if we loose lock during the delay.

Yesterday, Rana, Jessica and I measured the Transfer function from LSC-YARM-EXC to LSC-YARM-IN1. 

The plot below shows the magnitude and the phase of the measured transfer function. It also shows the normalized standard error in the estimated transfer function magnitude; the same quantity can be applied to the phase, only in this case it is interpreted as its standard deviation (not normalized). It is given by

where  is the ordinary coherence function and  is the number of averages used at each point of the estimate, in the case here we used 9 averages. This quantity is of interest to us in order to understand how the accuracy of transfer function measurement affects the ammount of subtraction that can be achieved online.

Since this transfer function is flat from 1-10 Hz (out of phase by 180 deg), this means that we can apply our IIR wiener filters direclty into YARM without taking into account the TF by prefiltering our witnesses with it. Of course this is not the case if we care about subtractions at frequencies higher than 10 Hz, but since we are dealing with seismic noise this is not a concern.

The coherence for this transfer function measurement is shown below,

After having checked old possibilities and deciding I wasn't imagining the lsc.mdl file not working, but working as another name, I tracked Alex down and asked for help.

After scratching our heads, we finally tracked it down to the RCG code itself, as opposed to any existing code.

Apparently, the skeleton.st file (located in /home/controls/cds/advLigoRTS/src/epics/util/) has special additional behavior for models with the following names: lsc, asc, hepi, hepia, asc40m, ascmc, tchsh1, tchsh2.

Alex was unsure what this additional code was for.  To disable it, we went into the skeleton.st file, and changed the name "SEQUENCER_NAME_lsc" to "SEQUENCER_NAME_lsc_removed" where ever it occured.  These names were in #ifdef statements, so now these codes will only be used if the model is named lsc_removed.  This apparently fixed the problem.  Running startlsc now runs the code as it should, and I can proceed to testing the communication to the lsp model.

Alex said he'd try to figure out what these special #ifdef code pieces are intended for and hopefully completely remove them once we've determined we don't need it.

This removes the old sqrt'ing from the inputs to the POW_NORM matrix (was only on the POP110 I/Q) and moves it to the DOF outputs.  Koji wanted this so that he could use the DC signals for normalization both sqrt'd and not sqrt'd.

The POW_NORM medm screen was updated accordingly.

Prior to the locking trials...

scripts/LSC/LSCoffset script had behaved peculiarly:

This script spawns LSC/offset3 in order to remove the dark offset from the channels.
How ever the offsets had been nulled every other PDs
(i.e. The offsets REFL11 I&Q were nulled.
The offsets REFL33 I&Q had been left untouched
The offset REFL55 I&Q had been nulled
and so on.)

I found that the script run many instances of "offset3" scripts in background.
It seemed that tdsavg did not like too many averaging channels at once.

So the "&"s in the LSCoffsets were removed and now the script runs much more slowly,
but works for all of the PDs listed.

I think I have never seen the offsets in REFL33 and REFL165 nulled down to this level before.

I made scripts/LSC/LSCoffsets2.py which is the script to zero the dark offset of all the LSC PD.  The list of PDs is same as the list in scripts/LSC/LSCoffsets. New script average all outputs of PDs parallelly, so we can zero the offsets much faster.

You can define the averaging time, and you can choose the channel for getting the dark offset from INMON or OUT16. You should know that if you use OUT16 channel, the effect of the unwhite filter is not taken into account.

Example usage (at scripts/LSC):

   ./LSCoffsets2.py -d 20 --out16

you can find the help by calling this script with option -h or --help

What do you mean???

What is the effect of the anti-whitening filter?

 so cool!

I could not dare to share my google doc with this site...

Just in case,  granted access to Google docs can be revoked any time from here:

https://www.google.com/accounts/IssuedAuthSubTokens

I entered 40m today at around 1:20 pm and left by 1:45 pm. I entered 104 through the machine shop entry. I did the following:

• I took photos and videos of the PSL table with lights on.
• I uncovered the AP table, took photos and video, and covered it back.
• I went to the X End table and took a video without opening the enclosure.
• Apart from flipping light switches, nothing else should have changed.

I entered 40m today at around 1:10 pm and left by 1:50 pm. I entered 104 through the machine shop entry. I took top view single picture photos of ITMY, BS, AP, ITMX, ETMX and ETMY tables. The latest photos will be put here on the wiki soon.

July
29 Thu BS chamber work: Move cable towers / green steering mirrors / (2 TTs with TT charactrization) / Put the heavy door by 5PM.
30 Fri Pumping down
31 Sat WFS work by Nancy

Aug
1 Sun - 5 Thu WFS work by Nancy
5 Thu PSL Table prep
6 Fri PSL Table prep / Likely to shut down the PSL

9 Mon PSL Table prep / shutting down of the PSL (optional)
10 Tue PSL box Frame lifting
12 Thu PSL table tapping

16 Mon - 17 Tue concrete pouring preparation
19 Thu - 23 Fri Tripod placement
24 Tue - 26 Thu concrete pouring

Rana noticed that recently the temperature inside the lab has been a little bit too high. That might be causing some 'unease' to the computers with the result of making them crash more often.

For the next hours I'll be paying attention to the temperature inside the lab to make sure that it doesn't go out of control and that the environment gets too cold.

 Today the lab is perceptibly cooler.

The temperature around the corner is 73 F.

I got a call from Calum ~830am today saying some facilities people entered the lab, opened the south entrance door, and tripped the alarm in the process. I came to the lab shortly after and was able to reset the alarm by flipping the switch on the alarm box at the south end entrance to "Alarm OFF". Then, I double checked that the door is closed, and re-enabled the alarm. The particle count at the SP table is not unusually high and the lasers (Oplev HeNe and AUX X) were still on, so doesn't look like any lasting damage was done. The facilities people were apparently wearing laser safety goggles.

We held the lab cleaning for the first time since the campus reopening (Attachment 1).
Now we can use some of the desks for the people to live! Thanks for the cooperation.
We relocated a lot of items into the lab.

• The entrance area was cleaned up. We believe that there is no 40m lab stuff left.
  • BHD BS optics was moved to the south optics cabinet. (Attachment 2)
  • DSUB feedthrough flanges were moved to the vacuum area (Attachment 3)
• Some instruments were moved into the lab.
  • The Zurich instrument box
  • KEPCO HV supplies
  • Matsusada HV supplies
• We moved the large pile of SUPERMICROs in the lab. They are around MC2 while the PPE boxes there were moved behind the tube around MC2 area. (Attachment 4)
• We have moved PPE boxes behind the beam tube on XARM behind the SUPERMICRO computer boxes. (Attachment 7)
• ISC/WFS left over components were moved to the pile of the BHD electronics.
  • Front panels (Attachment 5)
  • Components in the boxes (Attachment 6)

We still want to make some more cleaning:

- Electronics workbenches
- Stray setup (cart/wagon in the lab)
- Some leftover on the desks
- Instruments scattered all over the lab
- Ewaste removal

sudo yum install grace

Once again, I found the door to the outside in the control room open when I came in ~1215pm. I closed it.

I moved the N2 check script and the disk usage checking script from the (sudo) crontab of nodus to the controls user crontab on megatron .

Aug

2 Mon - 5 Thu WFS work (Nancy)

2 Mon - 4 Wed

Jenne: Seismometer fix / Seismic measurements on the PSL table
TT characterization (with Koji)
Preparations ETM suspensions (optional: may be in later weeks)

Kiwamu: CDS test for SUS (may be involving Koji)

Alberto: RF system prep.

All: For 5th and 6th: PSL cabling works Koji

5 Thu PSL Table prep
6 Fri PSL Table prep / Likely to shut down the PSL

9 Mon PSL Table prep / shutting down of the PSL (optional)
10 Tue PSL box Frame lifting
12 Thu PSL table tapping

16 Mon - 17 Tue concrete pouring preparation
19 Thu - 23 Fri Tripod placement
24 Tue - 26 Thu concrete pouring

It is feeling cold in the office area. According to the digital wall clock near the coffee machine, it is 19C. Rana bumped the thermostat setpoint up by 2F (from 75F to 77F). We need to setup long-term monitoring.

I was in the lab from 1630-1830. I have located and visually inspected all the parts required for the magnet regluing / optic cleaning parts of the planned vent, except the fresh batches of scpectroscopic grade solvents. I was in the cleanroom part of the clean and bake lab from 1630-1700.

These weren't present last week. The peaks are present in the EX PDH error monitor signal, and so are presumably connected with the green locking system. My goal tonight was to see if the arm length control could be done using the ALS error signal as opposed to POX, but I was not successful.

I looked into this issue today. Initially, my thinking was that I'd somehow caused clipping in the beampath somewhere which was causing this 2kHz excitation. However, on looking at the spectrum of the in-loop error signal today (Attachment #1), I found no evidence of the peak anymore!

Since the vacuum system is in a non-nominal state, and also because my IR ALS beat setup has been hijacked for the MZ interferometer, I don't have an ALS spectrum, but the next step is to try single arm locking using the ALS error signal. To investigate whether the 2kHz peak is a time-dependent feature, I left the EX green locked to the arm (with the SLOW temperature offloading servo ON), hopefully it stays locked overnight...

EX green stayed locked to XARM length overnight without a problem. The spectrogram doesn't show any alarming time varying features around 2 kHz (or at any other frequency).

Larisa Thorne received 40m lab specific, basic safety training. She will attend P. King's Basic Laser Safety Training Session tomorrow.

Larry stopped by today and had to disconnect the m25 machine (this is the 1st GC machine on the left as you walk into the control room) because its IP was conflicting with a machine over in Downs.  Do not use 131.215.115.125 as the IP on this machine as this is already assigned to someone else.  They couldn't figure out the root password to change it which is why it is not currently plugged into the network, and is not to be until an appropriate IP is assigned.

They've asked that whoever set the machine up to please contact them (extension 2974).

I accidently shut off the laser at 19:34 with the emergency shutoff button while trying to tap into a video line for the Sensoray device.