40m QIL Cryo_Lab CTN SUS_Lab CAML OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m elog, Page 318 of 357  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  9511   Tue Dec 31 23:19:58 2013 KojiSummaryGenerallinux1 RAID crash & recovery

Dec 22 between 6AM and 7AM, physical or logical failure has occure on the 4th disk in the RAID array on linux1.
This caused the RAID disk fell into the readonly mode. All of the hosts dependent on linux1 via NFS were affected by the incident.

Today the system has been recovered. The failed filesystem was restored by copying all of the files (1.3TB total) on the RAID to a 2TB SATA disk.
The depending hosts were restarted and we recovered elog/wiki access as well as the interferometer control system.


Recovery process

o Recover the access to linux1

- Connect an LCD display on the host. The keyboard is already connected and on the machine.
- One can login to linux1 from one of the virtual consoles, which can be switched by Alt+1/2/3 ...etc
- The device file of the RAID is /dev/sda1
- The boot didn't go straightforward as mounting of the disks accoding to /dev/fstab doesn't go well.
- The 40m root password was used to login with the filesystem recovery mode.
- Use the following command to make the editing of /etc/fstab available

# mount -o rw, remount /

- In order to make the normal reboot successfull, the line for the RAID in /etc/fstab needed to be commented out.

o Connect the external disk on linux1

- Brought a spare 2TB SATA disk from rossa.
- Connect the disk via an USB-SATA enclosure (dev/sdd1)
- Mount the 2TB disk on /tmpdisk
- Run the following command for the duplication

# rsync -aHuv --progress /home/ /tmpdisk/ >/rsync_KA_20131229_0230.log

- Because of the slow SCSI I/F, the copy rate was limited to ~6MB/s. The copy started on 27th and finished 31st.

o Restart linux1

- It was found that linux1 couldn't boot if the USB drive is connected.
- The machine has two SATA ports. These two are used for another RAID array that is not actually used. (/oldhome)
- linux1 was pulled out from the shelf in order to remove the two SATA disks.
- The 2TB disk was installed on the SATA port0.
- Restart linux1 but didn't start as the new disk is recognized as the boot disk.
- The BIOS setting was changed so that the 80GB PATA disk is recognized as the boot disk.
- The boot process fell into the filesystem recovery mode again. /etc/fstab was modified as follows.

/dev/VolGroup00/LogVol00 /                ext3    defaults        1 1
LABEL=/boot              /boot            ext3    defaults        1 2
devpts                   /dev/pts         devpts  gid=5,mode=620  0 0
tmpfs                    /dev/shm         tmpfs   defaults        0 0
proc                     /proc            proc    defaults        0 0
sysfs                    /sys             sysfs   defaults        0 0
/dev/VolGroup00/LogVol01 swap             swap    defaults        0 0
#/dev/md0                 /oldhome         ext3    defaults        0 1
/dev/sda1                /home            ext3    defaults        0 1
#/dev/sdb1                /tmpraid         ext3    defaults        0 1

- Another reboot make the operating system launched as usual.

o What's happen to the RAID?

- Hot removal of the disk #4.
- Hot plug of the disk #4.
- Disk #4 started to get rebuilt -> ~3hours rebuilding done
- This made the system marked as "clean". Now the raid (/dev/sdb1) can be mounted as usual.


o Nodus

- Root password of nodus is not known.
- Connect an LCD monitor and a Sun keyboard on nodus.
- Type Stop-A. This leads the nodus transition to the monitor mode.
- Type sync.
- This leads the system rebooted.

  9513   Thu Jan 2 10:15:20 2014 JamieSummaryGenerallinux1 RAID crash & recovery

Well done Koji!  I'm very impressed with the sysadmin skillz.

  9520   Mon Jan 6 16:32:40 2014 KojiSummaryGenerallinux1 RAID crash & recovery

Since this configuration change, the daily backup was speeded up by factor of more than two.
It was really limited by the bandwidth of the RAID array.

/cvs/cds/rtcds/caltech/c1/scripts/backup/rsync.backup.cumlog:

...
rsync.backup start: 2013-12-20-05:00:00, end: 2013-12-20-07:04:28, errcode 0
...
rsync.backup start: 2014-01-05-05:00:00, end: 2014-01-05-05:55:04, errcode 0

(The daily backup starts from 5:00)

  8140   Fri Feb 22 20:28:17 2013 JamieUpdateComputerslinux1 dead, then undead

At around 2:30pm today something brought down most of the martian network.  All control room workstations, nodus, etc. were unresponsive.  After poking around for a bit I finally figured it had to be linux1, which serves the NFS filesystem for all the important CDS stuff.  linux1 was indeed completely unresponsive.

