40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 118 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  7192   Wed Aug 15 13:23:34 2012 LizSummaryComputer Scripts / ProgramsLast Weekly Update

Over the past week I have been continuing to finalize the daily summary pages, attempting to keep the total run time under half an hour so that they can be run frequently.  I have had many hang ups with the spectrograms and am currently using second trends (with this method, the entire script takes 15 minutes to run).  I also have a backup method that takes 3 minutes of data for every 12 minutes, but could not implement any interpolation correctly.  This might be a future focus, or the summary pages could be configured to run in parallel and full data for the spectrograms can be used.  I configured Steve's tab to include one page of images and one page of plots and fixed the scripts so that it corrects for daylight savings time (at the beginning of the running, the program prints 'DST' or 'Not DST').

Right now, I am focusing on making coherence plots in a spectrogram style (similar to the matlab 'coh_carpet' function) and a spectrogram depicting Gaussianity (similar to the plots made by the RayleighMonitor).  I have also been working on my  final paper and presentation.

  11584   Wed Sep 9 11:00:49 2015 IgnacioUpdateIOOLast Wiener MCL subtractions

On Thursday night (sorry for the late elog) I decided to give the MCL FF one more try. 

I first remeasured the actuator transfer function because previous measurements had poor coherence ~0.5 - 0.7  at 3 Hz. I did a sine swept to measure the TF. 

Raw transfer function:

The data is attached here: TF.zip

Then I made Wiener filters by fitting the transfer function data with coherence > 0.95 (on the left). Fitting all the data (on the right). Here are the filters:

 

The offline subtractions (high coh fit on left, all data fit on right). Notice the better IIR performance when all the TF data was fitted.

 

The online results: (these were aquired by taking five DTT measurements with 15 averages each and then taking the mean of these measurements)

 

And the subtraction performance:

 

Attachment 3: TF.zip
  11592   Sun Sep 13 13:26:00 2015 ranaUpdateIOOLast Wiener MCL subtractions

When making the Wiener filter OFF/ON comparisons, we want to use the median PSD estimates, not the mean (which is what pwelch gives you).

cf. Sujan's note and Evan's follow-up

The median will be less sensitive to the transients / gltiches and will show more improvement I think.

  11713   Mon Oct 26 18:10:38 2015 IgnacioUpdateIOOLast Wiener MCL subtractions

As per Eric's request, here is the code and TF measurement that was used to calculate the MC2 FF filter that is loaded in FM5. This filter module has the filter with the best subtraction performance that was achieved for MCL.

code_TF.zip

Attachment 1: code_TF.zip
  3620   Wed Sep 29 12:08:28 2010 josephb, alexSummaryCDSLast burt save of old controls

This is being recorded for posterity so we know where to look for the old controls settings.

The last good burt restore that was saved before turning off scipe25 aka c1dcuepics was on September 29, 11:07.

  7399   Mon Sep 17 20:23:31 2012 JenneUpdateGeneralLast of In-vac mirror photos taken

[Manasa, Jenne]

We took the last of the in-vac photos of mirrors today.  I'll post in the morning.

Tomorrow, I'll align the DRMI once more to check, and get IPPOS and IPANG out of the vacuum.  I'll  take a look at POX, POY and POP, but we may just have to cross our fingers and hope for the best on those ones.  They were pretty hard to get out of the vac during their initial alignment, since they're so weak.

Also, tomorrow morning Steve is going to try out our new light access connector!!!!  I'm so excited!

The goal is to put heavy doors on, on Wed, and start pumping Wed afternoon / Thurs evening.

  7400   Mon Sep 17 23:58:01 2012 ranaUpdateGeneralLast of In-vac mirror photos taken

 My hope is that the DRMI flashes will be bright enough to see on the PO beams. IF we get 10 mW through the Faraday, you should get some buildup when the carrier resonates in the DRMI.

If the recycling gain is 10 and the pickoff fraction is 100 ppm you ought to get ~10 uW on PO. How much of the recycling cavity power gets out of POP?

  7401   Tue Sep 18 11:53:12 2012 JenneUpdateGeneralLast of In-vac mirror photos taken

Quote:

[Manasa, Jenne]

We took the last of the in-vac photos of mirrors today.  I'll post in the morning.

Tomorrow, I'll align the DRMI once more to check, and get IPPOS and IPANG out of the vacuum.  I'll  take a look at POX, POY and POP, but we may just have to cross our fingers and hope for the best on those ones.  They were pretty hard to get out of the vac during their initial alignment, since they're so weak.

Also, tomorrow morning Steve is going to try out our new light access connector!!!!  I'm so excited!

The goal is to put heavy doors on, on Wed, and start pumping Wed afternoon / Thurs evening.

 The photos on the OMC table are particularly tricky, since the camera plus the 'bathroom' mirror add a lot of weight....even if the MC locked, the input beam would be completely different, so all of the beams would be wrong.

During some of the work on the BS table, ITMY was realigned to have its beam retro-reflect, since the weight of the camera plus mirror was shifting all of the suspended optics on the BS table.  ITMY was restored after that, for subsequent photos.

Attachment 1: AllPhotos_Sept2012.pdf
AllPhotos_Sept2012.pdf AllPhotos_Sept2012.pdf AllPhotos_Sept2012.pdf AllPhotos_Sept2012.pdf AllPhotos_Sept2012.pdf AllPhotos_Sept2012.pdf AllPhotos_Sept2012.pdf AllPhotos_Sept2012.pdf
  7406   Wed Sep 19 01:15:15 2012 JenneUpdateGeneralLast of In-vac mirror photos taken - NOT!

I'm making a separate entry to go along with this thread of photos...

Putting the camera and 'bathroom' mirror on any table pretty significantly changes the leveling of any table.  The mirror especially is very heavy, although the camera is not feather light.  We need to come up with a new plan for taking alignment-confirming photos without adding anything to the tables.  That, or we have to level the table between each camera shot.  Anyone who has ever leveled one of our in-vac tables should shudder in horror at idea #2, so we need to put some thought into idea #1 before our next vent.  Vent Czar - can you put this on the list, in addition to the REFL rearrangement stuff?

As a result of this, PZT2 needed to be reverted to the place it was before work began on Saturday (so that the beam goes through the 45 degree target without any extra stuff on the table).  This means, unfortunately, that all of the photos / still captures of optics after PZT2 are invalid.

  14893   Tue Sep 17 23:46:21 2019 KojiUpdateCDSLatch Enable Logic

[Koji Gautam]

We continued to check the latch logic. Today we found that latch.py didn't catch the change of LSB but did for MSB. We determined that this happens when the slider value is chaged between the polling for LSB and MSB.
SInce these two should always be related to a single gain value, latch.py was modified so.

Now we don't observe any logic error for ~100 gain transisitions (see attached).

Attachment 1: Screenshot_from_2019-09-17_23-39-35.png
Screenshot_from_2019-09-17_23-39-35.png
  3235   Fri Jul 16 13:05:48 2010 Kyung-haUpdateSUSLate update for 7/13 Tue (Tip Tilts)

[Jenne & Kyung-ha]

