40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 288 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  2561   Tue Feb 2 16:10:09 2010 steveUpdatePEMconstruction progress next door

CES construction is progressing. The 40m suspensions are bearing well.

atm1, PEM  vs sus plots of 120 days

atm2, big pool walls are in place, ~10 ft east of south arm

atm3, 10 ft east of ITMY

atm4, ~60 ft east of ITMY

atm5, cold weather effect of N2 evaporator tower

  17123   Wed Aug 31 12:57:07 2022 ranaSummaryALScontrol of ALS beat freq from command line -easy

The PZT sweeps that we've been making to characterize the ALS-X laser should probably be discarded - the DFD was not setup correctly for this during the past few months.

Since the DFD only had a peak-peak range of ~5 MHz, whenever the beat frequency drifts out of the linear range (~2-3 MHz), the data would have an arbitrary gain. Since the drift was actually more like 50 MHz, it meant that the different parts of a single sweep could have some arbitrary gain and sign !!! This is not a good way to measure things.

I used an ezcaservo to keep the beat frequency fixed. The attacehed screenshot shows the command line. We read back the unwrapped beat frequency from the phase tracker, and feedback on the PSL's NPRO temperature. During this the lasers were not locked to any cavities (shutters closed, but servos not disabled).

For the purposes of this measurement, I reduced the CAL factor in the phase tracker screen so that the reported FINE_PHASE_OUT is actually in kHz, rather than Hz on this plot. So the green plot is moving by 10's of MHz. When the servo is engaged, you can see the SLOWDC doing some action. We think the calibration of that channel is ~1 GHz/V, so 0.1 SLOWDC Volts should be ~100 MHz. I think there's a factor of 2 missing here, but its close.

As you can see in the top plot, even with the frequency stabilized by this slow feedback (-1000 to -600 seconds), the I & Q outputs are going through multiple cycles, and so they are unusable for even a non serious measurement.

The only way forward is to use less of a delay in the DFD: I think Anchal has been busily installing this shorter cable (hopefully, its ~3-5 m long so that the linear range is more. I think a 10 m cable is too long.), and the sweeps taken later today should be more useful.

  14873   Thu Sep 12 09:49:07 2019 gautamUpdateComputerscontrol rm wkstns shutdown

Chub wanted to get the correct part number for the replacement UPS batteries which necessitated opening up the UPS. To be cautious, all the workstations were shutdown at ~9:30am while the unit is pulled out and inspected. While looking at the UPS, we found that the insulation on the main power cord is damaged at both ends. Chub will post photos.

However, despite these precautions, rossa reports some error on boot up (not the same xdisp junk that happened before). pianosa and donatella came back up just fine. It is remotely accessible (ssh-able) though so maybe we can recover it...

Quote:

please no one touch the UPS: last time it destroyed ROSSA. Please ask Chub to order the replacement batteries so we can do this in a controlled way (fully shutting down ALL workstations first). Last time we wasted 8 hours on ROSSA rebuilding

  14913   Mon Sep 30 11:42:36 2019 aaronUpdateComputerscontrol rm wkstns shutdown

I booted Rossa in rescue mode; though I see no errors on bootup, I still see the same error ("a problem has occurred") after boot, and a prompt to logout. I powered rossa off/on (single short press of power button), no change.

Booting in debug mode, I see that the error occurs when mounting /cvs/cds, with the error

[FAILED] Failed to mount /cvs/cds.
See `systemctl status cvs-cds.mount` for details.
[DEPEND] Dependency failed for Remote File System

Which is odd, because when I boot in recovery mode, is mounts /cvs/cds successfully. 

I booted in emergency mode by adding to the boot command

systemd.unit=emergency.target

but didn't have the appropriate root password to troubleshoot further (the usual two didn't work).

  3277   Fri Jul 23 15:32:02 2010 steveUpdatePEMcontrol room AC set point changed

The control room temp is warmer than usual. The heat exchanger Office Pro 18 set point was lowered from 70 to 68F yesterday.

The MOPA headtemp is higher also. The Neslab chiller bath temp peaks around 21.6 C daily. This should be rock solid 20.00 C

It did not have any effect.

Now, I have just lowered the thermostat setting of room 101 from 73 to71F  I  hope Koji can take this.

  10061   Wed Jun 18 18:00:36 2014 ericqUpdateComputer Scripts / Programscontrol room bashrc change

Some time ago, Rana changed the PS1 prompt codes on the control room computers. However, the exit codes of commands weren't being displayed, and there was some lingering color changing after the line. Hence, I changed it to look like this:

PS1='\[\033[0;35m\]\u'
PS1="$PS1\[\033[0;30m\]@"
PS1="$PS1\[\033[0;33m\]\h"
PS1="$PS1\[\033[0;97m\]|"
PS1="$PS1\[\033[0;92m\]\W"                                                 
PS1="$PS1\[\033[0;31m\] \${?##0}"
PS1="$PS1\[\033[0;97m\]>\[\033[0m\] "

