40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 153 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectdown
  2117   Mon Oct 19 13:00:53 2009 MottUpdateGeneralPhase Noise Measurement

Here is the result for the measurement of the phase noise.  We used the marconi function generator and compared it with an Isomet AOM driver (model 232A-1), so this is really a measure of the relative phase between them.  We used a 5x gain and a frequency response of 13 Hz/V for the modulation.  In all the attached plots, the blue is the data and the red is the measurement limit (as determined by the noise in the SRS785).  Also note that the units on the yaxis of the Phase noise plot are incorrect, they should be dB/Sqrt(Hz), I will fix this and edit as soon as possible.

Attachment 1: PhaseNoiseWithError.jpg
PhaseNoiseWithError.jpg
Attachment 2: G.jpg
G.jpg
Attachment 3: PSD.jpg
PSD.jpg
  8211   Sat Mar 2 00:23:19 2013 ranaSummaryCOCPhase Maps measured of the ATF flat mirrors

I took the two 'flat' 2" mirrors over to Downs and Garilynn showed me how to measure them with the old Wyko machine.

The files are now loaded onto our Dropbox folder - analysis in process. From eyeball, it seems as if the RoCs are in the neighborhood of ~5 km, with the local perturbations giving ~10-15 km of curvature depending upon position (few nm of sage over ~1 cm scales)

Koji's matlab code should be able to give somewhat more quantitative answers...

Ed: Here you are. "0966" looks good. It has RoC of ~4km. "0997" has a big structure at the middle. The bump is 10nmPV (KA)

 

Attachment 1: 0966_0997_phasemap.pdf
0966_0997_phasemap.pdf 0966_0997_phasemap.pdf 0966_0997_phasemap.pdf 0966_0997_phasemap.pdf 0966_0997_phasemap.pdf 0966_0997_phasemap.pdf 0966_0997_phasemap.pdf 0966_0997_phasemap.pdf
  2588   Wed Feb 10 23:44:56 2010 KojiSummaryCOCPhase Map Analysis

In the middle of the last month, Kiwamu and I went to Garilynn's lab to measure the phase maps of the new ITMs and SRMs.

Analysis of the phase map data were posted on the svn directory:
https://nodus.ligo.caltech.edu:30889/svn/trunk/docs/upgrade08/cocdocs/PhaseMaps/

The screen shots and the plots were summarized in a PDF file. You can find it here:
http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_09/Main_Optics_Phase_Maps

The RoCs for all of the PRMs are turned out to be ~155m. This is out of the spec (142m+/-5m) although the actual effect is not understand well yet..

These RoCs are almost independent from the radus of the assumed gaussian beam.
In deed, I have checked the dependence of the RoC on the beam spot position, and it turned out that the RoCs vary only little.
(In the SRMU01 case, for example, it varies from 153.5m to 154.9m.)
The beam radius of 3mm was assumed. The RoCs were calculated 20x20mm region around the center of the mirror with a 2mm mesh.
 

Attachment 1: SRM01_HR_RoC_rad_15mm.png
SRM01_HR_RoC_rad_15mm.png
Attachment 2: SRM01_HR_RoC_scan.png
SRM01_HR_RoC_scan.png
  2955   Thu May 20 10:06:56 2010 AidanHowToPhase CameraPhase Camera- raw data video


 

  2951   Wed May 19 14:36:46 2010 AidanHowToPhase CameraPhase Camera algorithm and stuff

 I had a think about the algorithm we might use for the phase camera measurement. MATLAB has an fft function that will allow us to extract the data that we need with a single command.

We record a series of images from a camera and put them into a 3D array or movie, image_arr, where the array parameters are [x-position, y-position, time], i.e. a 2D slice is a single frame from the camera. Then we can do an FFT on that object with the syntax, f3D = fft(image_arr, [ ], 3), which only does the FFT on the temporal components. The resulting object is a 3D array where each 2D slice is an 2D array of amplitude and phase information across the image for a single temporal frequency of the movie.

So if we recorded a movie for 1s where the sample rate is 58Hz, then the 1st frame of f3D is just a DC image of the movie, the 2nd frame are the complex 1Hz components of the movie, etc all the way up to 29Hz. 

Suppose then that we have a image, part of which is being modulated, e.g. a chopper wheel rotating at 20 or 24Hz, or a laser beam profile which contains a 1kHz beat between a sideband and a reference beam. All we have to do is sample at at least twice that modulation frequency, run the command in MATLAB, and then we immediately get an image which contains the phase and magnitude information that we're interested in (in the appropriate 2D slice o the FFT).

As an example, I recorded 58 frames of data from a camera, sampling at 58Hz, which was looking at a spinning chopper wheel. There was a white sheet of paper behind the wheel which was illuminated from behind by a flashlight. The outer ring was chopping at 24Hz and the inner ring was chopping at 20Hz. I stuck all the images into the 3D array in MATLAB, did the transformation and picked out the DC, 20Hz and 24Hz signals. The results are shown in the attached PDFs which are:

  1. phase_camera_DC_comp.pdf - a single image from the camera and the DC component (zoomed in) of the FFT
  2. phase_camera_F1_comp.pdf - the magnitude and phase information of the 20Hz component of the FFT
  3. phase_camera_F2_comp.pdf - the magnitude and phase information of the 24Hz component of the FFT (this PDF contains a typo that says 25Hz).
  4. load_raw_data.m - the MATLAB routine that loads the saved data from the camera and does the FFT

You can, and I have, run the MATLAB engine from C directly. This will allow you to transfer the data from the camera to MATLAB directly in memory, rather than via the disk, but it does need proper memory allocation to avoid segmentation faults - that was too frustrating for me in the short term. In this case, the 58 frames were recorded to a file as a contiguous block of data which I then loaded into MATLAB, so it was slower than it might've otherwise been. Also the computer I was running this on was a bit of a clunker so it took a bit of time to do the FFT.

The data rate from the camera was 58fps x (1024 x 1024) pixels per frame x 2 bytes per pixel = 116MB per second. If we were to use this technique in a LIGO phase camera, where we want to measure a modulation which is around 1kHz, then we'd need a sample rate of at least 2kHz, so we're looking at at least a 30x reduction in the resolution. This is okay though - the original phase camera had only ~4000 spatial samples. So we could use, for instance, the Dalsa Falcon VGA300 HG which can give 2000 frames per second when the region of interest is limited to 64 pixels high.