We suspended the mirror to one of the main frame with the ECD backplane we finished before. The hard task was to find the right balance for the mirror so that 1) it won't be tilted and 2) it'll be in the right position for the ECD backplanes so that the magnets attached to the mirror holder would be in the very center of each ECD holes. We used optical lever laser (red He/Ne) to check the balance of the mirror. We tried to use the jig for the mirror holder clamps but because of the size difference, we couldn't use it at all. (Since the magnets are very heavy, we thought the wire being not perfectly centered might work better. However, the jig dimension was way too different that the wire ended up in the middle of one of the holes.) Since there was no other clever way to attach the wire in the right position, we just tried to be as center/accurate as possible. After attaching wire to that mirror holder clamps, we hanged it to the frame. Again, we couldn't find any other accurate way to find the center so we held the wire and tried to adjust the mirror height as accurate as possible so that it can be in the right position in respect to ECD backplane and not be tilted at the same time. However, when we hanged the mirror, it was still tilted.. So we adjusted the mirror tilt using the mirror holder clamps. Since the holes on the clamps were ellipse shapes, we could adjust the position of the clamps a little bit. When we adjust the clamps, we started to tighten the screws when the mirror is NOT in the perfect position since the tightening up part changes the mirror angle anyways. Luckily, when we tightened up the last screw, the mirror was in the perfect position! After that, we poked the mirror several times to make sure that it comes back to the same place.

Amazingly, we could finish this whole hanging/adjusting process in about 30 mins! :D (Jan said it's because of his amazing moral support. :P Maybe he'll be there to support us everytime we work on the mirrors?)

  4893   Tue Jun 28 02:11:47 2011 JenneUpdateLockingLatest MICH noise budget

I have measured / calculated the latest MICH noise budget.  It doesn't really look all that stellar.

MICH_noise_budget_as_of_28June2011.png

As you can see, we are nowhere near being shot noise limited, since there's a huge discrepancy between all of the measured spectra and the teal Shot Noise line. 

