40m QIL Cryo_Lab CTN SUS_Lab CAML OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 305 of 350  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  6223   Wed Jan 25 17:32:03 2012 steveUpdateGreen Lockinggeen pointing into y arm is misaligned

I  placed an other Y2-LW-1-2050-UV-45P/AR steering mirror into the beam path of the green beam launching in order to avoid the ~30 degrees use of the 45 degrees mirror. The job is not finished.

  6227   Thu Jan 26 10:17:01 2012 steveUpdateGreen Lockinggeen pointing into y arm is realigned

Quote:

I  placed an other Y2-LW-1-2050-UV-45P/AR steering mirror into the beam path of the green beam launching in order to avoid the ~30 degrees use of the 45 degrees mirror. The job is not finished.

 The alignment is finished after the realization that the 3rd steering mirror had to be adjusted too.

The input power increased from 1.2 to 1.4 mW

Attachment 1: P1080513.JPG
P1080513.JPG
  15851   Mon Mar 1 11:40:15 2021 Anchal, PacoSummaryIMCgetting familiar with IMC controls

[Paco, Anchal]

tl;dr: Done no harm, no lasting change.

Learn burtgooey

- Use /cvs/cds/caltech/target/c1psl/autoBurt.req as input to test snapshot "/users/anchal/BURTsnaps/controls_1210301_101310_0.snap" on rossa after not succeeding in donatella

- Browse /opt/rtcds/caltech/c1/burt/autoburt/snapshots/TODAY just to know where the snapshots are living. Will store our morning work specific snapshots in local user directories (e.g. /users/anchal/BURTsnaps)

Identifying video monitors

- Switched channels around on video controls; changed C1:VID-MON7 to 16, back to 30, then C1:VID-QUAD2_4 to 16, to 18, then 20, back to 16, to 14 (which identified as PMCT), to 1 (IMC). Anyways, looks like IMC is locked.

[Yehonathan, Paco, Anchal]

Unlocking MC

- From IOO/LockMC, MC_Servo, FSS --> closed PSL shutter, reopen it and see the lock recovers almost instantly. Try MCRFL shutter, no effect. Toggled PSL shutter one more time, lock recovered.

- From IOO/LockMC, MC_Servo, toggle OPTION (after IP2A), lose and recover lock in similar fashion. MCRFL gets most of the light.

- Looked at IFO_OVERVIEW just to get familiar with the various signals.

 

  15852   Mon Mar 1 12:36:38 2021 gautamSummaryIMCgetting familiar with IMC controls

Pretty minor thing - but PMCT and PMCR were switched on Quad 2 for whatever reason. I switched them back because I prefer the way it was. I have saved snapshots of the preferred monitor config for locking but I guess I didn't freeze the arrangement of the individual quadrants within a quad. This would be more of a problem if the ITMs and ETMs are shuffled around or something like that.

Quote:
 

- Switched channels around on video controls; changed C1:VID-MON7 to 16, back to 30, then C1:VID-QUAD2_4 to 16, to 18, then 20, back to 16, to 14 (which identified as PMCT), to 1 (IMC). Anyways, looks like IMC is locked.

  3719   Thu Oct 14 13:15:14 2010 Leo SingerConfigurationComputersgit installed on rossa

I installed git on rossa using:

$ sudo yum install git

  16503   Mon Dec 13 15:05:47 2021 TegaUpdatePEMgit repo for temp sensor and sus medm

[temperature sensor]

git repo: https://git.ligo.org/40m/tempsensor.git

todo

Update the temp sensor channels to fit with cds format, ie. "C1:PEM-TEMP_EX", "C1:PEM-TEMP_EY", "C1:PEM-TEMP_BS"

- Use FLOAT32_LE data format for the database file (/cvs/cds/caltech/target/c1pem1/tempsensor/C1PEMaux.db) to create the new channels.

- Keep the old datadase code and channels so we can compare with new temp channels afterwards. Also we need a 1-month overlap b4 deleting the old channels.

 

[sus medm screen]

git repo: https://git.ligo.org/40m/susmedmscreen.git

todo (from talk with Koji)

- Link stateword display to open "C1CDS_FE_STATUS.adl"

- Damp filter and Lock filter buttons should open a 3x1 filter screen so that the 6 filters are opened by 2 buttons compared to the old screen that has 3 buttons connected to 2X1 filter screen

- Make the LOCKIN signla modulation flow diagramlook more like the old 40m screen since that is a better layout

- Move load coefficient button to top of sus medm screen (beside stateword)

- The rectangular red outline around the oplev display is confusing and needs to be modified for clarity

- COMM tag block should not be 3D as this suggests it is a button. Make it flat and change tag name to indicate individual watchdog control as this better reflect its functionality. Rename current watchdog switch to watchdog master is it does what the 5 COMM switches do at once.

- Macro pass need to be better documented so that when we call the sus screens from locations other than sitemap, we should know what macro variables to pass in, like DCU_ID etc.

- Edit sitemap.adl to point only to the new screens. Then create a button on the new screen that points to the old screen. This way, we can still access the old screen without clogging sitemap.

- Move the new screen location to a subfolder of where the current sus screens reside, /opt/rtcds/userapps/trunk/sus/c1/medm/templates

- Rename the overview screen (SUS_CUST_HSSS_OVERVIEW.adl) to use the SUS_SINGLE nomenclature, i.e. SUS_SINGLE_OVERVIEW.adl