Attachment 1: phase_camera_DC_comp.pdf
phase_camera_DC_comp.pdf
Attachment 2: phase_camera_F1_comp.pdf
phase_camera_F1_comp.pdf
Attachment 3: phase_camera_F2_comp.pdf
phase_camera_F2_comp.pdf
Attachment 4: load_raw_data.m
% load a raw data file into MATLAB

fid = fopen('phase_camera_data.dat');
n1 = 750;
A3D = ones(n1, n1, 58);

for jj = 1:58
    A = fread(fid, [1024, 1024], 'uint16');
    A3D(:,:,jj) = A((512-floor(n1/2)):(512-floor(n1/2))+n1-1, ...
                    (512-floor(n1/2)):(512-floor(n1/2))+n1-1);
... 64 more lines ...
  2725   Mon Mar 29 01:45:26 2010 daisukeConfigurationGeneralPeriscope version B for green laser ...

Here the design of the periscope for the 90 deg steering version is posted.

straight version http://nodus.ligo.caltech.edu:8080/40m/2709

Attachment 1: 40m_periscope_B.png
40m_periscope_B.png
Attachment 2: 40m_periscope_B_100329.pdf
40m_periscope_B_100329.pdf 40m_periscope_B_100329.pdf 40m_periscope_B_100329.pdf 40m_periscope_B_100329.pdf
Attachment 3: 40m_periscope_B_dwg_100329.zip
  2709   Wed Mar 24 12:40:25 2010 daisukeConfigurationGeneralPeriscope for green laser delivery from the BSC to PSL table

The periscope design for beam elevation of the green beams is posted. The design for the 90 deg steering version is also coming.

(2010-03-29: update drawings by daisuke)

90deg version: http://nodus.ligo.caltech.edu:8080/40m/2725

40m_periscope.png

Attachment 2: 40m_periscope_A_100329.pdf
40m_periscope_A_100329.pdf 40m_periscope_A_100329.pdf 40m_periscope_A_100329.pdf 40m_periscope_A_100329.pdf
Attachment 3: 40m_periscope_A_dwg_100329.zip
  2803   Fri Apr 16 17:46:54 2010 KojiUpdateVACPeeting mirrors aligned

Steve and Koji

We aligned the peeping mirrors to look at the surface of the ITMs.
They had been misligned as we move the positions of the ITMs, but now they are fine.

  479   Thu May 15 12:05:49 2008 josephbConfigurationPSLPath to PSL Position QPD
The 50/50 beamsplitter that was being used as the last turning mirror to the PSL Position QPD has been replaced with a Y1-1037-45-S plate. This turning mirror was also moved 4" farther along the beam path, so as to produce as small (few microwatts) transmission through the plate. The lensing optics were also shifted so as to maintain a focused beam on the photodiode. Lastly, the rotating ND filter was increased from 1.5 to 2.0 to reduce the incident power on the photodiode, since twice the power is now reaching it.

The small beam on transmission will be used by the digital cameras as a test beam.
  14157   Mon Aug 13 11:44:32 2018 gautamUpdateComputer Scripts / ProgramsPatch updates on nodus

Larry W said that some security issues were flagged on nodus. So I ran

sudo yum upgrade --exclude=elog-3.1.3-2.el7.x86_64

on nodus. The exclude flag is because there were some conflicts related to that particular package. Hopefully this has fixed the problem. It's been a while since the last update, which was in January of this year.

controls@nodus|~> sudo yum history
Loaded plugins: langpacks
ID     | Command line             | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
    29 | upgrade --exclude=elog-3 | 2018-08-13 11:36 | E, I, U        |  136 EE
    28 | install yum-utils        | 2018-08-13 11:31 | Update         |    1   
    27 | install nmap             | 2018-06-29 01:57 | Install        |    2   
    26 | install grace            | 2018-05-31 16:52 | Install        |   11   
    25 | install https://dl.fedor | 2018-05-31 16:51 | Install        |    1   
    24 | install perl-Digest-SHA1 | 2018-05-31 15:34 | Install        |    1   
    23 | install python-devel     | 2018-01-13 15:33 | Install        |    1   
    22 | install gcc              | 2018-01-13 15:32 | Install        |    6   
    21 | install git              | 2018-01-12 18:11 | Install        |    4   
    20 | update                   | 2018-01-12 18:01 | I, U           |   39   
    19 | install motif            | 2018-01-05 17:35 | Install        |    3   
    18 | install sendmail sendmai | 2017-12-03 05:11 | Install        |    6   
    17 | install vim              | 2017-11-21 18:12 | Install        |    3   
    16 | reinstall mod_dav_svn    | 2017-11-21 17:40 | Reinstall      |    1   
    15 | install mod_dav_svn      | 2017-11-21 17:39 | Install        |    1   
    14 | install subversion       | 2017-11-21 15:36 | Install        |    2   
    13 | -y install php           | 2017-11-20 22:15 | Install        |    4   
    12 | install links            | 2017-11-20 19:10 | Install        |    2   
    11 | install openssl098e.i686 | 2017-11-18 18:28 | Install        |    1   
    10 | install openssl-libs.i68 | 2017-11-18 18:26 | Install        |   11   
history list
  5807   Fri Nov 4 13:04:50 2011 ZachUpdateGreen LockingPassive summing box modifications

I spent some time the other day trying to diagnose the problem with the Y Arm universal PDH box (S/N 17), which Katrin has been unable to use for locking the green beam. As far as I can tell, there is nothing wrong with the box itself (though the weird TF behavior that Katrin noticed was not initially reproducible, so its cause may still be there).

I did notice that I was unable to generate a PDH error signal using the universal box. In this configuration, a summing circuit is needed to add the PZT modulation signal (fmod = 178875 Hz) in along with the feedback signal. To do this, Katrin was using a slightly different version of the passive summing box that Kiwamu built for the X Arm. I read this entry to understand how it is supposed to work and noticed that the "expected transfer functions" were not what the circuit actually does. I have talked to Kiwamu about it and he found that he posted the wrong TFs (he has the right ones on his computer). As you can see from the plot below, there is extra low passing that severely attenuates the modulation path to the PZT. In addition, there is a phase shift of ~-60 degrees, which is bad.

To combat this, I propose we simply change the resistor in the modulation path from 1M to 10k. This leaves the feedback path TF unchanged, and changes the mod path into a sort of bandpass filter for the modulation frequency. The fact that the phase is near zero at fmod means we don't have to come up with some way to phase shift the signal for demodulation. The attenuation level of ~-36 dB is also convenient: The ZAD-8 mixer wants 7 dBm, so, 10 dBm (FG) - 3 dB (splitter) - 36 dB (sumbox) = -25 dBm ~ 12 mV. This is roughly the desired PZT voltage level.

