ALL  illuminator lighting are off. ITMX and ETMY looks back lighted. I will check on their apertures.

In order to focus on 1064 resonant spots I tried to restore and align the arms  by script. I only got flashes.

I used the LED illuminations at ETMX and BS yesterday for a tour.
I am afraid that I left them on.

> I used the LED illuminations at ETMX and BS yesterday for a tour.
> I am afraid that I left them on.

It was turned off before the picture was taken.
All LED illuminations were turned off. I checked them a few times.

 The problem with the glow on the ETMY face is due to the red light being scattered off of the optical table from the HeNe laser for the OL. Why is the red light hitting the table?

One way to fix the problem for the camera image is to insert a long pass filter (if Steve can find one).

 Edmund Optics: NT62-874

 Edmund Optics: NT65-731

Edmund Optics: NT32-759 

The videocapture.py script is now in ...../scripts/general/ , along with the videoswitch. 

Also, there's a button gui on the VIDEO medm screen to capture different camera views.

Quad processor 2 & 3 were replaced.

The Chameleon HB (by Knox) video switch that we use for routing video signals into the control room monitors is broken.  Well, either it's broken, or something is wrong with the mv162 EPICS IOC which communicates with it via RS-232.  Multiple reboots/resets of both machines has not yet worked.  The CHHB has two RS-232 inputs--I switched to the second one, and there is now one signal coming through to a monitor but no switching yet. I've been unable to further debug it because we don't have anything in the lab (other than the omega iserver formerly used for the RGA logger) which can communicate with RS-232 ports.  I've been trying to get this thing (the iserver) working again, but can't communicate with it yet.  For now I'm just going to bypass the video switch entirely and use up all the BNC barrel connectors in the lab, so we can at least have the useful video displays back.

I updated /opt/rtcds/caltech/c1/scripts/general/videoscripts.py so that it supports movie capturing. It saves captured images (bmp) and movies (mp4) in /users/sensoray/SensorayCaptures/ directory.
I also updated /opt/rtcds/caltech/c1/scripts/pylibs/pyndslib.py because /usr/bin/lalapps_tconvert is not working and now /usr/bin/tconvert works.
However, tconvert doesn't run on ottavia, so I need Jamie to fix it.

videocapture.py -h:
Usage:
    videocapture.py [cameraname] [options]

Example usage:
    videocapture.py MC2F -s 320x240 -t off
       (Camptures image of MC2F with the size of 320x240, without timestamp on the image. MUST RUN ON PIANOSA!)
    videocapture.py AS -m 10
       (Camptures 10 sec movie of AS with the size of 720x480. MUST RUN ON PIANOSA!)


Options:
  -h, --help          show this help message and exit
  -s SIZE             specify image size [default: 720x480]
  -t TIMESTAMP_ONOFF  timestamp on or off [default: on]
  -m MOVLENGTH        specity movie length (in sec; takes movie if specified) [default: 0]

While looking at the decay of the violin mode of the PRM, I made a simple measurement of the decay rate.

Error signal: REFL33I

The peak @628Hz became 0.372 to 0.303 in 60 sec.

-> Half life of the amplitude T_{1/2} is 203sec.

Q = 4.53 f0 T_{1/2} = 5.8 x10^5

Recently the watch script was having difficulty grabbing a lock for more than a few seconds.  Rob discovered that the violin notch filters which were activated in the script were causing the instability.  We're not sure why yet.  The script seems significantly more stable with that step commented out.

i took some pictures with the dinocam this afternoon. I used the laptop computer next to it using wireless lan connection to the caltech network to send the pictures to me.

The installed anti virus software was bitching about the old database and wanted to update that. As the installed virus definition database was from mid last year i agreed and started downloading the update. As the file was huge (~100MB) it wasn't finished when i left. computer is still running and probably waiting for instructions.

Will come back on the weekend to finalize the new virus definition file database installation.

Suresh is captivating his audience with gravity waves on last Friday, March 25

Prof Alan Weistein guided the 24 student through the 40m. His performance was rated as  an enthusiastic 9.5

