After my investigations this afternoon (with help from Sendhil and Shivaraj), I do not find any problems with the POX whitening switching.

Earlier this afternoon / evening I was misleading myself into thinking that either the switching component (ADG333ABR) was broken, or that the whitening op amps (LT1124CS8) were broken on the POX I&Q and POY I&Q channels.  I had not realized until Jamie mentioned the possibility, that some of the DC gain stages were on for POX and POY.  POX and POY (I&Q for both) all had +36dB of gain, so when I was injecting my 60Hz sine wave into those channels, the whitening opamps were already saturated, which is why it didn't look like I was getting any gain.  When I set them all to 0dB (which is what AS11 and REFL11, the other 2 PDs using that whitening board, were set to), all 8 channels behaved the same.

The shaped whitening (which is either bypassed or not, depending on the condition of the software "unwhite" switch) is 2 filters in series, each with a zero at 15Hz, and a pole at 150Hz, with DC gain of 0dB.  For a 60Hz sine wave, this gives a factor of ~4 from each stage.  After setting all of the whitening gains to 0dB, I was able to see on all 8 channels of the board an input sine wave, a larger (by 4-ish) sine wave, and then a larger (by 4ish again) sine.  When I looked at the output of the switch of all 8 channels, the signal was either the same as the input amplitude, or the same as after the 2nd whitening stage, depending on the "unwhite" filters.

Before looking at actual signals, Sendhil and I also had checked to see that indeed, the board was receiving the digital signal input to the switch chip, requesting switching based on the state of the "unwhite" filters.

I looked through the elogs, and the only "symptoms" I find are from an IFO check-up session that Koji, Den and I had back in May, where we declared in the elog that POX whitening may or may not be switching.  See elog 6595.  We didn't mention what the actual symptoms we saw were, so unless Koji or Den remember something that I don't, I cannot confirm that we are no longer seeing those symptoms.  However, based on the number of "?" after "POX whitening not toggling the analog whitening", I don't think that we were totally sure that something was wrong in the first place.

Anyhow, the whitening board in the LSC rack labeled "WF1", serving AS11, REFL11, POX11 and POY11 has had a thorough checkup, and I give it a clean bill of health.

Manasa and Jan were having trouble locking the Yarm, and asked me to take a look at it.  After a good long time of trying to figure out what was going on, it finally occurred to me that I did not turn the DC gain on POX and POY back to the nominal 36dB.  As soon as I did that, both arms acquired lock.  Ooops.

[Rana, Jenne, Yuta] (late last night)