sum_circuit_new.png sumbox_TFs.png

  1518   Fri Apr 24 16:24:25 2009 robOmnistructureVACPaschen

In response to Steve's elog entry, and for 40m posterity, I provide the Paschen Curve.

Attachment 1: paschens.png
paschens.png
Attachment 2: paschenplot.m
% Paschen Curve plotting

% From http://home.earthlink.net/~jimlux/hv/paschen.htm

% Breakdown voltage:
% Vbreakdown = B * p * d / (C + ln( p * d))
% 
% Breakdown field strength:
% Ebreakdown = p * ( B / ( C + ln ( p * d)))
% 
... 38 more lines ...
  11358   Mon Jun 15 11:54:44 2015 ericqUpdateCDSParts not in SVN

I ran the following command to find which models/parts are not under version control, or have modifications not commited:

grep "mdl" $(cat models.txt) | awk '{print $NF}' | sort | uniq | xargs svn status

models.txt includes lines like "/opt/rtcds/caltech/c1/rtbuild/c1ass.log" for each running model. These are the build logs that detail every file being sourced. 

The resultant list is:

?       /opt/rtcds/userapps/release/cds/common/models/BLRMS_HIGHFREQ.mdl
C       /opt/rtcds/userapps/release/cds/common/models/rtdemod.mdl
M       /opt/rtcds/userapps/release/cds/common/models/SCHMITTTRIGGER.mdl
?       /opt/rtcds/userapps/release/isc/c1/models/blrms.mdl
?       /opt/rtcds/userapps/release/isc/c1/models/IQLOCK.mdl
?       /opt/rtcds/userapps/release/isc/c1/models/PHASEROT.mdl
?       /opt/rtcds/userapps/release/sus/c1/models/QPD_WHITE_CTRL_MUX.mdl

I will commit the uncommited c1 parts, and think about what to do about the rtdemod and SCHMITTRIGGER parts. 

Once I check out the latest revision of the userapps repo (in a seperate location), I will do something similar to look for models that have changed since the svn revision that is checked out in our running system. 

  14153   Fri Aug 10 11:29:39 2018 aaronConfigurationUpgradeParts list for BHD

I've started putting together a list of things we'll need to buy to do BHD readout. I'm still messing around with more detailed optics layouts, but wanted to get a list started here so people can let me know if I'm missing any big, obvious categories of goods.

My current plan makes minimal changes to the signal path going to the OMC, and tries to just get the LO beam into the OMC with minimal optics. I'm not thinking of any of the optics as suspended, and it requires several reflections of the LO beam, so probably this is not an excellent configuration, but it's a start for getting the parts list:

  1. My current thought is to use the MC reflection, the beam that heads from MC1 to MCR1, as the LO beam
    1. From MCR1, send the LO to a BS that directs it into an MMT, oriented along x (and lets us keep the MC refl PO)
    2. After the two MMT optics, the beam will be traveling along -x, and can be directed to a mirror that sends it towards -y to two steering mirrors that send it along -x then +x near the top of the table (perpendicular to the signal MMT.
    3. Then, send it to a PBS, which replaces the mirror directly after the signal MMT. This is where it combines 
  2. Beam is then sent to the steering mirrors to bring it into the OMC
  3. In parallel, the signal beam is going through the same path it has now, including the pickoff beam, with the one change that we need a HWP somewhere before the PBS, and the PBS replaces the mirror directly after the MMT (and needs to move a bit closer to have the beam properly directed)

I started making a layout of this scheme, but it's probably not going to work so I'm going to make a quick layout of this more major modification instead:

  1. Both the MCR beam and the AS beam come in about parallel. Send each to a PO mirror.
  2. The PO mirror directs both beams into parallel MMT aligned along x
  3. From the MMT, each is directed to a pair of steering mirrors located where the OMC MMT is located now
  4. From the steering mirrors go to the PBS that combines the signal and LO
  5. Then to two more steering mirrors to get into the OMC, which may be moved towards +x
  6. From the OMC go to the BHD PBS

What we need

Optics

  • HWP for just before the LO combines with the signal
  • HWP for just before the signal combines with the LO (is this necessary?)
  • PBS to replace OM5 (combines the LO and the signal)
  • Two MMT optics
  • Two piezo-driven TT optics for steering the LO to the PBS
  • One additional non-piezo optic for between the LOMMT and the LO-TTs
  • One additional BS to get the LO into the MMT (and to let us still have the PO)
  • -1 optic—we pick up one mirror that we replace with the PBS

Optomechanics

  • 2x HWP mounts
  • 1x PBS mount
  • 2x mounts for piezo-driven TT
  • 2x MMT optic mounts—I didn’t take a close enough look at these during the vent to know what we need here
  • 2x mounts for ordinary optics
  • 9x clamps for optics mounts (maybe fewer if some are on blocks)
  • 9x posts for optics mounts

Electronics

  • Additional TT driver
  • HV supply for the new TTs
  • Are the HWP actively controlled? We might need something to drive those?
  • Do we have enough DAC/ADC channels?

Questions

These are mostly just miscellaneous

  1. What of these optics need to be suspended? If we need suspensions on all of the LO optics, including the MMT, I’m not sure we’re going to be able to fit all of this on the table as I envision it…..
  2. What if anything can we put out of vacuum (HWP for example)?
  3. Do we actually need two MMT?
  14154   Fri Aug 10 16:43:50 2018 gautamConfigurationUpgradeParts list for BHD

Can we use the leakage beam from MMT2 on the OMC table as the LO beam? I can't find the spec for this optic, but the leakage beam was clearly visible on an IR card even with the IMC locked with 100 mW input power so presumably there's enough light there, and this is a cavity transmission beam which presumably has some HOM content filtered out.

Quote:

My current thought is to use the MC reflection, the beam that heads from MC1 to MCR1, as the LO beam

  14155   Sun Aug 12 10:59:34 2018 aaronConfigurationUpgradeParts list for BHD

That seems fine, I wasn't thinking of that beam. in that case could we just have a PBS directly behind MMT2 and send both beams to the same OMMT?

Alternatively we can move OM5 and the beam path OMPO-OMMTSM towards -y, then put the LO-OMMT parallel to the existing OMMT but displaced in +x... we'd have to move the existing OMC and BHD towards +x as well. 

Quote:

Can we use the leakage beam from MMT2 on the OMC table as the LO beam? I can't find the spec for this optic, but the leakage beam was clearly visible on an IR card even with the IMC locked with 100 mW input power so presumably there's enough light there, and this is a cavity transmission beam which presumably has some HOM content filtered out.

  14158   Mon Aug 13 17:20:07 2018 aaronConfigurationUpgradeParts list for BHD

I've attached the diagram of what I mean.

There are a couple caveats and changes that would have to be made that are not included in this diagram, because they would be made on different tables.

  1. I moved MMT2, which means the other MMT optics would have to be adjusted to accomodate this. I checked out the configuration on the BS table and this seems doable with a small rotation of MMT1 and maybe PJ2.
  2. I don't know the best way to get the OMC REFL beam out... thoughts?
  3. This diagram is kind of crappy after my edits, someone should tell me how to avoid collapsing all layers when I open these layout diagrams in inkscape, because I ended up editing the layout in Acrobat instead, where the lack of object grouping caused a bunch of the optics to lose one or two lines along the way.
  4. I didn't include all beam paths explicitly but can if this looks like a good configuration.
  5. The optic that picks off the transmission through MMT2 will need to move a bit, but there was a clamp in the way; this should be a minor change.
  6. The optic just before the OMC needs to be moved up a bit.
  7. The optic after the signal OMMT should be changed to a PBS and translated a bit; this is where the LO and signal beams will combine

Gautam also had some questions about the BHD/OMC timeline and plan. I feel somewhat on shaky ground with the answers, but figured I'd post them so I can be corrected once and for all.

  1. Is the plan really to use the current OMC setup to make a homodyne measurement? 
    1. I'm not sure where on the timeline the new OMC and BHD switchover are relative to each other. I have been imagining doing the swap to BHD before having a new OMC.
  2. I thought the current OMC resurrection plan was to do DC readout and not homodyne?
    1. I think the OMC resurrection plan is leading to DC readout, but when we switch over to BHD we'll be able to operate at the dark fringe. Is that right?
  3. Is it really possible to use our single OMC to clean both the LO and dark port beams? Isn't this the whole raging debate for A+?
    1. My understanding is yes, with the LO and DP in orthogonal polarizations. It's not clear to me why we expect to be able to do this while there is a debate for A+, perhaps our requirements are weaker. It is something I should calculate, I'll talk to Koji.
  4. A layout diagram would be really useful.
    1. Attached now.
  5. Where in the priority list does this come in?
    1. I am a leaf in the wind. I think this comes well after we have the OMC resurrected, we just want to get a sense for what parts we need so we can order them before the fiscal year closes.
Quote:

That seems fine, I wasn't thinking of that beam. in that case could we just have a PBS directly behind MMT2 and send both beams to the same OMMT?

Alternatively we can move OM5 and the beam path OMPO-OMMTSM towards -y, then put the LO-OMMT parallel to the existing OMMT but displaced in +x... we'd have to move the existing OMC and BHD towards +x as well. 

Quote:

Can we use the leakage beam from MMT2 on the OMC table as the LO beam? I can't find the spec for this optic, but the leakage beam was clearly visible on an IR card even with the IMC locked with 100 mW input power so presumably there's enough light there, and this is a cavity transmission beam which presumably has some HOM content filtered out.

 

Attachment 1: BHD_layout.pdf
BHD_layout.pdf
  13783   Tue Apr 24 10:10:43 2018 gautamUpdateComputer Scripts / ProgramsParticle swarm hyper parameter optimization

I'm copying and pasting Nikhil's email here as he was unable to login to the elog (but should now be able to in order to reply to any comments, and add more details about this test, motivation, methodology etc).

I did some post-processing after running the grid search. The following steps were carried out:

1) Selected those sets whose cost fun were less than a specific threshold (here 10000)

