40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 98 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  11701   Tue Oct 20 11:24:29 2015 ericqHowToLSCHow to DRFPMI

Herein, I will describe the current settings and procedures used to achieve the DRFPMI lock, cobbled together from scripts, burts and such. 


Initial Alignment

  1. With arms POX/POY locked, run dither alignment servos. Set transmon QPD offsets here
  2. Restore "PRMI Carrier" configuration, run BS and PRM dither alignment servos simultaneously. (Note: this sacrifices some X arm alignment for better dark port alignment. In practice no appreciable loss of TRX is observed)
  3. Misalign PRM, align SRM and tune SRM alignment by eye while looking at AS camera. 
  4. Restore POX/POY arm lock, lock green to arms, check that powers are high enough and align if neccesary.

Initial Configuration

CARM, DARM

For CARM and DARM, the A channels are used for the ALS signals, whereas the B channels are used for blending the RF signals. 

ALS

  • BEATX and BEATY, I and Q channels: +0dB Whitening Gain, Whitening Filters ON
  • Green beatnotes somewhere between 20-80MHz, following sign convention of temperature slider UP makes beat freq go UP.  Check spectrum of PHASE_OUT_HZ vs references in ALS_outOfLoop_Ref.xml. The locking script automatically sets the correct phase tracker gain, so no need to adjust manually.
  • CARM_A = -1.0 x ALSX + 1.0 x ALSY, G=1.0
  • DARM_A = 1.0 x ALSX + 1.0 x ALSY, G=1.0

RF

  • CM Board: REFL11 I daugher board output -> IN1, IN1 Enabled, -32dB input gain, 0.0V offset, all boosts off, AO polarity positive, AO gain +0dB
  • MC Board: IN2 disabled, -32dB input gain
  • CM_SLOW: +0dB Whitening Gain, Whitening ON, LSC-CM_SLOW_GAIN = -5e-4 (Though, it would be good to reallocate this gain to the input matrix element)
  • CARM_B = 1.0 x CM_SLOW, FM4 FM10 ON, G=0 (FM4 = LP700 for AO crossover stability, FM10 = 120:5k for coupled cavity pole compensation)
  • AS55: +9dB Whitening Gain, Whitening filters manual, Demod angle -37.0
  • DARM_B = -1e-4 x AS55 Q, G=0

DRMI 3F

For the DRMI, the A channels are used for the 1F signals, whereas the B channels are used for the 3F signals. The settings for transitioning to 1F after locking the DRFPMI have not yet been determined. 

These settings are currently saved in the DRMI configurator, but the demod angles are set for DRFPMI lock, so the settings don't reliably work for misaligned arms. 

  • REFL33: +30dB Whitening Gain, Whitening filters trigger on DRMI lock, Demod angle: 136.0
  • REFL165: +24dB Whitening Gain, Whitening filters trigger on DRMI lock, Demod angle: -111.0
  • POP22: +15dB Whitening Gain, Whitening filters OFF, Demod angle: -114.0
  • AS110: +36dB Whitening Gain, Whitening filters OFF, Demod angle: -116.0
  • POPDC: +0dB Whitening Gain, Whitening filters OFF (used as a supplemental trigger signal when CARM and DARM are buzzing and POP22 fluctuates wildly)
  • MICH_B = 6.0 x REFL165Q, offset = 15.0
  • PRCL_B = 5.0 x REFL33I, offset = 45.0
  • SRCL_B = -0.6 x REFL165I + 0.24 x REFL33 I, offset=0

The REFL33 element in SRCL_B is to reduce the PRCL coupling, was found empirically by tuning the relative gains with the arms misaligned and looking at excitation line heights. The offsets were found by locking the DRMI on 1F signals with arms misaligned, and taking the average value of these 3F error signals.  

Servo filter configuration

The CARM and DARM ALS settings are largely scripted by scripts/ALS/Transition_IR_ALS.py, which takes you from arms POX/POY locked to CARM and DARM ALS locked. The DRMI settings are usually restored from the IFO_CONFIGURE screen. 

  • CARM: FM[1, 2, 3, 5, 6] , G=4.5, Trigger forced on, no FM triggers, output limit 8k
  • DARM: FM[1, 2, 3, 5, 6] , G=4.5, Trigger forced on, no FM triggers, output limit 8k
  • MICH: FM[4, 5], G= -0.03, Trigger POP22 I x 1.0 [50, 10], FM[2, 3, 7] triggered [50, 10], output limit 20k
  • PRCL: FM[4, 5], G= -0.003, Trigger POP22 I x 1.0 [50, 10], FM[1, 2, 8, 9] triggered [50, 10], output limit 8k
  • SRCL: FM[4, 5], G= -0.4, Trigger AS110 Q x 1.0 [500, 100], FM[2, 7, 9] triggered [500, 100], output limit 15k

Actuation Output matrix

  • MC2 = -1.0 x CARM
  • ETMX = -1.0 x DARM
  • ETMY = 1.0 x DARM
  • BS = 0.5 x MICH
  • PRM = 1.0 x PRCL - 0.2655 MICH
  • SRM = 1.0 x SRCL + 0.25 MICH (The mich compensation is very roughly estimated)

Locking Procedure

When arms are POX/POY locked, and the green beatnotes are appropriately configured, calling scripts/DRFPMI/carm_cm_up.sh initiates the following sequence of events:

  • Turn ON MC length feedforward and PRC angle feedforward
  • Set ALS phase tracker UGFs by looking at I and Q magnitudes
  • Set LSC-ALSX and LSC-ALSY offsets by averaging, ramp CARM+DARM gains up, XARM+YARM gains down, engage CARM+DARM boosts, now ALS locked
  • Move CARM away from resonance, offset = -4.0 (DRMI locks quicker on this side for whatever reason)
  • Restore PRM, SRM alignment. Set DRMI A FM gains to 0, B FM gains to 1.0. Enable LSC outputs for BS, PRM, SRM
  • When DRMI has locked, add POPDC trigger elements to DRMI signals and transition SRCL triggering to POP22I. NB: In the c1lsc model, the POPDC signal incident on the trigger matrix has an abs() operator applied to it first. 
    • MICH Trig = 1.0 x POP22 I + 0.5 x POPDC, [50, 10]
    • PRCL Trig = 1.0 x POP22 I + 0.5 x POPDC, [50, 10]
    • SRCL Trig = 10.0 x POP22 I + 5 x POPDC, [500, 100]
  • Reduce POX, POY whitening gains from their nominal +45dB to +0dB, so there aren't railing channels making noise in the whitening chassis and ADCs
  • DC couple ITM oplevs (average spot position, set FM offset, turn on DC boost filter, let settle)
  • With an 8 second ramp, reduce CARM offset to 0 counts. 
  • MANUALLY adjust CARM_A and DARM_A offsets to where CARM_B_IN and DARM_B_IN are seen to fluctuate symetrically around their zero crossing.
    • Note: Last week, this adjustment tended to be roughly the same from lock to lock, unlike the PRFPMI which generally didn't need much adjustment. Also, by jumping from CARM offset of -0.4 to 0.4, it could be seen that the zero crossing in  CARM_B aka CM_SLOW aka REFL11 had some offset, so CARM_B_OFFSET was set to 0.005, but this may change. 

