I am not so happy with the control signals that are coming into the OAF via the RFM/Dolphin/shmem. 

The MCL/MCF signal travels via RFM from the IOO computer to the RFM model on the SUS computer, and then via dolphin to the OAF model on the LSC computer.

The MICH and PRCL signals travel via shmem from the LSC model to the OAF model, all on the LSC computer.  They don't go through the RFM model.

The seismometer channels travel via shmem between the PEM model on the SUS computer and the RFM model on the SUS computer, and then via dolphin between the SUS computer and the OAF model on the LSC computer.

Each pdf shows the power spectrum and a time series of the signals in their "original" model, and in the OAF model.  The seismometer is the only one that seems fine.  The time series match, except for a delay which is not surprising, since the signals have to travel.  The other signals seem pretty distorted.  What is going on??? Why can we trust some, but not all, of the signals that move between models and between computers???

 (This data was all taken while the MC was locked, but MICH and PRCL were not.  I don't think this should have any effect on the signal transfer though).

The MCL isn't soooo bad, so maybe we can keep moving forward with it, but I'm concerned that we're not really going to be successful OAF-ing the other degrees of freedom if the signals are so distorted.

[Katrin / Kiwamu]
The beat-note between the PSL green laser and the Y end green laser was successfully detected.
The detection was done by the new broad-band RFPD.
The next step will be an extraction of the frequency fluctuation signal using the delay-line-mixer frequency discriminator.

(What we did)
 + Connected a BNC cable which goes from the c1iscey's DAC to the laser slow input
    => this enables a remote control of the laser frequency via the temeperature actuation
 + Realigned the beam pointing of the Y end green laser
 + Installed all the necessary optics on the PSL table
     => currently the PSL green light is adjusted to completely S-polarization
 + readjusted the mode matching telescopes
     => the Y green beam becomes the one with a long Rayleigh range
 + Health check on the broad-band RFPD to see if it is working
 + Installed the BB-RFPD with a +/-15V power supply
 + Fine alignment of the beam combining path
 + Fine tuning of the Y end laser temperature
     => T_PSL = 31.72 deg when the slow FSS feedback is zero.
     => Based on Bryan's measurement (see #elog) the Y end laser temperature was adjusted to 34.0 deg by applying an offset to the slow input.
 + Found the beat note at 100 MHz or so.
     => optimizing the alignment of the beam combining path by maximizing the peak height of the beat-note.
     => maximum peak height observed with an RF spectrum analyzer was about -36 dBm.

The WFS servo loop will come on 5 seconds after the MC is locked. 

I have uncommented the lines in the mcup script which turn on the WFS servos.  But I shifted their location to the part after the MC is locked.

Put the accelerometers on top of MC2. Orientated as the arms,GUR1 and STS1:

Should be fixed a bit more rigidly.

Looking into the signals at a quiet time:

Hmm. Either the acc. are mislabeled or there is really bad x-y coupling. The connectors in the back of the acc. power supply / amplifier box are in ascending order.

With the loops closed I ran the $SCRIPTS/MC/WFS/senseWFSoutMATRX script and analysed the lockin outputs with $SCRIPTS/MC/WFS/matlab/wfsmatrix3.m.  I had to edit both the setupWFSlockins and the sensWFSoutMATRX scripts because in the past we used to switch on / off the ASC filter bank GAINs on the MC suspensions to start / stop the lockin excitation.  We cannot do this any more since these the WFS feedback signals have to get through these filters while the WFS loops are closed.  So the current, more sensible, scheme is to set the appropriate elements to 1 / 0 in the C1IOO_LKIN_OUT_MTRX.

Note:  The senseMCdecenter script will also have to be ammended in the same manner.

The lockin outputs measured are (reduceddata):

             wfs1P    wfs2P       mc2tP        wfs1Y     wfs2Y       mc2tY

MC1P  -10.3694    7.0642  -10.2133   -0.1025    0.4653   -0.0000
MC2P    8.2838   21.5141    8.4102   -0.2215    0.0734    0.0000
MC3P    9.4804    6.0835    9.6346   -0.0080    0.0366   -0.0000
MC1Y   -0.7339   -1.4498   -0.6175  -11.7502  -13.0480    0.0004
MC2Y    0.9004    0.6645    1.0554   25.6083    7.3399   -0.0046
MC3Y   -0.2914    2.1573   -0.1829   -2.1130   14.3038   -0.0000
 

After inverting and normalising a subset of the above matrix ( done in the wfsmatrix3.m )  we obtain the following output matrix coefs:

Apart from a negative sign (introduced by the negative gains in the WFS servo filters ) these values are quite close to the actuation vectors determined in open loop.

I have plugged these values into the WFS output matrix.  Will determine the open loop gain later when there arent so many people stomping around the MC.

Very elaborated measurement ;-)