The \${?##0} means: display the exit code if it is not zero (which means success). Thus, it only displays the exit code when its something other than what is expected.

  10073   Thu Jun 19 14:52:20 2014 not ericqUpdateComputer Scripts / Programscontrol room bashrc change

Quote:

Some time ago, Rana changed the PS1 prompt codes on the control room computers. However, the exit codes of commands weren't being displayed, and there was some lingering color changing after the line. Hence, I changed it to look like this:

PS1='\[\033[0;35m\]\u'
PS1="$PS1\[\033[0;30m\]@"
PS1="$PS1\[\033[0;33m\]\h"
PS1="$PS1\[\033[0;97m\]|"
PS1="$PS1\[\033[0;92m\]\W"                                                 
PS1="$PS1\[\033[0;31m\] \${?##0}"
PS1="$PS1\[\033[0;97m\]>\[\033[0m\] "

The \${?##0} means: display the exit code if it is not zero (which means success). Thus, it only displays the exit code when its something other than what is expected.

  It's a very good plan to always inspect the exit code of your command.  Well done.

  13160   Wed Aug 2 15:04:15 2017 gautamConfigurationComputerscontrol room workstation power distribution

The 4 control room workstation CPUs (Rossa, Pianosa, Donatella and Allegra) are now connected to the UPS.

The 5 monitors are connected to the recently acquired surge-protecting power strips.

Rack-mountable power strip + spare APC Surge Arrest power strip have been stored in the electronics cabinet.

Quote:

this is not the right one; this Ethernet controlled strip we want in the racks for remote control.

Buy some of these for the MONITORS.

 

  9743   Fri Mar 21 14:59:44 2014 steveUpdatePEMcontroling dust

Please take a look at the table top with the flashlight before removing it. If it is dusty, wipe it down with dry lint free cloth in the box.

There is one box with flash light and wiper at AP, ETMY & ETMX  optical tables.

  13134   Mon Jul 24 09:55:29 2017 SteveOmnistructureVACcontroller failer

Ifo pressure was 5.5 mTorr this Monday morning. The PSL shutter was still open. TP2 controller failed. Interlock closed V1, V4 and VM1

Turbo pump 2 is the fore pump of the Maglev. The pressure here was 3.9 Torr so The Maglev got warm ~38C but it was still rotating at 560 Hz normal with closed V1

Pressure plots are not available because of computer problems.

What I did:

Looked at pressures of Hornet and Super Bee  Instru Tech. Inc

Closed all annuloses and VA6,  disconnected V4 and VA6 and turned on external fan to cool Maglev

Opened V7 to pump the Maglev fore line with TP3

V1 opened manually when foreline pressure dropped to <2mTorr at P2 and the body temp of the Maglev cooled down to  25-27 C

VM1 opened at 1e-5 Torr

Valve configuration: vacuum normal with annuloses not pumped

Ifo pressure 8.5e-6 Torr -IT at 10am,  P2 foreline pressure 64 mTorr, TP3 controller 0.17A   22C  50Krpm

note: all valves open manually, interlock can only close them

 

Quote:

While walking down to the X end to reset c1iscex I heard what I would call a "rythmic squnching" sound coming from under the turbo pump.  I would have said the sound was coming from a roughing pump, but none of them are on (as far as I can tell).

Steve maybe look into this??

PS: please call me next time you see the vacuum is not Vacuum Normal

  2735   Tue Mar 30 21:11:42 2010 kiwamuSummaryGreen Lockingconversion efficiency of PPKTP

With a 30mm PPKTP crystal the conversion efficiency from 1064nm to 532nm is expected to 3.7 %/W.

Therefore we will have a green beam of more than 20mW by putting 700mW NPRO.

Last a couple of weeks I performed a numerical simulation for calculating the conversion efficiency of PPKTP crystal which we will have.

Here I try to mention about just the result. The detail will be followed later as another entry.


The attached figure is a result of the calculation.

The horizontal axis is the waist of an input Gaussian beam, and the vertical axis is the conversion efficiency.

You can see three curves in the figure, this is because I want to double check my calculation by comparing  analytical solutions.

The curve named (A) is one of the simplest solution, which assumes that the incident beam is a cylindrical plane wave.

The other curve (B) is also analytic solution, but it assumes different condition; the power profile of incident beam is a Gaussian beam but propagates as a plane wave.

The last curve (C) is the result of my numerical simulation. In this calculation a focused Gaussian beam is injected into the crystal.

The numerical result seems to be reasonable because the shape and the number doesn't much differ from those analytical solutions.

  2736   Tue Mar 30 22:13:49 2010 KojiSummaryGreen Lockingconversion efficiency of PPKTP

Question:

Why does the small spot size for the case (A) have small efficiency as the others? I thought the efficiency goes diverged to infinity as the radius of the cylinder gets smaller.

Quote:

With a 30mm PPKTP crystal the conversion efficiency from 1064nm to 532nm is expected to 3.7 %/W.

Therefore we will have a green beam of more than 2mW by putting 700mW NPRO.

Last a couple of weeks I performed a numerical simulation for calculating the conversion efficiency of PPKTP crystal which we will have.

Here I try to mention about just the result. The detail will be followed later as another entry.


The attached figure is a result of the calculation.

The horizontal axis is the waist of an input Gaussian beam, and the vertical axis is the conversion efficiency.

You can see three curves in the figure, this is because I want to double check my calculation by comparing  analytical solutions.

The curve named (A) is one of the simplest solution, which assumes that the incident beam is a cylindrical plane wave.

The other curve (B) is also analytic solution, but it assumes different condition; the power profile of incident beam is a Gaussian beam but propagates as a plane wave.

The last curve (C) is the result of my numerical simulation. In this calculation a focused Gaussian beam is injected into the crystal.

The numerical result seems to be reasonable because the shape and the number doesn't much differ from those analytical solutions.

 

  3765   Fri Oct 22 19:53:27 2010 yutaSummaryCDSconversion failure in digital filters

(Rana, Joe, Yuta)

We now understand that we never succeeded in converting old fiter files to new filter files.

For example, we just changed the sampling rate with coefficients remained and foton confused, or we forgot to rename some of the module names(ULSEN -> SUS_MC1_ULSEN) ......

This is why we sometimes damped and sometimes didn't, depending on filter switches. New filter files has been always wrong.

So, we started to convert them again.
We have to figure out how to convert the files that Foton accepts correctly.

  2482   Wed Jan 6 16:48:52 2010 steveBureaucracySAFETYcopied NPRO key

We lost our key to the Lightwave 125/6-OPN-PS   The key shop just made one look a like that works.

  15918   Fri Mar 12 21:15:19 2021 gautamUpdateLSCcoronaversary PRFPMi

Attachment #1 - proof that the lock is RF only (A paths are ALS, B paths are RF).

Attachment #2 - CARM OLTF.

Some tuning can be done, the circulating power can be made ~twice as high with some ASC. The vertex is still on 3f control. I didn't get any major characterization done tonight but it's nice to be back here, a year on i guess.

  13592   Wed Jan 31 15:46:05 2018 SteveUpdatesafetycrane inspection

Annual crane inspection with load tests is scheduled for Monday, Feb 5, 2018 from 8 to 11:30am

Konecranes rescheduled this appointment to: Monday, Feb 12, 2018

  8309   Tue Mar 19 10:30:00 2013 steveUpdateSAFETYcrane inspection 2013

 

Professional crane inspector: Fred Goodbar found two small leaks at the Vertex trolley as he was conducting the annual inspection of the 40m cranes.  Otherwise the cranes are in safe condition.

  14601   Fri May 10 13:00:25 2019 ChubUpdateGeneralcrane inspection complete

The 40M jib cranes all passed inspection!

  3279   Fri Jul 23 16:00:35 2010 steveUpdateSAFETYcrane load test tomorrow

All 3 cranes will be load tested at 1 ton tomorrow morning between 9am and 2pm

Do not come to the 40m lab during this period. We may disturb your experiment.

Please prepare your touchy set ups to take this test.

  3810   Thu Oct 28 13:01:34 2010 steveUpdatePEMcrane repair guys left for the day

Quote:

Fire-smoke sensors in the vertex area #2-31, 2-30 east, 2-32 south/MC2 and 2-37 old control room area are turned off to accommodate the welding

activity of folding crane. These sensors will be reactivated at 3:30pm today.

Stay out of the 40m lab: IFO room till 6 pm today.

 The new cord wheel was to big. They be back tomorrow?

The lab is open.

  9084   Wed Aug 28 11:23:41 2013 SteveUpdateVACcrane repair sheduled

Quote:

 1, Vacuum envelope grounds must be connected all times!  After door removal reconnect both cables immediately.

 2, The crane folding had a new issue of getting cut as picture shows.

 3, Too much oplev light is scattered. This picture was taken just before we put on the heavy door.

 4, We were unprepared to hold the smaller side chamber door 29" od of the IOC

 5, Silicon bronze 1/2-13 nuts for chamber doors will be replaced. They are not smooth turning.

 

 Fred Goldbar of KoneCranes will come 7:30am Wednesday, September 4 to look at this issue.

It is changed to Thursday morning.

  3477   Fri Aug 27 11:27:33 2010 steveUpdatePEMcrane safety document

I posted the crane safety document on the 40m wiki, vacuum page as 26 August 2010

Please add your comments and corrections.

 

The South End Crane will be balanced on Tuesday,  31 August 2010

This will mean that the back door of the south arm will be open on and off. Air quality will bad.

Please plan accordingly.

  9359   Thu Nov 7 11:19:04 2013 SteveUpdateVACcrane work POSTPONED to Monday

Quote:

 

The smoke alarms were turned off and surrounding areas were covered with plastic.

The folding I-beam was ground down to be in level with the main beam.

Load bearing cable moved into correct position. New folding spring installed.

Crane calibration was done at 500 lbs at the end of the fully extended jib.

Than we realized that the rotating wheel limit switch stopped working.

This means that the crane is still out of order.

 

 New limit switch will be installed tomorrow morning

Konecranes postponed installation Friday morning Nov. 8

Friday 5pm : Konacranes promising to be here 8am Monday, Nov 11

It was rescheduled on Tuesday again for Wednesday, Nov 13

  4487   Tue Apr 5 17:04:36 2011 steveSummarySAFETYcranes inspected and load tested

Mike Caton of Konecranes inspected and loadtested all 3  of the 40m cranes at max reach trolley positions with 1 ton.

  5276   Mon Aug 22 11:40:08 2011 steveUpdateVACcranes checked

Cranes are  checked and they are ready for lifting. At the east end will use the manual Genei-lift to put door on.

  8856   Tue Jul 16 13:48:26 2013 SteveUpdatePEMcranes cleaned

Keven and Steve,

The 3 cranes tested and  wiped off as preparation for upcoming vent.

  3378   Fri Aug 6 17:47:36 2010 steveSummaryGeneralcranes load tested at 1998 lbs

Quote:

Quote:

Quote:

The guy from KroneCrane (sp?) came today and started the crane inspection on the X End Crane. There were issues with our crane so he's going to resume on Monday. We turned off the MOPA fur the duration of the inspection.

  1. None of our cranes have oil in the gearbox and it seems that they never did since they have never been maintained. Sloppy installation job. The crane oiling guy is going to come in on Monday.
  2. They tried to test the X-End crane with 2500 lbs. (its a 1 ton crane). This tripped the thermal overload on the crane as intended with this test. Unfortunately, the thermal overload switch disabled the 'goes down' circuit instead of the 'goes up' circuit as it should. We double checked the wiring diagram to confirm our hypothesis. Seems the X-End crane was wired up incorrectly in the first place 16 years ago. We'll have to get this fixed.

The plan is that they will bring enough weight to test it at slightly over the rating (1 Ton + 10 %) and we'll retry the certification after the oiling on Monday.

 The south end crane has one more flaw. The wall cantilever is imbalanced: meaning it wants to rotate south ward, because its axis is off.

This effects the rope winding on the drum as it is shown on Atm2

Atm1 is showing Jay Swar of KoneCrane and the two 1250 lbs load that was used for the test. Overloading the crane at 125% is general practice at load testing.

It was good to see that the load brakes were working well at 2500 lbs. Finally we found a good service company! and thanks for Rana and Alberto

for coming in on Saturday.

 Jeff Stinson, technician of KoneCrane inspected the south end crane hoist gear box. This was the one that was really low on oil. The full condition require

~ 950cc of EPX-7 (50-70W) high viscosity gear oil. The remaining 120 cc oil was drained and the gear box cover was removed. See Atm 1

He found the gear box, load brake and gearing in good condition. The slow periodic sound of the drive was explained by the split bearings at Atm 3

The Vertex and the east end crane gear boxes needed only 60 cc oil to be added to each Atm 4 and their drives were tested.

Conclusion: all 3 gear boxes and drives are in good working condition.

Tomorrow's plan: load test at 1 ton and correct-check  3 phase wiring.

 Atm1, service report: load test were performed at max horizontal reach with 1998 lbs ( American Ton is 2000 lbs)

          Vertical drives and brakes worked well. The 5 minutes sagging test showed less than 1 mm movement .

          The wiring is correct. Earlier hypothesis regarding the wiring ignored the mechanical brake action.

Our cranes are certified now. Operator training and SOP is in the work.

Vertex Folding I -beam will get latch-lock and the south end I-beam will be leveled.

Atm2, south end

Atm3, east end

Atm4, folding crane at ITMX at 14 ft horizontal reach

  6430   Tue Mar 20 16:53:48 2012 steveUpdatePEMcranes maintenance & certified inspection of 2012

Fred Goodbar of Konecrane has completed the annual certified crane inspection and maintenance of our cranes as required in safety document.

They are in good working condition and safe to use.

  6266   Fri Feb 10 02:35:29 2012 kiwamuUpdateIOOcrazy ground motion

I gave up tonight's locking activity because the MC can't stay locked.

It seems that somehow the seismic noise became louder from about 1:00 AM.

I walked around the outside of the 40-m building to see what's going on, but no one was jumping or partying.

I am leaving the MC autolocker disabled so that the laser won't be driven crazy and the WFS won't kick the MC suspensions.

 

The attachment is a 3-hour trend of the seismometer outputs and the MC trans.

MCunlock.png

  6268   Fri Feb 10 11:01:31 2012 steveUpdateIOOcrazy ground motion

Quote:

I gave up tonight's locking activity because the MC can't stay locked.

It seems that somehow the seismic noise became louder from about 1:00 AM.

I walked around the outside of the 40-m building to see what's going on, but no one was jumping or partying.

I am leaving the MC autolocker disabled so that the laser won't be driven crazy and the WFS won't kick the MC suspensions.

 

The attachment is a 3-hour trend of the seismometer outputs and the MC trans.

MCunlock.png

 Something has started shaking last night.  Everybody is claiming to be innocent next door.

I turned off the 40m AC at 11:06

  486   Sun May 18 18:59:15 2008 ranaConfigurationComputerscron and hosts
I added rosalba to the hosts file for the control room machines (131.215.113.103).

I also removed the updateddb cron from our op440m crontab because it was running at 5 PM
even though I had set it to run at 5:57 AM. If it still runs then, it must be because of
another crontab.
  2153   Tue Oct 27 19:37:03 2009 kiwamuUpdateLSCcron job to diagnose LSC-timing

I set a cron job on allegra.martian to run the diagnostic script every weekend.

I think this routine can be helpful to know how the trend of timing-shift goes

The cron runs the script on every Sunday 5:01AM and diagnostics will take about 5 min.

 

! Important:

During the running of the script, OMC and DARM can not be locked.

If you want to lock OMC and DARM in the early morning of weekend, just log in allegra and then comment out the command by using 'crontab -e'

 

 

  2167   Mon Nov 2 10:56:09 2009 kiwamuUpdateLSCcron job works succesfully & no timing jitter

As I wrote on Oct.27th, the cron job works every Sunday.

I found it worked well on the last Sunday (Nov.1st).

And I can not find any timing jitter in the data, its delay still stay 3*Ts.

  16316   Wed Sep 8 18:00:01 2021 KojiUpdateVACcronjobs & N2 pressure alert

In the weekly meeting, Jordan pointed out that we didn't receive the alert for the low N2 pressure.

To check the situation, I went around the machines and summarized the cronjob situation.
[40m wiki: cronjob summary]
Note that this list does not include the vacuum watchdog and mailer as it is not on cronjob.

Now, I found that there are two N2 scripts running:

1. /opt/rtcds/caltech/c1/scripts/Admin/n2Check.sh on megatron and is running every minute (!)
2. /opt/rtcds/caltech/c1/scripts/Admin/N2check/pyN2check.sh on c1vac and is running every 3 hours.

Then, the N2 log file was checked: /opt/rtcds/caltech/c1/scripts/Admin/n2Check.log

Wed Sep 1 12:38:01 PDT 2021 : N2 Pressure: 76.3621
Wed Sep 1 12:38:01 PDT 2021 : T1 Pressure: 112.4
Wed Sep 1 12:38:01 PDT 2021 : T2 Pressure: 349.2
Wed Sep 1 12:39:02 PDT 2021 : N2 Pressure: 76.0241
Wed Sep 1 12:39:02 PDT 2021 : N2 pressure has fallen to 76.0241 PSI !

Tank pressures are 94.6 and 98.6 PSI!

This email was sent from Nodus.  The script is at /opt/rtcds/caltech/c1/scripts/Admin/n2Check.sh

Wed Sep 1 12:40:02 PDT 2021 : N2 Pressure: 75.5322
Wed Sep 1 12:40:02 PDT 2021 : N2 pressure has fallen to 75.5322 PSI !

Tank pressures are 93.6 and 97.6 PSI!

This email was sent from Nodus.  The script is at /opt/rtcds/caltech/c1/scripts/Admin/n2Check.sh

...

The error started at 11:39 and lasted until 13:01 every minute. So this was coming from the script on megatron. We were supposed to have ~20 alerting emails (but did none).
So what's happened to the mails? I tested the script with my mail address and the test mail came to me. Then I sent the test mail to 40m mailing list. It did not reach.
-> Decided to put the mail address (specified in /etc/mailname , I believe) to the whitelist so that the mailing list can accept it.
I did run the test again and it was successful. So I suppose the system can now send us the alert again.
And alerting every minute is excessive. I changed the check frequency to every ten minutes.

What's happened to the python version running on c1vac?
1) The script is running, spitting out some error in the cron report (email on c1vac). But it seems working.
2) This script checks the pressures of the bottles rather than the N2 pressure downstream. So it's complementary.
3) During the incident on Sept 1, the checker did not trip as the pressure drop happened between the cronjob runs and the script didn't notice it.
4) On top of them, the alert was set to send the mails only to an our former grad student. I changed it to deliver to the 40m mailing list. As the "From" address is set to be some ligox...@gmail.com, which is a member of the mailing list (why?), we are supposed to receive the alert. (And we do for other vacuum alert from this address).

 

 

 

 

  11311   Tue May 19 16:18:57 2015 ericqUpdateGeneralcrons fixed