When CARM and DARM are buzzing around true zero, powers maximized:

  • CARM and DARM FM1 (18,18:1,1 boosts) OFF
  • CARM_B_GAIN 0.0 -> 1.0, FM7 ON (20:0 boost)
  • DARM_B_GAIN 0.0 -> 0.015, FM7 ON (20:0 boost) 
  • MC servo board IN2 ENABLE, IN2 gain -32dB -> -16dB
  • Turn ALL MC2 violin filters OFF (smoothen out AO crossover)
  • If stable, CM board IN1 gain -32dB -> -10dB (This is the overall CARM gain, the arm powers stabilize within the last few dB of this transition)
  • CARM_A_GAIN 1.0 -> 0.7
  • CARM_A FM9 ON (LP1k), sleep, FM 1 ON (1:20 deboost), sleep, FM 2 ON (1:20 deboost), HOLD OUPUT, CARM now RF only
  • DARM_B_GAIN 0.015 -> 0.02, sleep, DARM_A_GAIN 1.0 -> 0.0 (This may not be the ideal final DARM_B gain, UGF hasn't been checked yet)

IFO is now RF only!

  • Turn on transmon QPD servos.
  • Adjust comm/diff QPD servo offsets to correct any problems evident on AS/REFL cameras. This usually brings powers from ~100-120 to ~130-140. 

This is as far as we've taken the DRFPMI so far, but the CARM bandwidth is still only at a few kHz. Based on PRFPMI locking, the next steps will be:

  • CM BOARD +12dB or so additional IN1 gain, more AO gain may be needed to get crossover to final position of ~100Hz
  • MC2 viollin filters back on
  • CM boost(s) on
  • AS55 whitening on
  • Transition DRMI to 1F
  2403   Sat Dec 12 07:36:56 2009 ranaHowToElectronicsHow to Measure the Length of a Cable: Interferometry

Need to measure the length of the cable, but too lazy to use a measuring tape?

Then you too can become an expert cable length measurer by just using an RF signal generator and a scope:

  1. Disconnect or short (not 50 Ohm term) the far side of the cable.
  2. Put a T on the near side of the cable.
  3. Drive the input of the T with your signal source.
  4. Look at the output of the T with the scope while sweeping the signal source's frequency knob.

The T is kind of acting like a beamsplitter in an asymmetric length Michelson in this case. Just as we can use the RF phase shift between the arms to measure the Schnupp asymmetry, we can also use a T to measure the cable length. The speed of light in the cable is documented in the cable catalog, but in most cases its just 66% of the speed of light in the vacuum.

  2316   Mon Nov 23 19:36:28 2009 JenneUpdateAdaptive FilteringHow to add ASS channels, so that they're saved to frames

[Jenne, Sanjit]

We would like several channels from the OAF/ASS screen to be saved to frames, so that we can use the channels for our OAF model.  In theory, this should involve uncommenting the desired channels in the .ini file (.../caltech/chans/daq/C1ASS.ini), and restart the frame builder.  Since this .ini file was generated a long time ago, and things have been changed since then, the chnnums in the .ini file and the corresponding .par file don't match up.  We need to go through the .par file (/cvs/cds/gds/param/tpchn_c3.par), and look up the chnnums for our channels, and copy those numbers into the .ini file.  Figuring out what was going on involved many fb40m restarts, but on the last one of the night, I restarted the backup script, so it should (hopefully) run tonight, and get all of the frames that we've been missing.

Notes to self: 

*  When adding channels to other front ends, the end of the process is to click the blue button on the C0DAQ_DETAIL screen next to your computer.  C1ASS isn't on that screen.  Instead, in the C1ASS_GDS screen, click DAQ Reload.

*  The channel names for the Test Points and the .ini files must be different.  That's why there's a '_2048' suffix at the end of every channel in our .ini file.

*  tpchn_C1 is all of the old-style system test points.  tpchn_C2 is the C1OMC, and tpchn_C3 is for the C1ASS testpoints.

*  When uncommenting channels in the C1ASS.ini file, make sure acquire is set to 1 for every channel we want saved.  The default in this .ini file is set to acquire = 0.

  14371   Wed Dec 19 22:11:28 2018 KojiUpdateGeneralHow to align the copper OMC

The OMC input optics layout is attached

Checked the spot position on OMMT-FM1. It was off from the center. This was causing the spot on OMMT1 off-center. This was fixed by the steering mirror for the AUX laser.

The beam alignment onto the OMC was tweaked with OMC-SM1 and OMC-SM2. This was the painful part. We had to make a sensor card that could get in to the narrow space of the OMC. (Attachment 2 right)

Attachment 2 left shows the naming convention of the OMC mirrors.

For the alignment, we gave 5Vpp trig waves at 3.1Hz to the input of the PZT amp so that the cavity is kept scanned continuously. Firstly check the rough spot positions for OMC-CM1 and OMC-CM2. If you carefully use the card, you can check if the beam is returning to OMC-IC. This return beam should have roughtly same hight as the incident beam. This can be adjusted by either of the steering mirrors.

Once the beam is going around the mirrors multiple times, the spot alignment can be checked at OMC-CM1. Bring a card right in front of CM1. If the card is lifter slightly above the incident spot, this automatically allows for the outgoing beam to go through. Depending on the pitch alignment, the next roundtrip (1RT) will be seen on the card. As you lift the card up more, you will be able to see more round trip beams (e.g. 2RT, 3RT, in the figure). If the yaw alignment is perfect, these spots would be lined up vertically. So you can try to align the horizontal direction with the steering mirrors. Then the vertical alignment can be done with the pitch knobs.

At this point you should be able to see some super high-order transmission at the OMC trans. For today, we stopped here as we already ran out of the knob ranges at multiple knobs. This is because the beam height in the mode matching telescope was not right, and the steering mirrors had to work more than their range.

Attachment 1: 110804_40m_OMC_layout.pdf
110804_40m_OMC_layout.pdf
Attachment 2: OMC_alignment.pdf
OMC_alignment.pdf
  16158   Mon May 24 20:55:00 2021 KojiSummaryBHDHow to align two OMCs on the BHD platform?

Differential misalignment of the OMCs

40m BHD will employ two OMCs on the BHD platform. We will have two SOSs for each of the LO and AS beams. The challenge here is that the input beam must optimally couple to the OMCs simultaneously. This is not easy as we won't have independent actuators for each OMC. e.g. The alignment of the LO beam can be optimally adjusted to the OMC1, but this, in general, does not mean the beam is optimally aligned to the OMC2.

Requirement

When a beam with the matched mode to an optical cavity has a misalignment, the power coupling C can be reduced from the unity as

C = 1 - \left(\frac{a}{\omega_0}\right)^2 - \left(\frac{\alpha}{\theta_0}\right)^2

where \omega_0 is the waist radius, \theta_0 is the divergence angle defined as \theta_0 \equiv \lambda/ \pi \omega, a and \alpha are the beam lateral translation and rotation at the waist position.

The waist size of the OMC is 500um. Therefore \omega_0 = 500um and \theta_0 = 0.68 mrad. If we require C to be better than 0.995 according to the design requirement document (T1900761). This corresponds to a (only) to be 35um and \alpha (only) to be 48urad. These numbers are quite tough to be realized without post-installation adjustment. Moreover, the OMCs themselves have individual differences in the beam axis. So no matter how we set the mechanical precision of the OMC installation, we will introduce a maximum of 1mm and ~5mrad uncertainty of the optical axis.

Adjustment

Suppose we adjust the incident beam to the OMC placed at the transmission side of the BHD BS. The reflected beam at the BS can be steered by picomotors. The distance from the BS to the OMC waist is 12.7" (322mm) according to the drawing.
So we can absorb the misalignment mode of (a, \alpha) = (0.322 \theta, \theta). This is a bit unfortunate. 0.322m is about 1/2 of the rayleigh range. Therefore, this actuation is still angle-dominated but a bit of translation is still coupled.

If we enable to use the third picomotor on the BHD BS mount, we can introduce the translation of the beam in the horiz direction. This is not too huge therefore we still want to prepare the method to align the OMC in the horiz direction.

The difficult problem is the vertical alignment. This requires the vertical displacement of the OMC. And we will not have the option to lower the OMC. Therefore if the OMC2 is too high, we have to raise the OMC1 so that the resulting beam is aligned to the OMC2. i.e. we need to maintain the method to raise both OMCs. (... or swap the OMCs). From the images of the OMC beam spots, we'll probably be able to analyze the intracavity axes of the OMCs. So we can always place the OMC with a higher optical axis at the transmission side of the BHD BS.

 

 

  8265   Sun Mar 10 13:29:29 2013 KojiHowToIOOHow to calculate the accumulated round-trip Gouy phase

How to calculate the accumulated round-trip Gouy phase (and namely the transverse mode spacing) of a general cavity
only from the round-trip ABCD matrix

T1300189

  13869   Sun May 20 17:43:01 2018 ranaUpdateElectronicsHow to choose resistors

Article from EE Times, describing why metal foil (NOT metal film) resistors are really better than wirewound when it comes to everything except high power dissipation.

Need to do some diggin to see if we can find ~1k metal foil resistors which can handle ~1W of heat.

Steve: here it is

  6637   Thu May 10 14:49:06 2012 KojiHowToGeneralHow to clean & bake black glass pieces

  966   Thu Sep 18 18:38:14 2008 YoichiHowToComputersHow to compile an SNL code for VxWorks
Dave Barker guided me through how to compile an SNL code into a Motorola 162 CPU object.

Here is the procedure:

(1) You need an account at LHO and a password for ops account at LHO. Contact Dave if you don't have these.

(2) Copy your code (say Particle.st) to the LHO gateway machine.
scp Particle.st username@lhocds.ligo-wa.caltech.edu:/cvs/cds/lho/target/t0sandbox0
(3) Login to lhocds.ligo-wa.caltech.edu
ssh username@lhocds.ligo-wa.caltech.edu
(4) Login to control0
ssh ops@control0
(5) Change directory to the sandbox dir.
cd /cvs/cds/lho/target/t0sandbox0
(6) Prepare for the compilation
setup epics
(7) Edit makefile in the directory. You have to modify a few lines at the end of the file.
There are comments for how to do it in the file.

(8) Compile
make Particle.o
(9) Copy the object file to the 40m target directory
scp Particle.o controls@nodus.ligo.caltech.edu:/cvs/cds/caltech/target/c1psl/

That is it.
  11485   Thu Aug 6 21:03:45 2015 IgnacioHowToWienerFilteringHow to do online static IIR Wiener filtering

In order to do online static IIR Wiener filtering one needs to do the following,

1) Get data for FIR Wiener filter witnesses and target.