On 11-11-08:
18:40 Stomp near STS1 for 2mins
18:47 Jump near GUR1 for 2mins
18:52 Walk from MC2 approx. half-way to vertex for 2mins

Tried to see if jumping / stomping the ground near STS1 / vertex or GUR1 / MC2 would show up in the seismometer or MC length data.
In GUR1 jumping / stomping clearly shows up in the timeseries. Also it clearly shows up as a low frequency signal if you walk to a position near MC2. E.g. walk from the vertex to MC2. Stop near the cones. Gives a big dip on GUR1X, that recovers in 10-20sec if you remain stationary. Big "hill" if you come from x-arm end and stop on the x side of MC2. So probably lots of tilt to GUR1X coupling at low frequencies.

Nothing was really visible in spectra (see below).

Resonances:

There appear to be a lot of resonances in the 10-20Hz range, see e.g. 1st attached pic.

Coherence:

Looking at the coherence of difference axis of the seismometers. Kind of dirty measurement, could have all kinds of reasons.
Quite a bit of coherence in STS1 at 5-6Hz. Possibly limiting the STS1X to MC-F coherence to up to 4Hz?

Elog was not responding and was restarted.

The c1iscex IO chassis seems to be working again, and the iscex front-end is running again.

However, I can't say that I actually fixed the problem.

Originally I thought the timing slave board had died by the fact that the front LED indicators next to the fiber IO were out.  I didn't initially consider this a power supply problem since there were other leds on the board that were lit.  I finally managed to track down Rolf to give downs the OK to pull the timing boards out of a spare IO chassis for us to use.  However, when I replaced the timing boards in the chassis with the new ones, they showed the exact same behavior.

I then checked the power to the timing boards, which comes off a 2-pin connector from the backplane board in the back of the IO chassis.  Apparently it's supposed to be 12V, but it was only showing ~2.75V.  Since it was showing the same behavior for both timing boards, I assumed that the issue was on the IO chassis backplane.

I (with the help of Todd Etzel) started pulling cards out of the IO chassis (while power cycling appropriately, of course) to see if that changed anything.  After pulling out both the ADC and DAC cards, the timing system then came up fine, with full power.  The weird part is that everything then stayed fine after we started plugging all the cards back in.  We eventually got back to the fully assembled configuration with everything working.  But, nothing was changed, other than just re-seating all the cards.

Clearly there's some sort of flaky connection on the IO chassis board.  Something is prone to shorting, or something, that overloads the power supply and causes the voltage supply to the timing card to drop.

All I can do at this point is keep an eye on it and go through another round of debugging if it happens again.

If it does happen again, I ask that everyone please not touch the IO chassis and let me look at it first.  I want to try to poke around before anyone giggles any cables so I can track down where the issue might be.

Jamie did computer magic.  I burt restored scxepics, and restored ETMX damping.

Indeed it is strange. I took a quick look at it.

In order to recover the same condition (e.g. the same amount of the reflected DC light and the same temperature readout),

it needed to have +8.9V in the slow input from the DAC through EPICS.

Obviously applying an offset in the slow input to maintain the same condition is not good.

It needs another solution to maintain the sweet frequency where the frequency of the PSL and the Y end laser is close in a range of 200 MHz.

Difficult to understand.

The mode matching does not change the recycling gain. It changes the coupling of the incident light into the cavity.
It changes the reflected and accumulated power, but the recycling gain is not affected.

The recycling gain is determined by the optical configuration and the optical loss in the cavity.

In the actual measurement, of course, we should take both of the loss and the mode matching into account.
But this is the issue of the measurement method.

The essential questions are:
How much is the actual recycling gain? And how does it affect the signal extraction?