I wrapped rampdown.py in rampdown.sh, which is just these lines:

#!/bin/bash
source /ligo/cdscfg/workstationrc.sh
/opt/rtcds/caltech/c1/scripts/SUS/rampdown.py > /dev/null 2>&1

This is now what megatron's cron runs. It appears to be working.

I also added the workstationrc line to the n2 and chiara HDD checking scripts that run on nodus, which should resolve the issue from ELOG 11249

  8141   Sat Feb 23 00:34:28 2013 yutaUpdateComputerscrontab in op340m deleted and restored (maybe)

I accidentally overwrote crontab in op340m with an empty file.
By checking /var/cron in op340m, I think I restored it.

But somehow, autolockMCmain40m does not work in cron job, so it is currently running by nohup.

What I did:
  1. I ssh-ed op340m to edit crontab to change MC autolocker to usual power mode. I used "crontab -e", but it did not show anything. I exited emacs and op340m.
  2. Rana found that the file size of crontab went 0 when I did "crontab -e".
  3. I found my elog #6899 and added one line to crontab

55 * * * *  /opt/rtcds/caltech/c1/scripts/general/scripto_cron /opt/rtcds/caltech/c1/scripts/MC/autolockMCmain40m >/cvs/cds/caltech/logs/scripts/mclock.cronlog 2>&1

  4. It didn't run correctly, so Rana used his hidden power "nohup" to run autolockMCmain40m in background.
  5. Koji's hidden magic "/var/cron/log" gave me inspiration about what was in crontab. So, I made a new crontab in op340m like this;