Looking closer I noticed that the Fibrenetix FX-606-U4 SCSI hardware RAID device connected to linux1 (see #1901), which holds cds network filesystem, was showing "IDE Channel #4 Error Reading" on it's little LCD display.  I assumed this was the cause of the linux1 crash.

I hard shutdown linux1, and powered off the Fibrenetix device.  I pulled the disk from slot 4 and replaced it with one of the spares we had in the control room cabinets.  I powered the device back up and it beeped for a while.  Unfortunately the device was requiring a password to access it from the front panel, and I could find no manual for the device in the lab, nor does the manufacturer offer the manual on it's web site.

Eventually I was able to get linux1 fully rebooted (after some fscks) and it seemed to mount the hardware RAID (as /dev/sdc1) fine.  The brought the NFS back.  I had to reboot nodus to get it recovered, but all the control room and front-end linux machines seemed to recover on their own (although the front-ends did need an mxstream restart).

The remaining problem is that the linux1 hardware RAID device is still currently unaccessible, and it's not clear to me that it's actually synced the new disk that I put in it.  In other words I have very little confidence that we actually have an operational RAID for /opt/rtcds.  I've contacted the LDAS guys (ie. Dan Kozak) who are managing the 40m backup to confirm that the backup is legit.  In the mean time I'm going to spec out some replacement disks onto which to copy /opt/rtcds, and also so that we can get rid of this old SCSI RAID thing.

Attachment 1: FX-606-U4_1205.pdf
FX-606-U4_1205.pdf
  118   Tue Nov 20 13:06:57 2007 tobinConfigurationComputerslinux1 has new disk
Alex put the new hard disk into linux1 along with a fresh install of linux (CentOS). The old disk was too damaged to copy.

Alex speculates that the old disk failed due to overheating and that linux1 could use an extra fan to prevent this in the future.
  140   Thu Nov 29 14:29:22 2007 tobinConfigurationComputerslinux1 httpd/conlogger fixed
I think I fixed the conlogger web interface on linux1.

Steps necessary to do this:
0. Run "/etc/init.d/httpd start" to start up httpd right now
1. Run "/usr/sbin/ntsysv" and configure httpd to be started automatically in the future
2. Copy /cvs/cds/caltech/conlogger/bin/conlog_web.pl to /var/www/cgi-bin and chown to controls
8. Hack the conlog_web.pl to (0) use /usr/bin/perl (1) not use Apache::Util, and (2) function with the newer version of CGI.pm
9. Enjoy!

The following steps are optional, and may be inserted between steps 2 and 8:
3. Try to install Apache::Util (via "perl -MCPAN -e shell" followed by "Install Apache::Util")
4. Notice that the installation dies because there is no C compiler installed
5. Bang head in disgust and abomination over a Linux distribution shipping without a C compiler installed by default
6. "yum install gcc"
7. Annoyed by further dependencies, go to step 8
  1088   Fri Oct 24 20:54:41 2008 ranaConfigurationComputerslinux2
I have removed linux2 and its cables from the control room and put it into 1Y3 along with op340m.

When Joe next comes in we can ask him to Cat6 it to the rest of the world, although it already
seems to me that the CDS hub/switch next Alberto's desk is too full and that we need to purchase
a 48 port device for there.
  1098   Tue Oct 28 12:01:01 2008 josephbConfigurationComputerslinux2

Quote:
I have removed linux2 and its cables from the control room and put it into 1Y3 along with op340m.

When Joe next comes in we can ask him to Cat6 it to the rest of the world, although it already
seems to me that the CDS hub/switch next Alberto's desk is too full and that we need to purchase
a 48 port device for there.


Note I still need to remove a fair bit of cabling no longer in use from the Martian network switch next to Alberto's desk. There's actually about 8-10 cables there which show no connectivity and are not being used. So there's really about 33% of the ports open in the control room hub, it just doesn't look like it.

As for linux2, I'll probably just connect it to the 1Y2 or 1Y6 Hubs when I get the chance.
  13095   Wed Jul 5 10:23:18 2017 SteveUpdatesafetyliquid nitrogen boil off

The liquid nitrogen container has a pressure releif valve set to 35 PSI  This valve will open periodically when contains LN2

The exiting  very cold gas can cause burning so it should not hit directly your eyes or skin.  Set the pointing of this valve into the corner.

Leave entry door open so nitrogen concentration can not build up.

Oxygen deficiency
Nitrogen can displace oxygen in the air, reducing the
percentage of oxygen to below safe levels. Because the brain
needs a continuous supply of oxygen to remain active, lack
of oxygen prevents the brain from functioning properly, and
it shuts down.
Being odorless, colorless, tasteless, and nonirritating,
nitrogen has no properties that can warn people of its pres-
ence. Inhalation of excessive amounts of nitrogen can cause
dizziness, nausea, vomiting, loss of consciousness, and death
Attachment 1: liqued_nitrogen_boil_off.jpg
liqued_nitrogen_boil_off.jpg
  13526   Wed Jan 10 16:27:02 2018 SteveConfigurationSEIload cell for weight measurement

We could use similar load cells   to make the actual weight measurement on the Stacis legs. This seems practical in our case.

I have had bad experience with pneumatic Barry isolators.

Our approximate max compression loads are 1500 lbs on 2 feet and 2500 lbs on the 3rd one.

Quote:

We've been thinking about putting in a blade spring / wire based aluminum breadboard on top of the ETM & ITM stacks to get an extra factor of 10 in seismic attenuation.

Today Koji and I wondered about whether we could instead put something on the outside of the chambers. We have frozen the STACIS system because it produces a lot of excess noise below 1 Hz while isolating in the 5-50 Hz band.

But there is a small gap between the STACIS and the blue crossbeams that attache to the beams that go into the vacuum to support the stack. One possibility is to put in a small compliant piece in there to gives us some isolation in the 10-30 Hz band where we are using up a lot of the control range. The SLM series mounts from Barry Controls seems to do the trick. Depending on the load, we can get a 3-4 Hz resonant frequency.

Steve, can you please figure out how to measure what the vertical load is on each of the STACIS?

 

Attachment 1: stacis3LoadCells.png
stacis3LoadCells.png
  13570   Tue Jan 23 16:02:05 2018 SteveConfigurationSEIload cells

1500 and 2000 lbs load cells arrived from MIT to measure the vertical loads on each leg.

Quote:

We've been thinking about putting in a blade spring / wire based aluminum breadboard on top of the ETM & ITM stacks to get an extra factor of 10 in seismic attenuation.

Today Koji and I wondered about whether we could instead put something on the outside of the chambers. We have frozen the STACIS system because it produces a lot of excess noise below 1 Hz while isolating in the 5-50 Hz band.

But there is a small gap between the STACIS and the blue crossbeams that attache to the beams that go into the vacuum to support the stack. One possibility is to put in a small compliant piece in there to gives us some isolation in the 10-30 Hz band where we are using up a lot of the control range. The SLM series mounts from Barry Controls seems to do the trick. Depending on the load, we can get a 3-4 Hz resonant frequency.

Steve, can you please figure out how to measure what the vertical load is on each of the STACIS?

 

Attachment 1: stacis3LoadCells.png
stacis3LoadCells.png
Attachment 2: DSC00025.JPG
DSC00025.JPG
Attachment 3: DSC00026.JPG
DSC00026.JPG
  1238   Mon Jan 19 15:10:37 2009 YoichiHowToComputersloadLIGOData a GUI for mDV
I installed loadLIGOData, a product of my weekend project, in /cvs/cds/caltech/apps/loadLIGOData.
This is a Matlab GUI for getting data from nds servers. It uses a modified version of mDV to retrieve data.
You can choose and download LIGO data into Matlab quickly.
I also wrote a GUI to plot the downloaded data easily.
With this GUI, you can plot multiple channel data in a single figure, which is useful to identify the cause for a lock loss etc.
You can change the time axis labels to UTC or Local time in stead of GPS second.

You can run it by typing loadLIGOData in a terminal of a linux machine.
A brief explanation of how to use it is written here:
http://lhocds.ligo-wa.caltech.edu:8000/40m/loadLIGOData

At this moment, data from test points cannot be retrieved properly (of course there is no way to go back to the past for test points.
But still we should be able to get data in real time.). I'll try to find a solution.
Attachment 1: loadLIGOData.png
loadLIGOData.png
Attachment 2: plotLigoData.png
plotLigoData.png
  1239   Mon Jan 19 18:21:41 2009 ranaUpdateComputersloadLIGOData a GUI for mDV
The tool is very nice; I looked at the seismic trend for 16 days (attached).
However, it gives some kind of error when trying to get Hanford or Livingston data.
Attachment 1: a.png
a.png
  1240   Tue Jan 20 15:28:42 2009 YoichiUpdateComputersloadLIGOData a GUI for mDV

Quote:
The tool is very nice; I looked at the seismic trend for 16 days (attached).
However, it gives some kind of error when trying to get Hanford or Livingston data.


I fixed it.
You have to click "Load channels" button when you select a new site.
I plotted one minute of MC_F signals from H1, H2, L1 and 40m.
Looks like L1 MC was swinging a lot.
Attachment 1: MC_F.png
MC_F.png
  9775   Wed Apr 2 09:31:22 2014 SteveUpdatePEMlocal 3.0M earthquake

Quote:

Koji locked the MC, arms, and PRMI, with no troubles, after the M8.2 earthquake off the coast of Chile, that happened about 4 hours ago.

 Atm2, Chilean 8.2M eq arrived to the 40m 16:57 in 10 minutes. Our OSEMs did not see them.  Hanford got it 2 minutes later.

Attachment 1: local3.0Meq.png
local3.0Meq.png
Attachment 2: 8.2MegChili?.png
8.2MegChili?.png
  14201   Thu Sep 20 08:17:14 2018 SteveUpdateSUSlocal 3.4M earth quake

M3.4 Colton shake did not trip sus.

 

Attachment 1: local_3.4M.png
local_3.4M.png
  14188   Wed Aug 29 09:20:27 2018 SteveUpdateSUSlocal 4.4M earth quake

All suspension tripped. Their damping restored. The MC is locked.

ITMX-UL & side magnets are stuck.

 

Attachment 1: 4.4_La_Verne.png
4.4_La_Verne.png
Attachment 2: 3.4_&_4.4M_EQ.png
3.4_&_4.4M_EQ.png
  14190   Wed Aug 29 11:46:27 2018 JonUpdateSUSlocal 4.4M earth quake

I freed ITMX and coarsely realigned the IFO using the OPLEVs. All the alignments were a bit off from overnight.

The IFO is still only able to lock in MICH mode currently, which was the situation before the earthquake. This morning I additionally tried restoring the burt state of the four machines that had been rebooted in the last week (c1iscaux, c1aux, c1psl, c1lsc) but that did not solve it.

Quote:

All suspension tripped. Their damping restored. The MC is locked.

ITMX-UL & side magnets are stuck.

 

 

  12149   Fri Jun 3 14:24:13 2016 SteveUpdateSUSlocal EQ 3.1 m

Local EQ 3.1 mag at Jun 2, 2016 11:06:16 PM UTC, Muscoy CA........no damage

Our STS should seen this shake.

 

Attachment 1: eq3.1mMuscoyCa.png
eq3.1mMuscoyCa.png
  12062   Tue Apr 5 08:55:51 2016 SteveUpdateSUSlocal EQ 3.1m

Local earth quake 3.1 magnitude in Valencia, Ca did not trip our suspensions.

 

Attachment 1: eq3.1Valencia.png
eq3.1Valencia.png
  12133   Wed May 25 08:32:55 2016 SteveUpdateSUSlocal EQ 3.5m

Local EQ 3.5 mag  at 2:28 UTC May 24, 2016 Rancho Cucamonga, Ca.....no damage

 

Attachment 1: 3.5Cucam.png
3.5Cucam.png
Attachment 2: local3.5cucam.png
local3.5cucam.png
  6527   Thu Apr 12 08:49:14 2012 DenUpdateSUSlocal damping and WFS

I tried to figure out what can add noise below 0.5 Hz to the MC_F. I compared MC1, MC2, MC3 suspos, suspit, susyaw and susside positions with damping (black curves) and without (red curves). Local damping is fine.

 mc1.png        mc2.png          mc3.png

Then I compared MC1, MC2, MC3 suspos, suspit, susyaw and susside positions with WFS on (black curve) and off (red curve). WFS add noise to MC1 and MC3 measured by osems (MC2 is fine though). WFS should change osem readings but is it a correct way to do this below 0.5 Hz (?) It looks like just a flat noise. Need to think about the conclusion.

 

 wfsmc1.png           wfsmc2.png            wfsmc3.png

  6528   Thu Apr 12 14:48:44 2012 SureshUpdateSUSlocal damping and WFS

    WFS servo is moving the MC mirror angles to minimise TEM01 and TEM10 modes within the MC cavity.    This means it will compensate not only for angular noise in the mirrors but also for the PSL beam pointing fluctuations.  So the extra "noise" we see when WFS loops are on is because they are active below the WFS UGF of about 2 Hz.  Also if the HEPA airflow is above 20% (of its max), the PSL beam jitter (caused by the airflow) will add broadband noise into the WFS servo loops and this will show up in the OSEM signals.  See elog 5943 for details.

 

 

Quote

    ......            

Then I compared MC1, MC2, MC3 suspos, suspit, susyaw and susside positions with WFS on (black curve) and off (red curve). WFS add noise to MC1 and MC3 measured by osems (MC2 is fine though). WFS should change osem readings but is it a correct way to do this below 0.5 Hz (?) It looks like just a flat noise. Need to think about the conclusion.

 

 wfsmc1.png                      

 

 

 

  6037   Tue Nov 29 15:30:01 2011 jamieUpdateCDSlocation of currently used filter function

So I tracked down where the currently-used filter function code is defined (the following is all relative to /opt/rtcds/caltech/c1/core/release):

Looking at one of the generated front-end C source codes (src/fe/c1lsc/c1lsc.c) it looks like the relevant filter function is:

filterModuleD()

which is defined in:

src/include/drv/fm10Gen.c

and an associated header file is:

src/include/fm10Gen.h
  6038   Tue Nov 29 15:57:43 2011 DenUpdateCDSlocation of currently used filter function

 

We are interested in the following question : Can the structures defined in fm10Gen.h (or some other *.c *.h files with defined as FLOAT variables) create single precision instead of double in the filter calculations?

 

typedef struct FM_OP_IN{
  UINT32 opSwitchE;     /* Epics Switch Control Register; 28/32 bits used*/
  UINT32 opSwitchP;     /* PIII Switch Control Register; 28/32 bits used*/
  UINT32 rset;          /* reset switches */
  float offset;         /* signal offset */
  float outgain;        /* module gain */
  float limiter;        /* used to limit the filter output to +/- limit val */
  int rmpcmp[FILTERS];  /* ramp counts: ramps on a filter for type 2 output*/
                        /* comparison limit: compare limit for type 3 output*/
                        /* not used for type 1 output filter */
  int timeout[FILTERS]; /* used to timeout wait in type 3 output filter */
  int cnt[FILTERS];     /* used to keep track of up and down cnt of rmpcmp */
                        /* should be initialized to zero */
  float gain_ramp_time; /* gain change ramping time in seconds */
} FM_OP_IN;  

 

  9500   Fri Dec 20 03:31:07 2013 KojiUpdateLSClock acquisition path for the CM servo

up/down scripts are to be made

(Offset Edit on Dec 20 10:38PM)


Configuration:
POY11QMon -> CM Servo In1 -> CM Servo -->Out1 -> ADC -> CM Slow FM -> LSC MC Servo FM -> ETMY(x1.0) -> DAC -> ETMY
                                       |
                                       -->Servo Out -> SR560 (DC, 1st order 30kHz LPF) -> MC In2


Lock acquisition path 1

Initial condition:

CM Slow FM:

  • Gain 2.6

CM Servo setting:

  • In1 Gain 31dB, SW:OFF, Offset -1.880, Boost Off, Super Boost Off, AO +8dB

MC Servo setting:

  • In2 10dB, SW:OFF

Acquisition:

  • Engage LSC
  • LSC MC servo gain +0.1, FM7/FM10 (Trigger FM2 with 3sec delay)
  • Turn on MC

Transition:

  • Enable AO path (CM servo In1 SW:ON, MC servo In2 SW:ON)
  • LSC MC gain +0.1 -> +0.2
  • AO path gain 8dB->14dB
  • LSC MC gain +0.2 -> +0.35
  • AO path gain 14dB->18dB
  • CM servo offset -1.88 -2.7 -> 0.8 0.0 (gradually)
  • Enable CM servo Boost

Lock acquisition path 2

Initial condition:

CM Slow FM:

  • Gain 2.6

CM Servo setting:

  • In1 Gain 31dB, SW:OFF, Offset -1.880, Boost Off, Super Boost Off, AO +20dB

MC Servo setting:

  • In2 10dB, SW:OFF

Acquisition:

  • Engage LSC
  • LSC Yarm G=+0.25 FM4/5 (Trigger FM3/6/7/8)

Transition:

  • Enable MC servo In2 (SW:ON)
  • Set LSC MC gain +0.2 FM7/10
  • Enable LSC MC (On)
  • Enable CM servo In1 (SW:ON)
  • Disable LSC Yarm (OFF)
  • Change CM servo offset -1.88 -> +0.700 -2.70 -> 0.0
  • Enable CM servo Boost
  • Turn on LSC CM FM2 (optional)

Transition to ETMY LSC to MCL

  • After all of the transition: LSC output matrix ETMY (+1.00)
  • LSC output matrix MC2 (-1.00)
  • LSC output matrix ETMY (0.00)
  9840   Tue Apr 22 02:14:55 2014 ericqUpdateLSClock acquisition path for the CM servo

In an effort to familiarize myself with the analog CM servo, I've begun to replicate Koji and Den's work from the ELOG post that this is a reply to.

I hooked POX11Q into the IN1 of the CM board. (POX is rotated by ~86 degrees in the CDS, meaning analog Q is almost perfect.)

While there, I took out the too-long delay cables Jenne introduced for REFLs 11 and 55. (Also note: when we do cable-based analog phasing in the future, we should do it on the LO side, instead of the PD input side.) I also heard a dangerously crinkly sound from the short SMA cable for REFL11, so I replaced it with a beefy looking new one I found on the SP table.

I messed with the gain and offset in the CM_SLOW input filter to get it to look just like POX11_I_ERR, and was able to lock the arm on it without an issue. I then put the SR560 between the CM and MC (30k pole, but also AC coupled, because I figure the digital loop should be doing the work down there, and don't want to kick the AO with an offset), and was able to turn on the AO path with a gain of 8dB on the CM board and 10dB on the MC board, as detailed in Koji's procedures.

I wasn't able to increase the AO gain to 9dB without breaking lock, but maybe this is ok, because by judging by the LSC filter gains, POX11 might be about 3 times bigger than POY, so maybe 8dB AO gain on POX ~ =18dB AO gain on POY? I was able to put the CM servo offset at 0, but turning on boosts promptly kicked the MC out of lock.

I'm stopping for the night; but tomorrow I'll bust out a spectrum analyzer to see if I actually have won some bandwidth with the CM servo, and check out the situation with the offsets and boosts.

  1560   Fri May 8 02:08:59 2009 peteUpdateLockinglock stretches

locks last for about an hour.  this was true last night as well (see "arm power curve" entries).   the second lock shown here evolves differently for unknown reasons.  the jumps in the arm powers of the first lock are due to turning on DC readout.  length-to-angle needs tuning.

 

 

Attachment 1: powers_oplev.pdf
powers_oplev.pdf
  3059   Wed Jun 9 11:13:11 2010 kiwamuUpdateGreen Lockinglock with PDH box

A progress on the end PDH locking :

by using a modified PDH box the green laser on the X-end station is locked to the arm cavity.

So far the end PDH locking had been achieved by using SR560s, but it was not sophisticated filter.

To have a sophisticated filter and make the control loop more stable, the PDH box labeled "#G1" was installed instead of the SR560s.

After the installation the loop looks more stable than the before.

Some details about the modification of the PDH box will be posted later.

 

Although, sometimes the loop was unlocked because the sum-amp (still SR560) which mixes the modulation and the feedback signal going to the NPRO PZT was saturated sometimes.

Thus as we expected a temperature control for the laser crystal is definitely needed in order to reduce such big low frequency drive signal to the PZT.

  1678   Tue Jun 16 14:02:16 2009 robUpdateLockinglocked

The IFO is locked, at the operating point (zero CARM offset).  The problem with reducing the residual CARM offset in the last stage appears to have been because the common mode gain was getting too high, and so the loop was going unstable at high frequencies. 

The cm_step script is currently a confusing mess, with all the debugging statements.  I'll clean it up this afternoon and check that it still works.

  2988   Wed May 26 04:14:21 2010 kiwamuUpdateGreen Lockinglocked

I guess I succeeded in locking of the cavity with the green beam 

 Strictly speaking, the laser frequency of the end NPRO is locked to the 40 meter arm cavity.

Pictures, some more quantitative numbers and some plots are going to be posted later.

 


After the alignment of the cavity I could see DC fringes in its reflection. Also I could see the cavity flashing on the monitor of  ETMY_CCD.

I drove the pzt of the NPRO with f=200kHz, and then the spectrum analyzer showed 200kHz beat note in the reflection signal. This means it's ready to PDH technique.

And then I made a servo loop with two SR560s, one for a filter and the other for a sum amp.

After playing with the value of the gain and the sign of the feedback signal, the laser successfully got lock. 

 

To make sure it is really locked, I measured the open loop transfer function of the PDH servo while it stayed locked. The result is shown in the attached figure.

The measured data almost agrees with the expected curve below 1kHz, so I conclude it is really locked.

However the plot looks very noisy because I could not inject a big excitation signal into the loop. If I put a big excitation, the servo was unlocked.

The current servo is obviously too naive and it only has f-1 shape, so the filter should be replaced by a dedicated PDH box as we planed.

Attachment 1: OLTF_endPDH.png
OLTF_endPDH.png
  2992   Wed May 26 14:38:02 2010 KojiUpdateGreen Lockinglocked

Congratulation! Probably you are right, but I could not get this is a real lock or something else.

1) How much was the fringe amplitude (DC) of the reflected beam? (Vref_max=XXX [V] and Vref_min=YYY [V])
    Does this agree with the expectation?

2) Do you have the time series? (V_ref and V_error)