Goal of this week :  ALS on the Y arm

Minimum success : Detection of the green beatnote between the freq-doubled PSL and the Y arm transmitted light

EDIT by KI:

  The definition of the recycling gain is wrong here.

See the latest entry (#5875)

Here is a summary about the Power Recycled Michelson (PRMI).

It seems the mode matching is also one of the greatest contributor on the low recycling gain.

 (Estimated parameters)

     +  Loss = 5.3% (or effective reflectivity of  93.28% in Michleson) => Under coupling !!

     +  Mode matching efficiency = 47.4 %  => Really bad !!

   With these values we end up with a recycling gain of 7 and a normalized REFLDC of  0.5 as observed (#5773).

Also according the incident beam scan measurement (#5773) the loss is NOT a local effect like a clipping, it is more like uniformly distributed thing.

As for the mode matching, the number indicates that approximately the half of the incident light is coming back to the REFL port without interacting with PRMI.

This is bad because the non-mode-matched light, which is just a junk light, is entering into the photo detectors unnecessarily.

In the worst scenario, those junk light may create a funny signal, for example a signal sensitive to the alignment of PRM.

(Estimation method)

The method to estimate the loss and the MM (Mode-Matching efficiency) is essentially the same as before (#5541).

One difference from the previous estimation is that the I used more realistic parameters on the transmissivity of ITMs and PRM :

     PRM : T = 5.637 %  (see the 40m wiki)

     ITM : T = 1.384 %  (see the 40m wiki)

 In addition to the basic calculations I also made plots which are handy for figuring out where we are.

Quantities we can measure are the reflected light from PRMI and the recycling gain using the REFL PD and the POY PD respectively.

So I wanted to see how the loss and MM can be estimated from the measured REFL DC and recycling gain.

The plots below are the ones.

[Loss map]

 The first figure shows a contour map of the loss as a function of the measured REFL DC and recycling gain.

The white area is a place where no proper solutions can be found (for example MM can get to more than 100 or loss becomes negative).

The star mark in the plot corresponds to the place where we are now. Obviously the loss is about 5%.

If we somehow decrease the amount of the loss the star mark will mostly go up in the plot.

[MM map]
 The second figure shows a contour map of the MM as a function of the measured REFL DC and recycling gain. 

The X and Y axis are exactly the same as that of the first plot. Again the star mark represents the place where we are.

We are currently at MM=47%

(Solutions)

Here are some solutions to bring the recycling gain higher.

We don't work on these things immediately since it requires opening of the chambers again and it will take some times.

But we should think about those options and prepare some stuff for a coming vent.

  + Refinement of the position of the mode matching telescopes.  => The Recycling gain can go up to 15.

     => Assuming the loss in the cavity doesn't change, the star mark in the first plot will go to the left hand side along the "0.05" black solid line.

     => However PRMI will be still under coupled.

     => Needs an estimation about which way we move the telescopes.

 + Locate the place of the dominant loss source and reduce it somehow.

    => The recycling gain will be more than 18 if the loss reduces by a factor of more than 5.

    => Needs a clever way to find it otherwise we have to do it in the classical way (i.e. white light and trying to find dirty surfaces)

As described in elog 2063 and the mevans document, we need to measure the TF of the OAF's plant, to find the delay.

At DC, the phase is 2.5deg, and at 32Hz, the delay is -4.6Hz (extrapolated from the points at ~30deg and ~38deg).  The DTT file is in /users/Templates/OAF/OAF-MCL-Delay-9Nov2011.xml . 

This gives a phase lag of 7.1deg at the Nyquist freq.

7.1 / 180 * 32 = 1.26, so ~1 cycle delay.  Not so much.  The new ADCs are waaaay faster than the old 110Bs.  Yay!

The Matlab NDS1 access seems to only work for some channels. With other channels it just hangs 'Busy' and does nothing.
Below you can see some channels that make matlab hang. Everyting happened on allegra. I tried compiling the NDS1 sources (from https://www.gravity.phy.syr.edu/dokuwiki/doku.php?id=ligodv:nds1_ligodv_install ) into mex files myself. Same result. I
 

a=NDS_GetChannels('fb:8088'); %/cvs/cds/caltech/apps/linux64/share/matlab/NDS_GetChannels.m
%data=NDS_GetData({'C1:IOO-MC_F_DQ'},1004826500,100,'fb:8088',a)     %Works
%data=NDS_GetData({'C1:IOO-WFS1_PIT_IN1_DQ'},1004826500,100,'fb:8088',a)     %Works
data=NDS_GetData({'C1:LSC-AS11_I_OUT'},1004826500,100,'fb:8088',a)         %Doesn't work, hangs
%%%which NDS_GetData.m: /cvs/cds/caltech/apps/linux64/share/matlab/NDS_GetData.m

error signal = signal measured behind the low-pass filter

feedback signal = output of the gain servo, going to the PZT

First of all both signals in V/sqrt(Hz) just in case I mess up the next calibration step.

The 60 Hz line (and its multiple) are a new feature. They show up as soon as the feedback loop is closed. So far, I couldn't find their origin.

For the next calibration step:

• width of a typical error signal, i.e. the frequency band width of the carrier slope, ~1.4 kHz
• height of a typical error signal 182 mV

 As reported a couple days ago, the ETMX IO chassis has no timing signal.  This is why we there is no QPD signal and why we turned off the ETMX watchdog.  In fact, I believe that there is probably nothing coming out of the ETMX suspension controller at all.

I'm working on getting the timing board replaced.  Hopefully today.

The ETMX oplev returning beam is well centered on the qpd. We lost this signal 2 days ago. I will check on the qpd.

ETMX sus damping restored.       c1iscex computer is down

With fancy analysis tools approaching usability I looked some more into noise projections from PIT,YAW motion of the MC mirrors to MC length.

Injection channels are: C1:IOO-MC1-PIT_EXC. Actual injection signal is recorded in C1:IOO-MC1-PIT_OUT and similar.
Source channels for the projection are C1:IOO-WFS1_I_PIT_OUT_DQ and similar.
Response channel is C1:OAF-MCL_IN_IN1 or C1:IOO-MC_F_DQ.
MC auto-alignment was off.

1. Fixed sine injection @ 0.5Hz

Every injection lasted 4mins.

2. Filtered white noise injection

Generated white noise from 0.5Hz-20Hz, then filtered that in the C1:IOO-MC1-PIT and similar filters by the following TF, (Notch 1Hz, Q=3, 40dB &  2 zeros @ 1.1Hz)

All injections lasted 4mins. I left the filters in the first filter bank but disabled them. 

Had since yesterday evening some trouble with getting a channel from rfm on c1sus to oaf on c1lsc via dolphin. Several restarts of c1lsc and c1sus didn't help. At some point this morning a restart of c1lsc helped. Everything ok again.
At the bad time the dolphin TF looked like this:

Should be flat at gain 1 and no phase change obviously.

I switched on the WFS servos with the output matrix (open loop) determined last Friday.  Only the WFS1Pit, WFS2Pit, WFS1Yaw and WFS2Yaw servo filters are now on.   I then adjusted the gains to obtain maximum suppresson of error signals without oscillations in the loops

I now proceed to determine the output matrix again.

 The MC alignment was bad and I wondered if it is because MC shifted or because the input PSL beam shifted.   So I remeasured the spot positions and find that MC2 Yaw has shifted a lot.   Todays measurements are in Cyan boxes above. The shift in MC3P is probably an associated shift due to some pit--yaw coupling.  So I am going to move MC2 and try to align the MC to the PSL.

A nice plot !

Can you put another y-axis on the right hand side of the same plot  in terms of the cavity displacements ?

And can you also measure a more important spectrum, namely the suppressed error signal ?

I measured the power spectrum of channel C1:GCY_SLOW_SERVO1_IN1, which is the PZT driving voltage.

I converted the output to a PSD. Next, I converted counts/sqrt(Hz) to volts/sqrt(Hz) by multiplying with 40 V / 2^16 counts.

Finally, I multiplied it with 5MHz/V for the PZT to end up with Hz/sqrt(Hz).

This corresponds to a cavity length fluctuation of

with lambda = 532nm and a YARM cavity length of 37.757m (elog # 5626).

All in one plot

It appears that the timing slave in the c1iscex IO chassis is dead.  It's front "link" lights are dark, although there appears to be power to the board (other on-board leds are lit).  These front lights should either be on and blinking steadily if the board is talking to the timing system, or blinking fast if there is no connection to the timing distribution box.  This likely indicates that the board has had some sort of internal failure.

Unfortunately Downs has no spare timing slave boards lying around at the moment; they're all stuffed in IO chassis awaiting shipping.  I'm going to email Rolf about stealing one, and if he agrees we'll work with Todd Etzel to pull one out for a transplant

I copied Mirko's PEM BLRMS block, and made it a library part.  I don't know where such things should live, so I just left it in isc/c1/models.  Probably it should move to cds/common/models.  To make the oaf compile, you have to put a link in /opt/rtcds/caltech/c1/core/branches/branch-2.1/src/epics/simLink , and point to wherever the model is living. 

I then put BLRMSs on the control signals coming into the OAF, and after the Correction filter bank in the Adapt blocks, so we can check out what we're sending to the optics.

 I assume you mean /opt/rtcds/caltech/c1/scripts/MC/WFS.

As I've tried to reitterate many times: we do not use /cvs/cds anymore.  Please put all new scripts into the proper location under /opt/rtcds.

 This was totally my fault.  I'm very sorry.  I modified the lockin part to output the Q phase, and forgot to modify the models that use that part appropriately.  BAD JAMIE!  I'll check to make sure this won't bite us again.

 After Rana pointed out the errors of our ways, we reverted all of these changes.

 I installed 4 remote AC power on/off strip at

1Y1   for the Vertex area 4 chamber illuminating lights ( CIL )

1Y3   for HV ps for PZT steering mirrors that should be interlocked with P1 pressure gauge. Power off above 3 mTorr

1Y4   for  ETMY CILs,

1X9   for ETMX CILs

I need one volunteer to help me to make MEDM screen and connect the network to the switches.

I clicked on the FE status screen, just to check on things, and everything on the c1iscex section was red (the IOP and c1scx).  Upon deciding that was probably a bad thing, I did a soft reboot from the control room.  Now the IOP says "NO SYNC", and the c1scx status thing is totally frozen. 

I have sent Jamie a whiny email. He promises to be here soon to fix it.

I've noticed that it always takes running the script twice for it to actually work. I think there's something wrong with how it's doing it. I'll mess with it sometime the elog isn't getting much use.

Elog restart script killed the elog, but didn't restart it.  Restarted by hand.

The Nov.19 interruption was rescheduled to be on Nov.20,2011

          CALIFORNIA INSTITUTE OF TECHNOLOGY

                 FACILITIES MANAGEMENT

            UTILITY & SERVICE INTERRUPTION

**PLEASE POST**

Building:         CENTRAL ENGINEERING SERVICES, STEELE HOUSE, KECK LAB,

                  LIGO GRAVITATION PHYSICS BLDG, SAFETY STORAGE (BY CES)

Date:             Sunday, Nov. 20,2011

Time:             10:00 AM TO 11:00 AM

Interruption:     ELECTRICITY

Contact:          MIKE ANCHONDO X-4999 OR TOM BRENNAN X-4984

*THIS INTERRUPTION IS REQUIRED FOR MAINTENANCE OF HIGH VOLTAGE SWITCHGEAR

IN CAMPUS SUB-STATION.

The PMC acted like it was sleeping. The HV slider was dead. The MC locked instantly as the PMC had transmission.

The 'helping' trick is a good one: we should use our best guess for the stackTF and the pendulumTF and put it into the IIR filter bank to pre-filter the seismometer signals before they get to the MC mirrors. Also should remember that the signal we send to suppress the seismic motion is applied to the pendulum as a force, not a displacement.

The 3 Hz fast cutoff in the MC_F signal is a good clue. It means that at low frequencies, perhaps the noise source is going through a digital 3 Hz elliptic or Chebychev filter.

 Dr. SUS failed while trying to get the sensor data. Specifically, it couldn't get ETMY data. This is odd, because in my tribulations last week I ended up having to add the ETMY_SENSOR channels manually into the NDS2 channel files. After doing this, I was able to get ETMY data just fine (though I admitted that we would have problems again as soon as we wanted to update the channel files). I even ran the diagAllSUS code in a sandbox and it pulled data---and generated input matrices---just fine.

The error persists even if I try to get the data manually:

>> d = NDS2_GetData({'C1:SUS-ETMY_SENSOR_UL'},t0,10,'mafalda.martian:31200');

Connecting.... authenticate done

Warning: daq_recv_next failed

??? Error using ==> NDS2_GetData

Fatal Error getting channel data.

I think Jamie is still waiting for J.Z.'s help with this, but it is probably pointless to keep trying to run this code before NDS2 is working again. Another option is to just use NDS, but I think certain people are opposed to this. 

Ok, here's the deal:

• For the time being, I have written a "doirun" bit into runDrSUS (i.e. it runs if doirun is 1 and doesn't if it's 0). This is a bad way of doing this, so in the end I think we should put a switch on the IFO MEDM and have the script read the value when the cron job is run. If you want it to be an opt-in rather than a toggle, we can have the script write it back to 0 every time. I don't know how to do this yet because I am an MEDM n00b, but I will do it soon.
• Since we have decided to keep a human in the loop on the writing to the frontend, I have kept the elog results push.
• I have also edited diagAllSUS.m so that it archives all computed matrices (hierarchy: .../scripts/SUS/peakFit/inMats/(gps_time_of_kick)/inMat(optic_name).mat). There is a 'writematrices' bit in the M-file, currently set to 0.
• I have written the script 'writeAllInMats' and the accompanying M-file 'writeAllInMats.m'. This allows the user to write whichever set of input matrices he or she desires (syntax: writeAllInMats (gps_time_of_kick)). If no argument is given, then it reads the most recent kick time from 'kickAll.time' and writes the corresponding matrices.

So, here is an example of how this works:

1. Someone decides to do a diagonalization on a particular weekend, (eventually) clicking a switch in MEDM
2. Cron runs runDrSUS at 8am that Sunday. This:
   1. Kicks all the optics, lets them swing for 5 hours, then reengages the watchdogs. The kick time is saved in kickAll.time, and an alert is posted to the elog
   2. Runs diagAllSUS, which computes and saves all matrix data. A report of the results is posted to the elog.
3. On Monday morning---or whenever---someone looks at the entry and decides whether or not to write the files
   1. If the results are good, he or she runs writeAllInMats and the latest matrices are written
   2. If the results are bad, he or she does nothing. The matrices are still archived and can be written at any time in the future.

The code is set to run tomorrow morning. Everything but the writing will be done.

In any case, the daily backup of the scripts are found in /cvs/cds/caltech/scripts_archive. 

I think you also should check the PZT's capacitance of the 700mW LightWave because 2.36 nF is the one for the 1W Innolight laser.

The scripts and screens needed to make the MC WFS ouput matrix are once again functional. 

I corrected the WFS lockins' phases to ensure that the Q outputs are minimised.  Since all the lockins have the same relative phase with respect to the oscillator I found that the same phase works for all of them.  About 90 deg in this case.

The scripts used to make the WFS outmatrix measurement live in /cvs/cds/rtcds/caltech/c1/scripts/MC/WFS

1) setupWFSlockins:   This script makes sure that all the ASC, WFS_ LKIN and WFS_servo filter banks used in this measurement are set up properly.  It also sets the WFS_lockin oscillator to 10 Hz.  There are filter modules in the SIG filter bank of the WFS demodulators. 

2) senseWFSoutMATRX:  This script cycles through the various MC actuators ( MC 1 2 3 : PIT and YAW ) and measures the response of the various ASC sensors (WFS and MC2_TRANS QPD).

3) The data collected by the sensWFSoutMATRX can be analysed with a matlab file called " wfsmatrix3.m " located in a subdirectory under WFS called 'matlab'.   I have added some comments in this file to make it easier to follow.   The output of this file, at the moment, gives only the " Actuation Vectors " for WFS1P, WFS2P, WFS1Y and WFS2Y.  It ignores the MC2TransQPD for now. 

4)  The lockin outputs are given below ( the 'reduceddata' )

             wfs1p      wfs2p      mc2tp      wfs1y      wfs2y     mc2ty

mc1p    0.2926   -0.4086    0.2926    0.0340    0.0064    0.0001
mc2p   -0.2830   -1.3060   -0.2833    0.0628    0.1171   -0.0003
mc3p   -0.3283   -0.3455   -0.3288   -0.0456    0.0275    0.0000
mc1y    0.0440    0.0261    0.0429    0.7204    0.9351   -0.0008
mc2y   -0.1006    0.0850   -0.1036   -1.5509   -0.3882    0.0165
mc3y     0.0150   -0.0832    0.0144    0.1114   -1.0573    0.0006

5) The actuation vectors are given below

6) This measurement was performed with the WFS servo loops open. I will try to close the loops with this matrix and run the script again to measure the output matrix in closed loop.