34 * * * *  /opt/rtcds/caltech/c1/scripts/general/scripto_cron /opt/rtcds/caltech/c1/scripts/MC/autolockMCmain40m >/cvs/cds/caltech/logs/scripts/mclock.cronlog 2>&1
55 * * * * /opt/rtcds/caltech/c1/scripts/general/scripto_cron /opt/rtcds/caltech/c1/scripts/PSL/FSS/RCthermalPID.pl >/cvs/cds/caltech/logs/scripts/RCthermalPID.cronlog 2>&1
07 * * * * /opt/rtcds/caltech/c1/scripts/general/scripto_cron /opt/rtcds/caltech/c1/scripts/PSL/FSS/FSSSlowServo >/cvs/cds/caltech/logs/scripts/FSSslow.cronlog 2>&1
00 * * * * /opt/rtcds/caltech/c1/burt/autoburt/burt.cron >> /opt/rtcds/caltech/c1/burt/burtcron.log
13 * * * * /cvs/cds/caltech/conlog/bin/check_conlogger_and_restart_if_dead
14,44 * * * * /opt/rtcds/caltech/c1/scripts/SUS/rampdown.pl > /dev/null 2>&1


  6. It looks like some of them started running, but I haven't checked if they are working or not. We need to look into them.

Moral of the story:
  crontab needs backup.

  8146   Sat Feb 23 15:26:26 2013 yutaUpdateComputerscrontab in op340m updated