One possible suspect is that the analog whitening filters weren't on when I took my measurements.  I didn't actually check to ensure that they were on, so they might not have been.  Right now we're limited by electronics and other boring noises, so I need to make sure we're limited by the noise of the diode itself (we don't have enough light in the IFO to actually be shot noise limited since that takes 2.5mA for AS55 and I only have 1.1mA, but we should be ~within a factor of 2ish).

  5035   Tue Jul 26 03:15:52 2011 JenneUpdateLockingLatest MICH noise budget

[Jenne, Rana]

We had another look at the MICH noise budget tonight. Rana has verified that my techniques / math aren't too ridiculous. 

In the first attachment, you'll notice that the MICH noise is waay above the shot noise of 1mW on the beam splitter.  We don't know why.  One problem is that the modulation depth of the 55MHz is too low by ~a factor of 10.  Kiwamu and his magical resonant circuit are working on fixing this.  This will not, however, fix the huge discrepancy here.  More investigation and meditation is required!  For this measurement, the whitening gain of AS55 was set to 42dB for both I and Q.

In the 2nd attachment, the PSL shutter is closed, so all of these are dark measurements of AS55.  (The input matrix on the LSC screen is AS55Q * 1 -> MICH_IN1, so they're the same).  All we've done is change the whitening gain before the ADC.  For 0dB and 9dB, you can see that the low freq noise didn't change - here we're still limited by the ADC noise.  With 21dB and 42dB we're clear of the ADC, so either is fine.  Unfortunately, the high freq stuff when the loop is on matches up with the high freq part of the dark noise, so that's part of the problem....

Attachment 1: MICHnoise_shotNoise_25July2011.pdf
MICHnoise_shotNoise_25July2011.pdf
Attachment 2: MICH_darkNoise_whiteningGainChanging_25July2011.pdf
MICH_darkNoise_whiteningGainChanging_25July2011.pdf
  10014   Mon Jun 9 20:07:53 2014 nicolasHowToComputer Scripts / ProgramsLatex (math) in the elog

\text{\LaTeX} in the elog

One feature that has been sorely missing in the elog has been the ability to easily add mathematical symbols. Here is an imperfect solution.

There is a browser plugin available for firefox, safari and chrome that allow you to add “markdown” formatting to any rich text input box in the browser. One feature of markdown is latex math formulae.

http://markdown-here.com/

The way it works is you type some latex formatted math text in between dollar signs, click the button in your browser, and it converts them to rendered images.

So this

$E=mc^2.$

becomes this

E=mc^2.

Some drawbacks:

The images are actually rendered through a google service, so if that service changes or goes down, the images won’t render, however the HTML source still contains the source string.
The size of formulae are not really matched to the text.
Going back and forth between rendered and unrendered can lose changes (if you make changes after rendering).

Bonus features:

It also works in Gmail!
You can do code highlighting:

#!/bin/bash   ### this is a comment  PATH=$PATH:/home/user/path    echo "How cool is this?" 

EDIT: it looks like the code highlighting is sort of broken :-(.

  3027   Tue Jun 1 18:39:59 2010 NancyUpdate Lead spheres for the seismographs

 

the lead spheres that were placed below the granite slab have been flattened by hammering to have lesser degree of wobbling of the slab.

the height of each piece, and the flatness of their surfaces was checked by placing another slab over them and checking by the spirit level.

P6010170.JPG

P6010166.JPG

P6010164.JPG

 

  16717   Wed Mar 9 10:23:28 2022 JordanUpdateVACLeak Testing of New Manual Gate Valve - Attempt #1

Jordan, Chub, Paco

Chub and I went into the lab this morning to leak check the new gate valve after pumping over the weekend. This would be done through the RGA and spraying helium around the newly installed flanges. The RGA is set to monitor the partial pressure of helium versus time and we visually watch for any spikes in pressure to indicate an air leak.

So, I mistakenly thought the gate valve was opened and both sides were being pumped on, this was not the case. The vavle was closed so there was a pressure differential whenI turned the handle it tripped the interlocks and closed V4. I closed VM3 to the RGA volume to prevent the filament from being damaged.

Then the medm screen for the vac controls started flashing rapidly, I closed the window and reopened the controls to find all the panels were white, but we could still see the read only vac screen. So Paco restarted c1vac and the controls were restored. V7 closed, but was then reopened.

We now need to restart pumping with the odd pressure differentials between V4 and VM3.

Plan

- TP2 turned off along with the AUX pump

- VM3 opened to vent RGA volume (RGA turned off, filament cooled)

- Open the manual vent screw on TP1 to bring the RGA+TP1 volume back to atmosphere, now no pressure diff. on V4

- Open V4, restart AUX pump to rough out the volume

- Connect RP1/3 line to the pump scroll, turn on RP1/3 RGA+TP1 volume went to mtorr

- Slowly open the manual gate valve

- Connect AUX pump to TP2 and rough out

- Restart TP2, once at speed open V4, close V6 and turn off RP1/3

Now we are pumping on the RGA/TP1 volume with TP2, leak check attempt #2 will happen tomorrow morning

  16721   Thu Mar 10 09:39:59 2022 JordanUpdateVACLeak Testing of New Manual Gate Valve - Attempt #2

This morning Chub and I leak checked the manual gate valve with the RGA and helium. There was no change in the helium partial pressure while spraying helium around the flanges, all looks good.

 

I also took a 100 AMU analog scan, after the filament had warmed up overnight and the plot was quite noisy even with the lowest scan speed. I recommend this unit go back to SRS for a filament replacement/recalibration. I am worried yesterday's "vent" of the RGA volume may have burned the filament. See the comparison of yesterday's analog scan to today's below.

Attachment 1: 3-09-2022.PNG
3-09-2022.PNG
Attachment 2: 3-10-2022.PNG
3-10-2022.PNG
  14673   Thu Jun 13 22:46:41 2019 KojiUpdateIOOLeft IMC at the intermediate gains

SURFS want some locking of IMC for camera adjustment.

So I left the IMC with intermediate gains so that it keeps locking and unlocking.

VCO (overall) iMC gain of -32, FSS common gain 3, and the FAST gain 20. I believe MC2tickle is ON too.

  1799   Mon Jul 27 19:55:19 2009 KojiHowToIOOLens selection: plano-convex? or bi-convex?

Q. When should we use plano-convex lenses, and when should we use bi-convex?

As I had the same question from Jenne and Dmass in a month,
I just like to introduce a good summary about it.
Lens selection guide (Newport)
http://www.newport.com/Lens-Selection-Guide/140908/1033/catalog.aspx

At a first order, they have the same function.
Abberation (= non-ideal behavior of the lens) is the matter.

  13000   Mon May 22 10:15:14 2017 jigyasaSummarytelescope designLens tubes and object distances

Since the f numbers of the lenses in the proposed design with biconvex lenses are a little less than 5 and the conjugate ratio(that is the ratio of object to image distance) is greater than 5, I explored the use of plano convex lenses, but with the same focal lengths, the accessible u-v range is restricted with the planoconvex rather than biconvex lenses.
On Friday, I had a discussion with Gautam and Steve about the hardware that is the cylindrical enclosures for the camera and the telescope and we examined two such aluminum cylindrical enclosures. One of them was the one being currently employed for the cameras. The dimensions were measured and the length was found to be 8’’ and an outer diameter of 26 cm within an error of 0.5 cm.
The other enclosure was longer with a length of 52 cm(±0.5 cm), outer diameter of 10”(±0.1”) and an inner diameter of 23.7cm(±0.1cm). Pictures of these enclosures are attached.
Both of these enclosures have internal optical rail to mount the camera and the telescope system. Depending on the weight of the telescope system(that includes the weight of the slotted lens tubes, the lenses), it might be more efficient to clamp the telescope system itself on the rails with the low weight camera mounted on the lens tube.
I also went around to get an idea of distance of the GigE from the test masses. This was just a step to verify if the object distances were really in the ranges being taken into consideration, that is between 1500 and 2500 mm. I also tried to cross check the measurements with the CAD drawing of the 40m. However, as I have been informed, the distances in the CAD version are not updated.

The distances from the optic to the CCD detector would range from around 75.1 cm for MC2, 94.01 cm for ITMX, 97.21 cm for ETMX, 117.19 cm for ITMY and 88.463 cm for ETMY. The illuminator for the ETMY was disconnected, so Gautam helped me access the manual lamp control to enable me to take measurements.
The values for ETMX, MC2 and ITMY are subject to an error of ±1’’. Due to a lot of obstructions, the values for ETMY and ITMX may be subject to a lot more error. Even so, these distances are clearly less than 2 meters, prompting me to run the simulations again and verify that the chosen combination is still useful.

As for the slotted lens tubes to mount the 2” lenses, the following options are available on the Thorlabs catalog. CVI and Edmunds do not seem to offer much of the stackable lens tubes.

SM2L30C is a lens tube onto which the optic can be mounted without the need of a spanner wrench. It also has a length of 3”. However, it has a rotatable slip shield which can be rotated open as and when the access to optic is required. However, there might be a slight compromise with rigidity here.

SM2L30 is a lens tube with internal thread depth of 3”, the optic can be mounted using spanner wrench and a retainer ring. The optic cannot be accessed from both ends of the tube here.
SM2M30 is a lens tube with no external threads, therefore lens tube couplers would be required to stack the tubes. The optic is accessible from both ends here though.

Considering the merits and demerits of all these available options, the use of SM2L30 might be considered as it provides a quick and efficient way of stacking multiple lens tubes. As for accessing the optic from both sides, using multiple tubes helps overcome the problem and still ensures that we are able to access a number of separation distances as per requirement.
Thorlabs also offers an internal C to external SM2 adapter so that the lens tube could be fixed onto the C mount of the camera. 

I would be examining the use of 1" diameter lenses for the eyepiece as suggested by Rana, as that might give us more flexibility. 

Attachment 1: Pictures1.pdf
Pictures1.pdf Pictures1.pdf Pictures1.pdf Pictures1.pdf
  1069   Wed Oct 22 17:48:58 2008 YoichiUpdateGeneralLenses for focusing the optical lever laser (Re:divergence of He Ne 1035P)
Steve had difficulty in finding lenses for focusing the HeNe laser for the ITM op-lev.
Following his measurement of the beam divergence, I did some calculation to find a suitable set of lenses and positions.

First, I fitted Steve's data to get the waist size and location of the new HeNe.
The first plot shows the fitting result.
The size of the waist is 0.3mm at -367mm from the laser output (i.e. inside the laser).
(I only used horizontal beam size data.)

Then using the obtained beam parameter, I calculated the propagation of the beam through two lenses.
After playing with the focal length and location of the lenses, I found that with parameters {f1=-0.125m, f2=0.2m, d1=0.2m, d2=0.1m} we get about 1mm beam at the QPD (about 4m away from the laser). f1 and f2 are the focal lengths of the lenses, d1 is the distance from the laser to the first lens and d2 is the distance between the two lenses.
The second plot shows the beam size as a function of the distance from the laser.

The Mathematica notebook used to plot the beam propagation is attached.
By running it on Mathematica 6, you can dynamically change the parameters (focal lengths and locations) by sliders, and the plot (like the one shown in the second attachment) updates in real time. It is cool. Please try it.



Quote:
The ITM oplevs laser diodes are noisy.
They will be replaced by JDS 1035P
SN T8093307 was measured with the beamscanner.
This will able us to calculate the right lenses to get a small beam on the qpd.

**
The first column is distance from the front face of the laser in cm.
The second column is beam diameter in the horizontal direction in microns.
The third column is the beam diameter in the vertical direction in microns.
(edit by Rana)
Attachment 1: BeamProfile.png
BeamProfile.png
Attachment 2: BeamPropagation.png
BeamPropagation.png
Attachment 3: BeamPropagation.zip
  12922   Fri Mar 31 16:10:33 2017 SteveUpdateTreasureLes Guthman

Les Guthman interviews  gradstudent Graig.

Main laser emergency shut off was acuated by accident during this fiming. The laser is turned on.

  4446   Mon Mar 28 15:49:18 2011 josephbUpdateCDSLessons from LST

[Koji,Joe]

PART 1:

Koji was unable to build his c1lst model first thing this morning.  Turns out there was  a bug with RCG parser that was introduced on Friday when we did the RCG updates.  We talked Alex who did a quick comment fix.  The diff is as follows:

Index: Parser3.pm
==============================

=====================================
--- Parser3.pm  (revision 2328)
+++ Parser3.pm  (working copy)
@@ -1124,8 +1124,8 @@
  print "Flattening the model\n";
  flatten_nested_subsystems($
root);
  print "Finished flattening the model\n";
-  CDS::Tree::do_on_nodes($root, \&remove_tags, 0, $root);
-  print "Removed Tags\n";
+  #CDS::Tree::do_on_nodes($root, \&remove_tags, 0, $root);
+  #print "Removed Tags\n";
  #print "TREE\n";
  #CDS::Tree::print_tree($root);
  CDS::Tree::do_on_nodes($root, \&remove_busses, 0, $root);

This was some code to remove TAGs from the .mdl file for some reason which I do not understand at this time.  I will ask tommorrow in person so I can understand the full story.

PART 2:

Koji then rebuilt and started the c1lst process.  This is his new test version of the LSC code.  We descovered (again) that when you activate too many DAQ channels (simply uncommenting them, not even recording them with activate=1 in the .ini file) that the frame builder crashes.  In addition, the c1lsc machine, which the code was running on, also hard crashed.

When a channel gets added to the .ini file (or uncommented) it is sent to the framebuilder, irregardless of whether its recorded or not by the frame builder.  There is only about 2 megabytes per second bandwidth per computer.  In this case we were trying to do something like 200 channels * 16384 Hz * 4 bytes = 13 megabytes per second.

The maximium number of 16384 channels is roughly 30, with little to no room for anything else.  In addition, test points use the same allocated memory structure, so that if you use up all the capacity with channels, you won't be able to use testpoints to that computer (or thats what Alex has led me to believe).

The daqd process then core dumped and was causing all sorts of martian network slowdowns.  At the same time, the c1lsc computer crashed hard, and all of the front end processes except for the IOP on c1sus crashed.

We rebooted c1lsc, and restarted the c1sus processes using the startc1SYS scripts.  However, the c1susfe.ko apparently got stuck in a wierd state.  We were completely unable to damp the optics and were in general ringing them up severely.  We tried debugging, including several burt restores and single path checks.

Eventually we decided to reboot the c1sus machine after a bit of debugging.  After doing a burt restore after the reboot, everything started to damp and work happily.  My best guess is the kernel module crashed in a bad way and remained in memory when we simply did the restart scripts.

 

  2870   Mon May 3 01:35:41 2010 KojiUpdateSUSLessons learned from MC spot centering

Lessons learned on the beam spot centering (so far)

Well-known fact:

The spot position on MC2 can be adjusted by the alignment of the mirror while maintaining the best overlapping between the beam and the cavity axes.

In general, there are two methods:

1) Use the cavity as a reference:
Move the MC mirrors such that the cavity eigenmode hits the centers of the mirrors.
-> Then adjust the incident beam to obtain the best overlapping to the cavity.

2) Use the beam as a reference:
Move the incident beam such that the aligned cavity has the spots at the centers of the mirrors.
-> Then adjust the incident beam to obtain the best spot position while the cavity mirrors keep tracking
the incident beam.

Found the method 1) is not practical.