7) This a.vectors obtained above are significantly different from that obtained a while ago (elog 5668) before the lockin demod phases (relative to each other) were fixed.  This could also be because both are open loop measurements and we might have wandered into the nonlinear regime of the WFS sensors.

 I have moved all the MC_ASS scripts to a directory called MC under ASS

Did somebody delete all the scripts in /opt/rtcds/caltech/c1/scripts/ASS ?

[Mirko, Den]

We still think about the coherence between seismic noise and mode cleaner length. We beleive that

1. Below ~0.1 Hz tilt affects on the seismometers as was simulated http://nodus.ligo.caltech.edu:8080/40m/5777

2. From 0.1 to 1 Hz is an interesting region. We try to figure out why we do not see any coherence here. Tilt does not seem to dominate.

At 1 Hz coherence might be lost because of the sharp resonance. For example, if the mirror is suspended to the platform by wires with f = 1 Hz and Q = 1000, then the coherence between platform motion and mirror motion will be lost as shown on the figure below.

For this reason we tried to "help" to the adaptive filter to guess transfer function between the ground motion and mirror motion by multiplying seimometer signal by the platform -> mirror transfer function. As we do not know exactly eigen frequency and Q of the wires, we did a parametric simulation as shown on the figure below

The maximum coherence that we could achieve with treak was 0.074 compared to 0.056 without. This was achieved at f=1.0011 Hz but with surprisingly high Q = 330. And though this did not help, we should keep in mind the tecnique of "helping" the adaptive filter to guess the transfer function if we partly know it.

