40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 96 of 339 Not logged in
ID Date Author Type Category Subject
10497   Fri Sep 12 00:28:04 2014 ericqUpdateLSCHoly sensitivity, Batman!

I took a quick measurement of the ALS stability, using POX and POY as out of loop sensors, using a CARM calibration line to line POX and POY up to the calibrated PHASE_OUT channels at 503Hz.

• X arm RMS ~1kHz
• Could use more low frequency suppression
• Y arm RMS ~200Hz

14573   Thu Apr 25 10:25:19 2019 gautamUpdateFrequency noise measurementHomodyne v Heterodyne

If I understand correctly, the Mach-Zehnder readout port power is only a function of the differential phase accumulated between the two interfering light beams. In the homodyne setup, this phase difference can come about because of either fiber length change OR laser frequency change. We cannot directly separate the two effects. Can you help me understand what advantage, if any, the heterodyne setup offers in this regard? Or is the point of going to heterodyne mainly for the feedback control, as there is presumably some easy way to combine the I and Q outputs of the heterodyne measurement to always produce an error signal that is a linear function of the differential phase, as opposed to the sin^2 in the free-running homodyne setup? What is the scheme for doing this operation in a high bandwidth way (i.e. what is supposed to happen to the demodulated outputs in Attachment #3 of your elog)? What is the advantage of the heterodyne scheme over applying temperature feedback to the NPRO with 0.5 Hz tracking bandwidth so that we always stay in the linear regime of the homodyne readout?

Also, what is the functional form of the curve labelled "Theory" in Attachment #2? How did you convert from voltage units in Attachment #1 to frequency units in Attachment #2? Does it make sense that you're apparently measuring laser frequency noise above 10 Hz? i.e. where do the "Dark Current Noise" and "Shot Noise" traces for the experiment lie relative to the blue curve in Attachment #2? Can you point to where the data is stored, and also add a photo of the setup?

14576   Thu Apr 25 15:47:54 2019 AnjaliUpdateFrequency noise measurementHomodyne v Heterodyne

My understanding is that the main advantage in going to the heterodyne scheme is that we can extract the frequecy noise information without worrying about locking to the linear region of MZI. Arctan of the ratio of the inphase and quadrature component will give us phase as a function of time, with a frequency offset. We need to to correct for this frequency offset. Then the frequency noise can be deduced. But still the frequency noise value extracted would have the contribution from both the frequency noise of the laser as well as from fiber length fluctuation. I have not understood the method of giving temperature feedback to the NPRO.I would like to discuss the same.

The functional form used for the curve labeled as theory is 5x104/f. The power spectral density (V2/Hz) of the the data in attachment #1 is found using the pwelch function in Matlab and square root of the same gives y axis in V/rtHz. From the experimental data, we get the value of Vmax and Vmin. To ride from Vmax to Vmin , the corrsponding phase change is pi. From this information, V/rad can be calculated. This value is then multiplied with 2*pi*time dealy to get the quantity in V/Hz. Dividing V/rtHz value with V/Hz value gives  y axis in Hz/rtHz. The calculated value of shot noise and dark current noise are way below (of the order of 10-4 Hz/rtHz) in this frequency range.

I forgor to take the picture of the setup at that time. Now Andrew has taken the fiber beam splitter back for his experiment. Attachment #1 shows the current view of the setup. The data from the previous trial is saved in /users/anjali/MZ/MZdata_20190417.hdf5

 Quote: If I understand correctly, the Mach-Zehnder readout port power is only a function of the differential phase accumulated between the two interfering light beams. In the homodyne setup, this phase difference can come about because of either fiber length change OR laser frequency change. We cannot directly separate the two effects. Can you help me understand what advantage, if any, the heterodyne setup offers in this regard? Or is the point of going to heterodyne mainly for the feedback control, as there is presumably some easy way to combine the I and Q outputs of the heterodyne measurement to always produce an error signal that is a linear function of the differential phase, as opposed to the sin^2 in the free-running homodyne setup? What is the scheme for doing this operation in a high bandwidth way (i.e. what is supposed to happen to the demodulated outputs in Attachment #3 of your elog)? What is the advantage of the heterodyne scheme over applying temperature feedback to the NPRO with 0.5 Hz tracking bandwidth so that we always stay in the linear regime of the homodyne readout? Also, what is the functional form of the curve labelled "Theory" in Attachment #2? How did you convert from voltage units in Attachment #1 to frequency units in Attachment #2? Does it make sense that you're apparently measuring laser frequency noise above 10 Hz? i.e. where do the "Dark Current Noise" and "Shot Noise" traces for the experiment lie relative to the blue curve in Attachment #2? Can you point to where the data is stored, and also add a photo of the setup?

Attachment 1: Experimental_setup.JPG
2952   Wed May 19 16:00:18 2010 JenneUpdateIOOHooray! We locked the MC! (and some other stuff)

[Jenne, Kevin]

We opened up the MC chambers again, and successfully got the MC locked today!  Hooray!  This meant that we could start doing other stuff....

First, we clamped the Faraday.  I used the dog clamps that Zach left wrapped in foil on the clean cart.  I checked with a card, and we were still getting the 00 mode through, and I couldn't see any clipping.  2 thumbs up to that.

Then we removed the weight that was on the OMC table, in the way of where MMT2 needs to go.  We checked the alignment of the MC, and it still locks on TEM00, but the spot looks pretty high on MC2 (looking at the TV view). We're going to have to relevel the table when we've got the MMT2 optic in the correct place.

We were going to start moving the PZT steering mirror from the BS table to the IOO table, place MMT2 on the OMC table, and put in a flat mirror on the BS table to get the beam out to the BS oplev table, but Steve kicked us out of the chambers because the particle count got crazy high.  It was ~25,000 which is way too high to be working in the chambers (according to Steve).  So we closed up for the day, and we'll carry on tomorrow.

Photos of the weight before we removed it from the OMC table, and a few pictures of the PZT connectors are on Picasa

2954   Wed May 19 22:28:05 2010 KojiUpdateIOOHooray! We locked the MC! (and some other stuff)

Good! What was the key?

The MC2 spot looks very high, but don't believe the TV image. Believe the result of script/A2L/A2L_MC2. What you are looking at is the comparison of the spot at the front surface and the OSEMs behind the mirror.

 Quote: [Jenne, Kevin] We opened up the MC chambers again, and successfully got the MC locked today!  Hooray!  This meant that we could start doing other stuff.... First, we clamped the Faraday.  I used the dog clamps that Zach left wrapped in foil on the clean cart.  I checked with a card, and we were still getting the 00 mode through, and I couldn't see any clipping.  2 thumbs up to that. Then we removed the weight that was on the OMC table, in the way of where MMT2 needs to go.  We checked the alignment of the MC, and it still locks on TEM00, but the spot looks pretty high on MC2 (looking at the TV view). We're going to have to relevel the table when we've got the MMT2 optic in the correct place. We were going to start moving the PZT steering mirror from the BS table to the IOO table, place MMT2 on the OMC table, and put in a flat mirror on the BS table to get the beam out to the BS oplev table, but Steve kicked us out of the chambers because the particle count got crazy high.  It was ~25,000 which is way too high to be working in the chambers (according to Steve).  So we closed up for the day, and we'll carry on tomorrow.   Photos of the weight before we removed it from the OMC table, and a few pictures of the PZT connectors are on Picasa.

11938   Wed Jan 20 02:53:18 2016 ericqUpdateLSCHopeful signs

[ericq, Gautam]

We gave DRFPMI locking a shot, with the ALS out-of-loop noises as attached. I figured the ALSX noise might be tolerable.

After the usual alignment pains, we got to DRMI holding while buzzing around resonance. Recall that we have not locked since Koji's repair of the LO levels in the IMC loop, so the proper AO gains are a little up in the air right now. There were hopeful indications of arm powers stabilizing, but we were not able to make it stick yet. This is perhaps consistent with the ALSX noise making things harder, but not neccesarily impossible; we assuredly still want to fix the current situation but perhaps we can still lock.

On a brighter note, I've only noticed one brief EPICS freeze all night. In addition, the wall StripTools seem totally contiuous since ~4pm, whereas I'm used to seeing some blocky shapes particularly in the seismic rainbow. Could this possibly mean that the old WiFi router was somehow involved in all this?

Attachment 1: 2016-01-20_ALSOOL.pdf
11941   Thu Jan 21 00:02:11 2016 KojiUpdateLSCHopeful signs

That's a good news. Only quantitative analysis will tell us if it is true or not.

Also we still want to analyze the traffic with the new switch.

 Quote: On a brighter note, I've only noticed one brief EPICS freeze all night. In addition, the wall StripTools seem totally contiuous since ~4pm, whereas I'm used to seeing some blocky shapes particularly in the seismic rainbow. Could this possibly mean that the old WiFi router was somehow involved in all this?

13647   Wed Feb 21 17:20:32 2018 johannesUpdateVACHornet gauge connected to DAQ.

I wired the six available BNC connectors on the front panel of the new XEND slow DAQ to physical Acromag channels. There were two unused ADC channels and eight DAC channels, of which I connected four. The following entries were added to /cvs/cds/caltech/target/c1auxex2/ETMXAUX2.db /caltech/target/c1auxex2/ETMXaux2.db

 Connector Acromag Channel EPICS Name In1 XT1221C #6 C1:Vac-CC1_HORNET_PRESSURE_VOLT In2 XT1221C #7 C1:PEM-SEIS_XARM_TEMP_MON C1:PEM-SEIS_EX_TEMP_MON Out1 XT1541B #4 C1:PEM-SEIS_XARM_TEMP_CTRL C1:PEM-SEIS_EX_TEMP_CTRL Out2 XT1541B #5 Not Assigned Out3 XT1541B #6 Not Assigned Out4 XT1541B #7 Not Assigned

C1:Vac-CC1_HORNET_PRESSURE_VOLT is converted to the additional soft channel C1:Vac-CC1_HORNET_PRESSURE in units of torr using the conversion  $10^{(\mathrm{Voltage}-10)}$ stated in the manual. A quick check showed that the resulting number and the displayed pressure on the vacuum gauge itself agree to ~1e-8 torr. Gautam added the new EPICS calc channel to the C0EDCU and restarted FB, now the data is being recorded.

Three of the output channels do not have a purpose yet, so their epics records were created but remain inactive for the time being.

Attachment 1: VacLog.png
4856   Wed Jun 22 17:35:35 2011 IshwitaUpdateGeneralHot air station

This is the new hot air station for the 40m lab.........

Attachment 1: P6220212.JPG
Attachment 2: P6220213.JPG
11634   Tue Sep 22 16:42:39 2015 ericqUpdateIOOHousekeeping

I've moved the OAF MC2 signal path to go directly from c1oaf to c1mcs, so that the LSC being ON/OFF doesn't interfere with the MC length seismic feedforward. Since the FB is currently down, I can't do a full test, but looking at monitor points in StripTool indicates it's working as intended.

I also cleaned up some LSC medm stuff; exposing the existing SRCL UGF servo, and removing a misleading arrow. This reminds me that I need to get calibration lockins back up and running...

15829   Sat Feb 20 16:20:33 2021 gautamUpdateGeneralHousekeeping + PRMI char

In prep to try some of these debugging steps, I did the following.

1. ndscope updated from 0.7.9 to 0.11.3 on rossa. I've been testing/assisting the development for a few months now and am happy with it, and like the new features (e.g. PDF export). v0.7.9 is still available on the system so we can revert whenever we want.
2. Arms locked on POX/POY, dither aligned to maximize TRX/TRY, normalization reset.
3. PRMI locked, dither aligned to maximize POPDC.
4. All vertex oplevs re-centered on their QPDs.

While working, I noticed that the annoying tip-tilt drift seems to be worse than it has been in the last few months. The IPPOS QPD is a good diagnostic to monitor stability of TT1/TT2. While trying to trend the data, I noticed that from ~31 Jan (Saturday night/Sunday morning local time), the IP-POS QPD segment data streams seem "frozen", see Attachment #1. This definitely predates the CDS crash on Feb 2. I confirmed that the beam was in fact incident on the IPPOS QPD, and at 1Y2/1Y3 that I was getting voltages going into the c1iscaux Acromag crate. All manner of soft reboots (eth1 network interface, modbusIOC service) didn't fix the problem, so I power cycled the acromag interface crate. This did the trick. I will take this opportunity to raise again the issue that we do not have a useful, reliable diagnsotic for the state of our Acromag systems. The problem seems to not have been with all the ADC cards inside the crate, as other slow ADC channels were reporting sensible numbers.

Anyways, now that the QPD is working again, you can see the drift in Attachment #2. I ran the dither alignment ~4 hours ago, and in the intervening time, the spot, which was previously centered on the AS camera CRT display, has almost drifted completely off (my rough calibration is that the spot has moved 5mm on the AS CCD camera). I was thinking we could try installing the two HAM-A coil drivers to control the TTs, this would allow us to rule out flaky electronics as the culprit, but I realize some custom cabling would be required, so maybe not worth the effort. The phenomenology of the drift make me suspect the electronics - hard for me to imagine that a mechanical creep would stop creeping after 3-4 hours? How would we explain the start of such a mechanical drift? On the other hand, the fact that the drift is almost solely in pitch lends support to the cause being mechanical. This would really hamper the locking efforts, the drift is on short enough timescales that I'd need to repeatedly go back and run the dither alignment between lock attempts - not the end of the world but costs ~5mins per lock attempt.

On to the actual tests: before testing the hardware, I locked the PRMI (no ETMs). In this configuration, I'm surprised to see that there is nearly perfect coherence between the MICH and PRCL error signals between 100Hz-1kHz 🤔 . When the AS55 demodulated signals are whitened prior to digitization (and then de-whitened digitally), the coherence structure changes. The electronics noise (measured with the PSL shutter closed) itself is uncorrelated (as it should be), and below the level of the two aforementioned spectra, so it is some actual signal I'm measuring there with the PRMI locked, and the coherence is on the light fields on the photodiode. So it would seem that I am just injecting a ton of AS55 sensing noise into the PRCL loop via the MICH->PRM LSC output matrix element. Weird. The light level on the AS55 photodiode has increased by ~2x after the September 2020 vent when we removed all the unused output optics and copper OMC. Nevertheless, the level isn't anywhere close to being high enough to saturate the ADC (confirmed by time domain signals in ndscope).

To get some insight into whether the whole RF system is messed up, I first locked the arm cavities with POX and POY as the error signals. Attachment #3 shows the spectra and coherence betweeen these two DoFs (and the dark noise levels for comparison). This is the kind of coherence profile I would expect - at frequencies where the loop gain isn't so high as to squish the cavity length noise (relative to laser frequency fluctuations), the coherence is high. Below 10 Hz, the coherence is lower than between 10-100 Hz because the OLG is high, and presumably, we are close to the sensing noise level. And above ~100 Hz, POX and POY photodiodes aren't sensing any actual relative frequency fluctuations between the arm length and laser frequency, so it's all just electronics noise, which should be incoherent.

The analogous plot for the PRMI lock is shown in Attachment #4. I guess this is telling me that the MICH sensing noise is getting injected into the PRCL error point between 100Hz-1kHz, where the REFL11 photodiode (=PRCL sensor) isn't dark noise limited, and so there is high coherence? I tuned the MICH-->PRM LSC output matrix element to minimize the height of a single frequency line driving the BS+PRM combo at ~313Hz in the PRCL error point.

All the spectra are in-loop, the loop gain has not been undone to refer this to free-running noise. The OLGs themselves looked fine to me from the usual DTT swept sine measurements, with ~100 Hz UGF.

Attachment 1: IPPOSdeat.pdf
Attachment 2: TTdrift.pdf
Attachment 3: POXnPOY.pdf
Attachment 4: PRMI.pdf
15831   Sun Feb 21 20:51:21 2021 ranaUpdateGeneralHousekeeping + PRMI char

I'm curious to see if the demod phase for MICH in REFL & AS chamges between thi simple Mcihelson and PRMI. IF there's a change, it could point to a PRCL/f2 mismatch.

But I would still bet on demod chain funniness.

15875   Sun Mar 7 15:26:10 2021 gautamUpdateLSCHousekeeping + more PRMI
1. Beam pointing into PMC was tweaked to improve transmission.
2. AS110 photodiode was re-installed on the AS table - I picked off 30% of the light going to the AS WFS using a beamsplitter and put it on the AS110 photodiode.
3. Adjusted ASDC whitening gain - we have been running nominally with +18dB, but after Sept 2020 vent, there is ~x3 amount of light incident on the AS55 RFPD (from which the ASDC signal is derived). I want to run the dither alignment servos that use this PD using the same settings as before, hence this adjustment.
4. Adjusted digital demod phases of POP22, POP110 and AS110 signals with the PRMI locked (sideband resonant). I want these to be useful to debug the PRMI. the phases were adjusted so that AS110_Q, POP22_I and POP110_I contain the signal (= sideband buildup) when the PRMI is locked.
5. Ran the actuator calibration routine for BS, ITMX and ITMY - i'll try and do the PRM and ETMs as well later.
6. With the PRMI locked (sidebands resonant), looked at the sideband power buildup. POP22 and POP110 remain stable, but there is some low frequency variation in the AS110_Q channel (but not the I channel, so this is really a time varying transmission of the f2 sideband to the dark port). What's that about? Also unsure about those abrupt jumps in the POP22/POP110 signals, see Attachment #1 (admittedly these are slow channels). I don't see any correlation in the MICH control signal.
7. Measured the loop shapes of the MICH (UGF ~90 degrees, PM~30 degrees) and PRCL (UGF~110 Hz, PM~30 degreees) loops - stability margins and loop UGFs seem reasonable to me.
8. Tried nulling the MICH-->PRCL coupling by adjusting the MICH-->PRM matrix element - as has been the case for a while, unable to do any better, and I can't null that line as we expect to be able to.
9. Not expecting to get anything sensible, but ran some sensing matrix lines (at the correct frequencies this time).
10. Tried locking the PRMI with MICH actuation to an ITM instead of the BS - I can realize the lock but the loop OLTF I measure with this configuration is very weird, needs more investigation. I may look into this later today evening.

I was also reminded today of the poor reliability of the LSC whitening electronics. Basically, there may be hidden saturations in all the channels that have a large DC value (e.g. the photodiode DC mon channels) due to the poor design of the cascaded gain stages. I was thinking about using the REFL DC channel to estimate the mode-matching into the PRC, but this has a couple of problems. Electronically, there may be some signal distortion due to the aforementioned problem. But in addition, optically, the estimation of mode-matching into the PRC by comparing REFL DC levels in single bounce off the PRM and the PRMI locked has the problem that the mode-matching is degenerate with the intra-cavity loss, which is of the same order as the mode mismatch (a percent or two I claiM). If Koji or someone else can implement the fix suggested by Hartmut for all the LSC whitening channels, that'd give us more faith in the signals. It may be less work than just replacing all the whitening filters with a better design (e.g. the aLIGO ISC whitening filter which implements the cascaded gain stages using single OP27s and more importantly has a 1 kohm series resistance with the input to the op amp (so the preceeding stage never has to drive > 10V/1kohms ~10mA of DC current) would presumably reduce distortion.

Attachment 1: PRMI_SBres.png
Attachment 2: MICH_act_calib.pdf
16994   Tue Jul 12 19:46:54 2022 PacoSummaryALSHow (not) to take NPRO PZT transfer function

[Paco, Deeksha, rana]

Quick elog for this evening:

• Rana disabled MC servo .
• Slow loop also got disengaged.
• AUX PSL beatnote is best taken with *free running lasers* since their relative frequency fluctuations are lowest than when locked to cavities.
• DFD may be better to get PZT transfer funcs, or get higher bandwidth phase meter.
• Multi instrument to be done with updated moku
• Deeksha will take care of updated moku
4005   Thu Dec 2 00:34:32 2010 ranaHowToLSCHow Does Cavity Locking Work (answered by Nikon)

https://nodus.ligo.caltech.edu:30889/gw.swf

Dr. Koji Arai and Nikon
3822   Fri Oct 29 11:29:29 2010 josephbUpdateCDSHow I broke the frame builder yesterday

Problem:

Long before Yuta came along and deleted daqd, I had done something to prevent the framebuilder code from running at all.

Cause:

Alex pointed out via e-mail that the corresponded to the inability to access certain frame files due to their permissions being only for root.

Turns out when I had run the code under the inittab, I forgot to make it use controls, instead of root (which is the default).  This later on caused problems for the code when it tried to access those files, resulting in the wierd errors we saw.

Solution:

Use chown to change the offending frame files back to controls.

Future:

Write a proper inittab script which uses "su controls" before running the daqd code.

9093   Mon Sep 2 03:51:14 2013 ranaHowToGeneralHow To Coil Cables
9097   Tue Sep 3 10:54:33 2013 SteveHowToGeneralHow To Coil Cables

 Quote:

If cables could dream?

This skill should be  mandatory for LIGOX graduates.

1589   Fri May 15 14:05:14 2009 DmassHowToComputersHow To: Crash the Elog

The Elog started crashing last night. It turns out I was the culprit, and whenever I tried to upload a certain 500kb .png picture, it would die. It has happened both when choosing "upload" of a picture, and when choosing "submit" after successfully uploading a picture. Both culprits were ~500kb .png files.

One terrible concern of mine is that the slow machines were rebooted at the power interruption.
Based on the elog entries, I assume they have not been burtrestored...

If this is true, they may cause some weird behaviors of the PSL/IOO electronics.

 Quote: Based on the elog entries, I assume they have not been burtrestored...

Do you know how to burtrestore or restart slow machines?

### Edit by Den: I did burtrestore of c1psl.snap from 2 days ago. Still slow machines behave not normal. For example, if I sweep C1:PSL-FSS_SLOWDC, SLOW monitor value does not change.

Quote:

 Quote: Based on the elog entries, I assume they have not been burtrestored...

Do you know how to burtrestore or restart slow machines?

### Edit by Den: I did burtrestore of c1psl.snap from 2 days ago. Still slow machines behave not normal. For example, if I sweep C1:PSL-FSS_SLOWDC, SLOW monitor value does not change.

Problems with Slow Machines?

12639   Wed Nov 23 17:48:16 2016 rana, kojiUpdateIOOHow bad is the McWFS?

Medium.

Previous elog entries on this:

10391   Thu Aug 14 19:23:25 2014 ranaHowToIOOHow do I set the FSS offset to make the PZT voltage start at the right place?

When the IMC locks, we want the FAST OUT of the TTFSS box to be close to zero volts. We also want the control signal from the MC Servo board to be close to 0 V. How to set this up?

With the IMC locked, we just servo the FSS input offset to minimize the MC board output :

ezcaservo -r C1:IOO-MC_FAST_MON -g 0.1 -t 10 C1:PSL-FSS_INOFFSET

I would have used "CDSUTILS", but that seems to have some sort of ridiculous bug where we can't have prefixes on channel names, even on the command line.

1911   Sat Aug 15 18:35:14 2009 ClaraFrogsComputersHow far back is complete data really saved? (or, is the cake a lie?)

I was told that, as of last weekend, we now have the capability to save full data for a month, whereas before it was something like 3 days. However, my attempts to get the data from the accidentally-shorted EW2 channel in the Guralp box have all been epic failures. My other data is okay, despite my not saving it for several days after it was recorded. So, my question is, how long can the data actually be saved, and when did the saving capability change?

7765   Fri Nov 30 09:59:53 2012 SteveHowToGeneralHow not to

Clean cabinet S15 doors were left open. You have to lock it up!

3733   Mon Oct 18 09:01:48 2010 steveHowToGeneralHow not to

This BNC cable is crying for help. Please do not do this to me.  It should be reported  to the  abused center.Throw this cable into the garbage now.

Attachment 1: P1060926.JPG
11459   Wed Jul 29 14:32:01 2015 SteveUpdateGeneralHow not to solder

Quote:

 Quote: Koji and Steve, The result: bad Guralp x-arm cable. I will swap the short cables tomorrow at the base.

Short 46" long cables at the base plates were swapped. Their solderings looked horrible.

This cable actually worked at 5-5-2015

Bad cable at ETMY station now.  The new cable should be a little bit longer ~52"

Koji could pull out easily 11 of the wires  from their socket.

Attachment 1: coldSoldering.jpg
11701   Tue Oct 20 11:24:29 2015 ericqHowToLSCHow to DRFPMI

# 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
Attachment 2: 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.

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
ssh username@lhocds.ligo-wa.caltech.edu
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
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.

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_alignmentcat 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 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) ...

ELOG V3.1.3-