Quote:

I guess I succeeded in locking of the cavity with the green beam 

 Strictly speaking, the laser frequency of the end NPRO is locked to the 40 meter arm cavity.

Pictures, some more quantitative numbers and some plots are going to be posted later.

 


After the alignment of the cavity I could see DC fringes in its reflection. Also I could see the cavity flashing on the monitor of  ETMY_CCD.

I drove the pzt of the NPRO with f=200kHz, and then the spectrum analyzer showed 200kHz beat note in the reflection signal. This means it's ready to PDH technique.

And then I made a servo loop with two SR560s, one for a filter and the other for a sum amp.

After playing with the value of the gain and the sign of the feedback signal, the laser successfully got lock. 

 

To make sure it is really locked, I measured the open loop transfer function of the PDH servo while it stayed locked. The result is shown in the attached figure.

The measured data almost agrees with the expected curve below 1kHz, so I conclude it is really locked.

However the plot looks very noisy because I could not inject a big excitation signal into the loop. If I put a big excitation, the servo was unlocked.

The current servo is obviously too naive and it only has f-1 shape, so the filter should be replaced by a dedicated PDH box as we planed.

 

  3262   Wed Jul 21 19:11:18 2010 DmassUpdateGreen Lockinglocked

What did you use to filter the 2f components from your error signal? A homemade low pass or what?

 