2) Next task was to see if the parameters of these good solutions had some pattern

3) I used a dimensionality reduction technique called t-SNE to project the 6 dimensional parameter space to 2 dim (for better visualization )

4) Made a scatter plot of these (see fig )

5) Used K-Means to find the clusters in this data

6) MarkerSize & Color reflect the cost fun. Bigger the marker size means better the solution.

7) Visual inspection implied cluster 5 had the best ranking points & more than any other cluster

8) These points had the following Parameter set: Workers {20,40}, SwarmSize {500}, MaxIter {500}, Self Adjustment {1}, Social Adjustment {1}, Tolerance {1e-3,1e-8} 

     See fig: for the box plot 

9) It looks like is a particular set of values rather than individual values that gives the best results.

 

Attachment 1: ClusterFminScaled.png
ClusterFminScaled.png
Attachment 2: ClusterID_5.png
ClusterID_5.png
  5134   Sun Aug 7 14:11:53 2011 JenneUpdatePEMParticle counts through the roof

[Jenne, Kiwamu]

While Kiwamu was finalizing the X green alignment, I started to prepare to remove the ETMY door, and begin checking out its OSEMs, etc, so we could start moving it to it's new place, and figure out why it's been wonky for a while.  I ran the particle counter, and we have a factor of ~5 more particles than normal.  Kiwamu and I agreed not to open ETMY.  Since we had briefly opened the IOO and Output Optics chambers to check the X green's position on the PSL table, we immediately shut those doors.  They were probably open for ~15 minutes or so.  (Yes Steve, we should have checked before opening any doors, but at least we remembered to check at all, and the doors were only open for a few minutes rather than for a few hours.)

I attach a 24hrs trend of the particle counts, for reference.  It looks like it's been a little high for a while, but today it's really dirty in the air.

Attachment 1: ParticleCount_High_7Aug2011.png
ParticleCount_High_7Aug2011.png
  1209   Wed Dec 31 22:59:40 2008 YoichiSummaryEnvironmentParticle counts going crazy
Yes it is a new year's eve, and a lot of crazy people are on Colorado to secure seats for the parade tomorrow.
They are burning woods to warm themselves. So smoky smell is floating around in the campus
and naturally the particle count is going up.

Actually at first I thought some building is on fire and called the security. Then they found
that it is the people on Colorado.

Now C1:PEM-count_half is 28400 and it is still climbing up.
  1211   Thu Jan 1 01:07:03 2009 YoichiSummaryEnvironmentParticle counts going crazy
I increased the fan speed of the PSL HEPA filter to the maximum.