I found some daily cron jobs for op340m I missed last night. Also, I edited timings of hourly jobs to maintain consistency with the past. Some of them looks old, but I will leave as it is for now.
At least, burt, FSSSlowServo and autolockMCmain40m seems like they are working now.
If you notice something is missing, please add it to crontab.

07 * * * * /opt/rtcds/caltech/c1/burt/autoburt/burt.cron >> /opt/rtcds/caltech/c1/burt/burtcron.log
13 * * * * /opt/rtcds/caltech/c1/scripts/general/scripto_cron /opt/rtcds/caltech/c1/scripts/PSL/FSS/FSSSlowServo >/cvs/cds/caltech/logs/scripts/FSSslow.cronlog 2>&1
14,44 * * * * /cvs/cds/caltech/conlog/bin/check_conlogger_and_restart_if_dead
15,45 * * * * /opt/rtcds/caltech/c1/scripts/SUS/rampdown.pl > /dev/null 2>&1
55 * * * *  /opt/rtcds/caltech/c1/scripts/general/scripto_cron /opt/rtcds/caltech/c1/scripts/MC/autolockMCmain40m >/cvs/cds/caltech/logs/scripts/mclock.cronlog 2>&1
59 * * * * /opt/rtcds/caltech/c1/scripts/general/scripto_cron /opt/rtcds/caltech/c1/scripts/PSL/FSS/RCthermalPID.pl >/cvs/cds/caltech/logs/scripts/RCthermalPID.cronlog 2>&1