Kiwamu:

I am using a homemade low pass filter.

It's just a RC passive LPF with the input impedance of 50 Ohm.

  6942   Mon Jul 9 05:15:46 2012 yutaUpdateGreen Lockinglocked MI while ALS using ASDC

I locked MI while both arm length are stabilized at IR resonance. This could be done using DC READOUT, in other words, use AS_DC as MICH error signal.
Lock using RF signals are still not successful.

FPMIALStrial20120709.png

  4141   Wed Jan 12 01:39:49 2011 kiwamuUpdateLSClocked X arm

[Suresh, Kiwamu]

 We eventually succeeded in locking X arm with the infrared beam.

The PDH signal is taken at MCL's ADC instead of c1lsc's, and fedback to MC2_POS through the MCL path.

Right now the lock is not so stable for some reasons, so we need to investigate it more.

 

(what we did)

 - strung a long BNC cable to connect the demodulated signal and the ADC of c1ioo.

          We didn't touch anything on the demodulation system, so the setup for the demodulation is exactly the same as that of yesterday (see here).

 - disconnected the actual MCL cable from the ADC breakout board at 1X2 rack. And put the demodulated signal onto it.

 - checked the analog dewhitening filter state for the MC2 coil driver, found the analog filter are always off.

  So we just made simDW and invDW always on.