Quote:
Yes it is a new year's eve, and a lot of crazy people are on Colorado to secure seats for the parade tomorrow.
They are burning woods to warm themselves. So smoky smell is floating around in the campus
and naturally the particle count is going up.

Actually at first I thought some building is on fire and called the security. Then they found
that it is the people on Colorado.

Now C1:PEM-count_half is 28400 and it is still climbing up.
  5140   Mon Aug 8 14:21:03 2011 steveUpdatePEMParticle counts controlled

Quote:

[Jenne, Kiwamu]

While Kiwamu was finalizing the X green alignment, I started to prepare to remove the ETMY door, and begin checking out its OSEMs, etc, so we could start moving it to it's new place, and figure out why it's been wonky for a while.  I ran the particle counter, and we have a factor of ~5 more particles than normal.  Kiwamu and I agreed not to open ETMY.  Since we had briefly opened the IOO and Output Optics chambers to check the X green's position on the PSL table, we immediately shut those doors.  They were probably open for ~15 minutes or so.  (Yes Steve, we should have checked before opening any doors, but at least we remembered to check at all, and the doors were only open for a few minutes rather than for a few hours.)

I attach a 24hrs trend of the particle counts, for reference.  It looks like it's been a little high for a while, but today it's really dirty in the air.

 The east end particle count is 155K for 0.3 micron and 15K for 0.5 micron  counts/cf min.  In order to minimize diffusion of dirt into the IFO we set up the mobile HEPA with CP Stat 100 tent.

This set up gives us practically ZERO inside the tent

Attachment 1: P1080149.JPG
P1080149.JPG
Attachment 2: P1080150.JPG
P1080150.JPG
  16416   Wed Oct 20 11:16:21 2021 AnchalSummaryPEMParticle counter setup near BS Chamber

I have placed a GT321 particle counter on top of the MC1/MC3 chamber next to the BS chamber. The serial cable is connected to c1psl computer on 1X2 using 2 usb extenders (blue in color) over the PSL enclosure and over the 1X1 rack.

The main serial communication script for this counter by Radhika is present in 40m/labutils/serial_com/gt321.py.

A 40m specific application script is present in the new git repo for 40m scripts, in 40m/scripts/PEM/particleCounter.py. Our plan is to slowly migrate the legacy scripts directory to this repo overtime. I've cloned this repo in the nfs shared directory at /opt/rtcds/caltech/c1/Git/40m/scripts which makes the scripts available at all computers and keep them upto date in all computers.

The particle counter script is running on c1psl through a systemd service, using service file 40m/scripts/PEM/particleCounter.service. Locally in c1psl, /etc/systemd/system/particleCounter.service is symbollically linked to the file in the file.

Following channels for particle counter needed to be created as I could not find any existing particle counter channels.

[C1:PEM-BS_PAR_CTS_0p3_UM]
[C1:PEM-BS_PAR_CTS_0p5_UM]
[C1:PEM-BS_PAR_CTS_1_UM]
[C1:PEM-BS_PAR_CTS_2_UM]
[C1:PEM-BS_PAR_CTS_5_UM]

These are created from 40m/softChansModbus/particleCountChans.db database file. Computer optimus is running a docker container to serve as EPICS server for such soft channels. To add or edit channels, one just need to add new database file or edit database files in thsi repo and on optimus do:

controls@optimus|~> sudo docker container restart softchansmodbus_SoftChans_1
softchansmodbus_SoftChans_1

that's it.

I've added the above channels to /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini to record them in framebuilder. Starting from 11:20 am Oct 20, 2021 PDT, the data on these channels is from BS chamber area. Currently the script is running continuosly, which means 0.3u particles are sampled every minute, 0.5u twice in 5 minutes and 1u, 2u, and 5u particles are sampled once in 5 minutes. We can reduce the sampling rate if this seems unncessary to us.

Attachment 1: PXL_20211020_183728734.jpg
PXL_20211020_183728734.jpg
  16420   Thu Oct 21 11:41:31 2021 AnchalSummaryPEMParticle counter setup near BS Chamber

The particle count channel names were changes yesterday to follow naming conventions used at the sites. Following are the new names:

C1:PEM-BS_DUST_300NM
C1:PEM-BS_DUST_500NM
C1:PEM-BS_DUST_1000NM
C1:PEM-BS_DUST_2000NM
C1:PEM-BS_DUST_5000NM
 

The legacy count channels are kept alive with C1:PEM-count_full copying C1:PEM-BS_DUST_1000NM channel and C1:PEM-count_half copying C1:PEM-BS_DUST_500NM channel.

Attachment one is the particle counter trend since 8:30 am morning today when the HVAC wokr started. Seems like there was some peak particle presence around 11 am. The particle counter even counted 8 counts of particles size above 5um!

 

Attachment 1: ParticleCountData20211021.pdf
ParticleCountData20211021.pdf
  16421   Thu Oct 21 15:22:35 2021 ranaSummaryPEMParticle counter setup near BS Chamber

SVG doesn't work in my browser(s). Can we use PDF as our standard for all graphics other than photos (PNG/JPG) ?

  16422   Thu Oct 21 15:24:35 2021 ranaSummaryPEMParticle counter setup near BS Chamber

rethinking what I said on Wednesday - its not a good idea to put the particle counter on a vac chamber with optics inside. The rumble from the air pump shows up in the acoustic noise of the interferometer. Let's look for a way to mount it near the BS chamber, but attached to something other than vacuum chambers and optical tables.

Quote:

I have placed a GT321 particle counter on top of the MC1/MC3 chamber next to the BS chamber.

 

  16423   Fri Oct 22 17:35:08 2021 Ian MacMillanSummaryPEMParticle counter setup near BS Chamber

I have done some reading about where would be the best place to put the particle counter. The ISO standard (14644-1:2015) for cleanrooms is one every 1000 m^2 so one for every 30m x 30m space. We should have the particle counter reasonably close to the open chamber and all the manufactures that I read about suggest a little more than 1 every 30x30m. We will have it much closer than this so it is nice to know that it should still get a good reading. They also suggest keeping it in the open and not tucked away which is a little obvious. I think the best spot is attached to the cable tray that is right above the door to the control room. This should put it out of the way and within about 5m of where we are working. I ordered some cables to route it over there last night so when they come in I can put it up there. 

  16750   Fri Apr 1 14:26:19 2022 Ian MacMillanSummaryPEMParticle counter setup near BS Chamber

I mounted the particle counter over the BS chamber attached to the cable tray as seen in Attachment 1. The signal cable runs through an active 30ft cable to the 1x2 rack. the wire is labeled and runs properly through the cable tray. The particle counter is plugged in at the power strip attached near the cable tray. The power cord is also labeled. 