00 0 * * * /var/scripts/ntp.sh > /dev/null 2>&1
00 4 * * * /opt/rtcds/caltech/c1/scripts/RGA/RGAlogger.cron >> /cvs/cds/caltech/users/rward/RGA/RGAcron.out 2>&1
00 6 * * * /cvs/cds/scripts/backupScripts.pl
00 7 * * * /opt/rtcds/caltech/c1/scripts/AutoUpdate/update_conlog.cron

  8147   Sat Feb 23 15:46:16 2013 ranaUpdateComputerscrontab in op340m updated

According to Google, you can add a line in the crontab to backup the crontab by having the cronback.py script be in the scripts/ directory. It needs to save multiple copies, or else when someone makes the file size zero it will just write a zero size file onto the old backup.

  5123   Fri Aug 5 13:51:51 2011 steveUpdateSUScross coupling

We need a plan how to minimize cross coupling in the OSEMs now

  6274   Fri Feb 10 23:19:09 2012 kiwamuUpdateIOOcross talk causing fake seimometer signals

[ Koji / Kiwamu ]

The frequent unlock of the MC are most likely unrelated to ground motion.

Although the reason why MC became unstable is still unclear.

 

 

There are two facts which suggest that the ground motion and the MC unlock are unrelated :

(1) It turned out that the seismometer signals (C1:PEM-SEIS-STS_AAA ) have a big cross talk with the MC locking signals.

    For example, when we intentionally unlocked the MC, the seismometer simultaneously showed a step-shaped signals, which looked quite similar to what we have observed.

    I guess there could be some kind of electrical cross talk happening between some MC locking signals and the seismometer channels.

    So we should not trust the signals from the STS seismometers. This needs a further investigation.

(2) We looked at the OSEM and oplev signals of some other suspended optics, and didn't find any corresponding fluctuations.

    The suspensions we checked are ETMX, ETMY, ITMX and MC1.

     None of them showed an obvious sign of the active ground motions in the past 24 hours or so.

Quote from #6266

It seems that somehow the seismic noise became louder from about 1:00 AM.

  1561   Fri May 8 02:39:02 2009 pete, ranaUpdateLockingcrossover

attached plot shows MC_IN1/MC_IN2.  needs work.

This is supposed to be a measurement of the relative gain of the MCL and AO paths in the CM servo. We expect there to

be a more steep slope (ideally 1/f). Somehow the magnitude is very shallow and so the crossover is not stable. Possible

causes? Saturations in the measurement, broken whitening filters, extremely bad delay in the digital system? needs work.

 

  1517   Fri Apr 24 16:02:31 2009 steveHowToVACcryo pump interlock rule

I tested the cryopump interlock today. It is touchy. I do not have full confidence in it.

I'm proposing that VC1 gate valve should be kept closed while nobody is working in the 40m lab.

How to open gate valve:

1, confirm temp of 12K on the gauge at the  bottom of the cryopump

2, if medm screen cryo reads OFF( meaning warm) hit reset will result reading ON (meaning cold 12K )

3, open VC1 gate valve if P1 is not higher than 20 mTorr

 

VC1 was closed at 18:25,

IFO condition: not pumped,

expected leak plus  out gassing should be less than 5 mTorr/day

The RGA is in bg-mode, annuloses are closed off

  1532   Wed Apr 29 10:20:14 2009 steveHowToVACcryo pump interlock rule is waved

Quote:

I tested the cryopump interlock today. It is touchy. I do not have full confidence in it.

I'm proposing that VC1 gate valve should be kept closed while nobody is working in the 40m lab.

How to open gate valve:

1, confirm temp of 12K on the gauge at the  bottom of the cryopump

2, if medm screen cryo reads OFF( meaning warm) hit reset will result reading ON (meaning cold 12K )

3, open VC1 gate valve if P1 is not higher than 20 mTorr

 

VC1 was closed at 18:25,

IFO condition: not pumped,

expected leak plus  out gassing should be less than 5 mTorr/day

The RGA is in bg-mode, annuloses are closed off

 The Cryo pump is running reliably since April 22 hence there is no need to close VC1 repeatedly.

The photo switch interlock was put back onto the H2 vapor pressure gauge and it is working.

  1527   Tue Apr 28 09:27:32 2009 steveConfigurationVACcryopump deserves some credit