- changed the gain of the MCL loop to have a stable lock for the X arm.

    right now a reasonable setup in the MCL filters are:

         FM1:ON, FM10:ON, G=0.1

 - In fact the lock of the MC is not so stable compared to before, frequently an attempt of locking the X arm leads to the unlock of the MC.

  4007   Fri Dec 3 05:21:11 2010 kiwamuUpdateGreen Lockinglocked the laser to the cavity

I succeeded in locking the end green laser to X arm with the new ETM.

Though the lock is still not so stable compared to the previous locking with the old ETM. Also the beam centering is quite bad now.

So I will keep working on the end green lock a little bit more.

Once the lock gets improved and becomes reasonably stiff, we will move onto the corner PLL experiment.

 

(to do)

 - beam centering on ITMX

 - check the mode matching

 - revise the control servo

  8521   Thu May 2 00:34:57 2013 KojiUpdateLSClocking

- Routine alignment

Locked the arm cavties. Ran ASS. As this was not enough precise alignment for PRMI locking, Yarm alignment was re-adjusted by sliders.
Xarm was also aligned in the same way.

- OPLEV alignment

Once the arms were aligned, OPLEV spots were adjusted. For this adjustment, PRM had to be aligned and OPLEV servos needed to be turned off.

- LSC offset nulling