2) Measure the transfer function (needs to be highly coherent, ~ 0.95 for all points) from the actuactor to the control signal of interest (ie. from MC2_OUT to MC_L).

3) Invert the actuator transfer function.

4) Use Vectfit or (LISO) to find a ZPK model for the actuator transfer and inverse transfer functions.

5) Prefilter your witness data with the actuator transfer function, to take into account the actuator to control transfer function when designing the offline Wiener FIR filter.

6) Calculate the frequency response for each witness from the FIR coefficients.

7) Vectfit the frequency reponses to a ZPK model, this is the FIR to IIR Wiener conversion step.

8) Now, either, divide the IIR transfer function by the actuator transfer function or more preferably, multiply by the inverse transfer function.

9) Use Quack to make SOS model of the IIR Wiener filter and inverse transfer function product that goes into foton for online implementation.

10) Load it into the system.

The block diagram below summarizes the steps above.

Attachment 1: iir.png
iir.png
  11273   Tue May 5 10:40:05 2015 ericqHowToComputer Scripts / ProgramsHow to get a web page running on Nodus

How to get your own web page running on Nodus

  1. On any martian machine, put your stuff in /users/public_html/$MYPAGE/
  2. On Nodus, run: ln -s /users/public_html/$MYPAGE /export/home/
  3. Your site is now available at https://nodus.ligo.caltech.edu:30889/$MYPAGE/
  4. If you want to allow straight up directory listing to the entire internet, on Nodus run: sudoedit /etc/sites-available/nodus, and add the following lines towards the bottom:
<Directory /export/home/$MYPAGE>
    Options +Indexes
</Directory>
  1550   Wed May 6 02:39:20 2009 YoichiHowToLockingHow to go to DC readout
I wrote a script called DC_readout, which you can find in /cvs/cds/caltech/scripts/DRFPMI/bang/nospring/.

Currently, the locking script succeeds 1/3 of the time. The freaky parts are the MC_F hand off and REFL_DC hand off.
MC_F hand off succeeds 70% of the time. REFL_DC goes well about a half of the time. Combined, the success rate is about 1/3.
We need some work on those hand offs.
Once you pass those freaky parts, the cm_step script usually goes smoothly and you will reach the full RF lock with the boost and the super boost1 engaged on the CM board.

To go to DC readout from there, run the DC_readout script.
First, this script will put some offset to the DARM loop so that some carrier light will leak to the AS port.
You are prompted to lock the OMC. Move the OMC length offset slider to find the carrier resonance and lock the OMC.
You have to make sure that it is carrier, not the 166MHz sideband. Usually the carrier light pulsates around 10Hz or so whereas the 166MHz SB is stable.
Once you locked the OMC to the carrier, hit enter on the terminal running the DC_readout script.
The script will do the rest of the hand off.
Once the script has finished, you may want to check darm_offset_dc in the C1LSC_LA_SET screen. This value sets the DC offset (a.k.a. the homodyne phase).
You may want to change it to what you want.
  11323   Sun May 24 14:45:02 2015 KojiHowToGeneralHow to launch StripTools at specified locations

LLO Operator Tips:

koji.arai@cr9:/opt/rtcds/userapps/trunk/asc/l1/scripts/initial_alignment$ cat autostart_strips.sh 
 

#!/bin/bash

# Baffle window setup 1500x480

StripTool -xrm 'StripTool.StripGraph.geometry:1500x470+0+24' /opt/rtcds/userapps/trunk/asc/l1/scripts/initial_alignment/baffle_pd.stp &
sleep 1

# DC signals setup

StripTool -xrm 'StripTool.StripGraph.geometry:1500x470+0+470' /opt/rtcds/userapps/trunk/asc/l1/scripts/initial_alignment/dc_signals.stp &
sleep 1

# WFS prx mich sry setup

StripTool -xrm 'StripTool.StripGraph.geometry:1500x470+0-24' /opt/rtcds/userapps/trunk/asc/l1/scripts/initial_alignment/wfs_prx_mich_sry.stp &
sleep 1


exit

  3661   Wed Oct 6 15:56:14 2010 josephbHowToCDSHow to load matrices quickly and easily

Awhile ago I wrote several scripts for reading in medm screen matrix settings and then writing them out.  It was meant as kind of a mini-burt just for matrices for switching between a couple of different setups quickly.

Yuta has expressed interest in having this instruction available.

In /cvs/cds/caltech/scripts/matrix/ there are 4 python scripts:

saveMatrix.py, oldSaveMatrix.py, loadMatrix.py, oldLoadMatrix.py

The saveMatrix.py and loadMatrix.py are for use with the current front end codes (which start counting from 1), where as the old*.py files are for the old system.

To use saveMatrix.py you need to specify the number of inputs, outputs, and the base name of the matrix (i.e. C1:LSP-DOF2PD_MTRX is the base of C1:LSP-DOF2PD_MTRX_0_0_GAIN for example), as well as an ouptut file where the values are stored.

So to save the BS in_matrix setting you could do (from /cvs/cds/caltech/scripts/matrix/)

./saveMatrix.py -i 4 -o 5 -n "C1:SUS-BS_TO_COIL_MTRX" -f -d ./to_coil_mtrx.txt

The -i 4 indicates 4 inputs, the -o 5 indicates 5 outputs, -n "blah blah" indicates the base channel name, -f indicates a matrix bank of filters (if its just a normal matrix with no filters, drop the -f flag), and -d ./to_coil_mtrx.txt indicates the destination file.

To write the matrix, you do virtually the same thing:

./loadMatrix.py -n "C1:SUS-PRM_TO_COIL_MTRX" -f -d ./to_coil_mtrx.txt

In this case, you're writing the saved values of the BS, to the PRM.  This method might be faster if you're trying to fill in a bunch of new matrices that are identical rather than typing 1's and -1's 20 times for each matrix.

I'll have Yuta add his how-to of this to the wiki.

  2938   Mon May 17 02:10:10 2010 KojiConfigurationIOOHow to lock / align the MC

Let me remind you how to lock and align the IMC

To lock

1. Open the doors for the IMC/OMC chambers. Open the manual shutter of the PSL just in front of the optical window

2. Run scripts/MC/mcloopson

3. Set the MC length path gain 0.3 / Set the MC total gain "+20"

4. If you want to avoid excitation of the mirrors by air turbulence, put a big plastic film and put three posters on the top and both the sides on the floor to block the wind go into the chamber.

To shut down

1. Run scripts/MC/mcloopsoff

2. Close the manual shutter, Remove the wind blockers, and the light door of the chambers

To align the MC

1. Tweak MC2 and MC3 to get maximum transmittion and/or minimum reflection.

  847   Mon Aug 18 15:32:18 2008 josephbConfigurationCamerasHow to multicast with gstreamer and Gige Cameras
In order to get multicasting to work, one simply needs to understand the address scheme.

In general, the address range 224.0.0.0 - 239.255.255.255 are reserved for multicasting. Within in this address space, there are some base level operations in the 224.0.0.x range which shouldn't be interfered with.

For a single site, the address range between 239.252.0.0 and 239.255.255.255 is probably best.