This is because we can move the eigenmode of the cavity only by very tiny amount if we try to keep the cavity locked.
How much we can move by mirror alignment is smaller than the waist radius or the divergence angle.
For the MC, the waist radius is ~2mm, the divergence angle is 0.2mrad. This means the axis
translation of ~1mm is OK, but the axis rotation of ~4mrad is impractical.

Also it turned out that adjustinig steering mirror to the 10-m class cavity is quite difficult.
A single (minimum) touch of the steering mirror knob is 0.1mrad. This already change the beam position ~0.1mm.
This is not an enough resolution.

Method 2) is also not so easy: Steering mirrors have singular matrix

Indeed! (Remember the discussion for the IMMT)

What we need is the pure angle change of 4mrad at the waist which is ~2m distant from the steering mirror.
This means that the spot at the steering mirror must be moved by 8mm (= 4mrad x 2m). This is the result of the
nearly-singular matrix of the steering mirrors.

We try to avoid this problem by moving the in-vac mirror (IM1), which has somewhat independent move.
The refl beam path also has the big beam shift.
But once the vacuum manifold is evacuated we can adjust very little angle.

This can also be a good news: once the angle is set, we hardly can change it at the PSL side.

  3233   Thu Jul 15 23:51:47 2010 Mr. MaricHowToSUSLevitate me if you can

You guys must work harder.

mag_lev.jpg


  11365   Fri Jun 19 03:00:56 2015 ericqUpdateCDSLibrary Model Parts examined

All simulink diagrams being used at the 40m are now under version control. I have compiled, installed, and restarted all current models to make sure that the files are all in a working state, which they seem to be. I have checked the latest version of the userapps svn repository to /opt/rtcds/userapps2.9, to compare the files therein with our current state. 

Surprisingly, only two files in the userapps svn have been changed since they were checked out here, and only one of these is a real change of any kind. 

LSC_TRIGGER.mdl was edited at some point simply to align some drawn lines; no functionality was changed. 

SCHMITTTRIGGER.mdl was edited to change the "INVERT" epics channel from an arbitrary EPICS input, to binary (true/false) input. This does not change the connectivity diagram, and in fact, I don't think we use this option in any of our scripts, nor is it exposed on our medm screens. 

Thus, I think that the only place for block changes can bite us is changes in the fundamental blocks in CDS_PARTS that are used in our custom 40m library parts. 

For posterity, these are the files used in compiling all of our running models. (Path base: /opt/rtcds/userapps/release)

/isc/common/models/CALIBRATION.mdl
/isc/common/models/FILTBANK_TRIGGER.mdl
/isc/common/models/LSC_TRIGGER.mdl
/isc/common/models/QPD.mdl
/cds/common/models/FILTBANK_MASK.mdl
/cds/common/models/lockin.mdl
/cds/common/models/rtbitget.mdl
/cds/common/models/rtdemod.mdl
/cds/common/models/SCHMITTTRIGGER.mdl
/cds/common/models/SQRT_SWITCH.mdl
/cds/c1/models/c1rfm.mdl
/cds/c1/models/c1tst.mdl
/cds/c1/models/c1x01.mdl
/cds/c1/models/c1x02.mdl
/cds/c1/models/c1x03.mdl
/cds/c1/models/c1x04.mdl
/cds/c1/models/c1x05.mdl
/isc/c1/models/ALS_END.mdl
/isc/c1/models/BLRMS_40M.mdl
/isc/c1/models/BLRMS_HIGHFREQ.mdl
/isc/c1/models/blrms.mdl
/isc/c1/models/c1als.mdl
/isc/c1/models/c1ass.mdl
/isc/c1/models/c1asx.mdl
/isc/c1/models/c1cal.mdl
/isc/c1/models/c1ioo.mdl
/isc/c1/models/c1lsc.mdl
/isc/c1/models/c1oaf.mdl
/isc/c1/models/c1pem.mdl
/isc/c1/models/IQLOCK.mdl
/isc/c1/models/IQ_TO_MAGPHASE.mdl
/isc/c1/models/PHASEROT.mdl
/isc/c1/models/RF_PD_WITH_WHITENING_TRIGGERING.mdl
/isc/c1/models/SENSMAT_LOCKINS.mdl
/isc/c1/models/TT_CONTROL.mdl
/isc/c1/models/UGF_SERVO_40m.mdl
/sus/c1/models/c1mcs.mdl
/sus/c1/models/c1scx.mdl
/sus/c1/models/c1scy.mdl
/sus/c1/models/c1sus.mdl
/sus/c1/models/lib/sus_single_control.mdl
/sus/c1/models/QPD_WHITE_CTRL_MUX.mdl
  10670   Wed Nov 5 11:37:29 2014 manasaUpdateGeneralLight from Y end reaches PSL table

[Steve, Diego, Manasa]

Since the beatnotes have disappeared, I am taking this as a chance to put the FOL setup together hoping it might help us find them.

Two 70m long fibers now run along the length of the Y arm and reach the PSL table.