I restarted the particle counter service in the c1psl computer in the /etc/systemd/system/ folder using the commands

sudo systemctl restart particleCounter
sudo systemctl status particleCounter

I cannged the usb hub assigned in the service file to ttyUSB0 which is what we saw the computer had named it.

Checking the channels from this elog show the same particle count as when testing with the buttons and checking the screen. It seems that the channels had been down but are now restarted.

Attachment 1: IMG_1407.jpg
IMG_1407.jpg
  16754   Sat Apr 2 15:46:13 2022 ranaSummaryPEMParticle counter setup near BS Chamber

nice - please update the particle counter page in the 40m wiki. Its probably years out of date.

Quote:

I mounted the particle counter over the BS chamber attached to the cable tray as seen in Attachment 1. The signal cable runs through an active 30ft cable to the 1x2 rack. the wire is labeled and runs properly through the cable tray. The particle counter is plugged in at the power strip attached near the cable tray. The power cord is also labeled. 

 

  949   Tue Sep 16 10:57:45 2008 YoichiConfigurationPEMParticle counter gain
Summary:
Since we reduced the integration time of the particle counter by a factor of 10, we had to add a gain of 10
to the EPICS channels C1:PEM-count_full and C1:PEM-count_half.
I asked Alex to change it and he did it. I forgot to ask him to change the gain of C1:PEM-count_half. So now only
C1:PEM-count_full has x10 gain.

Detail:
C1:PEM-count_full and C1:PEM-count_half are 'Soft Channel' records in the database (Pcount.db). The values are actually
written into the VAL fields directly by an SNL code Particle.o.
Particle.o reads data from the RS-232C port, to which the particle counter is connected. Then it parses the data and put values
into relevant EPICS channels using channel access. This means we cannot change the gain of the channels by modifying the
database file. For example, ASLO field does not have any effect when the value is directly written into the VAL field.
We had to modify the SNL code. Alex modified Particle.st and the new SNL object file is Particle_x10.o sitting in 
/cvs/cds/caltech/target/c1psl/. I modified seq.load so that c1psl loads Particle_x10.o when rebooted.
The source code for the old Particle.st can be found on lesath.ligo.caltech.edu in
/export/CDS/d/epics/apple/Caltech/40mVac/40mVacScipe/dev/src
I asked Alex to disclose the location of the source of the new code.
In order to compile the SNL code into an object file for Motorola CPU by ourselves, we have to call Dave Barker at LHO.
  12672   Wed Dec 7 11:52:48 2016 ericqUpdateIMCPartial IMC ringdowns

The transients are likely due to doppler interference due to the input laser frequency sloshing due to errant control signals after the IMC unlock. I performed a few "partial" ringdowns by reducing the power by about 80% while keeping the IMC servo locked. (Function generator at 0.5Vpp square wave, 0.25V offet. Turned IMC boosts off to increase the stable range of the servo).

I need to work out how to extract the loss from this, I think having a partial ringdown may change the calculations somewhat; the time constants in the trans and refl signals are not identical.

Thanks to Gautams nice setup, it was very easy to take these measurements. Thanks! Code and data attached.

Attachment 2: IMCpartial.zip
  12675   Thu Dec 8 19:01:21 2016 ranaUpdateIMCPartial IMC ringdowns

Mach Zucker on howto do Ringdowns:  https://dcc.ligo.org/LIGO-T900007

  15075   Thu Dec 5 01:54:39 2019 gautamUpdateLSCPartial CM board path engaged
  • The arm powers could be stabilized somewhat once the CM_SLOW path to MC2 was engaged.
  • However, I was never able to get the AO path to do anything good.
  • Took a bunch of CM board TFs, need to think about what I need to do differently to get this next bit to work.
  • An SR785 is sitting next to the LSC rack hooked up to the CM board. I also borrowed the GPIB unit from the AG4395 to grab data from said SR785.
  • One thing I noticed that the CARM_B (=CM_SLOW) and DARM_B (=AS55_Q) signals both had a DC offset, so maybe this is indicative of some DC offset in the PRMI 3f signals? Right now, I lock the PRMI without any offsets, and as I reduce the CARM offset, I can see the DC value of REFL11_I and AS55_Q changing significantly. To be investigated in tonight's locking.
Attachment 1: AOengaged.pdf
AOengaged.pdf
  16730   Tue Mar 15 18:45:12 2022 AnchalSummaryBHDPart X of BHR upgrade - BHDBS Path setup

[Paco, Anchal]

BS Chamber work

  • ASL was positioned in nominal place.
  • PR3 was moved to its nominal place from temprorary position.
  • BS Table was rebalanced
  • Earthquake stops were removed from all SOS from BS table (LO2, SR2, BS, PR3)

ITMY Chamber work

  • AS2, AS3, LO3, LO4, and BHDBS were positioned in the nominal place.
  • AS1 was moved to its nominal place from temporary position.
  • ITMY tbale was rebalanced
  • Earthquake stops were removed from all SOS from ITMY table (AS1, AS4, ITMY)
  16509   Wed Dec 15 16:11:38 2021 AnchalSummaryBHDPart VIII of BHR upgrade - Placed LO1

[Anchal, Yehonathan, Paco]


Today we opened ITMX chamber and removed the following optics and placed them in the Xend flow bench (see attachment 1):

  • POPM1
  • POPM2

Yehonathan brought his first SOS baby next to ITMX chamber. The suspension was carried by hands throughout. He gave me the suspension over the IMC beam tube from where I placed it on the table. I checked through the OSEMs and the face magnets were still on. I could not verify the side magnet but nothing seemed out of place.

I then moved LO1 near its planned place. I had to bolt it at 1 inch North and 0.5 inch West of its planned position because the side OSEM on ITMX is long and protrudes out of the base footprint. Even if it was small, the current layout would make the OSEM pins of the side OSEMs of ITMX and LO1 very near each other. So we can not place LO1 closer to ITMX from current position. This means the layout needs to be redesigned a bit for the modified position of LO1. I believe it will significantly shift and turn the beam from LO1 to LO2, so we might need to change the beam upstream from TT2 onwards. More discussion is required.

Unfortunately, what I thought was clicking photos was just changing modes between video and image mode, so I have no photos from today but only a video that I recorded in the end.


Photos: https://photos.app.goo.gl/23kpCknP3vz7YVrS

 