Gstreamer and the current 40m network hubs are designed to handle this kind of communication already, so one merely needs to point them at the correct addresses.

While in /cvs/cds/caltech/target/Prosilica/40mCode/SnapCode type:

CamServe -F 'Mono8' -c 44058 -E 20000 -X 0 -Y 0 -H 480 -W 752 -l 0 -m 300 | gst-launch-0.10 fdsrc fd=0 blocksize=360960 ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=60/1 ! ffmpegcolorspace ! queue ! smokeenc keyframe=8 qmax=40 ! udpsink host=239.255.1.1 port=5000

This will multicast to the 239.255.1.1 address, using port 5000.

On the machine you wish to subscribe type:

gst-launch udpsrc multicast-group=239.255.1.1 port=5000 ! smokedec ! ffmpegcolorspace ! ximagesink sync=false
  10515   Wed Sep 17 18:36:03 2014 KojiHowToGeneralHow to run DTT measurement automatically
  • Suppose you have a dtt template name test.xml
  • The file test.dtt

    open
    restore test.xml
    run -w
    save test2.xml
    quit
     
  • Run diag < test.dtt
  • The result is saved in test2.xml
  14865   Fri Sep 6 21:22:06 2019 KojiHowToCDSHow to save c1ioo

Q1 Can we run the machine with the reduced # of cores?

Q2 We might be able to order them quickly. What's the spec and configuration of the DIMMs (like DDR2-667MHz ECC 4GBx4, and even more specs (like Samsung 2GB DDR2 RAM PC2-6400 240-Pin DIMM M378T5663EH3) so that we are to identify the exact spec).

Q3 Can we scavenge the old OMC RT machine or even megatron to extract the memories?

  14866   Fri Sep 6 22:03:30 2019 aaronHowToCDSHow to save c1ioo

Saw these slightly delayed.

Q1: Not sure--is it a safe operation for me to remove the DIMM on CPU0, replace CPU0 (with no DIMM), and boot up to try this?

Q2: Specifically, it's this DIMM. The CPU core is compatible with DDR2, clock rate up to 333 MHz (DDR2-667) and 1, 2, or 4 GB of memory.

Q3: Hmm checking on that.
I see a message on megatron that it's currently running MC autolocker and the FSS slow servo, with nothing else listed. It's currently running 30-70% of its available memory on all 8 cores, so seems it's got some to spare. I need to relocate the old c1omc RT machine for myself, but becoming inefficient so I'm off.
 
Quote:

Q1 Can we run the machine with the reduced # of cores?

Q2 We might be able to order them quickly. What's the spec and configuration of the DIMMs (like DDR2-667MHz ECC 4GBx4, and even more specs (like Samsung 2GB DDR2 RAM PC2-6400 240-Pin DIMM M378T5663EH3) so that we are to identify the exact spec).

Q3 Can we scavenge the old OMC RT machine or even megatron to extract the memories?

  14867   Mon Sep 9 11:36:48 2019 aaronHowToCDSHow to save c1ioo

One pair of DIMM cards from the Sunstone box had the same Sun part number as those in c1ioo, so I swapped them in and reinstalled c1ioo's CPU0. c1ioo now boots up an seems ready to go, I'm able to log on from nodus. I also reinstalled optimus' CPU0, and optimus boots up with no problems.


  • old C1OMC RT
  • Megatron
    • I also found that megatron will require a CPU filler board if we remove one of its DIMM (it cannot operate with empty CPU module slots)
  • optimus
    • Rana says I can also consider using two of optimus' DIMM cards. Optimus appears to not be running any scripts currently, and I don't find any recent elog entries or wiki pages mentioning optimus with critical use.
    • I shutdown optimus (from the command line Mon Sep 9 13:17:58 2019).

While opening up optimus, I noticed a box labelled 'SUNSTONE' sitting below the rack--it contains two CPU modules a similar type as in c1ioo! I'm going to try swapping in the DIMM cards from this SUNSTONE box; I didn't find any elogs about sunstone--where are these modules from?

I reset c1lsc and c1sus, then ran rebootC1LSC.sh as before. All models started by the script are running with minimal red lights; c1oaf, c1cal, c1dnn, c1daf, and c1omc are not started by the script. I manually started these in the order c1cal->c1oaf->c1daf->c1dnn. Starting c1dnn crashed the other FE on c1ioo, so I reset all three FE again, and ran the script again (this time, including the startup for c1cal, c1oaf, and c1daf, but excluding c1dnn).

Except for c1dnn and c1omc, all models are started. The status lights are attached.

Attachment 1: reboot.png
reboot.png
  14900   Thu Sep 19 15:59:29 2019 aaronHowToCDSHow to save c1ioo

New DIMM cards have arrived. I stored them in the digital cabinet along y arm.

  11399   Thu Jul 9 16:39:03 2015 KojiConfigurationGeneralHow to set up your own summary page environment on the LDG cluster

Here is the summary of my investigation how to set up my own "summary page" environment on the LDG (LIGO Data Grid) cluster.

Here all albert.einstein must be replaced with your own LIGO.ORG user name.


1. Obtain LDAS cluster account

Run the following from any of the terminal and use your LIGO.ORG credential
ssh albert.einstein@ssh.ligo.org
You will be suggested to visit a particular web site. Fill the form on the web site and wait for the approval e-mails.

2. Use LDG SSH login portal

Once you received the approval of the account, you should be able to log in to the system. Type the following command again from your local terminal
ssh albert.einstein@ssh.ligo.org
You are asked to select the site and machines. Select 2- CIT and b. ldas-pcdev1, c. ldas-pcdev2, or d. ldas-pcdev3.

3. Setup bash environment

Setting up the python library path is very important for the proper processing.

Here is my setup for .bash_profile

# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi

if [ -f ~/.profile ]; then
        . ~/.profile
fi

# User specific environment and startup programs
PATH=$PATH:$HOME/bin
export PATH

# So that ssh will work, take care with X logins - see .xsession
[[ -z $SSH_AGENT_PID && -z $DISPLAY ]] &&
  exec -l ssh-agent $SHELL -c "bash --login"

and .bashrc

# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
    . /etc/bashrc
fi

# Set Python environment (based on gpwy-env script)

# clean path environment variable of duplicate entries
cleanpath() {
    if [[ -z "$1" ]]; then
       $1=PATH
    fi
    # map to local variable
    local badpath=$(eval echo \$$1)
    badpath=${badpath%%:}
    # remove duplicates
    badpath="$(echo "${badpath}" | awk -v RS=':' -v ORS=":" '!a[$1]++')"
    # remove trailing colon
    badpath=${badpath%%:}
    # reset variable and export
    eval $1=${badpath}
    eval export $1
}

# set PATH
cleanpath PATH
cleanpath PYTHONPATH

PATH=${HOME}/.local/bin:${PATH}
PYTHONPATH=${HOME}/.local/lib/python2.6/site-packages:${PYTHONPATH}

The order of cleanpath and PYTHONPATH= is important as we want to use the local library installation before anything kicks in.

4. Install required Python libraries

Run the following lines with this order so that they are installed in your "~/local"

# PIP installation
wget https://bootstrap.pypa.io/get-pip.py
python get-pip.py --user
# numpy, scipy, distribute, matplotlib, astropy, importlib installation
pip install numpy --upgrade --user
pip install scipy --upgrade --user
pip install distribute --upgrade --user
pip install matplotlib --user --upgrade
pip install astropy --upgrade --user
pip install importlib --user --upgrade

# We need to use dev branch of gwpy to run gwsumm propery
cp -r /home/detchar/opt/gwpysoft/lib/python2.6/site-packages/gwpy* ~/.local/lib/python2.6/site-packages/

# gwsumm installation
pip install --user git+https://github.com/gwpy/gwsumm

5. Setup summary pages for the 40m

Copy summary page setting from Max's directory.

cp -r ~max.isi/summary ~/

And make temporary directory for the summary pages.

mkdir /usr1/albert.einstein/summary

6. Modify typos in gw_summary_custon

Use your own editor to fix typos

emacs ~/summary/bin/gw_daily_summary_custom

replace max.isi to albert.einstein
change summary40m -> summary


Now the installation is done. From here, the description is for the routine procedure.

7. Run your summary page code

Run Kerberos authentication
kinit albert.einstein@LIGO.ORG

Run a summary page code for a specific date (e.g. for Jul 1st, 2015)
bash ${HOME}/summary/bin/gw_daily_summary_custom --day 20150701