- Keep an eye of the cpu usage of c1pem as we add BLRMS block for other optics. 

 

 

  16504   Tue Dec 14 11:33:29 2021 TegaUpdatePEMgit repo for temp sensor and sus medm

[Temperature sensor]

Added new temp EPICs channels to database file (/cvs/cds/caltech/target/c1pem1/tempsensor/C1PEMaux.db)

Added new temp EPICs channels to slow channels ini file (/opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini)

 

[SUS medm screen]

Moved new SUS screen to location : /opt/rtcds/userapps/trunk/sus/c1/medm/templates/NEW_SUS_SCREENS

Place button on the new screen to link to the old screen and replace old screens link on sitemap.

Fixed Load Coefficient button location issue

Fixed LOCKIN flow diagram issue

Fixed watchdog labelling issue

Linked STATE WORD block to FrontEnd STATUS screen

Replaced the 2x1 pit/yaw filter screens for LOCK and DAMP fliters with 3x1 LPY filter screen

*Need some more time to figure out the OPTLEV red indicator

  6231   Fri Jan 27 06:07:47 2012 kiwamuUpdateLSCglitch hunting

I went through various IFO configurations to see if there are glitches or not.

Here is a summary table of the glitch investigation tonight. Some of the cells in the table are still not yet checked and they are just left blank.

IFO configuration  Yarm
Xarm
MICH
Half PRMI
low finesse PRMI
PRMI (carrier)
PRMI (sideband)
DRMI
AS55 NO NO NO   up conversion noise glitch glitch glitch
REFL11 NO NO NO   up conversion noise
glitch glitch glitch
REFL33 NO NO NO   - glitch glitch glitch
REFL55 NO NO NO   up conversion noise
glitch glitch glitch
REFL165 NO NO NO   - glitch glitch glitch
POX11 - NO NO     glitch glitch glitch
POY11 NO - NO     glitch glitch glitch
POP55 - -            
                 

 

        Low finesse PRMI      

The low finesse PRMI configuration is a power-recycled MIchelson with an intentional offset in MICH to let some of the cavity power go through MICH to the dark port.

To lock this configuration I used ASDC plus an offset for MICH and REFL33 for PRCL.

The MICH offset was chosen so that the ASDC power becomes the half of the maximum.

In this configuration NO glitches ( a high speed signal with an amplitude of more than 4 or 5 sigma) were found when it was locked.

Is it because I didn't use AS55 ?? or because the finesse is low ??