The fibers are running through armaflex insulating tubes on the cable racks. The excess length ~6m sits in its spool on the top of the PSL table enclosure.

Both the fibers were tested OK using the fiber fault locator. We had to remove the coupled end of the fiber from the mount and put it back in the process. So there is only 8mW of end laser power at the PSL table after this activity as opposed to ~13mW.  This will be recovered with some alignment tweaking.

After the activity I found that the ETMY wouldn't damp. I traced the problem to the ETMY SUS model not running in c1iscey. Restarting the models in c1iscey solved the problem.

 

  5313   Sat Aug 27 20:38:17 2011 SureshUpdateIOOLight is back on WFS

[Valera, Suresh]

   We wanted to continue the work with WFS servo loops.  As the current optical paths on the AP table do not send any light to the WFS, I changed a mirror to a 98% window and a window to a mirror to send about 0.25mW of light towards the WFS.   The MC locking is unaffected by this change.   The autolocker works fine.

   When the power to the MC is increased, these will have to be replaced or else the WFS will burn.

  4849   Tue Jun 21 19:54:33 2011 SureshUpdateGreen LockingLightWave NPRO power supply shifted to ETMY end table

The Lightwave NPRO power supply which is being shared between the AS table and the ETMY table has been shifted back to the ETMY table

The current to the laser is set at 1.5A.  The laser output is 200mW at this current level.

  4832   Fri Jun 17 16:05:07 2011 kiwamuUpdateABSLLightWave out of MOPA box

[Suresh / Kiwamu]

 We did the following things :

   - Took the LightWave NPRO out from the MOPA box

   - Temporarily took out the laser controller which has been connected to the Y end laser.

   - Put the LightWave on AP table and plugged the laser controller and confirmed that it still emits a beam

 DSC_3139_small.png

 

[Things to be done]

   - measure the beam profiles and power

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

 

[Background and Motivation]

 The PRC and SRC length have to be precisely measured before the vent.

In order to measure those absolute length we are going to use the Stochino technique, which requires another laser to scan the cavity profiles.

The LightWave NPRO laser in the MOPA box was chosen for the Stochino laser because it has a large PZT range of 5 MHz/V and hence allows us to measure a wider frequency range.

The laser in the MOPA box had been connected to home-made circuits, which are not handy to play with. So we decided to use the laser with the usual laser controller.

Peter King said he has a LightWave laser controller and he can hand it to us.

Until we get the controller from him we do some preparations with temporary use of the Y end laser controller.

  14039   Thu Jul 5 17:33:36 2018 keerthana, sandrineUpdateelogLights not working
  • N/S ARM FL.
  • N/S ARM INC.

These two lights inside the 40m-lab are not working.

  11970   Tue Feb 2 18:35:47 2016 gautamUpdateGreen LockingLightwave NPRO moved from PSL table to SP table

I've moved the following components that was a part of Koji's setup from the PSL table to the SP table so that I may measure the beam profile of the beam from the spare Lightwave NPRO and work on a mode-matching solution for the X-end.

  • Lightwave laser
  • Lightwave controller
  • Interlock switch (Newport)
  • HWP and PBS