The result can be checked under

https://ldas-jobs.ligo.caltech.edu/~albert.einstein/summary/
https://ldas-jobs.ligo.caltech.edu/~albert.einstein/summary/day/20150701/

Rerun a code for a specific page. This requires the page structure already exists.
The red texts should be modified depending on what ini file you want to run for what day.

/home/albert.einstein/.local/bin/gw_summary day --on-segdb-error warn --verbose  --output-dir . --multi-process 20 --no-html  --ifo C1 --archive C1EVE 20150630  --config-file /mnt/qfs2/albert.einstein/public_html/summary/etc/defaults.ini,/mnt/qfs2/albert.einstein/public_html/summary/etc/c1eve.ini

This command can actually be found in
https://ldas-jobs.ligo.caltech.edu/~albert.einstein/summary/gw_summary_pipe.sh

8. Some useful command

To check which python library is used
python -c 'import gwpy; print gwpy.__file__'

To list installed python libraries and versions
pip list

This should return the list like the following.

...
astropy (1.0.3)
...
gwpy (0.1b1.dev121)
gwsumm (0.0.0.dev854)
...
matplotlib (1.4.3)
...
numpy (1.9.2)
...
scipy (0.15.1)
...

 

 

  11405   Mon Jul 13 18:27:27 2015 EveConfigurationGeneralHow to set up your own summary page environment on the LDG cluster

I'd like to build off of Koji's instructions with a few useful tips I discovered while setting up my own summary page environment.

To only make a specified selection of tabs for the summary pages, copy only the corresponding .ini files into /home/albert.einstein/summary/config and run the gw_daily_summary_custom following Koji's instructions below. When asked for nodus's password either hit "enter" three times without providing the password or comment out this section of the code to stop the summary page creation process from taking current data files from nodus. This is especially helpful when the 40m is down (like it is now).

After running the summary page code, the pages can be viewed at https://ldas-jobs.ligo.caltech.edu/~albert.einstein/summary/day/YYYYMMDD/ and corresponding error logs can be found at ~/public_html/summary/logs/gw_summary_pipe_local-687496-0.err.

  3658   Wed Oct 6 11:03:51 2010 josephb, yutaHowToCDSHow to start diaggui for right now

I'm hoping to get a proper install this week done, but for now, this a stop gap.

To start diagnostic test tools, go to rosalba.  (Either sit at it, or ssh -X rosalba).

cd /opt/apps

type "bash", this starts a bash shell

source gds-env.bash

diaggui

 --------- Debugging section ------

If that throws up errors, try looking with "diag -i" and see if there's a line that starts with nds.  In the case last night, Alex had not setup a diagconf configuration file in the /etc/xinetd.d directory, which setups up the diagconf service under the xinit service.  To restart that service (if for example the nds line doesn't show up), go to /etc/init.d/ and type "sudo xinit start" (or restart).

Other problems can include awg and/or tpman not running for a particular model on the front end machine.  I.e. diag -i should show 3 results from 192.168.113.85 (c1x02, c1sus, c1mcs) at the moment , for both awg and tp.  If not, that means awg and tpman need to be restarted for those.

These can be started manually by going to the front end, to the /opt/rtcds/caltech/c1/target/gds/bin/ directory, and running awgtpman -s sysname (or in the case of IOP files [c1x02, c1x03, etc], awgtpman -s sysname -4.  Better is probably to run the start scripts which live /opt/rtcds/caltech/c1/scripts/ which kills and restarts all the process for you.

 

 

  2867   Sun May 2 17:16:43 2010 KojiUpdateSUSHow to steer the incident beam to the MC?

Deviations of the MC spot from the center of the mirrors were measured.

MC1H = +0.29 mm
MC1V = -0.43 mm
MC3H = +1.16 mm
MC3V = -0.68 mm

1) The vertical deviation looks easy being adjusted as they are mostly translation. They are ~0.5mm too high.
The distance from SM2 to MC is 1.8m. Thus what we have to do is
rotate SM2 Pitch in CW knob by 0.25mrad.
1 turn steers the beam in 10mrad. So 0.25mrad is 1/40 turn (9deg)

2) The horizontal deviation is more troublesome. The common component is easily being adjusted
but the differential component (i.e. axis rotation) involves large displacement of the beam
at the periscope sterring mirrors.

(MC3H - MC1H) / 0.2 m * 1.8 m = 8 mm

The beam must be moved in 8mm at the periscope. This is too big.

We need to move the in-vac steering mirror IM1. Move SM2Yaw in 7mrad. This moves the spot on IM1 by 5mm*Sqrt(2).
Then Move Im1 Yaw such that we see the resonance.

For the alignment adjustment, try to maximize the transmission by MC2 Yaw (cavity axis rotation) and SM2Y (beam axis translation)  

Actual move will be:

- Move IM1Y CCW (assuming 100TPI 1.5 turn in total...half turn at once)
- Compensate the misalignment by SM2Y CW as far as possible.
- Take alignment with MC2Y and SM2Y as far as possible

This operation will move the end spot something like 15mm. This should be compensated by the alignment of MC1Y at some point.

Attachment 1: steering.png
steering.png
  2868   Mon May 3 00:36:49 2010 KojiUpdateSUSHow to steer the incident beam to the MC?

Actually, I tried some tweaks of the input steering to get the beam being more centered on the MC mirrors on Saturday evening.

I made a mistake in the direction of the IM1Y tuning, and it made the horizontal spot position worse.

But, this also means that the opposite direction will certainly improve the horizontal beam angle.

Rotate IM1Y CCW!!!


The current setting is listed below

Alignment
MC1P 3.2531
MC1Y -0.5327
MC2P 3.3778
MC2Y -1.366
MC3P -0.5534
MC3Y -2.607


Spot positions
MC1H = +1.15 mm
MC1V = -0.13 mm
MC3H = +0.80 mm
MC3V = -0.20 mm

 

Quote:

Deviations of the MC spot from the center of the mirrors were measured.

MC1H = +0.29 mm
MC1V = -0.43 mm
MC3H = +1.16 mm
MC3V = -0.68 mm

 

  3336   Fri Jul 30 17:54:55 2010 steveHowToVACHow to stop and start slow pumpdown

Quote:

Bob and Steve closed BS chamber with the help of the manual Genie lift and the pump down started. The PSL shutter was closed and manual block was placed in the beam path. High voltage power supplies were checked to be off.

Pumping speed ~ 1 Torr/min was achieved at  1/8 of a turn opened roughing valve RV1

 We are at 370 Torr at 9 hrs of  pumping. RV1 is opened to ~ 3/8 turn orifice. We are using one roughing pump RP3  and butterfly valve is in place.

 

How to stop: 1, close RV1 by torque wheel  2, close V3 from MEDM screen  3, turn off RP3 roughing from MEDM screen  4, disconnect metal hose to oily pump

after butterfly valve. This KF-45 O-ring seal should be kept clean 5, place/close  45 mm cover blanks at the end of the hose and and on the 5" nipple.

 

How to start: 1, remove blanks from  hose and nipple 2, reconnect roughing pump hose to RV1 nipple  3, turn on PR3  4, open V3  5, open RV1 by wrench to ~3/8

6, fine tune RV1 opening to 1 Torr/min

 

ESSENTIAL: one operator has to be present when oilly roughing pump is connected to the vac. envelope

  3338   Fri Jul 30 22:07:42 2010 KojiHowToVACHow to stop and start slow pumpdown

Kiwamu and Koji

The rough pumping was stopped at 230mmTorr. We are going to resume the pumping tomorrow morning.

  • RV1 was closed with torque wheel.
  • V3 was closed from MEDM
  • RP3 wss stopped from MEDM
  • The quick coupling to RP3 was disconnected.

Quote:

    How to stop: 1, close RV1 by torque wheel  2, close V3 from MEDM screen  3, turn off RP3 roughing from MEDM screen  4, disconnect metal hose to oily pump

after butterfly valve. This KF-45 O-ring seal should be kept clean 5, place/close  45 mm cover blanks at the end of the hose and and on the 5" nipple. 

    How to start: 1, remove blanks from  hose and nipple 2, reconnect roughing pump hose to RV1 nipple  3, turn on PR3  4, open V3  5, open RV1 by wrench to ~3/8

6, fine tune RV1 opening to 1 Torr/min