After some trouble getting the PRMI to lock with REFL55 I&Q last night, we began to think about the size of signals everywhere, and the coupling of the sidebands in the different cavity configurations.  We have determined that it is possible that the Q phase signal is too small everywhere, so the PRMI will never be easy to lock. The Q phase will be smaller than iLIGO equivalents since the modulation frequencies are lower, and we have a small Schnupp asymmetry. The calculations of signals at each port were all done for the DRMI case, where sidebands get recycled more, so signals get larger.  If locking the PRMI is "hopeless" due to very small signals, we should stop trying, move on with other things, and come back to the corner when we have the DRMI ready. In order to figure out if it is reasonable to keep working on the PRMI, we must calculate the size of all of our signals at each port, and convert them into real units (if we expect a 1mVpp signal at REFL11Q, we're not going to successfully lock MICH with that).

So, we should:

* Calculate sideband signals at AS and REFL, for 11 and 55 MHz, for the PRMI case.

* Convert those signals into physical units (Watts -> Amps -> Volts).

* In parallel, work on dual arm ALS, and FPMI locking.

   * Try using ALS CARM for frequency stabilization.

   * Hand off from ALS CARM and DARM to PSL.

* To do ALS-FPMI, we should:

     * Use A2L to center the IR spots on all arm cavity mirrors.

     * Align green beams to the arms.

    * For each arm, determine which frequency (arm green or PSL green) is higher.

          * Lock the arm in green, align Beat PD. 

          * Push ETM, watch beat in the phase tracker.

          * Repeat for other arm.

     * Use ALS input matrix to construct CARM and DARM signals.

         * Check by shaking ALS-CARM, watch both X and Y beat signals - if they move in the same direction, we were right, but if they move in opposite directions we have flipped CARM and DARM.

    * Send the ALS-CARM signal to MC2, or the analog common mode board.

Here are the transfer functions that we took back in 2011 (see elog 4915 and replies) for POX:

The table of all whitening filter zpk values is on the wiki: https://wiki-40m.ligo.caltech.edu/Electronics/WhiteningFilters

Re:  POY beam reduction.

We are able to lock the Yarm with the beam / gain as it is.  I had thought we might need to increase the DC gain in the whitening board by a factor of 2, but so far it's fine.

I'm working on getting the input beam centered on the Yarm optics.  To do this, I measured the spot positions, move the tip tilts, realign the cavity, then measure the new spot positions.  While doing this, I am also moving the BS and Xarm optics to keep the Xarm aligned, so that I don't have to do hard beam-finding later.

Here is the plot of spot measurements today.  The last measurement was taken with no moving, or realigning, just several hours later after speaking with our Indian visitors.  I'm closer than I was, but there is more work to do.

None of the suspensions All suspensions were tripped (edited by Manasa; see elog 8271) by this morning's earthquakes, but the MC suspensions are in a different place than they were a day ago.  The big symptom here is that the MCWFS are pulling the mode cleaner slightly out of alignment.  When it first locks, the reflected light is ~0.5, but when the WFS are engaged it goes up to ~0.8.  I'm going to put the MC optics back where they were (according to SUSpit and SUSyaw), and tweak up the MC from there. Probably other optics are affected, but I was going to work on continuing to center the beam on the Yarm optics, so I'll deal with the rest of the IFO in a minute.

Note re: lower plot - the mxstream was down on c1sus and c1ioo, so no fast channels on those computers were recorded for almost a day.  (The plot is one day 4 days long).  I was going to plot the seismic blrms along with the suspension pointing values, but there's no data saved, so there's no point.  Jamie tells me he thinks this spontaneous loss of the mxstream is fixed in the next RCG upgrade, and that we can talk about upgrading the RCG after the LSC meeting, so this data loss is no longer an issue.

EDIT:  Plot with 4 days of trend, rather than just 1.  The MC alignment (as measured by MC refl) has been very bad for several days.  I'm going to move the suspensions back to their last good place.  Also, Manasa realigned the MC after the EQ, so I don't actually know where the suspensions got kicked to this morning.

Looking more into the MC, it appears that no spot centering was done after the power attenuation optics were removed (see elog 8142).  Since Manasa had changed the zig-zag steering after putting in the attenuation optics (elog 7843) the pointing was not correct for the nominal MC.  This is (likely) why Yuta and Manasa found some significant decentering.  If Manasa's tweaks when preparing for vent were primarily in yaw, then this is most definitely what happened.  A note, this is why we should change to inserting the attenuation optics before the PMC, but even so, one should adjust the angle of the PBS, NOT the zig zag optics, to get the input pointing back to the same place.  This is also why it is useful to ensure the attenuation optics do not block the PSL pointing QPD pickoff, so it is easier to adjust the PBS to get back to the original pointing.

In any case, I touched the last zig-zag mirror in yaw today (the top of the knob was moved away from me) to recenter the spots.

With the MC unlocked, I centered the WFS.  Now the MC is back to its normal working condition....WFS are on, autolocker is on, reflected DC power is low, etc., etc.

This is my interpretation of where Steve is proposing to place the seismometers (he wrote ITMX southwest, but I'm pretty sure from the photo he means southeast).

I think his point is that these locations are on the less-used side of the beam tube, so they will not be in the way.  Also, they are not underneath the tube, so we will not have any problems putting the covers on/taking them off.

[Manasa, Jenne]

Manasa just went inside to recenter the AS beam on the camera after our Yarm spot centering exercises of the evening, and heard a loud beeping.  We determined that it is the RAID attached to the framebuilder, which holds all of our frame data that is beeping incessantly.  The top center power switch on the back (there are FOUR power switches, and 3 power cables, btw.  That's a lot) had a red light next to it, so I power cycled the box.  After the box came back up, it started beeping again, with the same front panel message:

H/W monitor power #1 failed.

Right now the fb is trying to stay connected to things, and we can kind of use dataviewer, but we lose our connection to the framebuilder every ~30 seconds or so.  This rough timing estimate comes from how often we see the fb-related lights on the frontend status screen cycle from green to white to red back to green (or, how long do the lights stay green before going white again).  We weren't having trouble before the RAID went down a few minutes ago, so I'm hopeful that once that's fixed, the fb will be fine. 

In other news, just to make Jamie's day a little bit better, Dataviewer does not open on Pianosa or Rosalba.  The window opens, but it stays a blank grey box.  This has been going on for Pianosa for a few days, but it's new (to me at least) on Rosalba.  This is different from the lack of ability to connect to the fb that Rossa and Ottavia are seeing.

~20 minutes ago, maybe right around the time the fb's RAID died (elog 8274) the mode cleaner started behaving weirdly again.  The reflected value is very high, even with the WFS on.  Earlier this evening, I saw that with the WFS off, the MC reflection was high, but the WFS brought it back down to ~0.7 or 0.8.  But now it's ~1.3.  With the WFS off, the reflected value is ~1.1.  I don't really understand.

Also, the PMC has been drifting in alignment in pitch all day, but a lot more later in the day. The PMC trans is 0.800 right now, but it was as high as 0.825 today, and spent most of the day in the high 0.81xxx range today.

I would provide plots, but as mentioned in elog 8274, we can't get data right now.

[Manasa, Annalisa, Jenne]

The MC wasn't locking on TEM00 this morning, and the WFS kept pulling the MC out of alignment.  The MC was realigned, and the WFS spots are back to being roughly centered (all of this only touching the MC sliders), but the WFS keep doing bad things.  They're okay, and improve the alignment slightly at first, but as soon as the FM1 integrator comes on, the MC alignment immediately starts going bad, and within a second or so the MC has unlocked.

The WFS are off right now, and we'll keep investigating after LIGOX.

Steve just told those of us in the control room that the custodian who goes into the IFO room regularly steps on the blue support beams to reach the top of the chambers to clean them.  Since we have seen in the past that stepping on the blue tubes can give the tables a bit of a kick, this could help explain some of the drift, particularly if it was mostly coming from TT2.  The custodian has promised Steve that he won't step on the blue beams anymore.

This doesn't explain any of the ~1 hour timescale drift that we see in the afternoons/evenings, so that's still mysterious.

Koji reminded me (again....this is probably the  2nd or 3rd time I've "discovered" this, at least) that the script

..../scripts/MC/WFS/WFS_FilterBank_offsets

exists, and that we should use it sometimes.  See his elog 7452 for details. 

Notes about using this script:

* Only use it after MC has been very well aligned.  MC REFL DC should be less than 0.5 when the MC is locked (with the DC value ~4.5 with the MC unlocked, as usual).  This is hard to achieve, but important.  Also, check the MC spot centering.

* With the WFS servo off, but the MC locked and light on the WFS diodes, run the script. 

Both X and Y green are aligned such that the arm beams hit the broadband PD.  Also, the 4th port of the combining BS for each arm was used to put a camera and DC PD for each arm.  So, ALS-TRX and ALS-TRY are both active right now.  The camera currently labeled "GRNT" is the Ygreen transmission.  I have a camera installed for Xgreen transmission, but I have not run a cable to the video matrix.  For now, to speed things up, I'll just use the GRNT cable and move it back and forth between the cameras.

I dedicated my evening to trying to get the Ygreen beatnote (the idea being to then get the Xgreen beatnote).

First up was tweaking up the green alignment.  Per Yuta's suggestion, elog 8283, I increased the refl PD gain by 2 clicks (20dB) to keep the lock super stable while improving the alignment.  After I finished, I turned it back to its nominal value.  I discovered that I need lenses in front of the DC PD (for Ygreen, and I'm sure Xgreen will be the same).  The beam is just barely taking up the whole 2mm diode, so beam jitter translates directly to DC power change measured by the diode.  I ended up going just by the green transmission camera for the night, and achieved 225uW of Ygreen on the PSL table.  This was ~2,000 counts, but some of the beam is always falling off the diode, so my actual counts value should be higher after installing a lens. 

I then opened up the PSL green shutter, which is controlled by the button labeled "SPS" on the shutter screen - I will fix the label during some coffee break tomorrow.  Using my convenient new PSL green setup, removing the DC PD allows the beam to reflect all the way to the fuse box on the wall, so you can check beam overlap between the PSL green and the arm green at a range of distances.  I did this for Ygreen, and overlapped the Ygreen and PSL green. 

I checked the situation of the beat cabling, since Jamie has the beatbox out for whitening filter modifications tonight.  In order to get some signal into the control room, I connected the output of the BBPD amplifier (mounted on the front of the 1X2 rack) directly to the cable that goes to the control room.  (As part of my cleanup, I put all the cables back the way I found them, so that Jamie can hook everything back up like normal when he finishes the beatbox.) 

I then started watching the signal on the 8591E analyzer, but didn't magically see a peak (one can always hope....).

I decided that I should put the offset in the Y AUX laser slow servo back to the value that we had been using for a long time, ~29,000 counts.  This is where things started going south.  After letting that go for a minute or two, I thought to go check the actual temperature of the laser head.  The "T+" temperature on the controller read something like 42C, but the voltmeter which reads a voltage proportional to the temp (10C/V) was reading 5.6V.  I immediately turned off the offset, but it's going to take a while for it to cool down, so I'll come back in the morning.  I want the AUX laser to be something like 34C, so I just have to wait.  Ooops.

Still to do (for the short-term FPMI):

* Find Y beatnote.

* Align Xgreen to the arm - it's still off in pitch.

* Align Xgreen and PSL green to be overlapped, hitting the BBPD.

* Find the X beatnote.

* Reinstall the beatbox.

* Use ALS to stabilize both arms' lengths.

* Lock MICH with AS.

* Look at the noise spectrum of AS - is there more noise than we expect (Yuta and Koji saw extra noise last summer), and if so, where does it come from?  Yuta calculated (elog 6931) that the noise is much more than expected from just residual arm motion.

* Write a talk.

I ran a cable to the GTRX camera.  It is now input #2.  The videoswitch script input naming is modified to match this:  Input 2 used to be "IFOPO", and is now "GTRX".  Input 28 used to be "GRNT", and is now "GTRY".  Both green trans cameras are available from the video screen.

 This is happening again to the Yend laser.  It's been fine for the afternoon, and I've been playing with the temperature.  First I have been making big sweeps, to figure out what offset values do to the actual temperature, and more recently was starting to do a finer sweep.  Using the 'max hold' function on the 8591, I have seen the beat appear during my big sweeps.  Currently, the laser temperature measurement is at the Yend, and the RF analyzer is here in the control room, so I don't know what temp it was at when the peaks appeared.

Anyhow, while trying to reaquire lock of the TEM00 mode after changing the temperature, I find that it is very difficult (the green seems misaligned in pitch), and every minute or so the light disappears, and I can no longer see the straight-through beam on the camera.  I went down to the end, and the same symptoms of LED on the laser head turning off, power out display goes to ~40mW, are happening.  I have turned off the laser as was the solution last time, in hopes that that will fix things.

Manasa has done some work to get the Xgreen aligned, so I'll switch to trying to find that beatnote for now.

I aligned the Xgreen and PSL green to overlap on the X beat PD, and reconnected the splitter which combines the X and Y beat signals and sends them to the control room.

I've been stepping the Xend laser temperature offset in steps of 20 counts, making sure the cavity unlocks and relocks on TEM00.  So far I have not seen any beat signals for the Xarm.  I've gone from 0 to 840.

I'll be back in a few hours to keep trying, although interested parties are invited to give it a whirl. 

This work earlier today had required moving the harmonic separator back closer to its original position, so that the green could get through without clipping.  I locked the Xarm (overriding the trigger) and realigned TRX to the PD and camera.

Jamie and I discovered a problem with Matlab/Simulink earlier today. 

In the end suspension models, there is a subblock (with top_names) for ALS stuff.  Inside there, we use a library part called "ALS_END".  When the model was created, it included the part ...../userapps/release/isc/c1/models/ALS_END.mdl .  However, if you open up the c1scy diagram and look in the ALS block for this part, you see the part that is in ..../userapps/release/isc/common/models/ALS_END.mdl .  Note the difference - the one we want is in the c1 directory, while the one that was created (by Jamie) for the LHO One Arm Test is in the common directory. 

If you compile the c1scy model, the RCG is using the correct library part, so the information regarding which part we want is still in there. 

However, if you delete the ALS_END part from the model, put the correct one in, save, close, then reopen the model, it once again displays the wrong model.  The right click "go to library part" option brings you to the library part that is displayed, which is currently the wrong one.  THIS IS BAD, since we could start modifying the wrong things.  You do get a warning by Matlab about the file being "shadowed", so we should take heed when we see that warning, and make sure we are getting the file we want.

We are currently running Matlab version 7.11.0.584, which is r2010b.  Step 1 will be to update Matlab to the latest version, in hopes that this fixes things.  We also should change the name of our c1 part, so that it does not have the same name as the one for the sites.  This is not a great solution since we can't guarantee that we will never choose the same names as other sites, but it will at least fix this one case.  Again, if you see the warning about "shadowed" filenames, pay attention.

I turned the laser back on around 1am.  This is still happening, although right now it is turning off more often than before, maybe every 15 seconds or so.  I am going to turn off the laser for the night.

The measured laser temperature is about 45C (I have a 25,000 count offset in the Y ALS Slow control right now....higher offset, lower temp), although the measured laser temp drops to ~43.5C when the power goes down.

In light of the Yend auxiliary laser's ill health, I think we should reconsider the possibility of changing out the Yend laser table next week.

My thinking here is that if whatever the new mode matching solution is for a replacement laser (Tara has borrowed our spare NPRO that used to sit on top of the fridge, or we could take Annalisa's) requires a rework of the table layout, we might as well put the new layout onto the new table.  So, we need to figure out what laser we will put in as the new Ygreen, and what it's waist looks like.  If it just requires a small movement of existing lenses or new lenses in similar positions to the current ones, we can keep living with our current table.  But, if the mode matching solution requires enough changes to distances / lens placement / whatever, we should think seriously about putting in the new table next week.

Here's what I would like to see happen on / before Monday:

Annalisa - Mode matching solution for new laser.  If we get the laser back from Tara, this will involve first measuring the waist, otherwise we already know the waist of the ABSL laser that Annalisa is currently using.

Annalisa and Steve - Find optics for new mode matching in the lab, or order them by Monday afternoon.

Manasa - List of every screw, washer, optic, mount, etc. that will go on the new Y end table, with a notation as to whether or not we have it in-hand, and if not, what needs to happen before we do.  Also, for things that we don't have, I'd like to see a summary of temporary solutions (e.g. keep using current mount for doubling crystal while new one is being machined).

Manasa / Annalisa / Koji - will the new mode matching solution fit within the existing layout, or do we need to redo the table layout?

Zach has just replied, and said that we should feel free to take the laser from his iodine setup in the West Bridge subbasement, in the ATF lab. 

Annalisa, please ask Koji or Tara to show you where it is, and help you bring it to the 40m.  You should install it (temporarily) on the PSL table, measure the waist, and find the beat in IR.  Elog 3755 and elog 3759 have some of the details on how it has been done in the past.

Does "Ready (in stock)" for the base plates mean in stock at the company, or in hand and already here in the lab?

For the 2" mirror mounts, are we planning on making a decision soon, or a long time in the future....i.e. is this something that should go in the temporary solution column?

For the mode matching and collimating lenses, do we actually have the ones you want in our lens kits?  A lot of those kits are half empty.

Most of the front ends' mx streams weren't running, so I did the old mxstreamrestart on all machines (see elog 6574....the dmesg on c1lsc right now, at the top, has similar messages).  Usually this mxstream restart works flawlessly, but today c1lsc isn't working.  Usually to the right side of the terminal window I get an [ok] when things work.  For the lsc machine today, I get [!!] instead. 

After having learned from recent lessons, I'm waiting to hear from Jamie.

I think we like the idea of flipping SR2 better than SR3 for the same ghost beam reasons as PR2 is better than PR3.  There isn't very much free space in the BS chamber, and if we flip PR/SR3, we have to deal with green ghosts as well as IR.

The flipping SR2 case seems okay to me - flipping either one of the SR folding mirrors gives us a slightly better g-factor than the design with infinite curvatures, and flipping SR2 gives us slightly better mode matching to the arm than the flipped SR3 case, but more importantly, there are fewer ghosts to deal with.  I vote we flip SR2, not SR3.

[Jenne, Gabriele]

We aligned MICH (first locked Yarm, but didn't optimize since we don't have TRY, then locked Xarm, then aligned MICH), but there was no beam on AS55.  We went out to check, and the beam was almost not hitting the small steering mirror between AS55.  We adjusted the BS splitting the beam between camera and PD, and got the beam back on AS55. We could then lock MICH.

We also futzed with the REFL55 phase to get PRCL stuff in I, and MICH stuff in Q.  The procedure was to align PRMI, then kick PRM in pos, and adjust the phase so we got signal mostly in I after the kick.  We started at the original value of 60deg, but are leaving it at -20deg.

To see how much of the light that comes out of the REFL port actually goes to the PDs, I measured the power immediately after leaving the vacuum (~575mW) and in front of REFL11 (~5mW) and REFL55 (~6mW).

So, 0.01 of the power leaving the vacuum actually goes to the REFL PDs. This number will be useful when calculating the actual signals (in volts) that we expect to see.

[Jenne, Gabriele, Jamie]

We have looked at Koji's old Finesse code, and determined that the PRMI sensing matrix that he calculated was for the sideband-resonant case.  Thus, this is the sensing matrix we are interested in for locking. Gabriele has confirmed this using independently written code with his software, Mist.

Pics or it didn't happen:

The sensing matrix is:

Numerical values are on the wiki:  https://wiki-40m.ligo.caltech.edu/IFO_Modeling/SensingMatrix

For any of the REFL PDs (1*f1, 1*f2, 3*f1, 3*f2), the PRCL signal is a factor of ~100 larger than the MICH signal.  Rana assures us that, with some clever triggering, we should be able to lock the PRMI. 

This means that we will not be venting in the next few days to flip the SRC folding mirror.  We will work on PRMI lock (probably first with 1*f, but then quickly moving on to 3*f), and as soon as Annalisa and Manasa have the new ETMY table ready for us, we will then do PRFPMI.  (We can also play with the Xarm green until Yarm green is back).

[Gabriele, Jenne]

We have achieved PRMI locks of the order ~5 seconds! Here is an example lock:

This was actuating MICH on the ITMs (+1 for ITMY, -1 for ITMX in the output matrix), and PRCL on PRM (+1). 

PRCL gain was +1, MICH gain was -10.

PRCL signal was normalized with POP22I with a matrix value of 0.003 . (No normalization of MICH).

Both PRCL and MICH were triggered on POP22I with high thresh of 200, low of 50.  MICH and PRCL FM2 (integrators) were triggered on POP22I with thresh of 400 and low thresh of 50.  FMs 4 and 5 were on for both MICH and PRCL always.

We zoomed in on the MICH_OUT signal, and the instability looks like it is around 300 Hz.  We aren't sure what this is.  I think this is a similar frequency to an oscillation that Yuta saw, but I'll have to check the old elogs.

PRM and BS SUS_LSC_POS filter banks both have notches between 1280-1290Hz.  The ITMs do not have this "Vio2" filter.

This is one of the first locks with the new triggering of both the INPUT and OUTPUT of the control filter banks.  I modified the lsc model before lunch. 

To do:  Where is this 300Hz coming from, and what can we do about it?  Why are we losing lock?  It's not due to the oscillation - maybe too much afternoon seismic?  Steve says he went next door and the rock monster / river is on medium/high.

[Rana, Gabriele, Jenne, Jamie, Lisa, Rana]

We have tuned the oplev servos for PRM, BS, ITMX, ITMY.  For each, we measured the servo transfer function.  Most had a UGF ~ 3Hz.  For those, we increased the gain by a factor of 2, and engaged the 3.3Hz resonant gains. The other case, such as PRM yaw, the gain was already okay, we just needed to engage the resonant gain.  We also checked the new phase margin, and for some of them switched the elliptic lowpass to 50Hz rather than 30 or 35.

Before and afters:

We need to, as a last check, look at the spectra before and after to ensure that no modes (like bounce or roll) are newly excited.

[Gabriele, Rana, Jenne, Jamie, Lisa, Zach]

We tweaked some things after dinner, and our locks got longer (~10sec) and more frequent!

What happened / notes:

* Increased analog gain from 15dB to 27dB for REFL55 I&Q.

* No analog whitening during lock acquisition.  (Need trigger + wait so whitening comes on after ~1sec...but this is not our limitation right now).

* Limit MICH and PRCL control to 5000, so that we don't kick optics too much, which makes them take too long to settle.

* ITMX and ITMY Vio2 filters turned off (PRM still has it on) in the SUS-optic_LSC module.

* MICH and PRCL DoFs triggering on POP22I, with levels 200 & 50.  FMs 4&5 always on.

* MICH and PRCL FM2 triggering on POP22I with levels 400 & 50.

* MICH gain = -0.200

* PRCL gain = +0.150

* MICH and PRCL normalization using POP22I, with matrix values 0.00160 .  This value is ~1/600, where 600 was the peak value of POP22I_ERR.

* REFL 55 phase set back to -15, to minimize PRCL signal in I phase.

* Checked signs for ITMX and ITMY in output matrix for MICH.  Lock MICH using only ITMX or ITMY, find sign to hold on the dark fringe for each.  +1 for ITMY, -1 for ITMX was correct.

* Tweaked up the oplev servos.  See separate elog 8362.  May need more tweaking, such as increasing the UGF, engaging 1Hz resonant gain.

* May need better coil actuator balancing on suspensions at 1Hz.

* Found a weird thing in DTT, which went away after closing and reopening, when looking at time series.  Sometimes we would see a square wave-like jump in the signals, all signals at the same time, with a frequency of 16.6Hz.  This was not present in other data retreival programs, like Jamie's getdata python script.

* We are not sure right now why we are falling out of lock.  We need to investigate more signals, to try to figure out what our current problem is.

* Reduced the amount of misalignment with the "misalign" script, to reduce hysteresis.

To Do / ideas:

* Calibrate oplev signals - see if one optic is moving more than others.

* Calibrate ERR and CTRL  - look at CTRL in meters, see if cavities are moving around like crazy.

* Calibrate POP22 using something like an AM laser modulation trick into units of PRCL SB gain. Compare with expectation - are we locked optimally, or do we have more power that we can be getting out?

* Try feeding back PRCL CTRL to MC2, to make the laser to follow the power recycling cavity, in hopes of reducing angular motion.  Rana tried this quickly with a 1 in the output matrix, but this kicked the MC out of lock - need to try smaller values.

 Manasa told me that she did things in a different order than her old elog. 

She had

(1) ssh'ed to c1lsc and did a remote shutdown / restart,

(2) restarted fb,

(3) restarted the mxstream on c1lsc,

(4) restarted each model individually in some order that I forgot to ask.

However, with the situation as in her "before" screenshot, all that needed to be done was restart the mxstream process on c1lsc. 

Anyhow, when I looked at the OAF model, it was complaining of "no sync", so I restarted the model, and it came back up fine.  All is well again.

[Gabriele, Jenne]

I put a notch in FM10 for both MICH and PRCL at 628Hz, to try to prevent us from exciting the mode that Gabriele saw on Friday.  Since those filter banks were all full, I have removed an ELP50 (ellip("LowPass",4,1,40,50)).  I write it down here, so we can put it back if so desired.

[Gabriele's work, I'm just spectating]

Annalisa is working on finding the PSL/AUX laser beatnote, so the PSL temp is changing, but Gabriele is still able to lock.  Here are some videos:

[Jenne, Gabriele]

Optical lever calibrations:

ITMX pit calibration = -9.07 cts/mrad

ITMX yaw calibration = -12.33 cts/mrad

ITMX plot:

BS pit calibration = -22.86 cts/mrad

BS yaw calibration = -24.14 cts/mrad

BS plot:

Method:  Similar to Manasa and Yuta's method last month.  We mounted each oplev QPD on a micrometer translation stage, centered the beam using the steering mirror, then used tdsavg to get 10 second averages of the _INMON channel for various settings of the micrometer stage.  For BS, we had to take out the PRM oplev to make room for the translation stage.  All QPDs were remounted in their original positions, within less than 1mm.  Measured the out-of-vac distances with the laser disto-meter, and the invac distances from the optic to the window from the CAD drawing.

Copying from other elog entries,

elog 8232:

We calibrated oplev for ITMY. Calibration factor for C1:SUS-ITMY_OL(PIT|YAW)_IN1 are;
  OLPIT: 6.29 +/- 0.11 counts/mrad
  OLYAW: 5.74 +/- 0.09 counts/mrad

elog 8221:

We calibrated oplev for PRM. Calibration factor for C1:SUS-PRM_OL(PIT|YAW)_IN1 are;
  OLPIT: 15.6 +/- 0.3 counts/mrad
  OLYAW: 17.8 +/- 0.3 counts/mrad

[Jenne, Gabriele]

We have put in a new EPICS input into the SUS library part, just before the OL_PIT and OL_YAW filter banks, so that the IN1 point is calibrated to microradians.  I recompiled all SUS-related models.  The OPTLEV_SERVO screen has been changed, so that you can see the calibration, and enter a value.  The gains have been reduced by a factor reciprocal to the calibration, so the loop gain is the same.

ETMs, SRM and MCs all have "calibration" numbers of 1, so the numbers aren't really calibrated, they're just the same as always.

It looks like the PRM and the BS are moving significantly (factor of ~30) more than the ITMs at a few Hz!  (Y-axis of plot is urad/rtHz)

EDIT JCD:  We need to fix up the MEDM QPD indicators, and the OpLev red lights on the watchdog screen, so they match the new numbers.  Also, Rana turned on the output limiters to 2000 for all oplev servos.

[Gabriele, Jenne]

We have implemented 4Hz resonant gains for both PRM and BS yaw.  The filter was already in place for PRM Yaw, so we just turned it on, but we also copied the filter over to BS Yaw.  We also changed the 3.3Hz res gain and the ELP for the PRM servo to match the BS servo, since after implementing the 4Hz gain, PRM was still much noisier than BS.  Now the 2 servos match, and PRM is a little quieter.  We hope that tonight's locking might be a little more stable after this work.

I modified /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini to include the C1:LSC-DegreeOfFreedom_TRIG_MON channels.  These are the same channel that cause the LSC screen trigger indicators to light up. 

I vaguely followed Koji's directions in elog 5991, although I didn't add new grecords, since these channels are already included in the .db file as a result of EpicsOut blocks in the simulink model.  So really, I only did Step 2.  I still need to restart the framebuilder, but locking (attempt at locking) is happening.

The idea here is that we should be able to search through this channel, and when we get a trigger, we can go back and plot useful signals (PDs, error signals, cotrol signals,....), and try to figure out why we're losing lock. 

Rana tells me that this is similar to an old LockAcq script that would run DTT and get data.

EDIT:  I restarted the daqd on the fb, and I now see the channel in dataviewer, but I can only get live data, no past data, even though it says that it is (16,float).  Here's what Dataviewer is telling me:

Connecting to NDS Server fb (TCP port 8088)
Connecting.... done
read(); errno=0
LONG: DataRead = -1
No data found

read(); errno=9
read(); errno=9
T0=13-03-29-08-59-43; Length=432010 (s)
No data output.


[Rana, Gabriele, Jenne]

We have now locked the PRMI using REFL55 I&Q for more than one minute!!!!!

This isn't really the most useful plot as is, but it was created using:

/opt/rtcds/caltech/c1/scripts/general/getdata C1:LSC-POP22_I_ERR_DQ C1:LSC-REFL55_I_ERR_DQ C1:LSC-REFL55_Q_ERR_DQ C1:LSC-MICH_IN1_DQ C1:LSC-MICH_OUT_DQ C1:LSC-PRCL_IN1_DQ C1:LSC-PRCL_OUT_DQ -d 80 -s 1049013520 -c

This is just one of several long lock stretches.  If I can get the TRIG_MON channels to be saved, we can automatically (versus my by-hand search) find lock stretches and make this kind of plot.  Although we want them saved in some raw format so we can zoom in on selected axes, I think.  This might require some python-fu from Jamie, or learning of python-fu for Jenne.

The secret sauce:

* The big key was changing REFL55's phase.  It was -4 when we looked at the I&Q signals, and minimized the PRCL information in the Q-phase.  We were able to get short lock stretches with this.  During these stretches, Rana changed the REFL55 phase until the lock sounded (audibly) quieter.  The final phase we settled on was +26. As we changed the phase, the lock stretches got longer and longer. 

* We also tweaked up the POP22 phase.  It was close from our previous efforts of looking at non-locked time series, but we perfected it by minimizing the signal in the Q-phase during lock stretches.  We also found that it drifted (according to this method) by ~5 degrees over ~half an hour (I don't remember the exact time between our phase tunings).

* POP22's low pass filters (both options, ELP10 and ELP50) must be OFF for any lock to be acquired.  Turning on either filter prevents locking.

* Normalization helped a lot.  Without normalization we weren't really able to catch any locks, certainly not of any significant length. (0.004, using POP22I, for both MICH and PRCL). 

* Parameters:

       ** Normalization:  use POP22I for both MICH and PRCL, value = 0.004

       ** Input matrix:  MICH with REFL55Q, value = 0.01; PRCL with REFL55I, value = 0.01  (we used the small number in the matrix so our servo gains weren't too tiny).

       ** POP22 lowpass filters OFF

       ** Analog whitening OFF for REFL55, POP22.

       ** Analog gain for REFL55 I&Q = 27 dB

       ** Analog gain for POP22 I&Q = 15 dB

       ** Output matrix:  MICH with -1 to ITMX, +1 to ITMY.  PRCL with +1 to PRM.

       ** Servo gains:  PRCL = 0.75;  MICH anywhere between -3 and -20.  Best in the -8 to -15 range.

       ** Vio2 filters in ITMX, ITMY, PRM (all actuated-on mirrors) were OFF. (Still need to lower the Q on these so they don't ring).

      ** PRCL and MICH triggering on POP22I.  The trigger-off was always 20, but the trigger-on changed throughout the night from ~170 to ~50.  I think 130 was a trigger value for at least some of the long-time locks.

      ** Low frequency seismic was small (i.e. no anomalous 0.1 Hz - 1 Hz noise) during successful lock times.  (Not to say it must be low, but it was low when we were able to lock for long stretches).

Things we had looked at and thought about throughout the evening:

* Oplev calibration.  See elog 8391 and 8393.  Optimized BS and PRM to reduce yaw angular motion.

* Actuators all functioning as expected.  We checked transfer functions of MICH_OUT/MICH_IN1 for locking with different optics, to ensure that at high frequency the response was 1/f^2.  Also, we locked MICH with (a) both ITMs, (b) BS, (c) ITMX and (d) ITMY.  We locked the PR-ITMY half-cav with (a) PRM and (b) ITMY.  We locked the PR-ITMX half-cav with (a) PRM and (b) ITMX.  Thus, we conclude that all of the PRMI-related optics are functioning as expected.

* Realigned REFL55 beam onto PD.  It was clipping a bit, so the DC power wasn't steady (when ITMs were misaligned, PRM aligned).  After alignment, the DC power as seen on a 'scope was much smoother.

* Turning off the limiters for the MICH and PRCL control signals allowed us to hear a high-pitched whine.  From looking at the time series, it's predominantly in MICH_OUT.  Rana speculates that perhaps the normalization is causing the UGF to wander temporarily to an unstable place.  For a time there was a high-Q peak between 500 and 600Hz, but reducing the gain (of MICH?) eliminated that.  Then we heard several times, irrespective of gain setting, the ~400Hz broad peak (I say broad because I was able to see it on DTT looking at the error and control signals, and it spanned +/-100Hz).

Things to investigate:

* Is there a good reason that we should switch to triggering on POP110, rather than the current POP22?  From Gabriele, Jamie and my Finesee/Mist modelling last week, without the arms, the 11MHz and 55MHz resonate at different PRC lengths.  If this difference is very small, then we are fine, but if the difference is large, it could be causing trouble - we're trying to catch the lock at the linear part of the 55MHz signal, but if that does not coincide with the linear part of the 11MHz signal, we're doing the wrong thing.  

* For the POP normalization, should we be using the amplitude or the power ( POP22 or sqrt(POP22) )?  Why?  Look at this with a modelling sweep and/or analytically.

* Look at different noise sources, potentially sensing noise, coil actuator noise,.....  We should check these out, and make sure we're not limited by anything obvious. 

Other To-Do:

* Make a "restore" medm screen, rather than restore script.  IFO Configure restore script can pull in values from the screen (EPICS values).  One screen per configuration. 

* Get TRIG_MON signals saved, write script to search for triggered lock times (between given gps times), then plot interesting signals for just before lock, during lock, and until just after a lockloss.

I have re-implemented POP110.  The cable coming from the AS110 diode is disconnected, labeled, and sitting in the cable tray next to the LSC rack. 

Now the POP diode path is:

Thorlabs 10CF ----many meters of heliax cable-----> Bias Tee ------> RF amplifier ------> Splitter ------> Bandpass 21.7MHz --------> POP22 demod board

                                                                                                                   |                                                                                    |

                                                                                                                   |                                                                                    |

                                                                                                                   V                                                                                  V

                                                                                                            POP DC                                                                        High pass 100MHz

                                                                                                                                                                                                        |

                                                                                                                                                                                                        |

                                                                                                                                                                                                       V

                                                                                                                                                                                              Lowpass 150MHz

                                                                                                                                                                                                       |

                                                                                                                                                                                                       |

                                                                                                                                                                                                      V

                                                                                                                                                                                        POP110 demod board

 Note: The TRY PD isn't installed and normalized properly yet, so the IFO OVERVIEW screen indicates lock for the Yarm constantly, which is not true.  Hopefully in the next day or so the screen will be back to telling the truth.

Also, the LSC Locking was left ENABLED (presumably over the weekend).   This is not so good.  It can kick optics around, so we should all take a look when we walk through the control room, and if no one is locking, please disable the LSC master switch. 

 To take this into account, last night, I reduced the TRY gain by a factor of 2.  This is not exactly correct - when the layout is finalized we need to figure out what the pickoff situation used to be (we think, based on the Xend, that it could have been 0.5*0.9), and do the correct normalization.

I have gone through the different individual degrees of freedom on the IFO_CONFIGURE screen (I haven't done anything to the full IFO yet), and updated the burt snapshot request files to include all of the trigger thresholds (the DoF triggers were there, but the FM triggers and the FM mask - which filter modules to trigger - were not).  I also made all of the restore scripts (which does the burt restore for all those settings) the same.  They were widely different, rather than just different optics chosen for misaligning and restoring.

Before doing any of this work, I moved the whole folder ..../caltech/c1/burt/c1ifoconfigure to ..../caltech/c1/burt/c1ifoconfigure_OLD_but_SAVE , so we can go back and look at the past settings, if we need to.

I also changed the "C1save{DoF}" scripts to ask for keyboard input, and then added them as options to the CONFIGURE screen.  The keyboard input is so that people randomly pushing the buttons don't overwrite our saved burt files.  Here's the secret:  It asks if you are REALLY sure you want to save the configuration.  If you are, type the word "really", then hit enter (as in yes, I am really sure).  Any other answer, and the script will tell you that it is quitting without saving.

I have also removed the "PRM" option, since we really only want the "PRMsb" for almost all purposes.

Also, I removed access to the very, very old text file about how to lock from the screen.  That information is now on the wiki:  https://wiki-40m.ligo.caltech.edu/How_To/Lock_the_Interferometer

I have noted in the drop-down menus that the "align" functions are not yet working.  I know that Den has gotten at least one of the arms' ASSes working today, so once those scripts are ready, we can call them from the configure screen.

Anyhow, the IFO_CONFIGURE screen should be back to being useful!

TRY signals are all gone!  Both the PD and the camera show no signal.  I went down there to turn off the lights, and look to see what was up, and I don't see any obvious things blocking the beam path on the table.  However, Steve has experimentally bungeed the lids down, so I didn't open the box to really look to see what the story is.

Absent TRY, I redid the IFO alignment.  Yarm locked, so I assumed it was close enough.  I redid Xarm alignment pretty significantly.  Transmission was ~0.5, which I got up to ~0.85 (which isn't too bad, since the PMC transmission is 0.74 instead of the usual 0.83).  I then aligned MICH, and PRM.  After fixing up the BS alignment, the POP beam wasn't hitting the POP PD in the center any more.  I centered the beam on the PD, although as Gabriele pointed out to me a week or two ago, we really need to put a lens in front of POP, since the beam is so big.  We're never getting the full beam when the cavity flashes, which is not so good.

Den is still working on locking, so I'll let him write the main locking report for the night.

We see that the PRC carrier lock seems to be more stable when we lock MICH with +1 for ITMY and -1 for ITMX, and PRCL with -1 for both ITMs.  This indicates that we need to revisit the systematic problem with using the PRM oplev to balance the coils, since that oplev has a relatively wide opening angle.  I am working on how to do this.

We have calibrated the overall actuators of each suspension independent of the optical levers. So, we know how much we are 
moving the optic in POS in real units as a result of the dither we inject for the lockin measurement. The amount the oplev beam 
appears to move if there is only POS motion is
d/cos(theta)
where theta is the oplev's angle of incidence and d is the distance the optic has moved in POS.  None of the of the steering mirrors in the 
oplev path matter. 

I propose that I will add an option in the lockin path to subtract away the apparent angle from the oplev output just before the signal 
goes into the lockin module.  Then we will be balancing the actuators based on only the actual angular motion.

The success of this technique depends on how well we know our actuator calibration and the oplev angle of incidence. This also 
assumes that the oplev beam is centered on the optic, so we don't have beam displacement from A2L of the oplev beam, which then 
makes another apparent angular motion.  I suspect that we are close enough that we won't have to worry about this effect.

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!

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

After Den's work with the ASS model this week, all of the channel names were changed (this wasn't pointed out in his elog....grrr), so none of the A2L scripts worked. 

They are now back, however there is still some problem with the plotting that I'm not sure I understand yet.  So, the measurement works, but I don't think we're saving the results and we certainly aren't plotting them yet. 

I wanted to check where the spots are on the mirrors, to make sure Den's stuff is doing what we think it's doing.  All of the numbers were within ~1.5mm of center, although Rossa keeps crashing (twice this afternoon?!?), so I can't copy and paste the numbers into the elog.

A near-term goal is to copy over Den's work on the Yarm to the Xarm, so that both arms will auto-align.  Also, I need to put the set of alignment scripts in a wrapper, and have that wrapper call-able from the IFO Configure screen.

Also, while thinking about the IFO Configure screen, the "save" scripts weren't working (on Rossa) today, even though I just made them work a week or so ago. Rossa, at least, was unhappy running csh, so I changed the "save" script over to bash.