I did some preliminary characterization of the beam from the Lightwave - in the power controlled mode, setting the "ADJ" parameter to 0 (which is the state recommended in the manual) gives an output power of ~240mW. I used the HWP and PBS to dump most of this into a "Black Hole" beam dump, but I was still getting about 300uW of power after this. This was saturating the CCD in the beam profiler (even though 300uW for a beam of ~1mm should be well within the recommended operating limits as per its manual - maybe the ND filter on the camera isn't really ND4.0), and so I further reduced the "ADJ" parameter on the laser controller to -20, such that I had no saturation of the CCD. I will try and take some data later today. The laser is presently in "Standby" mode, and the SP table is fully covered again.

  11971   Tue Feb 2 18:54:02 2016 KojiUpdateGreen LockingLightwave NPRO moved from PSL table to SP table

jiIn fact, it is one of the most difficult type mode profiling to measure a beam directly out from a laser source.

If you reduce the power by ADJ, this significantly changes the output mode as the pumping power varies temperature gradient of the laser crystal and thus thermal lensing in it. I'd recommend you to keep the nominal power.

If you use a PBS for power reduction, you should increase the transmission ~x10 from the minimum so that you are not dominated by possible junk polarization.

Any transmissive BK7 components where the beam is small can cause thermal lensing. In order to avoid this issue, I usually use two noncoated (or one AR coated) optical windows made of UV fused silica to pick off the beam. Once the beam power is reduced I suppose it is OK to use an additional ND filter in front of the CCD.

Another more reliable method is an old-good knife edge measurement.

  11973   Wed Feb 3 23:23:47 2016 gautamUpdateGreen LockingLightwave NPRO moved from PSL table to SP table

As Koji pointed out in the previous elog, the CCD beam profiler was ill suited for this measurement. Nevertheless, to get a rough idea of the beam profile, I made a few rearrangements to my earlier setup:

  • Kept the HWP at the same place it was, as this is roughly the configuration that is going to be used at the endtable anyways. It was ~7cm from the shutter housing on the laser head (unfortunately, I neglected to take a picture).
  • Moved the PBS downstream till it was ~40 cm away (so as to minimize the thermal lensing effect from the ~300mW beam) from the laser head. Rotated the HWP till I got about 6mW of transmitted power (dumped the rest into a black hole)
  • Installed a 95% reflecting BS to further attenuate the power to a level suitable for the CCD (dumped the reflected part onto a razor beam dump)
  • Installed the CCD beam profiler and captured an image, at ~60cm from laser head. In this configuration, I was able to get a clean image capture without the CCD saturating. Unfortunately, I could not transfer it off the laptop used to operate the beam profiler, I will upload a screen capture tomorrow once I get it. Anyways, the main observation was that the beam appeared quite elliptical (ellipticity ~0.6). It was also not clear to what extent thermal lensing at the PBS/BS was afftecting this measurement.

Following Koji's suggestion, I decided to do a knife-edge measurement as well. The measurement configuration was similar to the one described above, except the PBS/BS were removed, and a 1.0 neutral density filter was was installed ~80cm from the laser head (here the ~300 mW beam was >2mm in diameter, as judged by eye). I used the Ophir power meter, which was why I had to install an ND filter as it is rated for 100mW max power. I will put a picture up tomorrow. Thermal lensing shouldn't be of much consequence here, as we just need the whole beam to fall onto the power meter active area (verified by eye), and only the relative change in power levels as the knife edge cuts the beam matters. I took the cross-sectional profile of the beam by translating the knife in the x-direction (i.e. cut the beam "left to right" ).

Attachments 1 and 2 are the results from todays measurements. It remains to repeat by cutting the beam along the y direction, and see what ellipticity (if any) shows up. I also found some "nominal" numbers in page 4 of the Lightwave datasheet - it tells us to expect a waist 5cm from the shutter housing, with horizontal and vertical 1/e^2 diameters of 0.5mm and 0.38mm respectively. My measurement suggests a horizontal diameter of ~0.25mm (half the "nominal" value?!), and the waist location to be 8.22cm from the shutter housing. I wonder if this discrepancy is a red flag? Could it be due to the HWP? I'm reasonably sure of my calculations, and the fits have come out pretty nicely as well...

Attachment 1: KnifeEdgeScans_x.pdf
KnifeEdgeScans_x.pdf
Attachment 2: Beamscan_x.pdf
Beamscan_x.pdf
  11974   Thu Feb 4 09:16:46 2016 KojiUpdateGreen LockingLightwave NPRO moved from PSL table to SP table

I don't think the discrepancy is a serious issue as long as the mode is clean. The mode is determined by the NPRO crystal and is hard to change by anything except for the thermal lensing in the crystal.

And I never succeeded to reproduce the mode listed in the manual.

One thing you'd better to take care is that clipping of the beam produces diffraction. The diffracted beam spreads faster than the nominal TEM00 mode. Therefore the power meter should to be placed right after the razor blade. i.e. As you move the longitudinal position of the razor blade, you need to move the power meter.

  11977   Fri Feb 5 00:23:01 2016 gautamUpdateGreen LockingLightwave NPRO moved from PSL table to SP table

I've repeated the measurement for the x-direction and also did the y-direction, taking into account Koji's suggestion of keeping the power meter as close as possible to the knife edge. Attachment #1 shows a picture of the setup used. Because an ND filter is required to use this particular power meter, the geometrical constraints mean that the closest the power meter can be to the knife edge is ~3cm. I think this is okay. 

The result from the re-measured X-scan (Attachments #2 and #4) is consistent with the result from yesterday. Unfortunately, in the y-direction (Attachments #3 and #4), I don't seem to have captured much of the 'curved' part of the profile, even though I've started from pretty much adjacent to the HWP. Nevertheless, the fits look reasonable, and I think I've captured sufficient number of datapoints to have confidence in these fits - although for the Y-scan, the error in the waist position is large. The ellipticity as measured using this method is also significantly smaller than what the CCD beam profiler was telling us. 

If we are happy with this measurement, I can go ahead and work on seeing if we can arrive at a minimally invasive mode-matching solution for the X-end table once we switch the lasers out...

 

Attachment 1: Beamscan_setup.pdf
Beamscan_setup.pdf
Attachment 2: Beamscan_x.pdf
Beamscan_x.pdf
Attachment 3: Beamscan_y.pdf
Beamscan_y.pdf
Attachment 4: Zscan.pdf
Zscan.pdf
  11951   Tue Jan 26 17:50:22 2016 gautamUpdateGreen LockingLightwave frequency noise measurement

I attempted to measure the frequency noise of the extra Lightwave NPRO we have that is currently sitting on the PSL table. I did the following:

  1. Turn the Lightwave NPRO back on.
  2. Disable MC autolocker and close the PSL shutter.
  3. Checked the alignment of the pick off from the PSL beam and the beam from the Lightwave NPRO onto the PDA10CF. These seemed okay, and I didn't really have to tweak any of the steering optics. I was getting a DC signal level of ~7V (the PD should drive a 1Mohm load up to 10V so it wasn't saturated).
  4. Swept the crystal temperature on the Lightwave using the dial on the front panel of the controller. I found beatnotes at 48.1831 degrees and 45.3002 degrees. However, the amplitude of the beatnote was pretty small (approx. -40dBm on the Agilent NA). I tried playing around with the beam alignment and laser power on the Lightwave NPRO to see if I could increase the beatnote amplitude, but was unsuccessful - turning up the laser power (from the nominal level of 55mW as per the front panel display) caused the PD to saturate at 10V, while as far as I could tell, the alignment of the two beams onto the PD is reasonably good. This seems inconsistent with the numbers Koji has reported in this elog, where he was able to get a beatnote of ~1Vpp for a DC of 2.5 V. 
  5. I tried locking the PLL (in roughly the same configuration as reported here) with this small amplitude beatnote but was unsuccessful. 

I've turned the Lightwave NPRO back to standby for now, in anticipation of further trials later today. I've also restored the IMC. 

  11953   Wed Jan 27 18:19:45 2016 gautamUpdateGreen LockingLightwave frequency noise measurement

After adjusting the alignment of the two beams onto the PD, I managed to recover a stronger beatnote of ~ -10dBm. I managed to take some measurements with the PLL locked, and will put up a more detailed post later in the evening. I turned the IMC autolocker off, turned the 11MHz Marconi output off, and closed the PSL shutter for the duration of my work, but have reverted these to their nominal state now. The are a few extra cables running from the PSL table to the area near the IOO rack where I was doing the measurements from, I've left these as is for now in case I need to take some more data later in the evening...

  11956   Thu Jan 28 00:29:30 2016 gautamUpdateGreen LockingLightwave frequency noise measurement

Summary of the work done today:

Alignment and other work on PSL table

As mentioned in a previous elog, the beatnote amplitude I obtained was tiny - so I checked the alignment of the two beams onto the PD. I did this as follows:

  • Checked the alignment of the two beams on the recombination BS. Moved the steering mirror for the PSL beam until the two were aligned, as verified by eye using an IR card
  • Turn the steering mirror just before the fast focusing lens and thorlabs PD (kept the fork fixed, just loosened the screw on the post to do this) such that the far-field alignment of the two beams could be checked. I used the BS to tweak this alignment as necessary
  • Iterate the previous two steps till I was happy with the alignment
  • Return steering mirror before the PD to its original position, tweak alignment until DC level on the PD was maximized (as verified using an oscilloscope) 
  • Adjust the HWP just after the lightwave laser such that the power arriving at the PD from the PSL beam and the lightwave beam were approximately equal - verified by blocking each beam and checking change in the DC level

After doing all of this, I found a beatnote at ~-10dBm at a temperature of 45.3002 degrees on the Lightwave. The DC level was ~8V (~4V contribution from each beam). 

PLL and frequency nosie measurements:

Pretty much the same procedure as that described in this elog was followed for setting up the PLL and taking the measurements, except that this time, I used the two SR560s in a better way to measure the open loop TF of the PLL. This measurement suggested a UGF of ~ 10kHz, which seems reasonable to me. I turned the 11MHz marconi off because some extra peaks were showing up in the beat signal spectrum. I judged that the beatnote was not large enough to require the use of an attenuator between the PD and the mixer. I was able to lock the PLL easily enough, and I've attached spectra of the control signal (both uncalibrated and calibrated). To calibrate the spectrum, I did a quick check to determine the actuator gain of the spare Lightwave laser, by sweeping the fast PZT with a low frequency (0.5Hz) 1Vpp sine wave, and looking at the peak in the beat signal spectrum move on the network analyzer. This admittedly rough calibration suggests that the coefficient is ~5MHz/V, consistent with the other Lightwave. Eric suggested a more accurate way to do this would be to match up spectra taken using this method and by locking the PLL by actuating on the FM input of the Marconi - I didn't try this, but given the relatively large low-frequency drifts of the beatnote that I was seeing, and that the control signal was regularly hitting ~2V (i.e shifting the frequency by ~10MHz), I don't think this is viable with a low MHz/V coefficient on the Marconi, which we found is desirable as described here

Bottom line:

The spare Lightwave frequency noise seems comparable to the other two measurements (see attachment #2). If anything, it is a factor of a few worse, though this could be due to an error in the calibration? I'm also not sure why the shapes of the spectra from today's measurement differ qualitatively from those in elog 11929 above ~7kHz. 

 

Some random notes:

  • Do we want to do an AM/PM characterization of the spare Lightwave laser as well? It might be easier to do the PM measurement while we have this measurement setup working
  • Yesterday, I noticed some peaks in the spectrum of the PD output while only the PSL beam was incident on it, at ~35MHz and ~70 MHz. They were pretty small (~-50dBm), but still clearly discernible over the analyzer noise floor. It is unclear to me what the source of these peaks are.
Attachment 1: PLL_OLG.pdf
PLL_OLG.pdf
Attachment 2: Freq_noise_comparison.pdf
Freq_noise_comparison.pdf
  11969   Mon Feb 1 18:11:25 2016 gautamUpdateGreen LockingLightwave frequency noise measurement

Before distrubing the beat setup with the spare Lightwave laser, I wanted to see if I could resolve the apparent difference in behaviour between the measured free running noise of the spare Lightwave laser and my earlier measurements with the existing X and Y end lasers above ~5kHz. So I redid the measurement, but this time, on Eric's suggestion, while taking spectra on the SR785, I was careful to maintain the same "CH1 input range" while measuring the control signal spectrum and the measurement noise spectra. The level used was -20dBvpk. I think the measured spectrum shape now makes sense - above ~4kHz, the SR560 noise means that the SNR is poor and so we can only trust the spectra up to this value (the spectra for the end lasers are from earlier measurements where I did not take care to keep the input range constant). Anyways, I think the conclusion is that the spare Lightwave seems to have a free-running frequency noise that is approximately a factor of 3 worse than the Lightwave laser at the Y-end, though this may be because I didn't take the measurement at the optimal operating conditions (diode current, power etc). But I guess this is tolerable and that we can go ahead with the planned swapping out of the existing Innolight at the X-end with this laser. 

I will now move the Lightwave laser off the PSL table onto the SP table where I will do some beam characterization and see if I can come up with a satisfactory mode-matching solution for the swap. I've borrowed a beam profiler from the TCN lab for this purpose.

Attachment 1: Free_running_frequency_noise_comparison.pdf
Free_running_frequency_noise_comparison.pdf
  12075   Wed Apr 13 18:25:07 2016 gautamUpdateendtable upgradeLightwave health check

[Koji,gautam]

Lightwave NPRO information:

Model: 126-1064-700

Serial Number: 337

Manufactured: December 1998!!

Details of checks performed:

Koji tuned the parameters on the laser controller and we observed the following:

  1. Turning "ADJ" to +10 and the pumping current all the way up to the maximum (2.62A) allowed us to recover an output power of 300mW, at a laser crystal temperature of ~45degrees
  2. The output power increased almost monotonically as a function of the laser crystal temperature - why? We were able to see powers as high as 250mW (at ADJ=0) for the maximum crystal temperature of ~60 degrees.
  3. We checked that we could believe the readout of the power meter by measuring the power using the Scientech power meter - we saw ~270mW after the Faraday with this meter, accounting for ~10% loss through the Faraday, this corresponds to an output power of 300mW (all this was done at ADJ=+10, DC=2.62A). I suspect that the display is dodgy though, because changing the Diode Current from 2.52A to 2.62A increased the output power by almost 100mW, which seems hard to believe?
  4. The Lightwave NPRO does not have heat dissipation fins attached - could this be affecting the power output somehow? In any case, this has to be rectified. So if we decide to keep the Lightwave NPRO, the layout will still need minor changes to accommodate the heat fins. Steve, do we have these in hand?

Way forward

Ericq has begun the characterization of the repaired Innolight. We checked that it outputs 1W of power. We will now have to perform the following measurements:

  • Frequency noise using PLL
  • AM/PM response of the PZT
  • Laser power output as a function of diode current - this will be useful for diagnostic purposes in the future
  • AUX temperature vs PSL temperature at which beatnotes can be found
  • Waist measurement - the mode matching and optical layout upstream of the doubling oven at least will have to be modified significantly

All of these will have to be done before installing this laser at the endtable.

I believe the consensus as of now is to go ahead with carrying out the above measurements. Meanwhile, we will keep the Lightwave NPRO on and see if there is some miraculous improvement. So the decision as to whether to use the Innolight is deferred for a day or two.

  12079   Fri Apr 15 18:38:12 2016 gautamUpdateendtable upgradeLightwave health check - NO IMPROVEMENT

I re-measured the power levels today.

We have ~205mW out of the NPRO, and ~190mW after the Faraday. It doesn't look like the situation is going to improve dramatically. I'm going to work on a revised layout with the Innolight as soon as I've profiled the beam from it, and hopefully, by Monday, we can decide that we are going ahead with using the Innolight.

  46   Thu Nov 1 16:34:47 2007 Andrey RodionovSummaryComputersLimitation on attachment size of E-LOG

I discovered yesterday when I was attaching photos that it is NOT possible to attach files whose size is 10Mb or more. Therefore, 10Mb or something very close to that value is the limit.
  6146   Thu Dec 22 20:49:33 2011 KojiUpdateIOOLimitter activated for WFS servos

I set the limitters of the MC WFS servos not to inject the feedback more than 2000.

The residual of the WFS shakes the MC SUSs at every lock loss.

  6732   Thu May 31 16:54:12 2012 JenneUpdateGreen LockingLinks to old elogs for green beatnote laser temps

Because I keep taking a long time to search for these, since I can't remember the keywords in the different entries, here are the links:

elog 3759 : Green X end aux laser temperature setting vs. PSL laser temperature setting

elog 4439 : Green Y end aux laser temperature setting vs. PSL laser temperature setting

More words: beat note, doubling, second harmonic.

Relevant results: 

T_Xend = 8.31 + 0.9293*T_PSL

T_Yend = 6.9825 + 0.87326*T_PSL

 

Also, C1:GCY-SLOW_SERVO2_OFFSET was 29725 (twenty nine thousand seven hundred twenty five) cts when we sat down to start today.

C1:GCX-SLOW_SERVO2_OFFSET was 80 (eighty) cts when we sat down to start today.  Why the offsets are so different, I don't know.  But I was able to find the X green beatnote with this small number offset, so it is approximately correct.

  1904   Fri Aug 14 15:20:42 2009 josephbSummaryComputersLinux1 now has 1.5 TB raid drive

Quote:

Quote:

nodus was rebooted by Alex at Fri Aug 14 13:53. I launched elogd.

cd /export/elog/elog-2.7.5/
./elogd -p 8080 -c /export/elog/elog-2.7.5/elogd.cfg -D

 It looks like Alex also rebooted all of the control room computers.  Or something.  The alarm handler and strip tool aren't running.....after I fix susvme2 (which was down when I got in earlier today), I'll figure out how to restart those.

 Alex switched the mount point for /cvs/cds on Linux1 to the 1.5 TB RAID array after he finished copying the data from old drives.  This required a reboot of linux1, with all the resulting /cvs/cds mount points on the other computers becoming stale.  Easiest way to fix that he found was to do a reboot of all the control room machines.  In addition, a reboot fest should probably happen in the near futuer for all the front end machines since they will also have stale mount points as well from linux1.

The 1.5 TB RAID array mount is now mounted on /home of linux1, which was the old mount point of the ~300 GB drive.  The old drive is now at /oldhome on linux1.

 

  478   Thu May 15 10:40:21 2008 steveHowToGeneralLisa Goggin, PhD
Lisa Goggin successfully defended her thesis on May, 13 2008

"A Search For Gravitational Waves from Perturbed Black Hole Ringdowns in Ligo Data"

She started out as a surf student in the 40m.

Congratulation!
Attachment 1: lisa.JPG
lisa.JPG
  7247   Wed Aug 22 01:54:03 2012 JenneUpdateGeneralList o' things: YarmASS, ETMXTcamera, POXwhiteningTriggering

While meditating on other things, I have noticed / found the following today:

YARM ASS works okay.  Yesterday I measured the sensing matrix for the ASS for both arms (although I forgot to copy one of the matrix elements to my text file for Xarm - needs remeasuring).  I put the Yarm matrix in (after appropriate inversion, only non-zero pitch-to-pitch, yaw-to-yaw elements).  I turned on the Yarm ASS, and  the yaw converged pretty quickly (couple of minutes), with gains of -1 in the servos, overall gain of anywhere between 0.005 and 0.010.  The pitch took much longer, and I had to 'pause' several times by turning off the overall gain for the yarm ass when the MC lost lock (which has happened several times tonight - unknown cause).  Eventually, the pitch settled out, and quit changing, but the lockin outputs weren't zero, even though the error signal for the servos were almost zero (gains for the pitch servos were -0.5, overall gain ~0.005 was better than 0.01 - higher gain caused oscillations in the lockin outputs).  I think this means that I need to remeasure the yarm pitch ass matrix.  It's still much, much faster to just turn on the dithers, watch the striptool of the lockin outputs, and align the cavity by hand.

I think the ETMX Trans camera view is clipped a little bit.  I went down there, and it doesn't seem to be on the last optic before the camera, and moving the spot on the camera doesn't change the shape of the image, so I don't think it's on the camera.  We should look into this, since it's either clipping on the BS that separates some camera beam from the TRX beam, or TRX is getting a clipped beam too.  If the clipping is any earlier in the Trans path, the Trans QPD could also have some clipping.  This requires investigation.  The xarm trigger needs to be reset/disabled so we don't lose lock every time we block the TRX beam (as was happening to me).

XARM really doesn't like to relock unless the POX whitening is turned off.  Good flashes, doesn't really catch (10+ min waiting (while working on Yarm stuff) ).  After turning off the whitening, it catches almost immediately. Even though it's on the to-do list to rethink the tuning of our whitening, we should probably implement the whitening triggering now anyway.  It'll make things easier.

The double integrator that Rana implemented in the X and Y arm servo filters last week take 8 seconds to turn off (due to Foton settings), so even though they are triggered to turn off immediately upon lockloss, they sit around and integrate for 8 seconds, so have huge signals.  If the cavity flashes and the locking trigger engages during that 8 seconds, we send a huge kick to the ETMs.  I'm modeling the response of the filters to an impulse and noise, particularly in the case of ramping on the double integrators.  The problem is that a flat filter has 0deg phase, but the double integrator has 180deg phase at low frequencies, so there's some weird sign flipping that can happen as we ramp - this is part of what I'm modeling.

MC is losing lock unusually often tonight.  Everything on the servo board screen looks normal (which is good since that's all set by the autolocker).  I just disabled the test exc in, but that's been left enabled for a while now, and it hasn't (I think?) been a problem since there shouldn't be anything connected to the board there.  PMC transmission is a little low, 0.816, and FSS is starting to get near -1 on the slow actuator adjust, but we've seen locking of the PMC problems around -1.5 or -2 of the FSS, and the adjust value was at -0.8 earlier tonight and we still had MC locking problems.  I have had the seismic channels open on Dataviewer for the last several hours, and I'm not seeing any spikes in any of the Guralp channels which correspond to the times that the MC loses lock.  BLRMS don't seem particularly high, so MC lockloss cause is still a mystery for today.

The ETMX monitor selector on the VIDEO screen seems not to be switching the actual camera that's shown on the monitor.  Using the script command itself works, so my screen is wrong.

  11190   Wed Apr 1 16:52:02 2015 JenneUpdateLSCList of measurements

I'd like to get a concrete list of measurements written down, so that it's clear what needs to be done before I graduate.

Noise couplings:

  • Laser amplitude noise coupling to DARM
    • We don't have an AOM for ISS right now, but we should be able to just stick it back in the beam path, right?  I think Koji checked that the AOM was all okey-dokey recently.
    • AOM calibration should tell me how much the single-pass amplitude changes as a function of input signal.
  • Laser frequency noise coupling to DARM
    • Inject signal at the CM board input, which should be calibrated by looking at response to calibrated MC2 motion.
  • Marconi phase noise coupling to DARM
    • Marconi can produce internally or accept via BNC 0-10 rad of phase modulation.  Marconi spec sheet should give me rad/V for the input calibration.
  • Marconi amplitude noise coupling to DARM
    • Using external input of Marconi.  Marconi spec sheet should give me input calibration.
  • MICH err to DARM
    • Compare with Optickle model
  • PRCL err to DARM
    • Compare with Optickle model

Noise cancellation:

  • PRC angle
  • MICH noise removed from DARM (compare flat gain FF vs. Wiener FF)
  • PRCL noise removed from DARM (compare FF shape from model vs. Wiener FF)
  • MC length noise (equiv. to laser freq noise) removed from CARM & DARM

Are there things that I'm missing?  I've never had an IFO to characterize before.

  14582   Sun Apr 28 16:00:17 2019 gautamUpdateComputer Scripts / ProgramsList of suspension test

Here are some tests we should script.

  1. Checking Coil Vmons, OSEM PDmons, and watchdog enable wiring
    • Disable input to all the coil output filter modules using C1:SUS-<OPTIC>_<COIL>_SWSTAT (this is to prevent the damping loop control signals from being sent to the suspension)
    • Set ramptimes for these filter modules to 0 seconds.
    • Apply a step of 100 cts (~15 mV) using the offset field of this filter module (so the test signal is being generated by the fast CDS system).
    • Confirm that the step shows up in the correct coil Vmon channel with the appropriate size (in volts), and that other Vmons don't show any change (need to check the sign as well, based on the overall gain in this filter module).
    • Confirm that the largest response in the PDmon signals is for the same OSEM. There will be some cross-coupling but I think we always expect the largest response to be in the OSEM whose magnet we pushed provided the transimpedances are the same across all 5 coils (which is true except for PRM side), so this should be a robust criterion.
    • Take the step off using the watchdog enable field, C1:SUS-<OPTIC>_<COIL>_COMM. This allows us to confirm the watchdog signal wiring as well.
    • Reset ramptimes, watchdogs, input states to filter modules, and offsets to their pre-test values.
    • This test should tell us that the wiring assignments are correct, and that the Acromag ADC inputs are behaving as expected and are calibrated to volts.
    • This test should be done one channel at a time to check the wiring assignments are correct.
  2. Checking the SUS PD whitening
    • Measure spectrum of individual PD input (fast CDS) channels above 30 Hz with the whitening in a particular state
    • Toggle the whitening state.
    • Confirm that the whitened sensor noise above 30 Hz is below the unwhitened case (which is presumably ADC noise.
    • This test should be done one channel at a time to check the wiring assignments are correct.

Checking the Acromag DAC calibration is more complicated I think. There are measurements of the actuator calibration in units of nm/ct for the fast DACs. But these are only valid above the pendulum resonance frequency and I'm not sure we can synchronously drive a 10 Hz sine wave using the EPICs channels. The current test which drives the PIT/YAW DoFs with a DC misalingment and measures the response in the PDmon channels is a bit ad hoc in the way we set the "expected" response which is the PASS/FAIL criterion for the test. Moreover, the cross-coupling between the PDmon channels may be quite high. Needs some thought...

ELOG V3.1.3-