Attachment 1: signal-2021-12-15-161437.jpeg
signal-2021-12-15-161437.jpeg
  16510   Wed Dec 15 17:44:18 2021 KojiSummaryBHDPart VIII of BHR upgrade - Placed LO1

If ITMX already has another side magnet, we can migrate the side OSEM of ITMX to the other side. This way, the interference of the OSEMs can be avoided.

  16618   Mon Jan 24 18:53:09 2022 AnchalSummaryBHDPart VIII of BHR upgrade - LO2 placed and OSEMs tuned

I placed LO2 in its planned position in BS chamber, inserted the OSEMs, and tuned their position to halfway brightness. At the end of the work, I was able to damp the optic successfully. The full open (full brightness) OSEM ADC counts are:

UL 25743.  -> 12876
UR 27384. -> 13692
LL 25550. -> 12775
LR 27395 -> 13697
SD 28947 -> 14473

Today's OSEM tuning was relatively unhappening. I have only following two remarks:

  • BS table was 3 SOS near the East end and PRM is parked in the center, thus the table is very unevenly balanced. I had to use all available counter weights to make it flat near the LO2 suspension.
  • The side OSEM for LO2 is not exactly centered (probably due to table imbalance). I was able to balance the table to a point though that the side OSEM was responsive to full range and I was able to damp the optic.

Free swinging test set to trigger

LO2 is set to go through a free swinging test at 10 pm tonight. We have used this script (Git/40m/scripts/SUS/InMatCalc/freeSwing.py) reliably in the past so we expect no issues, it has a error catching block to restore all changes at the end of the test or if something goes wrong.

To access the test, on allegra, type:

tmux a -t LO2

Then you can kill the script if required by Ctrl-C, it will restore all changes while exiting.


Photos: https://photos.app.goo.gl/Ff3yGBprj9xgPbnLA

SUSPENSION STATUS UPDATED HERE

  16621   Tue Jan 25 10:55:02 2022 AnchalSummaryBHDPart VIII of BHR upgrade - LO2 input matrix diagonalization performed.

The free swinging test was successful. I ran the input matrix diagonalization code (/opt/rtcds/caltech/c1/Git/40m/scripts/SUS/InMAtCalc/sus_diagonalization.py) on the LO2 free-swinging data collected last night. The logfile and results are stored in /opt/rtcds/caltech/c1/Git/40m/scripts/SUS/InMAtCalc/LO2 directory. Attachment 1 shows the power spectral density of the DOF basis data (POS, PIT, YAW, SIDE) before and after the diagonalization. Attachment 2 shows the fitted peaks.


Free Swinging Resonances Peak Fits
  Resonant Frequency [Hz] Q A
POS 0.981 297 3967
PIT 0.677 202 1465
YAW 0.775 2434 1057
SIDE 1.001 244 4304

LO2 New Input Matrix
  UL UR LR LL SIDE
POS
0.46
1.237
1.094
0.318
0.98
PIT
1.091
0.252
-1.512
-0.672
-0.088
YAW
0.722
-1.014
-0.217
1.519
0.314
SIDE
-0.747
1.523
1.737
-0.534
3.134

The new matrix was loaded on LO2 input matrix and this resulted in no control loop oscillations at least. I'll compare the performance of the loops in future soon.

  16552   Thu Jan 6 21:04:41 2022 AnchalSummaryBHDPart VIII of BHR upgrade - LO1 OSEMs inserted

[Anchal, Koji] Part of elog: 40m/16549.

The magnets on the mirror face are arranged in a manner that the overall magnetic dipole moment is nullified faraway. Because of this, the coil output gains in all such optics need to have positive and negative signs in a butterfly mode pattern (eg. UL, LR: +ve and UR, LL: -ve).

In the particular case of LO1, we chose following coil output gains:

  COIL_GAIN
UL -1
UR 1
LR -1
LL 1
SD -1

This ensures that all damping gains have positive signs. Following damping gain values were chosen:

DOF C1:SUS-LO1_SUSXXX_GAIN
POS 5
PIT 2
YAW 0.2
SIDE 10

Having said that, this is a convention and we need to discuss more on what we want to set a convention (or follow a previous one if it exists). My discussion with Koji came up with the idea of fixing the motion response of an OSEM with respect to coil offset by balancing the coil gains across all optics and use same servo gains for all optics afterwards. But it is a complicated thought coming out of tired minds, needs more discussion.


Important notes for suspending the optics:

  • Do not insert the OSEMs fully. Leave all of the magnet out of the OSEMs before transportation.
  • Tighten the OSEMs completely while adjusting the height of the optic. Adjust height of OSEM holder plate if necessary.
  • Ensure the all cage screws are screwed tight completely.

Photos: https://photos.app.goo.gl/CJsS18vFwjo73Tzs5

  16450   Fri Nov 5 12:21:16 2021 AnchalSummaryBHDPart VI of BHR upgrade - Removal of ITMYC optics

Today I opened the ITMY chamber and removed the following optics and placed them in Xend flow bench (See attachment 1-3 for updated photograph):

  • OM1
  • OM2
  • ITMYOL1
  • ITMYOL2
  • SRMOL1
  • SRMOL2
  • POYM1
  • 3 counterweights one of which was double the height of others.

I also unscrewed SRM and parked it near the Western end of the table where no optical paths would intersect it. Later we will move it in place once the alignment of the rest of the optics has been done.

While doing this work, I found two unnoted things on the table:

  • One mirror mounted on a mount but not on a post was just sitting next to ITMY. I have removed this and placed it on Xend flow bench.
  • One horizontal razor or plate on the South end of table, mounted on what I thought looked like a picomotor. The motor was soldered to wires without any connector in-line, so I could not remove this. This is on the spot of AS4 and will need to be removed later.

Photos: https://photos.app.goo.gl/S5siAYguBM4UnKuf8

Attachment 1: XendFlowBenchLeftEnd.jpg
XendFlowBenchLeftEnd.jpg
Attachment 2: XendFlowBenchMiddle.jpg
XendFlowBenchMiddle.jpg
Attachment 3: XendFlowBenchRightEnd.jpg
XendFlowBenchRightEnd.jpg
  16789   Wed Apr 20 08:20:22 2022 PacoUpdateBHDPart V of BHR upgrade - PR2 weirdness