While Jenne was measuring the dark output of the POP PD, LSC offset nulling script was executed.

- Compensation of the POP spot size fix

As Jenne reported the POP path now has a lens and the denominator for the normalization got bigger.
To compensate this change, PRMI(sb) was locked by the same configuration as yesterday (i.e. AS55Q for MICH, REFL33I for PRCL). 
After some try and error, configuration for stable locking was found. 

PRCL
Signal source: REFL33I / Normalization POP110I x 1.00 / Trigger POP110I 80up 10down
Servo: input matrix 1.00 -> PRCL Servo FM3/4/5/6 Always ON G=+8.00
Actuator: output matrix 1.00 -> PRM

MICH
Signal source: AS55Q / Normalization POP110I x 0.01 / Trigger POP110I 80up 10down
Servo: input matrix 1.00 -> MICH Servo FM4/5 Always On G=-30
Actuator output matrix -1.00 -> ITMX / +1.00 -> ITMY

This suggests that POP110I signal is 5~6 times more than before the lens was installed. 

- SQRTing option for POP110I was implemented

The PRMI optical gain is derived from (Carrier)x(1st order Sideband) or (2nd order SB)x(1st order SB).
Here the carrier and the 2nd order sidebands are nonresonant.
Therefore the optical gain is proportional to the amplitude power recycling gain of the 1st order sidebands.
On the other hand, POP 2f signals are derived from the product of the 1st and -1st order sidebands.
This means that we should take a sqrt of the POP signals to compensate the recycling gain fluctuation.

Screenshot.png

- Locking with SQRT(POP110I)

PRCL
Signal source: REFL33I / Normalization SQRT(POP110I) x 10 / Trigger POP110I 10up 3down
Servo: input matrix 1.00 -> PRCL Servo FM3/4/5/6 Always ON G=+8.00
Actuator: output matrix 1.00 -> PRM

MICH
Signal source: AS55Q / Normalization SQRT(POP110I) x 0.1 / Trigger POP110I 10up 3down
Servo: input matrix 1.00 -> MICH Servo FM4/5 Always On G=-30
Actuator output matrix -1.00 -> ITMX / +1.00 -> ITMY

The lock seems not so different from the ones without SQRTing.

The spot was still moving in yaw direction. If I chose a correct alignment, I could minimize the modulation of the internal power
by misalignment. As you can see in the following plot.

Screenshot2.png

When the alignment was deviated from the optimum, the misalignment induced RIN was much worse although this was the longest lock I ever had with the PRMIsb. (more than 8 min)

Screenshot3.png

- Locking with other signal sources

REF55I/Q trial:

Demodulation phase was adjusted to make the difference of the peak heights for MICH maximized.
After the lock is acquired, I tried to swap the signal source at the input matrix. PRCL swapping was successful but
MICH swapping was not successfull.

It is much more hard to lock the interferometer with REFL55I compared with REFL33I.

REFL165I/Q trial:

As REFL165 PD never produced any useful signal, I tried to swap it with the BBPD used in the green setup.

- Borrowed the PD, power supply from the green setup.

- Put REFL165PD aside. Placed the BBPD in the path. The DC output was 0.8V. This corresponds to the input power of ~5mW.

- Checked the signal but it was very litte (several counts even at the maximum whitening gain).

- Decided to use the power reduction pick off to introduce much more light on the PD.
  This PO mirror is 90% reflector. Therefore I had to be careful no to fry the diode.
  Currently there are OD1.3 (x1/20) power attenuator to reduce the input power down to 6.5V (40mW).

- The resulting signal is very wiered suggesting the saturation of the PD at the RF stages.

- Probably I need to make a new PD circuit which has the high pass filter to reject other low frequency components.

  15172   Wed Jan 29 00:29:43 2020 gautamUpdateLSClocking 2020

The goal tonight was to go through the locking scripts to see if I could recover the state from November 2019, when I could have the arm lengths controlled by ALS, and sit at zero CARM offset with the PRMI remaining locked and the arm powers fluctuating between 0-300. The IR-->ALS transitions went smoothly tonight, and the PRMI locking was also fairly robust when the CARM offset was large, but was less good when reduced to 0. Nevertheless, it is good to know that the system can be restored to the state it was late last year. Next step is to figure out how to keep the PRMI locked and get the AO path engaged, this was what I was struggling with before the new year.

Attachment 1: PRFPMI_2020Jan.png
PRFPMI_2020Jan.png
  9456   Thu Dec 12 00:47:45 2013 DenUpdateLSClocking activity

Jenne, Den

Today we worked on PRM angular servos and Y-arm ALS stabilization.

In the current PRMI angular control configuration two servos simultaneously drive PRM - oplev and POP ASC. We considered 2 ways to redesign this topology:

  • once lock is acquired, turn on POP ASC servo that corrects oplev error signal
  • turn off PRM oplev and turn on POP ASC  servo

The first option requires model rewiring so we started from the second one. We had to redesign POP ASC pitch and yaw servos for this because PRM TF has changed. Attached is servo OLTF.

This method worked out well and once PRMI is locked we turned off oplev servo with ramp of 0.5 sec and enable ASC POP servo with ramp of 1 sec.

Once PRMI was locked and ASC running we have turned off PRM angular local damping that presumably prevents us from bringing arms into resonance due to IR coupling to shadow sensors.

PRMI was stable using only ASC POP servo and we moved on to ALS. We found Y-arm beatnote and enabled control to ETMY.

Cavity was stabilized but not robust - we were loosing IR in a minute because green relocked to 01 mode with transmission equal to more than half of 00 mode. This is probably due to angle to length coupling of ETMY.

We were also loosing IMC during cavity stabilization. We made MCL servo and will tune it tomorrow looking at the arm spectrum as an OOL sensor.

Attachment 1: POP_ASC.pdf
POP_ASC.pdf
  9462   Fri Dec 13 02:19:57 2013 JenneUpdateLSClocking activity

[Jenne, Den]

Tonight we worked on tweaking up the PRCL new ASC, and then PRMI+1 arm locking.  We were unable to get the Xarm to stay locked on a TEM00 mode for very long, and after an hour or two of using the PZTs to try to align the beam to the cavity, we gave up and just used Yarm green.