Paul, Mirko and Katrin visiting grad students received the 40m basic safety training.

After fighting with Altium for what seems like an eternity I have finished putting my vision of the vme crate backplane adapter board into an electronic format. It is dimensioned to fill the back space of the crate exactly. The connectors are panel mount and the PCB attaches to the connectors with screws, such that the whole thing will be mechanically much more stable than the current configuration. A mounting bracket will attach to horizontal struts that need to be installed in the crates, mechanical drawings to follow.

I made a crude sketch for how Lydia and I envision the connector situation on the back of the vme crates to be solved. Essentially the side panels of each crate extend about 2" (52 mm) beyond the edge of the DIN connectors. This is plenty of space for a simple PCB board. The connector of choice is D-Sub. We can split the 64 used pins into 2x 37 D-Sub OR (2x25 pin + 1x15pin). The former has fewer cables, but a few excess unused leads. A quick google search showed me that it is much cheaper to get twisted pair cables for 15 and 25 pin D-Subs. From what I remember, the used pins on the DIN connectors are concentrated on the low numbers end and the high numbers end, so might not need the 'middle' connector in many cases if we decide to break it up into three. I have to check this with Lydia though.

The D-Sub connectors would be panel mounted, for which we need a narrow panel piece with dsub cutouts. We can run horizontal struts across the vme crate from side panel to side panel. This way the force upon cable (dis)connection is mostly on the panel which is attached to the struts which are attached to the crate. This will also prevent gravitational sag or cable strain from pulling on the DIN connection, and we can use twisted pair cables with backshell, screws, and strain reliefs.

I was lookng into getting started with the PCB when Altium complained that the license is expired and to renew it. This is a relatively simple board layout so some free software out there is probably enough.

While Kiwamu and I were trying to investigate the the vertex glitches we were noticing excess noise in ITMX, which Kiwamu blamed on some sort of bad diagonalization.  Sure enough, the ITMX input matrix is in the default state [0], not a properly diagonalized state.  Looking through the rest of the suspensions, I found PRM also in the default state, not diagonalized.

We should do another round of suspension diagonalization.

Kiwamu (or whoever is here last tonight): please run the free-swing/kick script (/opt/rtcds/caltech/c1/scripts/SUS/freeswing) before you leave, and I'll check the matrices and update the suspensions tomorrow morning.

[0]

This reminds me that the whole Dr. SUS situation never got taken care of. Where I left off, I was having issues pulling 40m data with NDS2 (which is what all the diagonalization scripts use).

What is the deal with 40m+NDS2? If it is till no-go, can we have a consensus on whether this is too important to wait for? If so, I will rewrite the scripts to use NDS and we can upgrade to NDS2 once we can prove we know how to use it.

Theoretically the waist position of a Gaussian beam (1064) in our PPKTP crystal differs by ~6.7 mm from that of the incident Gaussian beam.

So far I have neglected such position change of the beam waist in optical layouts because it is tiny compared with the entire optical path.

But from the point of view of practical experiments, it is better to think about it.

In fact the result suggests the rough positioning of our PPKTP crystals;

we should put our PPKTP crystal so that the center of the crystal is 6.7 mm far from the waist of a Gaussian beam in free space.

(How to)

The calculation is very very simple.

The waist position of a Gaussian beam propagating in a dielectric material should change by a factor of n, where n is the refractive index of the material.

In our case, PPKTP has  n=1.8, so that the waist position from the surface of the crystal becomes longer by n.

Now remember the fact that the maximum conversion efficiency can be achieved if the waist locates at exact center of a crystal.

Therefore the waist position in the crystal should be satisfied this relation; z*n=15 mm, where z is the waist position of the incident beam from the surface and 15 mm is half length of our crystal.

Then we can find z must be ~8.3 mm, which is 6.7 mm shorter than the position in crystal.

The attached figure shows the relation clearly. Note that the waist radius doesn't change.

The mode profile of Gaussian beams in our PPKTP crystals was calculated.