Yesterday, I tried tuning the PR2 damping gains by increasing the gain until the damping gave the ~5 oscillations (by watching the damped motion using StripTool, and keeping an eye on the PD var). I noticed that often when I changed the gain, some OSEM sensors shifted (gained an offset!!) and the PD var values changed, typically increasing at higher damping gains. I reverted the changes until the PD var looked "normal" again (~ 2 mV) but it is hard to imagine that the damping filters can have such a "DC" effect, given the shape comprises single zero at 0 Hz (and pole at 30 Hz).

  16792   Wed Apr 20 18:50:03 2022 KojiUpdateBHDPart V of BHR upgrade - PR2 weirdness

It seemed that it comes from the servo oscillation. This does not happen when the output limitters were set to be 100-ish. But even so the gains looked quite low.

I turned on the Cheby rool-offs for all the DOFs, and this allowed me to increase the damping gain A LOT.
The gains were 2~5 but now they are now 20-25 for the face OSEMs and 150 for SD.

The attached is the example of the damping when all the damping loops are on.

I think we need to tune the servo loops carefully for all the SUSs by actually looking at the openloop transfer functions rather than a personal feeling. => To Do

Attachment 1: Screenshot_2022-04-20_18-46-11.png
Screenshot_2022-04-20_18-46-11.png
  16788   Tue Apr 19 18:10:10 2022 PacoUpdateBHDPart V of BHR upgrade - POX11 path, LO path, and ITMX Oplev

[Yuta, Paco]

We set up POX11 beam path from ITMX chamber to the ITMX in-air table. To do this, we first identified the POX reflection on the ITMX chamber, and then steered the POXM1 (in the BSC) by hand until we cleared the viewport. We also checked that the POX beam is centered on POXM1.

We then decided to slide the LO1 YAW to clear the LO beam path, which was otherwise clipping on the PR2 SOS. The slider (DAC limited) range of -25000 counts was barely enough to clear the SOS comfortably and avoid hitting the POXM1. The LO beam is now hitting LO2 mirror, so LO alignment can proceed from BSC and ITMY chamber.

Finally, we aligned the input ITMX Oplev beam to ITMXOL2, then ITMX, then to ITMXOL2, and finally into the ITMX in-air optical table. We took some photos of the Oplev beam (see Attachments) to note their position.

By the end of in-vacuum work there was still some flashing in the arm cavities, but fine alignment is required.


After closing the ITMX Chamber, and BSC, we moved on to center the ITMXOL beam. We accomplished this by using two mirrors instead of one as was previously the case. This relaxed the angle of incidence a little, but we had to change the path and the position of the QPD. The QPD sum reads ~ 6600 counts versus the ~ >8000 counts it read right before the vent. One attempt at closing the OL loop, and the ITMX starting oscillating in YAW (PIT was ok), so we realized that maybe we flipped the order in which the OL1 / OL2 mirror were arranged and so the YAW loop needed to flip its sign. Indeed after changing the C1:SUS-ITMX_OL_YAW_GAIN from -6.0 to 6.0 the OL_YAW loop is stable.

Attachment 1: DJI_0167.JPG
DJI_0167.JPG
Attachment 2: DJI_0169.JPG
DJI_0169.JPG
Attachment 3: DJI_0168.JPG
DJI_0168.JPG
  16797   Thu Apr 21 16:49:01 2022 PacoUpdateBHDPart V of BHR upgrade - BS Oplev + LO1 offset

[Paco, JC, Yuta]

We aligned the BS oplev using the new BSOL mirror pair. The main change is now the AOI of the oplev on the BS is quite normal. The output beam in the in-air table was quite large (diverging?) so we had to place a short FL lens in front of the QPD.


Separately, I added the LO1 YAW offset of ~ -2500 counts (before the coil driver changes it was -24500 counts) and saw LO beam hitting LO2. This means the alignment of the LO beam can move downstream.

  16800   Thu Apr 21 18:42:47 2022 TegaUpdateBHDPart V of BHR upgrade - Align LO and AS beams to BHD BS

[Tega, Yuta, Paco]

We tried aligning the LO and AS beams on to the BHD beamsplitter. During the alignment process, we noticed that the damping loop for AS1 was not working. Paco drew our attention to the fact that the UR OSEM signal was alway close to zero, so we checked to ensure that the magnet was still within the OSEM recess and it looks OK. Next we checked the electrical connection at the interface between the copper OSEM cables to the blue in-vacuum flat cable and this too looks alright also. Since the AS1 coil driver was recently modified, it is possible we might find the problem there, so I'll ask Koji about this.


So Koji clarified that the coil driver board and SATAMP boards are different so we should connect this issue to the coil driver board.

  16591   Tue Jan 18 14:26:09 2022 PacoSummaryBHDPart IX of BHR upgrade - Placed remaining filters SR2, PR3, PR2

[Anchal, Paco]

Added input filters, input matrix, damping filters, output matrix, coil filters, and copy the state over from LO1 into SR2, PR2, PR3 screens in anticipation for damping.

  16559   Sat Jan 8 16:01:42 2022 PacoSummaryBHDPart IX of BHR upgrade - Placed LO2 filters

Added input filters, input matrix, damping filters, output matrix, coil filters, and copy the state over from ITMX into LO2 screen in anticipation for damping.

  16554   Fri Jan 7 16:17:42 2022 AnchalSummaryBHDPart IX of BHR upgrade - Placed AS1 and AS4 filters

[paco]

Added input filters, input matrix, damping filters, output matrix, coil filters, and copy the state over from LO1 into AS1 screen in anticipation for damping.

Added input filters, input matrix, damping filters, output matrix, coil filters, and copy the state over from LO1 into AS4 screen in anticipation for damping.

  16545   Thu Jan 6 11:54:20 2022 AnchalSummaryBHDPart IX of BHR upgrade - Placed AS1 and AS4

[Paco (Vacuum Work), Anchal]

Today we opened the ITMY Chamber and installed suspended AS1 and AS4 in their planned positions. In doing so, we removed the razor or plate mounted on a pico motor at the south end of the table (see 40m/16450). We needed to make way for AS4 to be installed.


Photos: https://photos.app.goo.gl/YP2ZZhQ3jip3Uhp5A


We need more dog clamps for installing the suspensions, we have used temporary clamps for now. However, knows where new C&B clamps are, please let us know.

  16729   Tue Mar 15 18:42:37 2022 AnchalSummaryBHDPart IX of BHR upgrade - AS1 resuspended and OSEMs tuned

http://nodus.ligo.caltech.edu:8080/40m/16722

http://nodus.ligo.caltech.edu:8080/40m/16716

ELOG V3.1.3-