Another unexpected thing is that we see come coherence between gur1_x and mode cleaner WFS pitch signal at frequencies 0.1 - 1 Hz

 From this we can suggest that either mode MC_F channel does not completely reflect the mc length at low frequencies or WFS2 shows weard signal.

63% coupling efficiency into the new fiber collimator (Thorlabs XXXX) and the blue fiber.This should be sufficient for a beat measurement with the PSL laser.

I think the coupling efficiency is not too bad with having no mode matching lenses and no adjustable collimator lens.

252mW in front of the fiber

159 mW fiber output

My inclination is to not do the writing of the matrices automatically nor to do the weekly kicks. Its nice to have long locks of the MC, etc.

I suggest just making the kick on Sundays when someone intentionally asks for it (e.g. by pressing a button on Friday). The free-swinging ringdown ought to be a opt-in kind of feature, not opt-out.

After Kiwamu adjusted the MC2 PIT to accommodate the limited range of the PZT1 ( elog ),  I remeasured the spot positions today.  

As expected there is a translation of the beam axis to one side (Up? Down?) .  

I wonder how a beam translation by 5mm solved the PZT1 angular range limitation problem (?!)

I moved the place where we take the OAF Degree of Freedom signals from - now it's the error point rather than the feedback for DARM, CARM, MICH, PRCL, SRCL, XARM and YARM.  I didn't do anything to MCL.

While trying to compile, there was something wrong with the lockins that were there...it complained about the Q OUTs being unconnected.  I even reverted to the before-I-touched-it-today version of c1lsc from the SVN, and it had the same problem.  So, that means that whomever put those in the LSC model did so, and then didn't check to see if the model would compile.  Not so good.

Anyhow, I just terminated them, to make it happy.  If those are actually supposed to go somewhere, whoever is in charge of LSC lockins should take a look at it.

Also, as Mirko mentioned in the previous elog 5811, we wanted to calculate the effect on the MC without actuating, so we put in a new summing point and a filterbank so we have testpoints.

LSC model recompiled.

OAF model recompiled.

FB restarted because of the new channels added to OAF.