ESSENTIAL: one operator has to be present when oilly roughing pump is connected to the vac. envelope

  16413   Tue Oct 19 11:30:39 2021 KojiUpdateVACHow to vent TP1

I learned that TP1 was vented through the RGA room in the past. This can be done by opening VM2 and a manual valve ("needle valve")
I checked the setup and realized that this will vent RGA. But it is OK as long as we turns of the RGA during vent and bake it once TP1 is back.

Additional note:

- It'd be nice to take a scan for the current background level before the work.
- Turn RGA EM and filament off, let it cool down overnight. 
- Vent with clean N2 or clean air. (Normal operating temp ~80C is to minimize accumulation of H-C contaminations.)
- There is a manual switch and indicators on the top of the RGA amp. It has auto protection to turn filament off if the pressure increase over ~1e-5.

Attachment 1: Screen_Shot_2021-10-18_at_14.52.34.png
Screen_Shot_2021-10-18_at_14.52.34.png
  16418   Wed Oct 20 15:58:27 2021 KojiUpdateVACHow to vent TP1

Probably the hard disk of c0rga is dead. I'll follow up in this elog later today.

Looking at the log in /opt/rtcds/caltech/c1/scripts/RGA/logs , it seemed that the last RGA scan was Sept 2, 2021, the day when we had the disk full issue of chiara.
I could not login to c0rga from control machines.
I was not aware of the presence for c0rga until today, but I could locate it in the X arm.
The machine was not responding and it was rebooted, but could not restart. It made some knocking sound. I am afraid that the HDD failed.

I think we can
- prepare a replacement linux machine for the python scripts
or
- integrate it with c1vac

  11138   Thu Mar 12 19:54:31 2015 Q UpdateLSCHow to: PRY

Q doesn't like elogging, but he sent me this nice detailed email, so I'm copying it into the log:

I’ve locked the power recycled Y arm numerous times today, to try and find a usable AO recipe for the full locking.

Really, the “only" things that I think are different are the DC gain and pole frequency of the REFL11 CARM signal. The pole frequency can be simulated in the CM board (through the 1.4k:80 zero/pole pair), and the DC gain can be changed by changing the REFL1 gain on the CM board. 
 
The crossover frequency only depends on the relative gains of the digital and AO path, which is independent of these two factors, since they’re common to both. So, if we scale the common part appropriately, the same AO crossover procedure should work. I think.
 
So, concretely, I set up the gain in the CM_SLOW input filter so that 1x CM_SLOW_OUT -> CARM in the input matrix matched the ~120Hz UGF that we get with a gain 6 or 7 in the CARM FM. The REFL1 gain on the CM board was 0dB. 
 
I then normalized the signal by 1/Trmax. (i.e. I had TRY of ~3.3, so I put 0.30 in the normalization matrix), so that at full resonance, the slope should bee the same as with no normalizing. 
 
Then, with the Yarm locked on ALS through 1xCARM_A, PRY locked on REFL165, and at zero arm offset (TRY~3.3), I did the following
 
  • Transition the digital loop from 1xCARM_A (ALS) to 1xCARM_B (1xCM_SLOW_OUT)
  • Turn on CM_SLOW FM1 (whitening)
  • With CM board gains: 0db REFL1, 0dB AO, negative polarity, MC In2 gain=-32dB, turn on In2 on MC servo
  • Slowly ramp up MC In2 gain to -10dB (this starts pulling up the phase bubble of the loop)
  • Turn on the 300:80 filter in the CM_SLOW input filter (this provides a f^-2 slope around the crossover region)
  • Go from [AO,REFL1]=[-10,0] to [-4,+6] by stepping them together. (This brings you to a UGF of a few hundred Hz with tons of phase margin)
  • At this point, up the REFL1 gain to +12 or so. Turn on the :300 FM in the CM_SLOW input filter (This rolls off the digital part of the loop, makes the violin filters stop interfering with the shape)
  • UGF is now ~1kHz. Boosts can be turned on once the gain is ramped up high enough. 
 
The moral of the story is: if you set the REFL1 gain such that a +1.0 element in the input matrix gives you about the right UGF, then the above recipe should work, just with the REFL1 gains offset by your starting gain. (I suppose if you need a minus sign in the input matrix, that just means that the AO polarity needs to change too)
 
Every time the REFL1 gain is changed, the electronic offset changes, so I had to keep an eye on POY as a DC out-of-loop sensor and adjust the CM board voltage offset. For the full IFO, I think REFL55 would work for this. However, I hope that, since less REFL1 gain will be needed for the PRFPMI, the changes will be smaller….
 
Lastly, I think it’s good to keep the digital UGF at around 120, because the crossover steals some gain below the UGF, and you want to have some gain margin there. Turning off boosts may help with this too; I did all of this with all the normal CARM boosts on. 
 
Hope this made some sense!
  6185   Wed Jan 11 14:06:28 2012 Leo SingerHowToComputer Scripts / ProgramsHowTo for getting data from NDS off site

 This may or may not be general knowledge already, but Jamie and I added a HowTo explaining how to retrieve channel data from the frame builder via NDS, but off site on one's own computer.  See the Wiki page:

https://wiki-40m.ligo.caltech.edu/How_To/NDS

  13606   Mon Feb 5 14:11:01 2018 gautamUpdateALSHuge harmonics in ALS channels

I've been trying to setup for the THD measuremetn at the LSC rack for a couple of days now, but am plagued by a problem summarized in Attachment #1: there are huge harmonics present in the channel when I hook up the input to the whitening board D990694 to the output of a spare DAC channel at the LSC rack. Attachment #2 summarizes my setup. I've done the following checks in trying to debug this problem, but am no closer to solving it:

  • The problem is reminiscent of the one I experienced with the SR785 not too long ago - there the culprit was a switching power supply used for the Prologix GPIB-ethernet box.
  • Then I remembered sometime ago rana and i had identified the power supply for the Fibox at the LSC rack as a potential pollutant. But today, I confirmed that this power supply is not to blame, as I unplugged it from its powerstrip and the spectrum didn't change.
  • There are a couple of Sorensens in this LSC rack, from what it looks like, they supply power to a BIO interface box in the LSC rack. I thought we would want to keep this rack free of switching power supplies? Wasn't that the motivation behind keeping the (linear) power supplies for all the LSC rack electronics in a little separate rack along the east arm?
  • I confirmed that when the D990694 input is terminated, these harmonics are no longer present. 
  • I plugged the output of the SOS dewhite board to an oscilloscope - there is a ~20mVpp signal there even when the DAC output is set to 0, but this level seems too small to explain the ~1000 ct-pp signal that I was seeing. The whitening gains for these channels are set to 0dB.
  • I also looked at the signal in the time domain using DTT - indeed the peak-to-peak signal is a few thousand counts.
  • This isn't a problem with the particular input channel either - the behaviour can be reproduced with any of the 4 ALS input channels.

Am I missing something obvious here? I think it is impossible to do a THD measurement with the spectrum in this condition...

Attachment 1: ALSpowerlineHarmonics.pdf
ALSpowerlineHarmonics.pdf
Attachment 2: 2A1B3AC4-4059-416A-AD88-8AB0431D7A55.jpeg
2A1B3AC4-4059-416A-AD88-8AB0431D7A55.jpeg
  13608   Mon Feb 5 22:57:28 2018 gautamUpdateALSHuge harmonics in ALS channels

Did some quick additional checks to figure out what's going on here.

  1. The SOS/dewhite board for which I didn't have a DCC number is D000316. It has a single ended output.
  2. I confirmed that the origin of this noise has to do with the ground of the aforementioned D000316 - as mentioned in my previous elog, having one end of a BNC cable plugged into the whitening board D990694 and the other end terminated in 50ohms yields a clean spectrum. But making the ground of this terminator touch the ground of the SMA connector on the D000316 makes the harmonics show up.
  3. Confirmed that the problem exists when using either the SMA or the LEMO monitor output of these D000316 boards.

So either something is busted on this board (power regulating capacitor perhaps?), or we have some kind of ground loop between electronics in the same chassis (despite the D990694 being differential input receiving). Seems like further investigation is needed. Note that the D000316 just two boards over in the same Eurocrate chassis is responsible for driving our input steering mirror Tip-Tilt suspensions. I wonder if that board too is suffering from a similarly noisy ground?

Quote:
 