Congratulation Yoichi and Peter for full rf locking at night. Let's remember that the cryopump was shaking the hole vac envelope and ifo during this full lock.

  1610   Wed May 20 01:41:19 2009 peteUpdateVACcryopump probably not it

I found some neat signal analysis software for my mac (http://www.faberacoustical.com/products/), and took a spectrum of the ambient noise coming from the cryopump.  The two main noise peaks from that bad boy were nowhere near 3.7 kHz.

  9856   Fri Apr 25 22:20:01 2014 ranaUpdateIOOcsh/tcsh hackery combatted

To make the mcwfson/off scripts work from rossa (and not just Jamie's pet machine) I swapped the sh-bang line at the top of the script to use 'env bash' instead of 'env csh' in the case of mcwfsoff and 'env tcsh' in the case of mcwfson.

The script was failing to work due to $OSTYPE being defined for pianosa csh/tcsh, but not on rossa.

During debugging I also bypassed the ezcawrapper for ezcaswitch so that now when ezcaswitch is called, it directly runs the binary and not the script which calls the binary with numerous retries. In the future, all new scripts will be rewritten to use cdsutils, but until then beware of ezcaswitch failures.

WFS scripts checked into the SVN.

This was all in an effort to get Koji to allow me to upgrade pianosa to ubuntu 12 so that I can have ipython notebook on there.

Objections to upgrading pianosa? (chiara and megatron are already running ubuntu 12)

  8164   Mon Feb 25 22:42:32 2013 yutaSummaryAlignmentcurrent IFO situation

[Jenne,Yuta]

Both arms are aligned starting from Y green.
We have all beams unclipped except for IPANG. I think we should ignore IPANG and go on to PRMI locking and FPMI locking using ALS.
IPANG/IPPOS and oplev steering mirrors are kept un-touched after pumping until now.

Current alignment situation:
 - Yarm aligned to green (Y green transmission ~240 uW)
 - TT1/TT2 aligned to Yarm (TRY ~0.86)
 - BS and Xarm alined to each other (TRX ~ with MI fringe in AS)
 - X green is not aligned yet
 - PRMI aligned

Current output beam situation:
 IPPOS - Coming out clear but off in yaw. Not on QPD.
 IPANG - Coming out but too high in pitch and clipped half of the beam. Not on QPD.
 TRY   - On PD/camera.
 POY   - On PD.
 TRX   - On PD/camera.
 POX   - On PD.
 REFL  - Coming out clear, on camera (centered without touching steering mirrors).
 AS    - Coming out clear, on camera (centered without touching steering mirrors).
 POP   - Coming out clear, on camera (upper left on camera).


Oplev values:

Optic    Pre-pump(pit/yaw)    PRFPMI aligned(pit/yaw)
ITMX    -0.26 /  0.60         0.25 /  0.95
ITMY    -0.12 /  0.08         0.50 /  0.39
ETMX    -0.03 / -0.02        -0.47 /  0.19
ETMY     0.37 / -0.62        -0.08 /  0.80
BS      -0.01 / -0.18        -1    /  1 (almost off)
PRM     -0.34 /  0.03        -1    /  1 (almost off)


 All values +/- ~0.01. So, oplevs are not useful for alignment reference.

OSEM values:
Optic    Pre-pump(pit/yaw)    PRFPMI aligned(pit/yaw)
ITMX    -1660 / -1680        -1650 / -1680
ITMY    -1110 /   490        -1070 /   440
ETMX     -330 / -5380         -380 / -5420
ETMY    -1890 /   490        -1850 /   430
BS        370 /   840          360 /   800
PRM      -220 /  -110         -310 /  -110


  All values +/- ~10.
  We checked that if there's ~1200 difference, we still see flash in Watec TR camera. So, OSEM values are quite good reference for optic alignment.

IPANG drift:
  On Saturday, when Rana, Manasa, and I are trying to get Y arm flash, we noticed IPANG was drifting quite a lot in pitch. No calibration is done yet, but it went off the IPANG QPD within ~1 hour (attached).
  When I was aligning Yarm and Xarm at the same time, TRY drifted within ~1 hour. I had to tweak TT1/TT2 mainly in yaw to keep TRY. I also had to keep Yarm alignment to Y green. I'm not sure what is drifting so much. Suspects are TT2, PR2/PR3, Y arm and Y green.

  I made a simple script(/opt/rtcds/caltech/c1/scripts/Alignment/ipkeeper) for keeping input pointing by centering the beam on IPPOS/IPANG using TT1/TT2. I used this for keeping input pointing while scanning Y arm alignment to search for Y arm flash this weekend (/opt/rtcds/caltech/c1/scripts/Alignment/scanArmAlignment.py). But now we have clipped IPANG.


So, what's useful for alignment after pumping?:

  Optic alignment can be close by restoring OSEM values. For input pointing, IPPOS/IPANG are not so useful. Centering the beam on REFL/AS (POP) camera is a good start. But green works better.

  3689   Mon Oct 11 16:09:10 2010 yutaSummarySUScurrent OSEM outputs

Background:
 The output range of the OSEM is 0-2V.
 So, the OSEM output should fluctuate around 1V.
 If not, we have to modify the position of it.

What I did:
 Measured current outputs of the 5 OSEMs for each 8 suspensions by reading sensor outputs(C1:SUS-XXX_YYPDMON) on medm screens.

Result:

  BS ITMX ITMY PRM SRM MC1 MC2 MC3
UL 1.20 0.62 1.69 1.18 1.74 1.25 0.88 1.07
UR 1.21 0.54 1.50 0.99 1.77 1.64 1.46 0.31
LR 1.39 0.62 0.05 0.64 2.06 1.40 0.31 0.19
LL 1.19 0.88 0.01 0.64 1.64 1.00 0.05 1.03
SD 1.19 0.99 0.97 0.79 1.75 0.71 0.77 0.93

 White: OK (0.8~1.2)
 Yellow: needs to be fixed
 Red: BAD. definitely need fix

  5176   Wed Aug 10 15:39:33 2011 jamieUpdateSUScurrent SUS input diagonalization overview

Below is the overview of all the core IFO suspension input diagonalizatidons.

Summary: ITMY, PRM, BS are really bad (in that order) and are our top priorities.

UPDATE:

I had originally put the condition number of the calculated input matrix (M) in the last column.  However, after some discussion we decided that this is not in fact what we want to look at.  The condition number of a matrix is unity if the matrix is completely diagonal.  However, even our ideal input matrix is not diagonal, so the "best" condition number for the input matrix is unclear.

What instead we do know is that the matrix, B, that describes the difference between the calculated input matrix, M, and the ideal input matrix, M0: should be diagonal (identity, in fact):

M = M0 B

B should be diagonal (identity, in fact), and it's condition number should ideally be 1.  So now we calculate B-1, since it can be calculated from the pre-inverted input matrix:

B-1 = M-1 * M0

From that we calculate cond(B) == cond(B-1).

cond(B) is our new measure of the "badness" of the OSEMS.

new summary: ITMY, PRM, BS are really bad (in that order) and are our top priorities.

 

TM    INPUT MATRIX (M)
 cond(M) cond(B)
 PRM PRM.png        pit     yaw     pos     side    butt
UL   -2.000  -2.000  -2.000  -0.345   2.097 
UR   -0.375  -0.227  -0.312  -0.060   0.247 
LR    1.060   1.075   0.971   0.143  -0.984 
LL   -0.565  -0.698  -0.717  -0.141   0.672 
SD    1.513   1.485   1.498   1.000  -1.590
 75.569 106.756
 SRM SRM.png  

      pit     yaw     pos     side    butt
UL    0.791   1.060   1.114  -0.133   1.026 
UR    1.022  -0.940   1.052  -0.061  -1.027 
LR   -0.978  -0.987   0.886  -0.031   0.903 
LL   -1.209   1.013   0.948  -0.103  -1.043 
SD    0.286   0.105   1.249   1.000   0.030

 2.6501 3.90776
 BS  BS.png  

      pit     yaw     pos     side    butt
UL    1.420   0.818  -0.069   0.352   1.038 
UR    0.276  -1.182   1.931  -0.217  -0.905 
LR   -1.724  -0.274   1.940  -0.254   0.862 
LL   -0.580   1.726  -0.060   0.315  -1.194 
SD    0.560   0.171  -3.535   1.000   0.075 

9.8152 7.28516
ITMX ITMX.png       pit     yaw     pos     side    butt
UL    0.437   1.015   1.050  -0.065   0.714 
UR    0.827  -0.985   1.129  -0.221  -0.957 
LR   -1.173  -1.205   0.950  -0.281   1.245 
LL   -1.563   0.795   0.871  -0.125  -1.084 
SD   -0.581  -0.851   2.573   1.000  -0.171 
 4.08172 4.69811
 ITMY  ITMY.png  

      pit     yaw     pos     side    butt
UL    0.905  -0.884  -0.873   0.197   0.891 
UR   -1.095   1.088   1.127  -0.252  -1.115 
LR   -0.012  -0.028   0.002   0.001   0.030 
LL    1.988  -2.000  -1.998   0.451   1.964 
SD    4.542  -4.608  -4.621   1.000   4.517 

 801.453 774.901
 ETMX  ETMX.png        pit     yaw     pos     side    butt
UL    0.344   0.475   1.601   0.314   1.043 
UR    0.283  -1.525   1.786  -0.071  -1.181 
LR   -1.717  -1.569   0.399  -0.102   0.938 
LL   -1.656   0.431   0.214   0.283  -0.837 
SD    0.995  -2.632  -0.999   1.000  -0.110 
 4.26181 4.33518
 ETMY  ETMY.png        pit     yaw     pos     side    butt
UL   -0.212   1.272   1.401  -0.127   0.941 
UR    0.835  -0.728   1.534  -0.101  -1.054 
LR   -0.953  -1.183   0.599  -0.066   0.827 
LL   -2.000   0.817   0.466  -0.092  -1.177 
SD   -0.172   0.438   2.238   1.000  -0.008 
 4.04847 4.33725

 

  6862   Sun Jun 24 00:10:45 2012 yutaUpdateGreen Lockingcurrent beat electronics

I moved amplifiers for beat PD at PSL table to 1X2 rack. Current beat setup from PD to ADC is shown below. Setup for X beat and Y beat are almost the same except for minor difference like cable kind for the delay line.

Currently, DC power for amplifiers ZHL-1000LN+ is supplied by Aligent E3620A.
I tried to use power supply from the side of 1X1 rack, but fuse plug(Phoenix Contact ST-SI-UK-4) showed red LED, so I couldn't use it.
Measured amplification was +25 dB for 10-100 MHz.

Measured gain from RF input to monitor output of the beat box was ~ -1 db for 10-100 MHz.

beatsetup20120623.png

ELOG V3.1.3-