Also, as we have already known, the up conversion noise (#6212) showed up -- the level of the high frequency noise are sensitive to the 3 Hz motion.

  6202   Tue Jan 17 01:02:07 2012 kiwamuUpdateLSCglitch hunting in REFL RFPDs : strange

A very strange thing is going on.

The REFL11 and REFL55 demod signals show high frequency noise depending on how big signals go to the POS actuator of PRM.

This noise shows up even when the beam is single-bounced back from PRM ( the rest of the suspensions are misaligned) and it's very repeatable.

Any idea ?? Am I crazy ?? Is PRM making some fringes with some other optics ??

 

 

(background)

 The most annoying thing in the central part locking is glitches showing up in the LSC error signals (#6183).
The symptom is that when the motion in PRCL at 3 Hz becomes louder, somehow we get glitches in both the MICH and PRCL error signals.
In the frequency domain, those glitches are mostly contribute to a frequency band of about 30 - 100 Hz.
Last Thursday Koji and I locked the half PRM (PRMI with either ITMX or ITMY misaligned) to see if we still have the glitches in this simpler configuration.
Indeed there were the same kind of glitches --a loud 3 Hz motion triggers the glitches.
It was shown particularly in the REFL11 signal but not so much in the REFL33 while AS55 didn't show any glitches.
 
 
(Still glitches even in the single bounce beam)
   We were suspecting some kind of coupling from a beam jitter, so that the 3 Hz motion somehow brings the beam spot to a bad place somewhere in the REFL paths.
I misaligned all the suspensions except for PRM such that the beam directly bounces back from PRM and go to the REFL port.
Indeed there still were glitches in the REFL11 and REFL55 demod signals. It showed up once per 30 sec or so and pushes up the noise floor around 30 - 100 Hz.
There might be a little bit of glitches also in the REFL33, but the ADC noise floor and the expected glitch noise level were comparable and hence it was difficult to see the glitches in REFL33.
 

(Glitch is related to the PRM POS actuation)

 In the single-bounce configuration I started shaking the PIT and YAW motions of PRM at 3 Hz using the realtime LOCKIN oscillator to see if I can reproduce the glitches.
However no significant glitches were found in this test.
Then I started shaking the POS instead of the angular DOFs, and found that it causes the glitches.
At this point it didn't look like a glitch any more, it became more like a stationary noise.
 
 The attached screen shot is the noise spectrum of the REFL11_I.
The red curve is the one taken when I injected the 3 Hz excitation in POS by the LOCKIN oscillator.
The excitation is at 3 Hz with an amplitude of 1000 counts.
As a comparison I plotted the same spectrum when no excitation was injected and it is plotted in pink.
 

 PRMsingle_bounce.png

It seems there is a cut off frequency at 100 Hz.
This frequency depends on the amplitude of the excitation -- increasing the amplitude brings the cut off frequency higher.
This noise spectrum didn't change with and without the oplevs and local damping.
 

(Possible scenario)

A possible reason that I can think of right now is : PRM is interfering with some other optics for some reason.
But if it's true, why I didn't see any fringes in the AS demod signals in the half PRM configuration ?
 

Quote from #6183

 We tried to figure out what is causing spikes in the REFL33 signal, which is used to lock PRCL.

No useful information was obtained tonight and it is still under investigation.

  6208   Tue Jan 17 19:07:47 2012 ranaUpdateLSCglitch hunting in REFL RFPDs : strange

 Another possibility is that there is some beam clipping of the REFL beam before it gets to the PD. Then there could be a partial reflection from that creating a spurious interference. Then it would only show the fringe wrapping if you excite the scatterer or the PRM.

  6224   Thu Jan 26 05:40:10 2012 kiwamuUpdateLSCglitch in the analog demodulated signals

Indeed the glitches show up in the analog demodulated signals. So it is not an issue of the digital processing.

With an oscilloscope I looked at the I/Q monitor outputs of the LSC demodulators, including REFL11, REFL33, REFL55, POY11, AS55 while keep locking the carrier-resonant PRMI.

I saw some glitches in REFL11, REFL55 and AS55. But I didn't see any obvious glitches in REFL33 and PO11 because the SNR of those signals weren't good enough.

 


(some example glitches)

The attached plot below is an example shot of the actual signals when the carrier resonant PRMI was locked.

The first upper row is the spectrogram of REFL11_I, REFL55_I, REFL33_I and AS55_Q in linear-linear scale.

The second row shows the actual time series of those data in unit of counts.

The bottom row is for some DC signals, including REFLDC, ASDC and POYDC.

 

glitch.png

You can see that there are so many glitches in the actual time series of the demod signals (actually I picked up the worst time chunk).

It seems that  most of the glitches in REFL11, REFL33 and AS55  coincide.

The typical time scale of the glitches was about 20 msec or so.

Note that the PRMI was locked by REFL33 and AS55 as usual.

  6284   Thu Feb 16 03:47:16 2012 kiwamuUpdateLSCglitch table

I updated the table which I posted some time ago (#6231). The latest table is shown below.

It seems that the glitches show up only when multiple DOFs are locked.

Interesting thing is that when the low finesse PRMI is locked with a big MICH offset (corresponding to a very low finesse) it doesn't show the glitches.

Qualitatively speaking, the glitch rate becomes higher as the finesse increases.

I will try SRMI tomorrow as this is the last one which I haven't checked the presence of the glitches.

 

 

 Yarm

(POY11 -->

ETMY)

Xarm

(POX11 --> ETMX)

MICH

(AS55-->BS)

or

(AS55 --> ITMs)

Half PRMI

(REFL11 --> PRM)

or

(REFL33 --> PRM)

low finesse PRMI

(ASDC --> ITMs)

(REFL33 --> PRM)

PRMI (carrier)

(AS55 --> ITMs)

(REFL33 --> PRM)

PRMI (sideband)

(AS55 --> ITMs)

(REFL33 --> PRM)

DRMI
AS55 NO NO NO NO glitch (depends on finesse)
glitch glitch glitch
REFL11 NO NO NO NO glitch (depends on finesse)
glitch glitch glitch
REFL33 NO NO NO NO - glitch glitch glitch
REFL55 NO NO NO NO glitch(depends on finesse) glitch glitch glitch
REFL165 NO NO NO - - - - -
POX11 - NO NO NO  - glitch glitch glitch
POY11 NO - NO NO  - glitch glitch glitch
POP55 - - - -  -  - - -
                 

 

 

  9445   Thu Dec 5 16:20:26 2013 SteveUpdateCDSglitches are gone

Quote:

c1scy had frequent time-over. This caused the glitches of the OSEM damping servos.

Today Eric Q was annoyed by the glitches while he worked on the green PDH inspection at the Y-end.

In order to mitigate this issue, low priority RFM channels are moved from c1scy to c1tst.
The moved channels (see Attachment 1) are supposed to be less susceptible to the additional delay.

This modification required the following models to be modified, recompiled, reinstalled, and restarted
in the listed order:
c1als, c1sus, c1rfn, c1tst, c1scy

Now the models are are running. CDS status is all green.
The time consumption of c1scy is now ~30us (porevious ~60us)
(see Attachment 2)

I am looking at the cavity lock of TEM00 and I have witnessed no glitch any more.
In fact, the OSEM signals have no glitch. (see Attachment 3)

We still have c1mcs having regularly time-over. Can I remove the WFS->OAF connections temporarily?

 Koji cleaned up very nicely.

Attachment 1: glitchesGONE.png
glitchesGONE.png
Attachment 2: NOglitches.png
NOglitches.png
  6321   Sat Feb 25 14:27:26 2012 kiwamuUpdateLSCglitches in the RFPD outputs

Last night I took a closer look at the LSC analog signals to find which components are making the glitches.

I monitored the RFPD output signals and the demodulated signals at the same time with an oscilloscope when the PRMI was kept locked.

Indeed the RFPD outputs have some corresponding fast signals although I only looked at the RELL11 I and Q signals.

(REFL33 didn't have sufficiently a high SNR to see the glitches with the oscilloscope.)

I will check the rest of channels.

  12674   Thu Dec 8 10:13:43 2016 SteveUpdateLSCglitching ITMY_UL has a history

 

 

Attachment 1: glitching__ITMY-UL_2007.png
glitching__ITMY-UL_2007.png
  12654   Thu Dec 1 08:02:57 2016 SteveUpdateLSCglitching ITMY_UL_LL

 

 

Attachment 1: ITMY_UL_LL.png
ITMY_UL_LL.png
  1427   Wed Mar 25 09:55:45 2009 steveUpdateIOOglitching sensors of MC

SUS-MC1_SENSOR_SIDE and SUS-MC2_SENSOR_UL are glitching

Yesterday's 4.8mag earthquake at Salton Sea is shown on Channel 1

Attachment 1: glitchesofMC.jpg
glitchesofMC.jpg
  11863   Tue Dec 8 15:40:48 2015 SteveUpdateVACglitchy RGA scan at day 434

The noise floor of the Rga scan is glitching less today

 

Attachment 1: lessGlichingToday.png
lessGlichingToday.png
  16582   Thu Jan 13 16:08:00 2022 YehonathanUpdateBHDgluing magnets after AS1/4 misfortune

{Yehonathan, Anchal, Paco}

In the cleanroom, we removed AS1 and AS4 from their SOS towers. We removed the mirrors from the adapters and put them in their boxes. The broken magnets were collected from the towers and their surfaces were cleaned as well as the magnet sockets on the two adapters and on the side block from where the magnets were knocked off.

We prepared our last batch of glue (more glue was ordered three days ago) and glue 2 side magnets and 2 face magnets. We also took the chance and apply glue on the counterweights on the thick optic adapters so there is no need to look for alternatives for now.

The peek screws and nuts were assembled on the thick optics SOS towers instead of the metal screws and nuts that were used as upper back EQ stops.

  10750   Wed Dec 3 08:36:49 2014 SteveUpdateLSCgood IFO status
Attachment 1: goodStatus.png
goodStatus.png
  5911   Wed Nov 16 12:21:33 2011 KojiUpdateeloggooglebot (Re: restarted)

- elogd itself is a sort of web server which has no freedom to put our own file, we can not put robots.txt

- If we include elog using proxy in the usual web tree of Apache, we can put robots.txt at the root.

- So far, if we prevent "page0" browse by google, we will be saved for a while.

- It seems that the indexing is set to be refused by the following meta tags. But it does not prohibit googlebot to use "page0" URL, of course.

<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
  4855   Wed Jun 22 15:24:10 2011 kiwamuUpdateABSLgot a laser controller for LightWave

Peter King came over to the 40m with a laser controller and gave it to us.

We will test it out with the LightWave NPRO, which was used for MOPA.

Attachment 1: DSC_3150.JPG
DSC_3150.JPG
Attachment 2: DSC_3153.JPG
DSC_3153.JPG
  3805   Thu Oct 28 03:39:58 2010 yutaUpdateIOOgot very stable MC locking

(Rana, Suresh, Jenne, Kiwamu, Kevin, Yuta)

Summary:
  Last night we locked MC by feeding back the signal to NPRO PZT.
  But it was not so stable.
  We wanted more gain to lower the seismic motion, but we don't need high gain in high frequency part(>~1kHz) because it may cause something bad(NRPO PZT oscilatting, PMC not able to catch up with the NPRO frequency change, etc).
  So, we put DC gain boost today.
  It successfully made MC locking stable!

What we did:
1. Lowered the main laser temperature from 32.2° C to 31.8° C.
  When we increased the laser temperature, PMC transmission get lower.  32.2° C was on the cliff, so we put it to plateau region.

2. Lowered the gain of PMC servo (2dB instead of 8dB last night), because PMC was oscillating.
  We got 5.3V OMC transmission.

3. Made 3Hz pole, 30Hz zero filter and put in NPRO PZT servo loop.
  0dB at DC, -20dB at high frequency (see Kevin's elog #3802)

4. Put more gain to NPRO PZT servo loop to compensate -20dB at high frequency.
  In a word, we put DC gain boost.
  Attachment #1 is the MEDM screen screenshot for MC servo.

5. Aligned the beam into QPD at MC2 trans.
  We put lens in front of the QPD.
  Now, we can see the actual motion of the beam, and resonance peaks(Attachment #2; not locked at the highest).
    (We added 30Hz LPF after each 4 quadrant inputs to reduce noise)

Plan:
 - optimize MC suspension alignments
 - activate OL DAQ channels
 - reduce RFAM
 - install tri-mod box
 - QPD signal at MC2 should be more high(currently, ~7counts which equals to ~4mV)
 - change temperature of X-end laser to get green beat

Attachment 1: C1IOO_MC_SERVO20101028.png
C1IOO_MC_SERVO20101028.png
Attachment 2: MCrocks!.png
MCrocks!.png
  115   Mon Nov 19 14:32:10 2007 steveBureaucracySAFETYgrad student safety training
John Miller and Alberto Stochino has received the 40m safety bible.
They still have to read the laser operation manual and sign off on it.
  12099   Fri Apr 29 00:55:46 2016 gautamUpdateendtable upgradegreen PDH locked to Xarm

Using the modulation frequency suggested here, I hooked up the PDH setup at the X-end and succeeded in locking the green to the X arm. I then rotated the HWP after the green Faraday to maximize TRX output, which after a cursory alignment optimization is ~0.2 (I believe we were used to seeing ~0.3 before the end laser went wonky). Obviously much optimization/characterization remains to be done. But for tonight, I am closing the PSL and EX laser shutters and applying first contact to the window once more courtesy more PEEK from Koji's lab in W Bridge. Once this is taken care of, I can install the Oplev tomorrow, and then set about optimizing various things in a systematic way.. MC autolocker has also been disabled...

Side note: for the IR Transmon QPD, we'd like a post that is ~0.75" taller given the difference in beam height from the arm cavity and on the endtable. I will put together a drawing for Steve tomorrow..

  3656   Tue Oct 5 21:22:46 2010 yutaUpdateVACgreen beam reached PSL table

YES ! We got the green light coming out from the OMC chamber to the PSL table !

 (Koji, Kiwamu, Yuta)

Background

As a result of the work in the chambers, the green beam reached the OMC chamber yesterday.
Today's mission was to let the green beam coming out from the chambers to the PSL table.

What we did:
1. Installed the last three steering mirrors.
  The mirrors were 532 HR mirror with AR and 1deg wedge (CVI Y2-LW-1-2050-UV-45-P/AR).
  Two of them are placed to the MC chamber. Another one was to the OMC chamber

During putting the mirrors to the MC chamber, we found that a cable tower was sitting on a position exactly where we wanted to put one of the mirrors.

So we moved the tower to the very south west corner. 

 

2. Installed a periscope to the MC chamber

The function of this periscope is to lower the beam height of the green light which is risen up by another periscope in the BS chamber.

We aligned it to the green beam, so that the beam hits the center of the mirrors on the periscope.  

 

3. Aligned the optics

We aligned the green mirrors so that we can let the green beam go out from the chamber.

Actually the inside of the OMC chamber didn't look like the same as that of our optical layout.

For example there is unknown base plate, which apparently disturbs the location of our last steering mirror.

Therefore we had to change the designed position of the steering mirror.

Now the mirror is sitting near the designed position (~ 1/2 inch off), but it's fine because it doesn't clip any 1064 beam.

 
Result:

The green beam is now hitting the north wall of the PSL table.

 

Notes:

The green beam looks having some fringes, it may be caused by a multiple reflection from a TT when the green beam goes through it. We are going to check it. 

 

Next work:

- Damping of the suspended optics

- Resurrect MC and its stable lock

- Remove MCT pickoff path

- Align optics in the main path

- Recycled Michelson lock

 IMG_3627.jpg

 

  9665   Mon Feb 24 17:21:42 2014 SteveUpdateGreen Lockinggreen fiber status today

Quote:

Alex, Gautam and Steve,

Single mode fiber 50m long is layed out into cable tray that is attached to the beam tube of the Y arm.

It goes from ETMY to PSL enclosure. It is protected at both ends with " clear- pvc, slit corrugated loom tubing " 1.5" ID

The fiber is not protected between 1Y1 and 1Y4

 The X -arm fiber is in the high cable tray and it has has  coupler mounts.

 The Y -arm fiber is in the low cable tray and it has no coupler mounts.

 The fibers are only protected at entering and exiting the trays.

 We have only 68 ft spare 1.5"  ID protective plastic tubing.

Attachment 1: etmy_F@1Y2.JPG
etmy_F@1Y2.JPG
Attachment 2: etmy-F@PSL_.jpg
etmy-F@PSL_.jpg
Attachment 3: etmx_F@se.JPG
etmx_F@se.JPG
Attachment 4: etmx_F@1Y8.JPG
etmx_F@1Y8.JPG
Attachment 5: etmx_F@PSL.JPG
etmx_F@PSL.JPG
Attachment 6: etmy_F@ee__.jpg
etmy_F@ee__.jpg
  9419   Thu Nov 21 09:56:15 2013 SteveUpdateSUSgreen glass beam dumps

 Green welding glass  is used in these Koji designed dumps (D1102375)

We have 10 pieces of hexagonal  dumps for 5.5" high beam They require 1 5/8" space.  Atm1 

Atm2, Large V traps are 3" tall only, 5 pieces

Atm3, Diamond shapes come with 2" and 1" square green glass ( after Koji's correction I removed the not needed glass ) D1102445 and D1102442

 

Baked green glass pieces in stock: 30 pieces of 2" x 2" ,---  30 pieces of 1" x 1",David 4-17-2014

Baked diamond holders in stock: 10 pieces of 2" and 10 pieces of 1"David 4-17-2014

PEEK shims 2" and  1"

Baked green glass pieces blank:  4 pieces of 7" x 9"

Baked green glass pieces with 40 mm hole on 7" x 9" for SUS tower:  7 pieces.

NOTE: in December 2012 we talked about 50 mm aperture need. What diameter is the right one  today? 51 mm aperture plates are cut 4-10-2014

Attachment 1: HEXdump.jpg
HEXdump.jpg
Attachment 2: Vdump.jpg
Vdump.jpg
Attachment 3: Diamond1_2inchTraps.jpg
Diamond1_2inchTraps.jpg
  355   Tue Mar 4 10:08:21 2008 robUpdateComputersgreen lights unreliable when c0daqctrl down

So far I've tried powering off the framebuilder, power-cycling the RAID (it was showing an error message about bad IDE channel #4), and rebooting the LSC (just for fun). When I reset the LSC, its green light on the RFM_NETWORK screen did not turn red, making all these lights suspect. The iscepics40m process is what controls these red/green lights, so maybe it's gone wonky. It appears to be running however, on c1dcuepics, and it also seems to be functioning correctly in other ways (it's communicating correctly with the LSC).

Update: Alex and Jay came by. The solution was to reset the c0daqctrl processor, which apparently was not done in Rana's rebooting spree. Or maybe it needed to be done last.
  3122   Fri Jun 25 20:32:30 2010 kiwamuUpdateGreen Lockinggreen power on the PSL table

The power of the green beam generated on the PSL table should be about 650uW in terms of the shot noise.

       One of the important parameters we should know is the power of the green beam on the PSL table because it determines the SNR.

The green beam finally goes to a photo detector together with another green beam coming from the arm cavity, and they make a beat signal and also shot noise.

So in order to obtain a good SNR toward the shot noise at the photo detector, we have to optimize the powers.

If we assume the green power from the arm is about 650uW,  a reasonable SNR can be achieved when these powers are at the same level. 

To get such power on the PSL table, a 90% partial reflector is needed for picking it off from the PSL as we expected.

 


  power dependency of SNR

      Suppose two lasers are going to a photo detector while they are beating (interfering).

The beat signal is roughly expressed by

      [signal]  ~ E1EE1 E2*,

                     ~ 2 ( PP2)½ cos (phi), 

 where  E1 and Erepresent the complex fileds,  Pand Prepresent their powers and phi is a phase difference.

This equation tells us that the strength of the signal is proportional to  ( PP2)½  .

At the same time we will also have the shot noise whose noise level depends on the inverse square route of the total power;

          [noise] ~ ( PP2)½.

 According to the equations above, SNR is expressed by

        SNR = [signal] / [noise] ~ ( PP2)½  / ( PP2)½.

If we assume Pis fixed,  the maximum SNR can be achieved when  P2 goes to the infinity. But this is practically impossible.

Now let's see how the SNR grows up as the power P increases. There are two kinds of the growing phase.

    (1) When PP1 , SNR is efficiently improved with the speed of  P2½.

    (2) But  when P>   P1 , the speed of growing up becomes very slow. In this regime increasing of  P2 is highly inefficient for improvement of the SNR.

Thus practically PP is a good condition for the SNR.

At this point the SNR already reaches about 0.7 times of the maximum, it's reasonably good.

 


 power estimation

         According to the fact above, we just adjust the green powers to have the same power levels on the PSL table.

 The table below shows some parameters I assume when calculating the powers.

ITM transmissivity @ 532nm  Ti 1.5 %
ETM transmissivity @ 532nm Te 4.5 %
Transmissivity of the arm cavity @ 532nm T_cav 74.4 %
Transmissivity of the BS @ 532nm T_BS 97 %
Transmissivity of  PR1 and SR1 @ 532nm T_PR 90%
Transmissivity of the PMC @ 1064 nm T_pmc 65 %
The power of the green beam at the end station P_end 1 mW
The power of the PSL  P_psl 2 W
Conversion efficiency of the PPKTP eta 3 %/W

         Attached figure shows a simplified schematic of the optical layout with some numbers. 

By using those parameters we can find that the green beam from the arm cavity is reduced to 650uW when it reaches the PSL table.

To create the green beam with the same power level on the table, the power of 1064 nm going to the doubling crystal should be about 150mW.

This amount of the power will be provided by putting a 90% partial reflector after the PMC.

 

Attachment 1: optical_power.png
optical_power.png
  9553   Tue Jan 14 10:34:57 2014 SteveUpdatePSLgreen transmission measurment

GariLyn is using our green light on the west side of the PSL table. The green PDA36As were moved and the HEPA turned up to 60V

Attachment 1: greenPickUp.jpg
greenPickUp.jpg
  6250   Fri Feb 3 17:31:09 2012 steveUpdateGeneralgreen welding glass

Schott, green welding glass, shade 14, 3 mm thick  was measured in the beam path of 1.2W, S polarization of 1064nm at ~1 mm diameter size as MC reflected path.

Absorption 95%, R 5% at incident angle 25-50 degrees. It looks like the perfect material for beam trap.

 

Attachment 1: 02031202.JPG
02031202.JPG
  2026   Wed Sep 30 01:04:56 2009 robUpdateComputersgrief

much grief.  somehow a burt restore of c1iscepics failed to work, and so the LSC XYCOM settings were not correct.  This meant that the LSC whitening filter states were not being correctly set and reported, making it difficult to lock for at least the last week or so.

Attachment 1: C1LSC_XYCOM.jpg
C1LSC_XYCOM.jpg
  7248   Wed Aug 22 11:41:20 2012 steveUpdateGeneralgrout plate for optical table at the ends

Reinforced concrete grout plate for existing carbon steel stands at the ends.

 

Attachment 1: IMG_1561.JPG
IMG_1561.JPG
Attachment 2: 08231201.PDF
08231201.PDF
  3448   Fri Aug 20 15:49:14 2010 steveUpdatePEMgrouting is done

The preparation for pouring concrete is continuing. The grout forms were removed. Half inch ribbed steel bars were epoxied into our 4" thick floor.

The concrete holding sides- forms are cut to size. They will be installed on Monday morning and pouring concrete should follow.

We can be planning for cleaning up on Tuesday

 

Atm1, epoxy used bars

Atm2, south west tripod feet grouted

Atm3, ribbed bars are getting ready

Attachment 1: P1060699.JPG
P1060699.JPG
Attachment 2: P1060700.JPG
P1060700.JPG
Attachment 3: P1060704.JPG
P1060704.JPG
  3444   Thu Aug 19 16:03:59 2010 steveUpdatePEMgrouting of PSL tripod legs

The 10' x 6' optical table is seating on 6 tripods. Each tripod leg has 3 feet. They are supported by jack screws against copper plates on the concrete floor.                            These set screws allowed us to set the height,  level and distribute the load of the table.

To lock this position of the table grouting is used around the jack screws and between the concrete floor and the tripod feet.

Once the grout set the load will be carried by the hole feet  of 4" x 3.25" x3 = 39 sq inches per tripod leg

 

These ~4" thick grouted islands of 8-9" OD will be covered by 4" concrete. The area between the legs will be filled with 8" thick concrete.

http://www.fivestarproducts.com/techinfo/GroutHandbook.pdf

 

Atm1, http://www.fivestarproducts.com/cementgrouts/specsheets/grout_ss.pdf

         Cement based grout, early height change 0 - 4%, hardened height change 0 - 0.3%

Atm2-3,  pouring grout

Atm4,  south west leg is done

 

Tomorrow: setting up ribbed bars, building frame to hold concrete and pour concrete

Attachment 1: P1060687.JPG
P1060687.JPG
Attachment 2: P1060681.JPG
P1060681.JPG
Attachment 3: P1060686.JPG
P1060686.JPG
Attachment 4: P1060696.JPG
P1060696.JPG
  7150   Fri Aug 10 21:37:15 2012 DenUpdatePEMgur, sts noise

 Using Guralp, STS-2 and Trillium I compared Gur and STS-2 self-noise assuming that Trillium noise is not worse then STS-2 noise.

gur_sts_noise.png

Interesting that STS-2 (or Trillium if its noise is worse) noise is not too much better then Guralp noise.

  6536   Mon Apr 16 09:10:37 2012 DenUpdatePEMgur2_x

Already not for the first time I notice that GUR2 readjusts its X zero position

seisms.png

 

As a result the coherence between GUR1X and GUR2X is lost, but between GUR2X and GUR2Y shows up. It seems that these two signals mix at some point.

gur12_coh.jpg

  6537   Mon Apr 16 09:44:54 2012 JenneUpdatePEMgur2_x

Quote:

Already not for the first time I notice that GUR2 readjusts its X zero position

As a result the coherence between GUR1X and GUR2X is lost, but between GUR2X and GUR2Y shows up. It seems that these two signals mix at some point.

 Can you go back in time before the X-position jumped to plot the x1-x2 and x2-y2 coherences?  Just to see what things look like?

  6538   Mon Apr 16 14:37:01 2012 DenUpdatePEMgur2_x

Quote:

Quote:

Already not for the first time I notice that GUR2 readjusts its X zero position

As a result the coherence between GUR1X and GUR2X is lost, but between GUR2X and GUR2Y shows up. It seems that these two signals mix at some point.

 Can you go back in time before the X-position jumped to plot the x1-x2 and x2-y2 coherences?  Just to see what things look like?

DAQ is not working now but ordinary the coherence between GUR1X and GUR2X is ~1 at 0.1 - 10 Hz and between GUR2X and GUR2Y is ~0.

  6721   Wed May 30 22:51:32 2012 DenUpdatePEMguralp isolation box

When I've put Guralps inside the isolation box, the signal from seismometers increased and was out of AA board range. I've reduced the gain of the readout box by a factor of 2. Now R2 for channels 1-6 is (2000, 1050, 1050, 2000, 1050, 1050) Ohm.

The signal increased in the frequency range 30-50 Hz. Guralp noise become better. That's good. However, it is still worse then in the manual.

As Yuta is dancing on the isolation box, Guralp signal is most time out of the AA board range. So I calculated the noise based on 5 min data. This may be enough, but I'll repeat the experiment later with 30 min data.

lin_box_noise.png

  6696   Tue May 29 00:35:57 2012 DenUpdatePEMguralp readout box

I measured the frequency response of the Guralp readout box and noise by providing sin signal of amplitude 50 mV at 15 Hz for channels 1-3.

1_3.png

It turns out that the gain is ~250, while my liso model simulated it to be 200. This is because it is hard to approximate AD620 amplifier.

Noise of the box does not seem to be too bad at low frequencies.

  6618   Mon May 7 21:46:10 2012 DenUpdateCDSguralp signal error

GUR1_XYZ_IN1 and GUR2_XYZ_IN1 are the same and equal to GUR2_XYZ.  This is bad since GUR1_XYZ_IN1 should be equal to GUR1_XYZ.  Note that GUR#_XYZ are copies of GUR#_XYZ_OUT, so there may be (although there isn't right now) filtering between the _IN1's and the _OUT's.  But certainly GUR1 should look like GUR1, not GUR2!!!

Looks like CDS problem, maybe some channel-hopping going on? I'm trying a restart of the c1sus computer right now, to see if that helps.....

Figure:  Green and red should be the same, yellow and blue should be the same.  Note however that green matches yellow and blue, not red.  Bad.

guralps.png

 

 

  6757   Tue Jun 5 21:09:40 2012 yutaUpdateComputer Scripts / Programshacked ezca tools

Currently, ezca tools are flakey and fails too much.
So, I hacked ezca tools just like Yoichi did in 2009 (see elog #1368).

For now,

/ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcaread
/ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcastep
/ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcaswitch
/ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcawrite

are wrapper scripts that repeats ezca stuff until it succeeds (or fails more than 5 times).

Of course, this is just a temporary solution to do tonight's work.
To stop this hack, run /users/yuta/scripts/ezhack/stophacking.cmd. To hack, run /users/yuta/scripts/ezhack/starthacking.cmd.

Original binary files are located in /ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcabackup/ directory.
Wrapper scripts live in /users/yuta/scripts/ezhack directory.

I wish I could alias ezca tools to my wrapper scripts so that I don't have to touch the original files. However, alias settings doesn't work in our scripts.
Do you have any idea?

  6768   Wed Jun 6 18:04:22 2012 JamieUpdateComputer Scripts / Programshacked ezca tools

Quote:

Currently, ezca tools are flakey and fails too much.
So, I hacked ezca tools just like Yoichi did in 2009 (see elog #1368).

For now,

/ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcaread
/ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcastep
/ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcaswitch
/ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcawrite

are wrapper scripts that repeats ezca stuff until it succeeds (or fails more than 5 times).

Of course, this is just a temporary solution to do tonight's work.
To stop this hack, run /users/yuta/scripts/ezhack/stophacking.cmd. To hack, run /users/yuta/scripts/ezhack/starthacking.cmd.

Original binary files are located in /ligo/apps/linux-x86_64/gds-2.15.1/bin/ezcabackup/ directory.
Wrapper scripts live in /users/yuta/scripts/ezhack directory.

I wish I could alias ezca tools to my wrapper scripts so that I don't have to touch the original files. However, alias settings doesn't work in our scripts.
Do you have any idea?

I didn't like this solution, so I hacked up something else.  I made a new single wrapper script to handle all of the utils.  It then executes the correct command based on the zeroth argument (see below).

I think moved all the binaries to give them .bin suffixes, and the made links to the new wrapper script.  Now everything should work as expected, with this new retry feature.

controls@rosalba:/ligo/apps/linux-x86_64/gds-2.15.1/bin 0$ for pgm in ezcaread ezcawrite ezcaservo ezcastep ezcaswitch; do mv $pgm{,.bin}; ln ezcawrapper $pgm; done
controls@rosalba:/ligo/apps/linux-x86_64/gds-2.15.1/bin 0$ cat ezcawrapper
#!/bin/bash

retries=5

pgm="$0"
run="${pgm}.bin"

if ! [ -e "$run" ] ; then
    cat <&2
This is the ezca wrapper script.  It should be hardlinked in place of
the ezca commands (ezcaread, ezcawrite, etc.), and executing the
original binaries (that have been moved to *.bin) with $retries
failure retries.
EOF
    exit -1
fi

if [ -z "$@" ] || [[ "$1" == '-h' ]] ; then
    "$run"
    exit
fi

for try in $(seq 1 "$retries") ; do
    if "$run" "$@"; then
	exit
    else
	echo "retrying ($try/$retries)..." >&2
    fi
done
echo "$(basename $pgm) failed after $retries retries." >&2
exit 1

  6769   Wed Jun 6 18:22:52 2012 JamieUpdateComputer Scripts / Programshacked ezca tools

Quote:

I didn't like this solution, so I hacked up something else.  I made a new single wrapper script to handle all of the utils.  It then executes the correct command based on the zeroth argument (see below).

I think moved all the binaries to give them .bin suffixes, and the made links to the new wrapper script.  Now everything should work as expected, with this new retry feature.

Yuta and I added a feature such that it will not retry if the environment variables EZCA_NORETRY is set, e.g.

$ EZCA_NORETRY=true ezcaread FOOBAR

  8068   Tue Feb 12 18:25:43 2013 JamieSummaryGeneralhalf PRC with astigmatic PR2/3

Quote:
  arbcav a la mode measurement
g tangential 0.9754 0.9753 0.986 +/- 0.001
g sagital 0.9686 0.9685 0.968 +/- 0.001

Given that we're measuring different g parameters in the tangential and sagittal planes, I went back to alamode to see what astigmatism I could put into PR2 and/or PR3 to match what we're measuring.  I looked at three cases: only PR2 is astigmatic, only PR3 is, or where we split the difference.  Since the sagittal measurement matches, I left all the sagittal curvatures the same in

case 1: PR3 only

  PR2 RoC (m) PR3 RoC (m) g (half PRC)
tangential 706 -420 0.986
sagittal 706 -700 0.969

case 2: PR3 only

  PR2 RoC (m) PR3 RoC (m) g (half PRC)
tangential 5000 -700 0.986
sagittal 706 -700 0.969

case 3: PR2 and PR3

  PR2 RoC (m) PR3 RoC (m) g parameter
tangential 2000 -600 0.986
sagittal 706 -700 0.969

From Koji's post about the scans of the G&H mirrors, it looks entirely reasonable that we could have these levels of astigmatism in the optics.

What this means for full PRC

These all make the same full PRC situation:

     g (tangential):  0.966

     g (sagittal):  0.939

     ARM mode matching:  0.988

 

  1165   Mon Dec 1 15:09:27 2008 robUpdatePEMhalf-micron particle count is alarming
  1168   Tue Dec 2 19:51:32 2008 ranaUpdatePEMhalf-micron particle count is alarming
The 0.5 micron dust monitor count is now pretty high (36000). I wandered around the lab to see if there was anything
nasty going on but I didn't see or smell anything in particular. Since today Alberto was sitting around where the
dust monitor is while aligning the PSL beam, we should blame him. Its either garlic, cologne, or time to bathe.

The 400 day hour trend shows that while the counts are not so unusual, the 40m is dirtier than it was last year.
Attachment 1: Untitled.png
Untitled.png
Attachment 2: dust.png
dust.png
  9970   Mon May 19 09:19:44 2014 SteveUpdateLSChappy IFO

15 hours

Attachment 1: whenthinksareworking.png
whenthinksareworking.png
ELOG V3.1.3-