Am I missing something obvious here? I think it is impossible to do a THD measurement with the spectrum in this condition...

 

  7989   Sun Feb 3 13:20:02 2013 KojiSummaryGeneralHypothesis

Rana mentioned the possibility that the PR2 curvature makes the impact on the mode stability. Entry 7988
Here is the extended discussion.


Hypothesis:

The small but non-negligible curvatures of the TT mirrors made the recycling cavity unstable or nearly unstable.


Conclusion:

If the RoC of the TT mirrors are -600 m (convex), the cavity would be barely stable.
If the RoC of the TT mirrors are less than -550m, the horizontal modes start to be unstable.
Assumption that all of the TT mirrors are concave should be confirmed.


Fact (I): Cavity stability

- The folded PRMI showed the mode stability issue. (L=6.78m from Jenne's entry 7973)
- The folded PRM-PR2-PR3-flat mirror cavity also showed the similar mode issue. (L=4.34m)
- The unfolded PRM-PR2 cavity demonstrated stable cavity modes. (L=1.91m)

Fact (II): Incident angle

- PRM 0deg
- PR2 1.5deg
- PR3 41deg

Fact (III): Mirror curvature

- RoC of PRM (PRMU02): +122.1m (measured, concave), or +115.6m (measured by the vendor)
- RoC of G&H mirrors: -600m ~ -700m (measured, I suppose the negative number means convex) (Jenne's entry 7851)
  [Note that there is no measurement of the phase map for the PR2 mirror itself.]
- RoC of LaserOptik mirrors: -625m ~ -750m (measured, I suppose that the measurement shows the mirrors are convex.) (Jan's entry 7627 and 7638)

Let's assume that the TT mirrors are always convex and have a single number for the curvature radius, say RTT


Cavity mode calculation with Zach's arbcav

1) The unfolded PRM-PR2 cavity:

The cavity becomes unstable when 0 > RTT > -122m  (This is obvious from the g-factor calculation)
==> The measured RoC of the TT mirrors predicts the cavity is stable. (g=0.98, Transverse Mode Spacing 3.54MHz)

2) The folded PRM-PR2-PR3-flat mirror cavity:

The cavity becomes unstable when RTT < -550 m
==> The measured RoC of the TT mirrors (RTT ~ -600m) predicts the cavity is barely stable (g=0.997, TMS ~600kHz).

- The instability occurs much faster than the unfolded case.
- The horizontal mode hits unstable condition faster than the vertical mode.
- The astigmatism mainly comes from PR3.

3) The folded PRMI:

The cavity becomes unstable when RTT < -550 m
==> The measured RoC of the TT mirrors (RTT ~ -600m) predicts the cavity is barely stable. (g=0.995, TMS ~500kHz)

- The instability occurs with almost same condition as the case 2)

The calculation result for the PRMI with RTT of -600 m. The code was also attached.


Q&A:

Q. What is the difference between unfolded and folded?
A. For the unfolded case, the PR2 reflect the beam only once in a round-trip.
For the folded case, each TT mirror reflects the beam twice. Therefore the lens power by the mirror is doubled.

Q. Why the astigmatism mainly comes from PR3?
A. As the angle of incidence is much bigger than the others (41deg).

Q. Why the horizontal mode is more unstable than the vertical mode?
A. Off-axis reflection of a spherical mirror induces astigmatism. The effective curvature of the mirror in
the horizontal direction
is R / Cos(theta) (i.e. longer), while it is R Cos(theta) (i.e. shorter). Indeed, the vertical and horizontal ROCs are factor of 2 different
for the 45deg incidence.

Q. Why the stability criteria for the case 2) and 3) similar?
A. Probably, once the effective curvature of the PRM-PR2-PR3 becomes
negative when RTT < -550 m.

Q. You said the case 2 and 3 are barely stable. If the TMS is enough distant form the carrier, do we expect no problem?
A. Not really. As the cavity get close to the instability, the mode starts to be inflated and get highly astigmatic.
For the case 2), the waist radii are 5.0mm and 3.7mm for the horzontal and vertical, respectively.
For the case 3), they are 5.6mm and 4.1mm for the horzontal and vertical, respectively.
(Note: Nominally the waist radius is 3.1mm)

Q. What do you predict for the stability of the PRM-PR2-Flat_Mirror cavity?
A. It will be stable. The cavity is stable until
RTT becomes smaller than -240 m.

Q. If the TT mirrors are concave, will the cavity stable?
A. Yes. Particularly if PR3 is concave.

Q. Rana mentioned the possibility that the mirrors are deformed by too tight mounting of the mirror in a ring.
Does it impact the stability of the cavity?

A. Possible. If the curvature is marginal and the mounting emphasizes the curvature, it may meet the unstable condition.

Q. How can we avoid this instability issue?
A.
1. Use flatter mirrors or at least concave mirrors.

2. Smaller incident angle to avoid emphasis of the RoC in the horizontal direction
3. Use weaker squishing force for mounting of the mirrors
4. Flip the PR3 mirror in the mounting ring by accepting the compromise that the AR surface is in the cavity.

Attachment 1: mode_density_PRC.pdf
mode_density_PRC.pdf mode_density_PRC.pdf
Attachment 2: mode_density_PRC.zip
  7992   Mon Feb 4 15:06:56 2013 KojiSummaryGeneralHypothesis

Quote:

Q. How can we avoid this instability issue?
A.
1. Use flatter mirrors or at least concave mirrors.

2. Smaller incident angle to avoid emphasis of the RoC in the horizontal direction
3. Use weaker squishing force for mounting of the mirrors
4. Flip the PR3 mirror in the mounting ring by accepting the compromise that the AR surface is in the cavity.

 Another possibility is to use a ring heater to correct the curvature. I talked a bit with Aidan about this.

  6479   Tue Apr 3 12:42:19 2012 Mike J.UpdateComputersHysteresis Model

Here's my first hysteresis model in Simulink. It's based on the equation y=Amplitude*sin(frequency*t+phase)+(hysteresis/frequency2) as a solution to y''+frequency2*y+hysteresis=0. All values in the model are variables that should be manipulated through the model workspace or external code.