NB: We haven't done anything to MCL, although it is not in use.  Den is still going to get around to elogging what servo shaping he changed on that last night.

I wrote a script that will handle the transitions between the new PRCL ASC and the PRM oplev and local damping.  The script is accessible from the PRC ASC screen, and will detect when the PRMI is locked or not.  When it is locked, it will turn down the PRM oplev gains and turn on the ASC, and then it will turn off the local shadow sensor damping for PRM pitch and yaw.  When the PRMI unlocks, the script will turn off the ASC and restore oplev and local shadow sensor damping. 

We saw that the bounce mode of the PRM was getting rung up with our new ASC, so we included a band stop in the ASC, and also turned on the triggering for the PRCL LSC FM6, which has the resonant gain for the bounce mode (as well as roll, and the stack mode).  This made the PRMI spot very stable. 

We then moved on to green arm locking.  The Yarm is behaving perfectly nicely (as nice as it has been lately - it's alignment and mode matching could also use some work), but Xarm was giving us a bit of trouble.  As always (since the PZTs were installed?), the mode matching isn't excellent for the green to the arm, so it can be hard to catch a TEM00 mode.  Also, even if we did catch a good mode, it would often not stay locked for more than a few tens of seconds.  We tried several alignment tweakings, and several different end laser temperatures (within the confines of seeing the beatnote under 100MHz), and didn't have a lot of success.  It looks like Eric had the slow servo engaged for the Xend laser, so the temperature offset was something like +300,000, which seemed totally crazy.  I turned that off, and found the beatnote somewhere around output of -10,300.  So, I haven't gone to the end to look at the temperature, but it's going to be different than when Eric was taking measurements this afternoon.  It seems like the main problem with the Xarm is poor mode matching - the maximized input pointing for TEM00, when you unlock and relock the cavity, is just as likely to give you a TEM_9_0 mode, as TEM00.

So, we gave up on the Xarm for the evening, and tried PRMI+1arm, with the new PRCL ASC.  This was successful!   The Yarm beatnote was around laser slow servo output of +4450.  Beatnote at 46.0MHz, -26dBm.  We found the IR resonance, moved off, locked the PRMI, transitioned to the new ASC, and brought the Yarm back to IR resonance.  What we see is that the power fluctuations in the PRC are much smaller than they were back around Halloween (elog 9338), however the arm power fluctuations still seem very, very large.  This is certainly partly due to the fact that we haven't done a thorough Yarm alignment since before messing with the greens, so we will have drifted somewhat.  Also, the ALS beatnote sensor isn't perfect, so won't be perfect at holding us near resonance. 

Den is thinking about whether we can use the arm transmission QPD signals to feed back to the ETM ASC servos, to try to reduce the RIN in the arms.  I feel like we should also see if this amount of power fluctuation can be explained by our ALS noise, because maybe we'll be fine once we transition to IR and turn off the ALS system.   Attached is a plot showing that the arm's RIN is coherent with the spot motion seen by the transmission QPD, so we need to check the alignment of the cavity, as well as consider using the trans QPD in an ASC feedback loop.

Here is a plot of the PRC sideband power, as well as the Yarm transmission.  The GPS time for this plot is approximately 1070963372.

PRMI_Yarm_NewPRCLasc.png

Attachment 2: try_dc.pdf
try_dc.pdf
  9463   Fri Dec 13 02:30:22 2013 KojiUpdateLSClocking activity

According to the measurement by Eric, the X-arm green PDH UGF is too low. We still have some room to increase the gain.

The out of loop stability of the ALS for each arm should be measured everyday.
Otherwise we can't tell whether the arm is prepared for advanced locking activities or not.

We expect to see the arm stablity of ~50pm_rms for the Y arm and ~150pm_rms for the X arm.

  9471   Sat Dec 14 02:51:47 2013 DenUpdateLSClocking activity

I had a look on x,y arms stabilization using ALS. Input green beam was misaligned and I was loosing 00 every few minutes. I vent on the floor and realigned green beams.

YARM alignemt was smooth - transmission increased from 0.4 to 0.85 with PSL shutter off.

XARM was tough. Steering mirrors did not have any derivatives when transmission power was 0.5. I walked the beam with piezos but got only 0.55. It seems that the input beam is mismatched to the cavity. When the transmission was 1 last time? Does anyone have a model of the xend table to compute mode matching?

Input green alignent was improved and I could keep arms stabilized for periods of ~30min - 1 hour. Still not forever.

I noticed that ALS_XARM and ALS_YARM servos have limiters of 6000 and control signal had high frequency components that were not rolled off as shown on the plot "ETMY_DRIVE". I have added a low pass filter that reduced RMS by factor of 5 and took 7 degrees of phase at UGF=150 Hz. Now margin is 33 degrees.

Then I excited ETMY longitudinally at 100 Hz and measured first and second harmonics of the YARM RIN. I got total DC offset of 0.3 nm. This means significant length coupling to RIN. First of all, "scan arm" script does not tune the offset very precise. I guess it looks at DC power, checks when cavity passes through symmetrical points of the resonance and takes the average. It is also useful to look at POX/POY and confirm that average is 0. Plot "ALS_RIN" shows comparison of YARM power fluctuations when it is locked using IR and stabilized using ALS. By manually correcting the offset I could reduce length coupling into RIN, coherence was ~0.1.

Cavity RMS motion also couples length to RIN. Plot "ALS_IR" shows YARM error signal. I also looked at POY signal (LSC-YARM_IN1) as an OOL sensor. At low frequencies POY sees only IMC length fluctuations converted to frequency. I have engaged MCL path and ALS error and LSC error signals overlaped. Cavity RMS motion is measured to be 200 pm.

Attachment 1: ETMY_DRIVE.pdf
ETMY_DRIVE.pdf
Attachment 2: ALS_RIN.pdf
ALS_RIN.pdf
Attachment 3: ALS_IR.pdf
ALS_IR.pdf
  9480   Tue Dec 17 02:10:29 2013 DenUpdateLSClocking activity

Koji, Den

Some results and conclusions from tonight:

PRC macroscopic length is detuned. We measured REFL phases in carrier and sideband configurations - they are different by ~45 degrees for both 11 and 55 MHz sidebands. Additional measurement with phase locked lasers is required.

We got stable lock of PRMI+2arms with CARM offset of ~200 pm. We think this is the point when we should transition to 1/sqrt(TR) signals. We plan to rewire LSC model and also test CM servo with 1 arm during the day.

POP ASC OL shape changes when we reduce CARM offset probably due to normalization by sum inside the PD. Servo gets almost useless when PRMI power fluctuates by a factor of few.

SMA cables were made and installed for the REFL165 RF amplifier in lsc rack.

  9853   Fri Apr 25 03:14:46 2014 ericqUpdateLSClocking activity

[ericq, Jenne, Zach]

We spent some time tonight trying to push our CARM locking further, to little avail. DARM/CARM loop oscillations kept sneaking up on us. We measured some MC2 motion -> REFL11 Transfer Functions to see if we could see CARM plant features; plots will come in the near future...

  9855   Fri Apr 25 13:18:08 2014 Dark JamieUpdateLSClocking activity

Quote:

[ericq, Jenne, Zach]

We spent some time tonight trying to push our CARM locking further, to little avail. DARM/CARM loop oscillations kept sneaking up on us. We measured some MC2 motion -> REFL11 Transfer Functions to see if we could see CARM plant features; plots will come in the near future...

 Probably things would have worked better if you would have gotten your hair done at the same place as me.

Attachment 1: m10008_f1_bg.jpg
m10008_f1_bg.jpg
  5754   Fri Oct 28 05:17:13 2011 kiwamuUpdateLSClocking activity : PZT1 is still railing

Status update on the LSC activity:

 To see how good/bad the beam pointing is, I locked the Y arm with POY11.
Then I ran the ASS servo to automatically correct the alignment of the ITMY and ETMY suspensions and also the beam pointing.
The result is that the PZT1_X is still railing to the negative side.
Due to it the transmitted light from the Y arm is about 0.6 or so which is supposed to be 1 if the beam pointing is perfect.
The EPICS value of PZT1_X is at the minimum of -10 and the ASS servo tried to push it more negative side.
 
 Tomorrow night I will intentionally introduce offsets in the MC suspensions to avoid the railing.
The goal will be a scan of the incident beam while measuring the recycling gain.
  5474   Tue Sep 20 03:02:23 2011 KeikoUpdateLSClocking activity tonight

 Keiko, Anamaria, Koji

We were not able to establish the stable DRMI tonight. We could lock MICH and PRCL quite OK, and lock the three degrees of freedom at somewhere strange for several seconds quite easily, but the proper DRMI lock was not obtained.

When MICH and PRC are locked to the carrier, REFL DC PD reading dropps from ~3000 counts to 2600~2700 counts as REFL beam is absorbed to PRC. We'll try to lock PRC to sidebands - but flipping gain sign didn't work today, although it worked a few days ago. 

POP beam (monitor) is useful to align PRM.

  6080   Wed Dec 7 02:55:38 2011 kiwamuUpdateGreen Lockinglocking activity tonight

No real progress.

Probably I spent a bit too much time realigning the beat-note optical path.

 

(what I did)

 - Switched on a power supply which was supposed to give +/- 15V for the broadband beat-note PD.
   The power supply had been somehow turned off.
 - Realigned the beat-note path. When we installed the new EOM mount today, we moved some of the green steering mirrors to make a space.
   So we had to realign the downstream of the beat-note path. After the realignment the DC output of the PD was about 120 mV and the signal level of the beat-note was at -20 dBm.
 - Took noise spectrum of the beat-note with the arm cavity locked by the IR-PDH
    The noise curve was almost the same as before (i.e. unknown high frequency white noise above 20 Hz and some low frequency noise which has structures at 1 and 3 Hz).
-  Closed the ALS loop with the coarse sensor. But I was too lazy to go further more. 

Quote from #6076
Tomorrow I will try :
  (1) Using the fine sensor.
  (2) Noise budgeting with the fine sensor.

  6166   Wed Jan 4 03:03:24 2012 kiwamuUpdateLSClocking activity tonight and beyond
Last night and tonight, I was doing a kind of rehabilitation -- locking PRMI and DRMI with the new trigger system.
Although MC wasn't so awesome (#6164), I confirmed that the DRMI can stay locked with the conventional RFPD combination (#4760).
Additionally I have modified the IFO configure scripts, such that they also automatically restore the thresholds values for triggering.
The scripts are available in the C1IFO_CONFIGURE screen as usual.

 

       Locking plan            

Here is a plan in my mind and these are basically the details of the gantt chart (#6143):

  • (1 day task) Measurement of the recycling gains of the RF sidebands with the PRMI and DRMI configuration, using POP22/110 RFPD.
    • I need to have confidence that I am really locking the DRMI with SRC resonating to 55 MHz.
    • Also those values will enable us to estimate losses and mode matching again (maybe ?).
  • (3-4 days task) Measurement of the sensing matrix using the multiple-LOCKIN system.
    • Write a script to automatically measure the sensing matrix. This must be easy.
      • The results will enable us to diagonalize the input matrix and therefore it eventually gives more solid lock of the DRMI
      • Also it will give us the optical gains of 3f signals. So this is actually a step toward the 3f signal check.
  • (3-4 days task) Noise budgeting on the 3f signals
    • This is a very important part of the DRMI characterization because the results will tell us whether we can hold the DRMI lock with a sufficient SNR or not.
    • If it turns out that they don't have good SNRs, we then have to come up with some ideas to improve the SNRs.
  • (Extra fun task depending on schedule) 3f DRMI lock + Y arm ALS
    • If the beat-box electronics are not available by the time when the work above are completed, I will do this fun task.
    • Probably it is better to start preparing the common mode servo electronics because it will be needed anyway.

 

  429   Sun Apr 20 18:23:27 2008 ranaSummaryLSClocking attempts
I noticed that the adaptive FF for the MC had stopped doing anything; this turned out
to be that the MC lost lock and the mcdown script turned off the FF path to MC1.

Although there's no elog, it looks like there was ~60 attempts at locking the IFO
between 12:38 and 4:27 on Saturday afternoon. I'm attaching here a plot showing
lock attempt durations and a histogram of lock times.
Attachment 1: quix.png
quix.png
ELOG V3.1.3-