40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 56 of 339  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  6454   Tue Mar 27 17:38:03 2012 JenneUpdateIOOAnother possibility / thought

I'm meditating over the mode matching from the mode cleaner to the ITMs, and I had another thought:

Have we changed the pointing of the MC significantly enough that we are no longer on the center of the MMT mirrors?  To be this significant, we would probably also have had to scoot the Faraday a bit too, since it's skinny like a straw.  It looks like our measurements of the input beam have been the following:

MC waist, 21 May 2010

After MMT2, 18 June 2010 (a few days before this, we flipped the MMT2 mount to 'perfect' the mode matching up to 99.3%, so I don't think the MMT has moved since then.)

After MMT2, 26 March 2012

There's a big o' ~2 year gap between our measurements, and we've been in and out of the vacuum a few times since then.  I'll flip through the elog, but does anyone have any memory of us moving the Faraday after June 2010?  When was the last time we made sure that we were at least close to the center of the MMT mirrors? 

  6456   Tue Mar 27 18:03:46 2012 JenneUpdateIOOBeam Profile measurement: IPPOS beam

This is wrong!  See following elog for corrected plot (and explanation)

I'm not done meditating on what's going on, but here's what I've got right now:

BeamProp_usingMeas2012MMTnumbersLowRes.png

This is a beam profile, using the distances from the combined Kiwamu / Jenne sketch earlier today. 

0 meters along the horizontal axis is meters from the Mode Cleaner waist. (Yes, I was bad and forgot to label it.  Get over it.)

The pink and green dots to the left of the plot are the MC fitted waist measurements that we made in May 2010.

The pink and green dots in the ~center of the plot are the fitted waist measurements that Suresh and Keiko took yesterday, of the IPPOS path, so after the MMT.

The black dot is where we would like our non-astigmatic beam to be.  This is the calculated waist size of the cavity mode, using the new ~37.76m distance, after we moved the ETMs to their current positions.  The black dot indicates 3.036 mm at the ITM (averaged between the BS-ITMX and BS-ITMY distances).

The moral of the story that I'm getting from this plot:  something funny is going on.

The distances Kiwamu quoted on the sketch are very close to the ones that I used for designing and checking the MMT in the first place, which were based off of measurements using rulers etc to measure distances.  Steve said he looked at photos today, and agreed that Kiwamu's numbers looked reasonable also.

Something that we haven't done lately is measure the position of each optic from every other optic, along the beam path.  I propose we come up with a clever way to put a target on top of / next to mirrors, and then a way to hold the laser distance measure-er at an optic, so that we can go thorough systematically and measure the actual path that our beam is seeing.  Maybe this is too much work, and not worth it, but it would make me happier.  In my head, these 'fixtures' are just small pieces of cleaned aluminum, one that can sit on a mirror mount, and one which we can use to align the laser ruler to approximately the front of an optic.  Nothing fancy.

  6457   Tue Mar 27 21:20:32 2012 JenneUpdateIOOBeam Profile measurement: IPPOS beam

Quote:

The moral of the story that I'm getting from this plot:  something funny is going on.

 Yup, something funny was going on.  Nic's MM code that I used, "a la mode", calls for the focal length of the optics, whereas the code that I wrote and used for ages called for the radius of curvature.  f = R/2.  Fixing that factor of 2 I get something more like:

BeamProp_usingMeas2012MMTnumbersLowRes.png

This is obviously much better, in that the beam profile goes through (within some error) both of the measured sets of points - the MC waist measured in May 2010, and after the MMT measured yesterday.

So, what does it all mean?  That I'm not sure of yet.

  6460   Wed Mar 28 01:17:29 2012 JenneUpdateIOOBeam Profile measurement: IPPOS beam

As I was a little dissatisfied with the inaccuracy in the distance numbers in Kiwamu's sketch, I went back to the 18 Dec 2010 table layout drawing for more accurate numbers.  These are now included in this round of plots.

Also, I include astigmatism due to the incident angles on MMT1 (~3.5 deg) and MMT2 (~1 deg).

First plot, IPPOS path, using the recent (fixed) measurements from Suresh to fix the beam width.  Note that the old 2010 measurements of the MC waist are consistent with this measurement.

Second plot, Main IFO path all the way to the ITM (average) position, using the 2010 MC waist measurements to fix the beam width.

Third plot, Main IFO path all the way to the ITM position, but with PRM flipped (negative RoC), using the 2010 MC measurement to fix beam width.

With the PRM correctly oriented (2nd plot), I get beam waists of (x = 2.529 mm, y = 2.646 mm), which corresponds to a mode matching to the arm cavity of (eta = 97.43%, PRM correct).

With the PRM flipped (3rd plot), I get beam waists of (x = 3.176 mm, y = 3.3 mm), which corresponds to a mode matching to the arm cavity of (eta = 99.55%, PRM flipped).

 

First plot:

BetterDistances_IPPOSLowRes.png

Second plot (this is how the MMT was designed to be, before the ETMs were moved, which made the ideal waist larger):

BetterDistances_MainIFO_PRMnormalLowRes.png

Third plot:

BetterDistances_MainIFO_PRMflippedLowRes.png

For both the 2nd and 3rd plot, we can't look at the post-MMT waist measurements, since that distance on the plots is after the PRM, which is a curved optic.  So the fact that the post-MMT measurements match the correct-PRM plot better than the flipped-PRM plot can't be taken to be meaningful.

Moral of the story:  I'm not sure how to interpret any of this to tell us if the PRM is flipped or not, since the measurements are all of the beam profile before the beam sees the PRM.  We'd have to measure the profile after the PRM somehow in order to get that information.  We have okay but not great mode matching to the arm if the PRM is correct, but I don't know that we readjusted the MMT after we moved the ETMs.  I don't remember recalculating any optimal telescope lengths after the arm length change.  If we need better mode matching, I can do that calculation, although given how much space we don't have, it would be hard in practice to move the MMT mirrors by much at all.

  6461   Wed Mar 28 18:26:47 2012 JenneUpdateIOOBeam Profile measurement: IPPOS beam

More calculations....

Game Plan:  Using MC waist measured beam as the starting point of beam propagation, move MMT mirrors around until the beam profile fits with the IPPOS measurements from Monday.

Plot 1:  Allow MMT mirrors to move as much as they want to.  Note that the Y-beam goes through the IPPOS measured point. (This implies we put the MMT in the wrong place by ~half a meter.  Unlikely)

Plot 2: Using MMT locations from plot 1, what does the beam look like at the ITMs? 

Plot 3:  Allow MMT mirrors to move as much as 2cm.  Note that the Y-beam doesn't quite go through IPPOS measured point.

Plot 4: Using MMT locations from plot 3, what does the beam look like at the ITMs?

For all of the above, I was optimizing the propagation of the Y-beam profile.  Since the X-beam profile measurement is so different, if I want to optimize to X and let the MMT mirrors move as much as they want, MMT1 ends up inside the MC.  Unlikely.  So I'm just looking at Y for now, and maybe Suresh or someone needs to rethink the error bars on their measurements or just remeasure.

Plot 1:

OptimizedMMT_halfMeterChange_IPPOSviewLowRes.png

Plot 2:

OptimizedMMT_halfMeterChange_IFOviewLowRes.png

Plot 3:

OptimizedMMT_pt2cMeterChange_IPPOSviewLowRes.png

Plot 4:

OptimizedMMT_pt2cMeterChange_IFOviewLowRes.png

  6462   Wed Mar 28 20:54:02 2012 JenneUpdateIOOBeam Profile measurement: IPPOS beam

I fitzed by hand with the numbers for the incident angles on MMT1 and MMT2, and then let the code optimize the position of MMT1 and MMT2.

Here I have set the incident angle for MMT1 = 25deg, and MMT2 = 12deg (should be 3.5deg, 1deg by design).  The length of the telescope doesn't want to change by more than 7mm, but the position of the telescope wants to change by 1.3meters.  Is it possible that the distances on the Monday IPPOS measurements aren't actually correct?

MMT_moved_by_1pt3meters_MMT1th_25_MMT2th_12_LowRes.png

  6465   Thu Mar 29 13:23:05 2012 JenneOmnistructureComputersWireless router for GC

Quote:

I installed a NETGEAR Wireless Router (WPN824N) today on the 131 network. The admin password for it as well as the wireless access password are in the usual places.

The SSID is 40EARTH. I have set it to allow WPA as well as WPA2 access, so the speed is only 54 Mbps for now. In a year or so, we can turn off the WPA support and up the speed.

 This router was confiscated by the GC guys this morning around ~10am.  They barged in and said that someone at the 40m had connected a new router, and we had magically taken down half of the GC network.  The cable was plugged in to the wrong port on the back of the router. 

Junaid / Christian said that they would "secure" the router, and then reinstall it.  Apparently just having a password didn't satisfy them.  This was the compromise, versus them just taking the router and never bringing it back.

 

  6476   Mon Apr 2 18:58:32 2012 JenneUpdateIOOBeam Profile measurement: IPPOS beam

Suresh noted that I never wrote down the waist positions of the beam propagated through the MMT (based on where we think it is from ruler-based measurements).  This uses the MC waist measured beam as the starting point, and just propagates through the MMT, out to the IPPOS port.

Yq:

  Properties:
                    q: 2.2488 +23.8777i
               lambda: 1.0640e-06
            waistSize: 0.0028  (at z = 13.2676 meters)
               waistZ: 2.2488    (relative to z = 13.2676 meters)
      divergenceAngle: 1.1910e-04
    radiusOfCurvature: 255.7849
            beamWidth: 0.0029
        rayleighRange: 23.8777

So, to sum up, the vertical beam waist is 2.8438 mm at 11.0188 meters from the MC waist.

 

Xq:

  Properties:
                    q: 5.1953 +24.7342i
               lambda: 1.0640e-06
            waistSize: 0.0029   (at z = 13.2676 meters)
               waistZ: 5.1953    (relative to z = 13.2676 meters)
      divergenceAngle: 1.1702e-04
    radiusOfCurvature: 122.9525
            beamWidth: 0.0030
        rayleighRange: 24.7342

So, to sum up, the horizontal beam waist is 2.8943 mm at 8.0723 meters from the MC waist.

In pictorial form,

NonOptimized_propagatedWaistPlotted_LowRes.png

  6493   Fri Apr 6 11:14:34 2012 JenneUpdateAdaptive Filteringstatic and adaptive

Quote:

I've run static and adaptive filters simultaneously. AA32 filters rotate the phase of the witness signals GUR1X and GUR1Y and now the performance of the static filter is worse. Next time I'll recalculate Wiener filter coefficients taking this into account. But still 2 filters together can deal with a stack better.

static_oaf.pdf

 This is super awesome!  I'm totally excited!!

  6494   Fri Apr 6 11:32:09 2012 JenneUpdateComputersRAID array is rebuilding....

Suresh reported to Den, who reported to me (although no elogs were made.....) that something was funny with the FB.  I went to look at it, and it's actually the RAID array rebuilding itself.  I have called in our guru, Jamie, to have a look-see.

  6499   Fri Apr 6 19:04:35 2012 JenneUpdatePEMSTS releveled, GUR2 plugged in

[Den, Jenne]

We were wondering why the STS-2 signal was funny.  When I went to look at it, the X-axis indicator was pointing ~45deg from the x-axis, so that it was pointing between the arms of the IFO.  Also, the bubble in the level was totally stuck on one side.  We locked the masses, and I put the seismometer back to the correct orientation, and then leveled it.  We unlocked the masses and turned the power back on, and hit the auto-zero button a few times.  Right now the X-axis signal is fine, but Y and Z are still railed, but it's been like 24 seconds, not 24 hours since we last hit auto zero, so there's still some time to wait.

Also, GUR2 was unplugged on both ends of the cable.  We plugged it back in.  However, it looks like the *seismometer* labeled #1 is now plugged into *channels* GUR2, and the seismometer labeled #2 is plugged into channels GUR1.  Recall that Den has only modified X, Y, Z for GUR1 channels, not any other channels in the breakout box.

  6509   Mon Apr 9 15:02:30 2012 JenneUpdateLSCLocked MICH

I was going to try some locking, but things are a little too noisy. 

Just so Kiwamu knows what I did today, in case he comes back....

I ran LSCoffsets, and aligned both X and Y arms and saved their positions, and aligned MICH, and saved the BS position. 

I'll play with it more later, when there aren't trucks driving around outside that I can hear / feel in the control room.

  6510   Mon Apr 9 15:09:34 2012 JenneUpdateLSCLocked MICH

Quote:

I was going to try some locking, but things are a little too noisy. 

Just so Kiwamu knows what I did today, in case he comes back....

I ran LSCoffsets, and aligned both X and Y arms and saved their positions, and aligned MICH, and saved the BS position. 

I'll play with it more later, when there aren't trucks driving around outside that I can hear / feel in the control room.

 After giving up on locking, the MC is getting unlocked every now and again (2 times so far in the last few minutes) from transient seismic stuff.

  6515   Tue Apr 10 13:42:54 2012 JenneUpdateEnvironmentPlumbing guys are here

I don't know why, but they're looking around on the roof, and inside our ceiling above the bathrooms.

  6516   Tue Apr 10 17:02:29 2012 JenneUpdateIOOMode matching recollections and conclusions

...Mostly just recollections at this point.

I re-looked at the mode matching's sensitivity to misplaced optics.  Here is the plot that the original MMT code from 2010 spits out:

IMMT_positionSensitivity_plotted10Apr2012_LowRes.png

What this plot is telling us is that we should lose no more than 0.1% of mode matching "goodness" if we messed up the curved optic's positions by up to 2 cm.  If we can't place optics to within 2 cm, we might as well go back to optics kindergarten, because that's pretty lame.

UPDATE: Here is a histogram using the new code, which definitely includes the non-unity index of refraction for the transmissive optics and the Faraday.  The only optics which are permitted to move are the 2 curved optics, and they are allowed a stdev of 20mm.  Again, we shouldn't be doing worse than ~99% mode matching, even if we're 2cm off from the MMT positions that we measured with a ruler.  This histogram only has 300 iterations, since it takes quite a while (~0.5sec) to calculate each iteration.  Note this is mode overlap using the measured MC waist, propagated through optics, compared to the ideal arm mode.  This is completely ignoring the IPPOS measurements so far.

Histogram_20mmStDev_MMTmovesOnly_LowRes.png

 

UPDATE 2: Allowed 5 degrees of incident angle motion for both curved optics, which changes the astigmatism of the beam downstream.  Still, no big change from ~99% mode matching efficiency.  Again, this doesn't include any information from the IPPOS measurements.  3000 iterations this time around, since I didn't need my computer.  Curved optics still allowed to move back and forth by 2cm. 

Histogram_20mmStDev_MMTmovesAndTilts_LowRes.png 

More meditations and conclusions to follow...  currently running hist code to allow tilt of optics, to account for astigmatism changes also. 

Suresh and I are going to do some beam measurements tomorrow with the beamscanner, and then we will do a few measurements with the razor blade technique, to confirm that we're doing things okey dokey.

  6519   Wed Apr 11 14:34:48 2012 JenneUpdateEnvironmentPlumbing guys are here

Quote:

I don't know why, but they're looking around on the roof, and inside our ceiling above the bathrooms.

 Bob tells me that the carpenter is going to move the nitrogen bottles to the other side of the outside door, so that the plumbers can install a safety shower / eyewash right outside our door.

Also, the carpenter just mounted a new glass door cabinet from Bob's lab in the IFO room, so we have some new storage space.

  6520   Wed Apr 11 16:33:16 2012 JenneBureaucracyGeneral40m Meeting Action Items

Action Items from Last Week:

(non-existant)

-----------------------------------------------------------------------

Action Items this Week and LEAD PERSON:

Assemble and ship 4 TTs from LHO - SURESH

Prepare electronics for TTs (coil drivers) - JAMIE

In-air TT testing to confirm we can control / move TTs before we vent (starting in ~2 weeks) - SURESH

Connect TTs to digital system and controls, lay cables if needed - JAMIE with SURESH

OAF comparison plot, both online and offline, comparing static, adaptive and static+adaptive - DEN

Static-only OAF noise budget (Adaptive noise budget as next step) - DEN

Black glass: big baffle pieces to clean&bake, get small pieces from Bob, put into baskets, make new basket for 1" pieces, get to clean&bake - KOJI

IPPOS beam measurement - SURESH with JENNE

AS beam measurement (if beam is bright enough) - SURESH and JENNE

Mode matching calculations, sensitivity to MC waist measurement errors, PRM position - JENNE

Summary of IFO questions, measurements to take, and game plan - JENNE

Think up diagnostic measurement to determine mode matching to PRC while chambers are open, while we tweak MMT - JAMIE, JENNE, KOJI, SURESH

  6521   Wed Apr 11 17:56:26 2012 JenneUpdateGeneralSummary of things to figure out with the IFO

Questions:

Power recycling gain

   * It should be ~40, but we observe/measure it to be ~7.  Even if mode matching of ~50% is assumed, gain is calculated to be ~15

   * Would like to measure PR gain independent of mode matching, if possible

Power recycling cavity mode matching

   * Reflectivity of PRMI was measured to be ~50%.  That's pretty high.  What's going on?

   * Even if we're mode matched to the arm, are we appropriately mode matched to the PRC?

Is beam from MC clipped in the Faraday?

   * We had to use MC axis for input pointing since PZTs aren't totally working.

   * Need to measure IPPOS beam for different MC alignments to see if horizontal waist measurement stays constant.

PRM flipped?

   * Not likely, but it can't hurt to confirm for sure.

   * Want to know, since it could give us a different plan for MMT moving than if the PRM is correct.

Thick optic non-normal incidence in IPPO - does this exaggerate astigmatism, which would help explain IPPOS measurement?

Is PRC waist same size / position as arm cavity waist, given the current "known" positions of all the optics?

   * How is this effected by moving the PRM?

------------------------------------------------------------------------------------

Measurements to take and what information they give us:

IPPOS beam scan, with MC as-is

   * Confirm (or not) IPPOS measurements from last week

IPPOS beam scan with different MC alignments

   * Will tell us about Faraday clipping, if any

AS beam scan, misaligned PRM, misaligned SRM, misaligned ITMX, single bounce from ITMY

   * Can only take this measurement if beam is bright enough, so we'll just have to try

   * Will confirm IPPOS measurement, but includes going through the thick PRM, so can compare to calculated intra-PRC mode

REFL beam scan (already done....is the data satisfactory? If so, no need to redo), single bounce off of PRM

   * Will tell us about the potential PRM flipping

   * Need to compare with calculated mode at REFL port for flipped or non-flipped PRM

Look at POP camera, see 2nd pass through cavity

   * Try to match 1st and 2nd pass.  If they don't match, we're not well matched to PRC mode

Look at beam directly on ETMY cage, then beam from ETM, bounce off ITM, back to ETM cage

   * If the beams are the same size, we're well matched to arm cavity mode

   * Use fancy new frame-grabber.

----------------------------------------------------------------------------

MMT code things to calculate, and what information it gives us:

REFL beam path, for PRM flipping comparison

Thick IPPO non-normal incidence - I'm not sure how to do this yet, since I only know how non-normal incidence changes effective radii of curvature, and this is a flat optic, so *cos(theta) or /cos(theta)  won't do anything to an infinite RoC

Compare PRC waist to arm cavity waist, using "known" optic positions

Mode matching sensitivity to MC waist measurements

Mode matching sensitivity to PRM position

  6522   Wed Apr 11 18:19:51 2012 JenneUpdateIOOMode matching recollections and conclusions

Another histogram.  This one allows the MMT mirror positions to move, the MMT incident angle for both curved optics to change, and the MC waist size and position to change.  The error quoted for the MC waist size measurement from 2010

was +\- 0.01mm, and the MC waist position was +\- 28mm.  

This histogram is showing that we're pretty sensitive to the MC waist measurement, which is used to define the beam.  We can be up to ~2% off in our ideal mode matching to the arms if we're using the incorrect initial beam for the telescope design.

ModeMismatch_MMTpos_MMTang_MCw0_MCwz_change_LowRes.png

  6524   Thu Apr 12 00:16:38 2012 JenneUpdateEnvironmentEarthquake - moderate

 


M4.7 - Santa Isabel, Mexico 2012-04-12 06:48:38 UTC

Mode Cleaner doesn't want to stay locked.  Seismic is coming down from an earthquake ~20min ago.  

We're in the process of measuring IPPOS, so this is obnoxious.

EDIT:  Followed by a 6.2 and a 7.1 at 07:06UTC and 07:15UTC in the same area.

We're following the tried and true tradition of going home when there's an earthquake big enough that the MC won't stay locked.

Several optics have rung up, PRM is the only one which has tripped so far, because the side sensor has the extra gain, but the watchdog threshold is set for the face OSEMs.

  6525   Thu Apr 12 00:40:45 2012 JenneUpdateSUSPRM, BS oplevs off

There's a beam dump after the HeNe on the BS oplev table, since the IPPOS measurement optics (steering mirrors) are in the way of the oplev beams. 

Don't enable the BS or PRM oplevs!!!!  We'll post a notice in the elog when the oplevs are back to normal. 

Self, remember to disable the oplevs manually if they come on with any restore scripts.

  6532   Thu Apr 12 23:52:49 2012 JenneUpdateLockingPRMI locked - 'bouncy'

I am locking some things, and have the PRM aligned, and it will stay locked for short periods of time, but as Kiwamu warned me, when the PRM alignment is better, the lock is more "crazy" and unstable.  This should go on our list of mysteries.

 

  6533   Fri Apr 13 01:27:10 2012 JenneUpdateSUSOplevs recentered

It's been a while since I think anyone has done it, and several optics were pretty far from centered, so I centered all of the oplevs except for SRM.

I am confident about my arm alignment, MICH and PRC (so BS, ITMX, ITMY, PRM, ETMX and ETMY), but I wasn't sure if I was getting SRC right, so I didn't touch the SRM's oplev.

Suresh removed all of the IPPOS measurement optics, so there was nothing blocking the BS and PRM oplevs.

However, the PRM oplev was ridiculously bad, and I don't know how long it's been that way.  Some of the optics shooting the beam into the chamber weren't optimally aligned, so the beam coming out of the chamber was hitting the lowest edge of the optic mount, for the first optic the beam encountered.  I adjusted the mirror launching the beam into the chamber by a teeny bit, so that the outcoming beam was ~horizontal and hitting the center of the first steering mirror in pitch.  I had to move that steering mirror a little to the right (if you are staring at the HR face of the mirror), to get the beam to come close to the horizontal center of the optic.  Then I proceeded to do normal oplev alignment.

Also, I've noticed lately that ITMX is noisier than all the other optics.  It's kind of annoying.  The sensor RMS values reported for the ITMX watchdogs for UL and LL are rarely below 2, and are often (~70% of the time?) above 3.  The SD RMS is a normal 1-ish.

  6537   Mon Apr 16 09:44:54 2012 JenneUpdatePEMgur2_x

Quote:

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

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

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

  6544   Wed Apr 18 11:46:14 2012 JenneUpdateGeneralPower outage last night

Quote:

  • there are no oplev signals in MC1, MC2, and MC3
  • Something is wrong with PRM.  He is very noisy.  Turning on his oplev servo makes him go crazy.

 None of the 3 MC optics have oplevs, so there shouldn't be any oplev signals. Although MC2 has the trans QPD, which was once (still is??) going through the MC2 oplev signal path.

PRM was noisy last week too.  But turning on his oplev shouldn't make him crazy. That's not so good. Try restoring PRM (the ! near the PRM label on the IFO align screen), then checking if his oplev is ~centered.  Maybe PRM wasn't in the nominal position at the time you restored from.

  6545   Wed Apr 18 11:54:31 2012 JenneUpdateGeneralPower outage last night

Quote:

None of the 3 MC optics have oplevs, so there shouldn't be any oplev signals. Although MC2 has the trans QPD, which was once (still is??) going through the MC2 oplev signal path.

 Duh.  Unawake brain.  The MCs look fine.

  6566   Wed Apr 25 11:45:34 2012 JenneUpdatePEMBlue Bird Pre-Amplifier

It looks like we should change the "R40" and "R47" diodes.  If you do it this week, ask Jamie or Koji to check that you've got them oriented correctly before soldering them and plugging it in.

  6587   Mon Apr 30 21:05:32 2012 JenneUpdateSUSETMY oplev power supply dead

[Jenne, MikeJ]

The ETMY oplev quad sum was ~0, so we went to investigate.  The power supply was dead.  Keying it on and off didn't fix things, and it was certainly getting power since the front indicator light was flickering.  We replaced it with a different power supply, and the oplev is back.

Also, the Y-green AUX laser was off, presumably from the power outage a while back.  I turned it back on.

 

EDIT JD:  The first power supply we used didn't work....the oplev was on for a few minutes, then went off again.  We switched to one of the new (still JDSU) power supplies from Edmund Optics, and it's been happily working for at least an hour now.

  6589   Mon Apr 30 22:41:34 2012 JenneUpdateSUSETMY oplev power supply dead

Quote:

And has the temp controller of the green been recovered too? (Push enable button)

 

 Just now, yes.

  6590   Mon Apr 30 22:58:57 2012 JenneUpdateElectronics11MHz Marconi set to default after power outage

After a power outage, a Marconi comes back to it's defaults.  It needed to be reset to the values in elog 5530.  I'm putting a label on the Marconi so we don't have to look it up next time.

Before fixing the Marconi, POY11, AS11 and AS55 all looked like noise, no real signals, even though the arm is flashing.  Now they all look PDH-y, so things are better.

  6596   Thu May 3 13:19:17 2012 JenneUpdateLockingMore success last night

I locked each arm, and the Michelson last night, no problems after I increased the Yarm gain from 0.1 to 0.2 .  I checked the green beam alignment just before going home, and both of the green beams are locking on ~03 or 04 modes, so aligning them is on the list for today.

  6597   Thu May 3 13:35:56 2012 JenneBureaucracyGeneral40m Meeting Action Items

Action Items:

IFO:

         Arm cavity sweeps, mode scan - JENNE

        Align AS OSA (others?) - JENNE       

        Investigate PRMI glitches, instability (take PRM oplev spectra locked, unlocked, to see if PRM is really moving) - KOJI, JENNE, DEN

         Connect up beatbox for Xarm use - KOJI with JENNE       

 

TT:

Prepare electronics for TTs (coil drivers) - JAMIE

In-air TT testing to confirm we can control / move TTs before we vent (starting in ~2 weeks) - SURESH

Connect TTs to digital system and controls, lay cables if needed - JAMIE with SURESH

OAF:

OAF comparison plot, both online and offline, comparing static, adaptive and static+adaptive - DEN

Static-only OAF noise budget (Adaptive noise budget as next step) - DEN

Build amplifiers for new small microphones - DEN 

SLC:

Black glass: to clean&bake - KOJI

Scattered light measurement at the end stations: design / confirmation of the mechanical parts/optics/cameras - JAN

MM:

IPPOS beam measurement - SURESH with JENNE

AS beam measurement (if beam is bright enough) - SURESH and JENNE

Mode matching calculations, sensitivity to MC waist measurement errors, PRM position - JENNE

Think up diagnostic measurement to determine mode matching to PRC while chambers are open, while we tweak MMT - JAMIE, JENNE, KOJI, SURESH

Computers:

       Upgrade Rossa, Allegra to Ubuntu, make sure Dataviewer and DTT work - JAMIE

 

  6599   Thu May 3 19:52:43 2012 JenneUpdateCDSOutput errors from dither alignment (Xarm) script

epicsThreadOnceOsd epicsMutexLock failed.
Segmentation fault
Number found where operator expected at -e line 1, near "0 0"
        (Missing operator before  0?)
syntax error at -e line 1, near "0 0"
Execution of -e aborted due to compilation errors.
Number found where operator expected at (eval 1) line 1, near "*  * 50"
        (Missing operator before  50?)
epicsThreadOnceOsd epicsMutexLock failed.
Segmentation fault
Number found where operator expected at -e line 1, near "0 0"
        (Missing operator before  0?)
syntax error at -e line 1, near "0 0"
Execution of -e aborted due to compilation errors.
syntax error at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
Number found where operator expected at (eval 1) line 1, near "*  * 50"
        (Missing operator before  50?)
epicsThreadOnceOsd epicsMutexLock failed.
status : 0
I am going to execute the following commands
ezcastep -s 0.6 C1:SUS-ETMX_PIT_COMM +-0,50
ezcastep -s 0.6 C1:SUS-ITMX_PIT_COMM +,50
ezcastep -s 0.6 C1:SUS-ETMX_YAW_COMM +,50
ezcastep -s 0.6 C1:SUS-ITMX_YAW_COMM +-0,50
ezcastep -s 0.6 C1:SUS-BS_PIT_COMM +0,50
ezcastep -s 0.6 C1:SUS-BS_YAW_COMM +0,50
hit a key to execute the commands above

  6601   Thu May 3 22:37:44 2012 JenneUpdateGeneralOpLev 90-day trend

After fixing the PRM tonight, all of the oplevs look okay. 

.....except ITMX, which looks like it's power dropped significantly after the CDS upgrade.  To be investigated tomorrow.

  6602   Fri May 4 17:44:42 2012 JenneUpdateGeneralOpLev 90-day trend

Quote:

After fixing the PRM tonight, all of the oplevs look okay. 

.....except ITMX, which looks like it's power dropped significantly after the CDS upgrade.  To be investigated tomorrow.

 I had a look-see at ITMX's oplev.  I can't see any clipping, so maybe the power is just low?  One thing that was funny though is the beam coming directly from the laser.  There is the main, regular beam, and then there is a thin horizontal line of red light also coming straight out of the laser.  I don't know what to do about that, except perhaps put an iris right after the HeNe, to block the horizontal part?  I'm not sure that it's doing anything bad to the optic though, since the horizontal part gets clipped by other optics before the beam enters the vacuum, so there is no real irregularity on the beam incident on the QPD.

I realigned the oplev on the QPD, using last night's ITMX alignment + whatever drift it picked up over night, so it may need re-recentering after Xarm is nicely aligned.

  6603   Fri May 4 17:46:46 2012 JenneUpdateGreen LockingPSL doubling oven back on

While walking past the PSL, I noticed that the PSL's doubling oven's heater was still disabled from the power outage.  As with the ETMY heater, I hit the Enable button, and it started warming up (according to the front panel at least).

  6617   Mon May 7 21:19:00 2012 JenneUpdateSUSETMX oplev

I'm still not super happy with the low power level of the ETMX oplev, so I went to investigate.

OpLevETMX_1100days.png

This is a 3-year plot.  The first ~year in the plot, the oplev sum is ~15000 cts, and in the most recent year, it's ~1000 cts.  A new HeNe was installed in May 2011 (elog 4686), with an output of 2.6mW, after the old one had died.  When the new one was installed, Steve said that it was giving ~1400 counts, so maybe 1000 isn't too, too embarrassing.  There is, however, a lens on the injection side, which is AR coated for 1064.  The power before this lens (measured with the Ophir, set to 632nm) was ~2.6mW.  The power after this lens was ~1.5mW.  Now THAT is embarrassing.  I'm adding replacing that lens to the to-do list (elog 6595), although I don't want to do it until such a time (maybe in an hour, maybe in a few days?) when I've got the Xarm locked / aligned, so I can nicely re-center the oplev.  UPDATE:  The lens is a KBC 037 (-100) lens, and the sticker on the lens mount says coated for 1064.  We don't have any KBC037's in the visible lens kits, so we need to get one before I can do this replacement (PURCHASED 10pm).

There is an elog (elog 5004) from July 2011, which mentions that these channels have not been saved for a long time, so that's why there's the year-long gap. 

 

  6620   Tue May 8 03:33:24 2012 JenneUpdateSUSNew misalign / restore scripts for IFO_ALIGN screen

Since Den wasn't able to fix c1sus (make it talk to the framebuilder) before he left a few hours ago, I decided to do some housekeeping rather than actual locking. 

I wrote new save / misalign / restore scripts for all of the suspended optics on the C1IFO_ALIGN screen.  Adding save / restore versions for the mode cleaner optics should be quick and easy.  Now when you use the ! button for each optic, it points you to the new scripts.  I still have the burt capabilities there, but the restore script has the burt-restore line commented out.

Functionality:

SAVE:  burt-save the PIT_COMM and YAW_COMM values, as well as write those values and the date to a text file.

MISALIGN:  Turn off oplevs, move 100 steps of 0.01 in the "+" direction.

RESTORE: Move ~100 steps toward the saved value, until you're within 0.001 of the saved value (step size is "saved val" minus "current val" divided by 100).  Then just write the saved value to the slider (otherwise if the slider were touched between the last "save" and the restore, we might not be able to step precisely to the value we want). Turn oplevs back on.

Scripts are in the same place the old ones used to live:  ...../caltech/c1/medm/c1ifo/cmd/   New scripts are C1IFO_OPTIC(save/restore/misalign)_soft.cmd

I'm checking this one off of the to-do list.

 

Good things:  (a) I remembered / re-learned / just plain learned a lot about scripting.  (b) the optics are now walked slowly over to their misaligned state, and slowly walked back.  The past regime had the optics suddenly kicked over by a lot, sometimes enough to trip / come close to tripping watchdogs, which was never good.

Bad things: it took a long time.  Now it's bedtime.

  6621   Tue May 8 03:38:28 2012 JenneUpdateGeneralMEDM svn emergency!!!

We officially are *failures* at svn-ing our scripts and screens.  This is NOT OKAY.  I checked in a few things, since there were already folders on the svn, but many things don't have folders created.  It's a hot mess.  We need to get our shit together, and become as disciplined about MEDM and scripts as we have been (under Jamie's watchful eye) of the simulink models.

I'm not going to start fixing it all right now.  It might not even happen at this point until after GWADW, but it needs to happen.

  6625   Tue May 8 16:43:15 2012 JenneUpdateCDSDegenerate channels, potentially a big mess

Rana theorized that we're having problems with the MC error signal in the OAF model (separate elog by Den to follow) because we've named a channel "C1:IOO-MC_F", and such a channel already used to exist.  So, Rana and I went out to do some brief cable tracing.

MC Servo Board has 3 outputs that are interesting:  "DAQ OUT" which is a 4-pin LEMO, "SERVO OUT" which is a 2-pin LEMO, and "OUT1", which is a BNC->2pin LEMO right now.

DAQ OUT should have the actal MC_F signal, which goes through to the laser's PZT.  This is the signal that we want to be using for the OAF model.

SERVO OUT should be a copy of this actual MC_F signal going to the laser's PZT.  This is also acceptable for use with the OAF model.

OUT1 is a monitor of the slow(er) MC_L signal, which used to be fed back to the MC2 suspension.  We want to keep this naming convention, in case we ever decide to go back and feed back to the suspensions for freq. stabilization.

Right now, OUT1 is going to the first channel of ADC0 on c1ioo.  SERVOout is going to the 7th channel on ADC0.  DAQout is going to the ~12th channel of ADC1 on c1ioo.  OUT1 and SERVOout both go to the 2-pin LEMO whitening board, which goes to some new aLIGO-style ADC breakout boards with ribbon cables, which then goes to ADC0.  DAQout goes to the 4pin LEMO ADC breakout, (J7 connector) which then directly goes to ADC1 on c1ioo.

So, to sum up, OUT1 should be "adc0_0" in the simulink model, SERVOout should be "adc0_6" on the simulink model, and DAQout should be "adc1_12" (or something....I always get mixed up with the channel counting on 4pin ADC breakout / AA boards). 

In the current simulink setup, OUT1 (adc0_0) is given the channel name C1:IOO-MC_F, and is fed to the OAF model.  We need to change it to C1:IOO-MC_L to be consistent with the old regime.

In the current simulink setup, SERVOout (adc0_6) is given the channel name C1:IOO-MC_SERVO.  It should be called C1:IOO-MC_F, and should go to the OAF model.

In the current simulink setup,DAQout (~adc1_12) doesn't go anywhere.  It's completely not in the system.  Since the cable in the back of this AA / ADC breakout board box goes directly to the c1ioo I/O chassis, I don't think we have a degenerate MC_F naming situation.  We've incorrectly labeled MC_L as MC_F, but we don't currently have 2 signals both called MC_F.

Okay, that doesn't explain precisely why we see funny business with the OAF model's version of MCL, but I think it goes in the direction of ruling out a degenerate MC_F name.

Problem:  If you look at the screen cap, both simulink models are running on the same computer (c1ioo), so when they both refer to ADC0, they're really referring to the same physical card.  Both of these models have adc0_6 defined, but they're defined as completely different things.  Since we can trace / see the cable going from the MC Servo Board to the whitening card, I think the MC_SERVO definition is correct.  Which means that this Green_PH_ADC is not really what it claims to be.  I'm not sure what this channel is used for, but I think we should be very cautious and look into this before doing any more green locking.  It would be dumb to fail because we're using the wrong signals.

 

  6626   Tue May 8 17:48:50 2012 JenneUpdateCDSOAF model not seeing MCL correctly

Den noticed this, and will write more later, I just wanted to sum up what Alex said / did while he was here a few minutes ago....

 

Errors are probably really happening.... c1oaf computer status 4-bit thing:  GRGG.  The Red bit is indicating receiving errors.  Probably the oaf model is doing a sample-and-hold thing, sampling every time (~1 or 2 times per sec) it gets a successful receive, and then holding that value until it gets another successful receive. 

Den is adding EPICS channels to record the ERR out of the PCIE dolphin memory CDS_PART, so that we can see what the error is, not just that one happened.

Alex restarted oaf model:  sudo rmmod c1oaf.ko, sudo insmod c1oaf.ko .  Clicked "diag reset" on oaf cds screen several times, nothing changed.  Restarted c1oaf again, same rmmod, insmod commands.

Den, Alex and I went into the IFO room, and looked at the LSC computer, SUS computer, SUS I/O chassis, LSC I/O chassis and the dolphin switch that is on the back of the rack, behind the SUS IO chassis.  All were blinking happily, none showed symptoms of errors.

Alex restarted the IOP process:  sudo rmmod c1x04, sudo insmod c1x04.  Chans on dataviewer still bad, so this didn't help, i.e. it wasn't just a synchronization problem.  oaf status: RRGG. lsc status: RGGG. ass status: RGGG.

sudo insmod c1lsc.ko, sudo insmod c1ass.ko, sudo insmod c1oaf.ko .  oaf status: GRGG. lsc status: GGGG. ass status: GGGG.  This means probably lsc needs to send something to oaf, so that works now that lsc is restarted, although oaf still not receiving happily.

Alex left to go talk to Rolf again, because he's still confused.

Comment, while writing elog later:  c1rfm status is RRRG, c1sus status is RRGG, c1oaf status is GRGG, both c1scy and c1scx are RGRG.  All others are GGGG.

  6627   Wed May 9 00:45:13 2012 JenneUpdateCDSNo signals for DTT from SUS

Upgrades suck.  Or at least making everything work again after the upgrade.

On the to-do list tonight:  look at OSEM sensor and OpLev spectra for PRM, when PRMI is locked and unlocked.  Goal is to see if the PRM is really moving wildly ("crazy" as Kiwamu always described it) when it's nicely aligned and PRMI is locked, or if it's an artifact of lever arm between PRM and the cameras (REFL and AS).

However, I can't get signals on DTT.  So far I've checked a bunch of signals for SUS-PRM, and they all either (a) are just digital 0 or (b) are ADC noise.  Lame.

Steve's elog 5630 shows what reasonable OpLev spectra should look like:  exactly what you'd expect.

Attached below is a small sampling of different SUS-PRM signals.  I'm going to check some other optics, other models on c1sus, etc, to see if I can narrow down where the problem is.  LSC signals are fine (I checked AS55Q, for example).

UPDATE:  SRM channels are same ADC noise.  MC1 channels are totally fine.  And Den had been looking at channels on the RFM model earlier today, which were fine.

ETMY channels - C1:SUS-ETMY_LLCOIL_IN1 and C1:SUS-ETMY_SUSPOS_IN1 both returned "unable to obtain measurement data".  OSEM sensor channels and OpLev _PERROR channel were digital zeros.

ETMX channels were fine

UPDATE UPDATE:  Genius me just checked the FE status screen again.  It was fine ~an hour ago when I sat down to start interferometer-izing for the night, but now the SUS model and both of the ETMY computer models are having problems connecting to the fb.  *sigh* 

  6628   Wed May 9 01:14:44 2012 JenneUpdateCDSNo signals for DTT from SUS

Quote:

UPDATE UPDATE:  Genius me just checked the FE status screen again.  It was fine ~an hour ago when I sat down to start interferometer-izing for the night, but now the SUS model and both of the ETMY computer models are having problems connecting to the fb.  *sigh* 

 Restarted SUS model - it's now happy. 

c1iscey is much less happy - neither the IOP nor the scy model are willing to talk to fb.  I might give up on them after another few minutes, and wait for some daytime support, since I wanted to do DRMI stuff tonight.

Yeah, giving up now on c1iscey (Jamie....ideas are welcome).  I can lock just fine, including the Yarm, I just can't save data or see data about ETMY specifically.  But I can see LSC data, so I can lock, and I can now take spectra of corner optics.

  6629   Wed May 9 04:47:20 2012 JenneUpdateLockingPRM is really moving when PRMI locked

A few things tonight.  Locked both arms simultaneously (IR only).  Locked MICH, Locked PRMI, although it doesn't like staying locked for more than a minute or so, and not always that long.

Locking PRCL was possible by getting rid of the power normalization.  We need to get some triggering going on for the power norm.  I think it's a good idea for after the cavity is locked, but when PRCL is not locked, POP22 is ~0, so Refl33/Pop22 is ~inf.  The PRCL loop kept railing at the Limit that was set.  Getting rid of the power normalization fixed this railing. 

I took some spectra of PRM's oplev, while PRMI was locked, and unlocked.  The PRM is definitely moving more when the cavity is locked.  I'm not sure yet what to do about this, but the result was repeatable many times (~6 or 7 over an hour or so).  The OpLev spectra when PRMI was locked didn't depend too strongly on the PRM's alignment, although I think that's partly because I wasn't able to really get the PRM to optimal alignment.  I think POP22I is supposed to get to 7 or so...last week with Koji it was at least flashing that high.  But tonight I couldn't get POP22I above 4, and most of the time it wouldn't go above 3.  As I was aligning PRM and the circulating SB power increased, POP22I fluctuations increased significantly, then the cavity unlocked.  So maybe this is because as I get closer, PRM gets more wiggly.  I tried playing 'chicken' with it, and took spectra as I was aligning PRM (align, get some improvement, stop to take spectra, then align more, stop to take spectra....) but usually it would fall out of lock after 1-2 iterations of this incremental alignment and I'd have to start over.  When it relocked, it usually wouldn't come back to the same level of POP22I, which was kind of disappointing. 

In the PDF attached, pink and light blue are when the PRMI is locked, and red and dark blue are no PRCL feedback.  The effect is more pronounced with Pitch, but it's there for both Pitch and Yaw.

Also, I need to relook at my new restore/misalign scripts.  They were acting funny tonight, so I'm taking back my "they're awesome, use them without thinking about it" certification.

  6634   Wed May 9 14:32:31 2012 JenneUpdateCDSBurt restored

Den and Alex left things not-burt restored, and Den mentioned to me that it might need doing.

I burt restored all of our epics.snaps to the 1am today snapshot.  We lost a few hours of striptool trends on the projector, but now they're back (things like the BLRMS don't work if the filters aren't engaged on the PEM model, so it makes sense).

  6636   Wed May 9 15:50:13 2012 JenneBureaucracyGeneral40m Meeting Action Items

I'm combining the IFO check-up list (elog 6595) and last week's action items list (elog 6597).  I thought about making it a wiki page, but this way everyone has to at least scroll past the list ~1/week.

Feel free to cross things out as you complete them, but don't delete them.  Also, if there's a WHO?? and you feel inspired, just do it!

PRIORITY ITEMS:

Dither-align arm to get IR on actuation nodes, align green beam - JENNE

Arm cavity sweeps, mode scan - JENNE

ASS doesn't run on Ubuntu! or CentOS Fix it! - JENNE, JAMIE's help

Input matricies, output filters to tune SUS.  check after upgrade. - JENNE

POX11 whitening is not toggling the analog whitening??? - JAMIE, JENNE, KOJI

OAF comparison plot, both online and offline, comparing static, adaptive and static+adaptive - DEN

 

THE FULL LIST:

  • General
    • Revamp control room - more monitors, maybe move TV shelves. - JENNE
    • Audio system for the signals!!!! Even a crappy one! - LEO
  • SUS
    • ETMX oplev - replace 1064nm lens with 632nm lens (KBC037, -100) - JENNE
    • Input matricies, output filters to tune SUS.  check after upgrade. - JENNE
  • IFO
    • Fix occasional common-mode power transient in the arm transmissions. Probably an alignment thing. Would ISS help? - WHO??
    • Drift of the green incident axis -> Assess the amount of the drift / replace the mount - JENNE, KOJI
    • Calibration of POP22 / AS110 - JENNE
    • PMC/IMC/ARM characterization (loss, finesse, reflectivity, etc) - JENNE
    • Dither-align arm to get IR on actuation nodes, align green beam - JENNE
    • Arm cavity sweeps, mode scan - JENNE
    • Align AS OSA (others?) - JENNE  
    • Investigate PRMI glitches, instability - JENNE
    • PZT or Picomotor mounts for PSL/ALS beams - WHO??
    • ALS on the both arm simultaneously / common / diff ALS scripts - JENNE
  • CDS
    • Capture OSA signals in CDS (the 'scope TDS1001B has a USB port in the back for connecting to the computer) - WHO??
    • Transmon (arms) for high and low power - WHO??
    • POX11 whitening is not toggling the analog whitening??? - JAMIE, JENNE, KOJI
    • Install guardians to monitor EPICS values - WHO??
  • Electronics
    • Actuator noise level characterization (coil driver response in V/m & coil driver noise level V/rtHz) - WHO??
    • Beat box - KOJI
    • I/Q DFD - WHO??
    • Improvement of POP22/110/AS110 RF circuits. - WHO??
  • MEDM
    • Complete 40m overview screen - everything should be clickable with pseudo 3D icons - JENNE
    • Better suspension screen - copy from sites. - WHO??
    • Script to generate a MEDM tree - WHO??
    • Resurrect MEDM snapshots - WHO??
    • New ! buttons on every screen, include wiki page - WHO??
  • SCRIPT
    • Locking scripts with integrator triggers / disabling when unlocked - JENNE
    • Daily diagnosis of the MC spot positions (there must be something already...) - SURESH?
    • Daily/occasional adjustment of the incident axis on the MC - SURESH?
    • IFO_CONFIGURE scripts still do a burt restore, so step the optics.  Need to remove optic alignment from config .snap files, use reg restore script instead. - JENNE
    • OPLEV/OSEM trending script before the IFO work for diagnosis. - JENNE
    • Auto-locker for arms - JENNE
    • Auto-locker for PMC, PSL things - DEN
    • Diagnostic script for CDS - mx_stream, other stuff. - WHO??
  • Video
    • If each video screen has a caption, that would be great - WHO??
    • GUI interface of "videoswitch" - MIKEJ
    • Mouse Jiggler for Zita (called Swinput?) - JENNE
  • Ubuntu vs. CentOS
    • burttoday is not aliased in ubuntu.    burttoday:      aliased to cd /opt/rtcds/caltech/c1/burt/autoburt/today/ - JAMIE
    • Upgrade Rossa, Allegra, make sure they connect to DTT, Dataviewer, AWG. - JAMIE
    • ASS doesn't run on Ubuntu! or CentOS Fix it! - JENNE, JAMIE's help
    • CentOS machines cannot open simulink models properly (get "Bad Link"s everywhere, so you can't do anything useful) - JAMIE
  • MM
    • IPPOS beam measurement - SURESH with JENNE
    • AS beam measurement (if beam is bright enough) - SURESH and JENNE
    • Mode matching calculations, sensitivity to MC waist measurement errors, PRM position - JENNE
    • Think up diagnostic measurement to determine mode matching to PRC while chambers are open, while we tweak MMT - JAMIE, JENNE, KOJI, SURESH
    • Use sensoray to capture, measure beam mode at AS, POP - YUTA
  • Stray Light
    • Scattered light measurement at the end stations: design / confirmation of the mechanical parts/optics/cameras - JAN
  • OAF
    • OAF comparison plot, both online and offline, comparing static, adaptive and static+adaptive - DEN
    • Static-only OAF noise budget (Adaptive noise budget as next step) - DEN
    • Build amplifiers for new small microphones - DEN
    • Script for daily / weekly re-calculation of Wiener, post to elog if need changing - DEN
  • Tip Tilts
    • Prepare electronics for TTs (coil drivers) - JAMIE
    • In-air TT testing to confirm we can control / move TTs before we vent - SURESH
    • Connect TTs to digital system and controls, lay cables if needed - JAMIE with SURESH
  • RF Photodiodes
    • Opto Energy diode laser - look into buying - ERICG
    • Purchase fibers, splitters, other supplies - ERICG
    • Set everything up - ERICG

  6641   Fri May 11 17:21:56 2012 JenneUpdateIOOOAF left enabled - MC unlocked for more than an hour

No leaving the OAF running until you're sure (sure-sure, not kind of sure, not pretty sure, but I've enabled guardians to make sure nothing bad can happen, and I've been sitting here watching it for 24+ hours and it is fine) that it works okay.

OAF (both adaptive and static paths) were left enabled, which was kicking MC2 a lot.  Not quite enough that the watchdog tripped, but close.  The LSCPOS output for MC2 was in the 10's or 100's of thousands of counts.  Not okay.

This brings up the point though, which I hadn't actively thought through before, that we need an OAF watchdog.  An OAF ogre?  But a benevolent ogre.  If the OAF gets out of control, it's output should be shut off.  Eventually we can make it more sophisticated, so that it resets the adaptive filter, and lets things start over, or something. 

But until we have a reliable OAF ogre, no leaving the adaptive path enabled if you're not sitting in the control room.  The static path should be fine, since it can't get out of control on it's own.

Especially no leaving things like this enabled without a "I'm leaving this enabled, I'll be back in a few hours to check on it" elog! 

  6646   Wed May 16 11:53:45 2012 JenneUpdateComputersImage Subtraction

Quote:

It doesn't look all that different, but the first image didn't have that much lit up in it to begin with.

 This is totally cool!  You can see that the OSEM lights are almost entirely gone in the subtracted image.

Can you switch to trying with one of the *TM*F cameras?  (ITMXF, ITMYF, ETMYF, ETMXF)  They tend to have more background, so there should be a more dramatic subtraction.  Den or Suresh should be able to lock one of the arms for you.

  6660   Tue May 22 13:06:11 2012 JenneUpdateIOOWFS didn't turn off automatically

I just sat down in the control room, and discovered the PMC (and everything else) unlocked.  I relocked the PMC, but the MC wasn't coming back.  After a moment of looking around, I discovered that the WFS were on, and railing.  I ran the "turn WFS off" script, and the MC came back right away, and the WFS came on as they should.

We need to relook at the WFS script, or the MC down script, to make sure that any time the MC is unlocked, no matter why it unlocked, the WFS output is off and the filter histories are cleared.

  6667   Wed May 23 13:57:11 2012 JenneBureaucracyGeneral40m Meeting Action Items

PRIORITY ITEMS:

Align Ygreen beam - JENNE, YUTA

Arm cavity sweeps, mode scan - JENNE, YUTA

ASS doesn't run on Ubuntu! or CentOS Fix it! - YUTA, JENNE, JAMIE's help

Input matricies, output filters to tune SUS.  check after upgrade. - JENNE

POX11 whitening is not toggling the analog whitening??? - JAMIE, JENNE, KOJI

Decide on plots for 40m Summary page - DEN, STEVE, JENNE, KOJI, JAMIE, YUTA, SURESH, RANA, DUNCAN from Cardiff/AEI

 Look into PMC PZT drift - PZT failing? Real MC length change? - JENNE, KOJI, YUTA

THE FULL LIST:

  • General
    • Revamp control room - more monitors, maybe move TV shelves. - JENNE
    • Audio system for the signals!!!! Even a crappy one! - LEO
  • SUS
    • Input matricies, output filters to tune SUS.  check after upgrade. - JENNE
  • IFO
    • Fix occasional common-mode power transient in the arm transmissions. Probably an alignment thing. Would ISS help? - MIKEJ?
    • Drift of the green incident axis -> Assess the amount of the drift / replace the mount - JENNE, KOJI
    • Calibration of POP22 / AS110 - JENNE
    • PMC/IMC/ARM characterization (loss, finesse, reflectivity, etc) - JENNE
    • Align green beam - JENNE, YUTA
    • Arm cavity sweeps, mode scan - JENNE, YUTA
    • Align AS OSA (others?) - JENNE  
    • Investigate PRMI glitches, instability - JENNE
    • PZT or Picomotor mounts for PSL/ALS beams - WHO??
    • ALS on the both arm simultaneously / common / diff ALS scripts - JENNE
  • CDS
    • Capture OSA signals in CDS (the 'scope TDS1001B has a USB port in the back for connecting to the computer) - WHO??
    • Transmon (arms) for high and low power - WHO??
    • POX11 whitening is not toggling the analog whitening??? - JAMIE, JENNE, KOJI
    • Install guardians to monitor EPICS values - WHO??
  • Electronics
    • Actuator noise level characterization (coil driver response in V/m & coil driver noise level V/rtHz) - WHO??
    • Beat box - KOJI
    • I/Q DFD - WHO??
    • Improvement of POP22/110/AS110 RF circuits. - WHO??
  • MEDM
    • Complete 40m overview screen - everything should be clickable with pseudo 3D icons - JENNE
    • Better suspension screen - copy from sites. - WHO??
    • Script to generate a MEDM tree - WHO??
    • Resurrect MEDM snapshots - WHO??
    • New ! buttons on every screen, include wiki page - WHO??
    • Screen for errors in signal transmission between models - DEN
  • SCRIPT
    • Locking scripts with integrator triggers / disabling when unlocked - JENNE
    • Daily diagnosis of the MC spot positions (there must be something already...) - SURESH?
    • Daily/occasional adjustment of the incident axis on the MC - SURESH?
    • IFO_CONFIGURE scripts still do a burt restore, so step the optics.  Need to remove optic alignment from config .snap files, use reg restore script instead. - JENNE
    • OPLEV/OSEM trending script before the IFO work for diagnosis. Put into 40m summary screen. - JENNE, DUNCAN from Cardiff/AEI
    • Auto-locker for arms - JENNE
    • Auto-locker for PMC, PSL things - DEN
    • Diagnostic script for CDS - mx_stream, other stuff. - WHO??
  • Video
    • If each video screen has a caption, that would be great - WHO??
    • GUI interface of "videoswitch" - MIKEJ
    • Mouse Jiggler for Zita (called Swinput?) - JENNE
  • Ubuntu vs. CentOS
    • burttoday is not aliased in ubuntu.    burttoday:      aliased to cd /opt/rtcds/caltech/c1/burt/autoburt/today/ - JAMIE
    • Upgrade Allegra, make sure connect to DTT, Dataviewer, AWG. - JAMIE
    • ASS doesn't run on Ubuntu! or CentOS Fix it! - JENNE, JAMIE's help
    • CentOS machines cannot open simulink models properly (get "Bad Link"s everywhere, so you can't do anything useful) - JAMIE
  • MM
    • IPPOS beam measurement - SURESH with JENNE
    • AS beam measurement (if beam is bright enough) - SURESH and JENNE
    • Mode matching calculations, sensitivity to MC waist measurement errors, PRM position - JENNE
    • Think up diagnostic measurement to determine mode matching to PRC while chambers are open, while we tweak MMT - JAMIE, JENNE, KOJI, SURESH
    • Use sensoray to capture, measure beam mode at AS, POP - YUTA
  • Stray Light
    • Scattered light measurement at the end stations: design / confirmation of the mechanical parts/optics/cameras - JAN
    • Align AUX laser into dark port - KOJI, YUTA
  • OAF
    • OAF comparison plot, both online and offline, comparing static, adaptive and static+adaptive - DEN
    • Static-only OAF noise budget (Adaptive noise budget as next step) - DEN
    • Script for daily / weekly re-calculation of Wiener, post to elog if need changing - DEN
  • Tip Tilts
    • Prepare electronics for TTs (coil drivers) - JAMIE
    • In-air TT testing to confirm we can control / move TTs before we vent - SURESH
    • Connect TTs to digital system and controls, lay cables if needed - JAMIE with SURESH
  • RF Photodiodes
    • Opto Energy diode laser - purchase - ERICG
    • Purchase fibers, splitters, other supplies - ERICG
    • Set everything up - ERICG

 

ELOG V3.1.3-