Attachment 1: hysteresis1.mdl
Model {
  Name			  "hysteresis1"
  Version		  7.6
  MdlSubVersion		  0
  GraphicalInterface {
    NumRootInports	    0
    NumRootOutports	    0
    ParameterArgumentNames  ""
    ComputedModelVersion    "1.9"
    NumModelReferences	    0
... 734 more lines ...
  6487   Thu Apr 5 01:07:08 2012 Mike J.UpdateComputersHysteresis Plots

Here are the hysteresis plots from the most recent model, which uses a modified harmonic oscillator equation y''=-(Frequency)2*y-Hysteresis.  The hysteresis constant seems to change both the amplitude and equilibrium point of the pendulums, which is akin to changing the length of a pendulum without changing the frequency. This does not make sense. Perhaps the hysteresis value should be moved to the "spring" constant for the pendula and not restricted to a position-biasing value.

SHO_hyst_plot.png

  1314   Mon Feb 16 22:58:51 2009 rana, yoichiConfigurationSUSHysteresis in SUS from Misalignments
WE wondered if there was some hysteresis in the SUS alignments. When we leave the optics misaligned for a
long time it seems to take awhile for the optic to settle down. Possibly, this is the slow deformation of
the wires or the clamps.

The attached PNG shows the plot of the bias sliders for a few days. You can see that we misalign some of the
optics much more than the others. This must be stopped.

Kakeru is going to use his nearly complete optical lever calibrations to quatify this by stepping the optics
around and measuring the effect in the optical lever. Of course, the misalignment steps will be too large to
catch on the OL, but he can calibrate the align-sliders into radians to handle this.
Attachment 1: a.png
a.png
  6142   Wed Dec 21 14:23:08 2011 ranaConfigurationSUSHysteresis in suspensions?

While discussing the suspension hysteresis measurements, Koji, Kiwamu, and I realized that the suspension wire standoff is aluminum, whereas the standoff for the LIGO LOS are using quartz.

Using a soft aluminum standoff is bad. The movement of the suspension will slowly wear the groove and produce opportunities for mechanical upconversion and hysteresis.

In fact, the wire standoff as well as the clamping block on the top should be made of sapphire or ruby to prevent any such wearing issues. Steve is hot on the case.

 

  6128   Sat Dec 17 01:56:16 2011 KojiSummarySUSHysteresis test

[Koji Kiwamu]

We wonder if the flakiness of MC2 comes from the suspension or not.

To test it, we are shaking all of the suspension biases +/-1.0 with a script.

The script is here:
/users/koji/111216/SUS_hysteresis.sh

For this test, we closed the mechanical shutter before the MC.

Also some amount of misalignment is anticipated.
Don't be surprised if you see nothing is working when you come to the lab in the weekend.

 

 -- EDIT by KI:
I found the ITMY watchdogs tripped around 2:40 AM and then re-engaged it.
  72   Tue Nov 6 18:18:15 2007 tobinConfigurationComputersI broke (and fixed) conlogger
It turns out that not only restart_conlogger, but also conlogger itself checks to see that it is running on the right machine. I had changed the restart_conlogger script to run on op340, but it would actually silently fail (because we cleverly redirect conlogger's output to /dev/null). Anyway, it's fixed now: I edited the conlogger source code where the hostname is hardcoded (blech!) and recompiled.

On another note, Andrey fixed the "su" command on op440m. It turns out that the GNU version, in /usr/local/bin, doesn't work, and was masking the (working) sun version in /bin. Andrey renamed the offending version as "su.backup".
  17106   Thu Aug 25 16:39:31 2022 CiciUpdateGeneralI have learned the absolute basics of github

I have now added code/data to my github repository. (it's the little victories)

  4525   Thu Apr 14 17:45:59 2011 BryanConfigurationGreen LockingI leave you with these messages...

OK… the Y-arm may be locked with green light, which was the goal, and this is all good but it's not yet awesome. Awesome would be locked and aligned properly and quiet and optimised. So...  in order to assist in increasing the awesome-osity, here are a few stream-of-consciousness thoughts and stuff I've noticed and haven't had time to fix/investigate or have otherwise had pointed out to me that may help...

 

Firstly, the beam is not aligned down the centre of the cavity. It's pretty good horizontally, but vertically it's too low by about 3/4->1cm on ETMY. The mirrors steering the beam into the cavity have no more vertical range left, so in order to get the beam higher the final two mirrors will have to be adjusted on the bench. Adding another mirror to create a square will give more range AND there will be less light lost due to off 45degree incident angles. When I tried this before I couldn't get the beam to return through the Faraday, but now the cavity is properly aligned this should not be a problem.

 

A side note on alignment - while setting cameras and viewports and things up, Steve noticed that one of the cables to one of the coils (UL) passes behind the ETMY. One of the biggest problems in getting the beam into the system to begin with was missing this cable. It doesn't fall directly into the beam path if the beam is well aligned to the cavity, but for initial alignment it obscures the beam - this may be a problem later for IR alignment.

 

Next, the final lambda/2 waveplate is not yet in the beam. This will only become a problem when it comes to beating the beams together at the vertex, but it WILL be a problem. Remember to put it in before trying to extract signals for full LSC cavity locking.

 

Speaking of components and suchlike things, the equipment for the green work was originally stored in 3 plastic boxes which were stored near the end of the X-arm. These boxes, minus the components now used to set up the Y-end, are now similarly stored near the end of the Y-arm.

 

Mechanical shutter - one needs to be installed on the Y-end just like the X-end. Wasn't necessary for initial locking, but necessary for remote control of the green light on/off.

 

Other control… the Universal PDH box isn't hooked up to the computers. Connections and such should be identical to the X-arm set-up, but someone who knows what they're doing should hook things up appropriately.

 

More control - haven't had a chance to optimise the locking and stability so the locking loop, while it appears to be fairly robust, isn't as quiet as we would like. There appears to be more AM coupling than we initially thought based on the Lightwave AM/PM measurements from before. It took a bit of fiddling with the modulation frequency to find a quiet point where the apparent AM effects don't prevent locking. 279kHz is the best point I've found so far. There is still a DC offset component in the feedback that prevents the gain being turned up - unity gain appears limited to about 1kHz maximum. Not sure whether this is due to an offset in the demod signal or from something in the electronics and haven't had time left to check it out properly yet. Again, be aware this may come back to bite you later.

 

Follow the bouncing spot - the Y-arm suspensions haven't been optimised for damping. I did a little bit of fiddling, but it definitely needs more work. I've roughly aligned the ETMY oplev since that seems to be the mass that's bouncing about most but a bit of work might not go amiss before trusting it to damp anything.

 

Think that's about all that springs to mind for now…

 

Thanks to everyone at the 40m lab for helping at various times and answering daft questions, like "Where do you keep your screwdrivers?" or "If I were a spectrum analyser, where would I be?" - it's been most enjoyable!

 
  4532   Fri Apr 15 13:43:23 2011 BryanConfigurationGreen LockingI leave you with these messages...

Y-end PDH electronics.

The transfer function of the Y-end universal PDH box:

Y_End_Electronics_TF.png

 

  1707   Sat Jun 27 02:48:09 2009 ClaraUpdatePEMI moved accelerometers and made some pretty pictures

I have been working on finding the best spots to put the accelerometer sets in order to best subtract out noise (seismometers next!). Here is a plot of what I've done so far:

80min_accel_0123.png

All of these were 80-minute samples. The dashed line is unfiltered, solid line filtered. So, Setup #1 looks the best so far, but I didn't leave it there very long, so perhaps it was just a really awesome 80 minutes. I've put the accelerometers back in the Setup #1 position to make sure that it is really better.

And, in case you can't intuitively figure out what configuration the accelerometers are in by such descriptive names, here are some helpful pictures. I didn't know about the digital cameras at first, so these are actually sketches from my notebook, which I helpfully labeled with the setup numbers, color-coded to match the graph above! Also, there are some real-life photographs of the current arrangement (Setup #1' if you forgot).

MC1_accel_sketch_side.png

MC1_accel_sketch_top.png

MC2_accel_sketch.png

Doesn't this one look kind of Quentin Blake-esque? (He illustrated for Roald Dahl.)

MC1acc_S01.JPG

This is the MC1 set.

MC2acc_S123.JPG

Guess which one this is!

  4998   Wed Jul 20 11:13:59 2011 Larisa ThorneUpdateelogI restarted the ELOG as it seemed to have crashed

 

  4872   Thu Jun 23 22:59:45 2011 kiwamuUpdateABSLI-P curve of LWE

 The I-P curve was measured again, but this time in a lower current range of 1.0-1.9 [A].

The plot below is the latest I-P curve.

IP_curve_small.png

(Decision)

Based on the measurement and some thoughts, I decided to run this laser at about 1.8 [A] which gives us a middle power of ~ 360 [mW].

In the 40m history, the laser had been driven at 2.4 [A] in years of approximately 2006-2009, so it's possible to run it at such a high power,

but on the other hand Steve suggested to run it with a smaller power such that the laser power doesn't degrade so fast.


(notes)

  The laser controller handed from PK (#4855) was used in this measurement.

The nominal current was tuned to be 1.8 [A] by tuning a potentiometer on the laser head (see page.18 on the manual of LWE).

There was a huge bump around 1.4 [A] and sudden power drop at 1.48 [A] although I don't know the reason.

Quote from #4842

The old days the NPRO ( inside the MOPA ) was running ~1.7A  500 mW

  4877   Fri Jun 24 07:49:23 2011 steveUpdateABSLI-P curve of LWE with serial numbers

Quote:

 The I-P curve was measured again, but this time in a lower current range of 1.0-1.9 [A].

Quote from #4842

The old days the NPRO ( inside the MOPA ) was running ~1.7A  500 mW

 Lightwave Laser Head M126-1064-700   sn238,  mounted on full size Al base and side heat sink on

Controller 125/126 Smart Supply   sn 201M

  4840   Mon Jun 20 11:38:49 2011 kiwamuUpdateABSLI-P curve of LightWave M126-1064-700

The I-P curve of the LightWave NPRO (M126-1064-700), which was taken out from the MOPA box, was measured. It looks healthy.

The output power can go up to about 1 W, but I guess we don't want it to run at a high power to avoid any further degradation since the laser is old.

 

IP_curve.png

 X-axis is the current read from the display of the controller. Y-axis is the output power, directly measured by Coherent PM10.

The measurement was done by changing the current from the controller.

Quote from #4832

 [Things to be done]

   - measure the beam profiles and power

   - get a laser controller, which will be dedicated for this laser, from Peter King

ELOG V3.1.3-