I confirmed that the Rayleigh range of the incoming beam (1064 nm) and that of the outgoing beam (532 nm) is the same.

And it turned out that the waist postion for the incoming beam and the outgoing beam should be different by 13.4 mm toward the direction of propagation.

These facts will help us making optical layouts precisely for our green locking.

(detail)

The result is shown in the attached figure, which is essentially the same as the previous one (see the entry).

The horizontal axis is the length of the propagation direction, the vertical axis is the waist size of Gaussian beams.

Here I put x=0 as the entering surface of the crystal, and x=30 mm as the other surface.

The red and green solid curve represent the incoming beam and the outgoing beam respectively. They are supposed to  propagate in free space.

And the dashed curve represents the beams inside the crystal.

A trick in this calculation is that: we can assume that  the waist size of 532 nm is equal to that of 1064 nm divided by sqrt(2) . 

If you want to know about this treatment in detail,  you can find some descriptions in this paper;

"Third-harmonic generation by use of focused Gaussian beams in an optical super lattice" J.Opt.Soc.Am.B 20,360 (2003)"

If I understand your elog, you are just calculating the the offset in position space that you get by having a refractive index.

Did you end up changing the mode matching so that the rayleigh range (which changes with refractive index) was confocally focused inside the crystal (e.g. Zr = 15 mm?

- As you said, I just calculated the waist position in the crystal because the speed of light changes in a medium and eventually the waist position also changes.

- Yes, I did. Once you get a beam with the right waist size, you just put your crystal at the waist position with the offset.

  In fact you don't have to think about the rayleigh range inside of the crystal because what we care is the waist size and it doesn't change.

 I thought we cared about satisfying the confocal focusing parameter, that is to say we want to set Zr = 2L_crystal. If Zr changes inside the crystal, this is the number we care about..isn't it NOT the waist size, but the rayleigh range we care about? I am not entirely sure what youre response is saying you did...

1. Calculate Zr = pi * wo^2/(lamba/n)
2. Do mode matching to get this wo in free space
3. Calculate the offset you need to move the oven by using n
4. Move hte ovens

OR

1. Calculate Zr = pi*wo^2/(lamba)
2. Do mode matching to get this in free space
3. Calculate the offset you need to move your ovens using n
4. Move your ovens

I guess the waist size would also let me know - are you using 69 um or 53 um waist size?

since the summary pages are working again, I was clicking through and noticed that there's a wandering peak in the whitened IMC spectrogram that goes from 10-30 Hz over the course of a day.

https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20200909/ioo/

anyone know what this is ?

The wasp nest will be removed tomorrow from from the out side of the east arm window.

The resonant frequency of the newly arrived gravity bee detector is not known.
 

I've changed the watchdog rampdown script so it brings the SUS watchdogs to 220, instead of the 150 it previously targeted.  This is to make tripping less likely with the jackhammering going on next door.  I've also turned off all the oplev damping.

Please do not touch the watchdogs for all SUSs except for MCs,

because I am going to measure the free swinging spectra for ITMs, ETMs, BS, PRM, SRM tonight.

Today, it is good chance to summarize those data under atmospheric pressure.

thank you.

The watchdogs' issue has been solved and they are now working fine.

It was just because one of the Sorensens had been off.

For the new CDS test, I turned off the watchdogs for PRM, SRM, BS, ITMs and MCs.

I will restore these watchdogs after several hours from now.

I am leaving ITMX and ETMX freely swinging, so that later I can take the spectra and diagonalize the input matrices.

Please don't restore the watchdogs until tomorrow morning.

Tonight, swing again.

Please do not restore the watchdogs until tomorrow (Dec.9) morning.

A Caltech maintenance staff dropped by at around noon today, and told me that he had seen a small puddle of water on the other side of the door along the Y-arm that is kept locked (about 10m from the end-table, on the south side of the arm). He suspected a leak in the lab. Koji and I went down to the said door and observed that there was indeed a small puddle of water accumulated there. There isn't any obvious source of a leak on our side of the door, although the walls tiles in the area suggest that there could be a leak in one of the pipes running through the wall/under the floor. In any case, the leak doesn't seem too dramatic, and we have decided to consult Steve as to what is to be done about this once he is back on Wednesday.

The leak was found inside the wall. Fortunately the plumbers were able to access it from CES room 108

This has been leaking for sometimes. The damaged wall area is about 18 ft long and 1 ft high.

rob, koji, steve

We noticed some water (about a cup) on the floor under the NESLAB chiller today.  We put the chiller up on blocks and took off the side panel for a cursory inspection, but found no obvious leaks.  We'll keep an eye on it.

 The culprit has been found:  One of the bottles of chiller water had a tiny leak in it, and apparently the floor is sloped just right to make it look like the water had been coming from under the chiller.  All is well again in the world of chilled water.

I added ~500 cc of distilled water to the laser chiller yesterday.

We will start preparing for pumping down. Main goal for this is to demonstrate PRFPMI using ALS.
Here are to-dos before we pump down.

Feb 18 eveing
- check input beam and Y arm alignment again
- IPPOS/IPANG alignment
- check all oplevs

Feb 19 morning
- open ETMX chamber heavy door
- align BS to X end
- adjust OSEM values (added by YM)
- center beam on all AS optics
- make sure AS/REFL is clear
- take picture of flipped PR2 (added by YM)
- make sure green is not clipped by new PRM oplev mirrors  (added by YM)
- center all oplevs

Feb 19 afternoon - Feb 20 morning
- close PSL shutter
- close all heavy doors and put the access connector back
- start pumping down

Feb 20 evening
- start aligning IFO

 The chiller appears to be broken.  We currently have it on, with both the SENSOR and RS-232 unplugged.  It's running, circulating water, and the COOL led is illuminated.  But the temperature is not going down.  The exhaust out the back is not particularly warm.  We think this means the refrigeration unit has broken, or the chiller computer is not communicating with the refrigerator/heat exchanger.  Regardless, we may need a new chiller and a new laser.

steve, alberto, rob

After some futzing around with the chiller, we have come to the tentative conclusion that the refrigeration unit is not working.  Steve called facilities to try to get them to recharge the refrigerant (R-404a) tomorrow, and we're also calling around for a spare chiller somewhere in the project (without luck so far).

After a brief look this morning, I called it and declared that we were ok to close up.  The access connector is almost all buttoned up, and both ETM doors are on.

Basically nothing moved since last night, which is good.  Jenne and I were a little bit worried about how the input pointing might have been effected by our moving of the green periscope in the MC chamber.

First thing this morning I went into the BS chamber to check out the alignment situation there.  I put the targets on the PRM and BS cages.  We were basically clear through the PRM aperture, and in retro-reflection.

The BS was not quite so clear.  There is a little bit of clipping through the exit aperture on the X arm side.  However, it didn't seem to me like it was enough to warrant retouching all the input alignment again, as that would have set us back another couple of days at least.

Both arm green beams are cleaning coming out, and are nicely overlapping with the IR beams at the BS (we even have a clean ~04 mode from the Y arm).  The AS and REFL spots look good.  IPANG and IPPOS are centered and haven't moved much since last night.  We're ready to go.

The rest of the vertex doors will go on after lunch.

Today Steve and I tried to recenter the Guralps. The breakout box technique didn't work for us, so we just turned the leveling screws until we got the mass position outputs within +/-50 mV for all DoF as read out by the breakout box.

Some points:

1. GUR1 is at the ETMY (E/W arm) and GUR2 is at the X-end (South arm)
2. The SS containers are good and make a good seal.
3. We had to replace the screws on the granite slab interface plate. The heads were too big to allow the connector to snap into place.
4. The Guralps had been left way, way off level and the brass locking screws were all the way up. We locked them down after leveling today. Steve was blaming Cathy(?).
5. The GUR1_Z channel now looks good - see the summary pages for the before and after behavior. My mistake; the low frequency is still as bad as before.
6. GUR2 X/Y still look like there is no whitening or if the masses are stuck or the interface box is broken.
7. When we first powered them up, a few of the channels of both seismometers showed 100-200 Hz oscillations. This has settled down after several minutes.

The attachment shows the 6 channels after our work. You can see that GUR2_X/Y still look deadish. I tried wiggling the cables at the interface box and powering on/off, but no luck. Next, we swap cables.

Tried to bring the weather station back to life, but no luck. The unit on the wall is alive and so is the EPICS IOC (c1pem1). But there is apparently no communication between them. telnet into c1pem and the error message repeating at the prompt is:

Weather Monitor Output: NO COMM

Might be related to the flaky connector situation that Liz and I found there a couple summers ago, but I tried jiggling and reseating that one with no luck. Looks like it stopped working around 8 PM on March 24, 2014. That's the same time as a ~30s power outage, so perhaps we just need some more power cycling? Tried hitting the reset button on the VME card for c1pem1, but didn't change anything.

Let's try power cycling that crate (which has c1pem1, c0daqawg, and some GPS receiver)...nope - no luck.

Also tried power cycling the weather box which is near the BS chamber on the wall. This didn't change the error message at the c1pem1 telnet prompt.

It's been a miserable week for lock acquisition, with each night worst than the last.  The nadir was around Sunday night, when I couldn't even get a PRM to lock stably, which meant that the auto-alignment scripts could not finish successfully.  It now appears that was due to some XYCOM mis-settings. 

We've also been having problems with timing for c1susvme2.  Attached is a one-hour plot of timing data for this cpu, known as SRM.  Each spike is an instance of lateness, and a potential cause of lock loss.  This has been going on for a quite a while.

Tonight we also encountered a large peak in the frequency noise around 485 Hz.  Changing the MZ lock point (the spot in the PZT range) solved this.

Summary of the week ending Aug 8th.  Number of elog entries = 56

- VAC
 + The vent started Wednesday morning
 + Repositioning of the green periscopes and associated mirrors are done.
 + Got both of the green beams coming out from  the chambers
 + Moved the ETMX suspension tower by -8.09 inch (away from vertex)
 + Fixed the alignment of the ETMX CCD mirrors
 + Recovered the X green beam axis for the latest ETMX position

- SUS
 + oplev centered prior to the vent

- LSC
 + ETMY_TRANS_QPD didn't respond at all, needs to be fixed
 + Old MZ PD (InGaAs 2mm, @29.5MHz) has been modified for REFL33.
  The 11MHz notch circuit is at the amp side instead of the diode side. This is ready for the installation
 + REFL165 PD has been made from the old 166MHz PD.

- IOO
 + IPPOS has been sick since 19th of July, 2011
 + IPANG is clipped on a pick-up mirror on the ETMY table. QPD itself is healthy.
 + The spot positions on the MC mirrors were measured prior to the vent.
   The results are almost the same as before within a few percent difference expect for the MC2 yaw.
 + An attenuator, consisting of two HWPs and a PBS, has been installed on the PSL table for the MC low power state.
 + a 10% BS in front of the MCREFL_RFPD was replaced by a perfect reflector for the low power mode.
 + The incident power for MC was decreased to 20 mW
 + The beam axis going to MC was misalgned due to the attenutor.
    Then the beam was aligned by touching two steering mirrors on the PSL table
 + MC is able to be locked in air. The reflection DC goes from 1.4 to 0.13 V when the MC is locked.

- ABSL
 + With the mass-kicking technique, the arm lengths were measured.
   Xarm =  37.5918 m, Yarm = 37.5425 m.

- Green locking
 + Y green beam is aligned to the Y arm
 + Locking of the Y green is not robust, it needs to be revisited

- OAF
 + Wiener Filtering was applied on the data collected from the X-arm for a duration of 1500 seconds.

- Misc.
 + The hazardous waste people are moving chemicals around outside our door, and have roped off our regular front door.
 + The horizontal trolley drive of the east end crane stopped working. It will be fixed.