40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 202 of 344  Not logged in ELOG logo
IDdown Date Author Type Category Subject
  7186   Wed Aug 15 01:14:19 2012 YaakovUpdatePEMDifferential Motion of X and Y Arm

Den and I measured the differential motion of the x and y arms using Guralp 1 at the end of the y arm, Guralp 2 at the beamsplitter, and the Streckeisen at the end of the x arm.

I calibrated the Streckeisen to the Guralp by calculating the relative gain of the seismometer signals at the microseism. The Guralp 1-y amplitude was 1.0237 times Guralp 2-y and Guralp 2-x was 38.54 times STS-x. The Guralp calibration (to go from counts to meters) I used was 0.61/1000/800/80/(2*pi*f) m/count.

The differential motion should keep decreasing at low frequencies because the ground will move together at such large wavelengths. It goes up because the seismometer noise begins to dominate at low frequencies (below about 0.5 Hz). Another possible error source could be that the seismometers are not perfectly aligned along the arm.

diff_motion_x_arm.pngdiff_motion_y_arm.png

Attachment 1: diff_motion_x_arm.png
diff_motion_x_arm.png
Attachment 2: diff_motion_y_arm.png
diff_motion_y_arm.png
  7185   Wed Aug 15 00:52:17 2012 DenUpdateWienerFilteringfilter calculation

A Matlab script to calculate Wiener filter coefficients and convert fir to iir is ready. Input is a file with zero mean witness and desired signals, output is a Foton zpk command to specify iir filter.

The plot shows comparison of offline fir , iir and online iir filtering. Spectrum below 4 Hz is still oscillating due to acoustic coupling, this is not a filtering effect. At 1 Hz actuator is badly compensated, more work should be done. Other then that online and offline filtering are the same.

wiener.png

  7184   Tue Aug 14 22:16:46 2012 JenneUpdateLSCLSC whitening triggers

I'm ~30% of the way through implementing LSC whitening filter triggers.  I think that everything I have done should be compile-able, but please don't compile c1lsc tonight.  I haven't tested it, and some channel names have changed, so I need to fix the LSC screen when I'm not falling asleep.

Also, Rana pointed out that we may not want the whitening to trigger on immediately upon acquiring lock - if there are other modes ringing down in the cavity, or some weird transients, we don't want to amplify those signals.  We want to wait a second or so for them to die down, then turn on analog whitening.  Jamie - do you know how long the "unit delay" delays things in the RCG?  Do those do what I naively think they do?  I'll ask you in the morning.

  7183   Tue Aug 14 21:01:51 2012 ranaUpdatePEMBLRMS

Screenshot-Untitled_Window.png

I fixed up the seismic.stp file for the StripTool display:

  1. All BLRMS channels now have a y-axis range of 3 decades. So they all are displaying the same relative changes.
  2. So the 0.01-0.1 Hz band which is all over the place is real, sort of. Masha says that it is due to the seismometer signal being dominated by noise below 0.1 Hz. She is going to fix this somehow.
  3. I changed the samping time from 1 sec. to 10 sec. to make the traces less fuzzy.
  4. We (Masha / Liz) should harmonize the colors of this file with what's on the summary pages.
  7182   Tue Aug 14 17:47:44 2012 JamieUpdateCDSc1sus machine replaced

Rolf and Alex came back over with a replacement machine for c1sus.   We removed the old machine, removed it's timing, dolphin, and PCIe extension cards and put them in the new machine.  We then installed the new machine and booted it and it came up fine.  The BIOS in this machine is slightly different, and it wasn't having the same failure-to-boot-with-no-COM issue that the previous one was.  The COM ports are turned off on this machine (as is the USB interface).

Unfortunately the problem we were experiencing with the old machine, that unloading certain models was causing others to twitch and that dolphin IPC writes were being dropped, is still there.  So the problem doesn't seem to have anything to do with hardware settings...

After some playing, Rolf and Alex determined that for some reason the c1rfm model is coming up in a strange state when started during boot.  It runs faster, but the IPC errors are there.  If instead all models are stopped, the c1rfm model is started first, and then the rest of the models are started, the c1rfm model runs ok.  They don't have an explanation for this, and I'm not sure how we can work around it other than knowing the problem is there and do manual restarts after boot.  I'll try to think of something more robust.

A better "fix" to the problems is to clean up all of our IPC routing, a bunch of which we're currently doing very inefficient right now.  We're routing things through c1rfm that don't need to be, which is introducing delays.  It particular, things that can communicate directly over RFM or dolphin should just do so.  We should also figure out if we can put the c1oaf and c1pem models on the same machine, so that they can communicate directly over shared memory (SHMEM).  That should cut down on overhead quite a bit.  I'll start to look at a plan to do that.

 

  7181   Tue Aug 14 16:33:51 2012 SashaUpdateComputer Scripts / ProgramsSimPlant indicator added

I added an indicator to the watch dog screen so that a little "SP" icon appears whenever the SimPlant is on. Since we only have one simplant (ETMX), only ETMX has the simPlant indicator. However, since assymetry is ugly, I moved all of the OL icons over so that they're in a line and so that there is room for future SP icons.

I also fixed the link to the Watchdogs on the main SUS screens (it was dead, but now it is ALIVE).

  7180   Tue Aug 14 16:19:12 2012 JenneUpdateGreen LockingXend doubling crystal heater unplugged, replugged

I went down to the Xend table to look at it to understand Steve's proposal, and I noticed that the doubling crystal's heater's cable is mushed between the table's edge and the black table cover wall.  This made me sad, so I disabled the heater, turned it off, then unplugged the cable from the back of the controller.  I tried to re-route the cable through the hole in the black table cover wall, but going that way the cable is ~1 foot too short.  So I put it back the way it was, but used a totally hacky solution to prevent the cable from being mushed.  I put a dog clamp right at the edge of the table so it is pushing on the table cover wall a little bit, to give the cable space to get out.  This is very mickey mouse, and kind of lame.  But we either need to make a cable extension, or somehow get the heater controller to sit much, much higher under the table.

I plugged the heater controller back in, and turned it back on to the same setpoint that it was at (I think 37.5C).  It's probably warm by now, but when I turned it back on, the heater's actual temp was 33C.

  7179   Tue Aug 14 15:58:44 2012 JenneUpdateGeneralTranslation to English: larger optical tables at the ends

Quote:

Quote:

I'm proposing larger optical tables at the ends to avoid the existing overcrowding. This would allow the initial pointing and optical level beams to set up correctly.

The existing table is 4 x 2 would be replaced by 4' x 3'   We would lose only ~3" space  toward exist door.

I'm working on the new ACRYLIC TABLE COVER for each end that will cost around $4k ea.  The new cover should fit the larger table.

Let me know what you think.

I'm not sure I see the motivation.  The tables are a little tight, but not that much.  If the issue is the incidence angle of the IP and OPLEV beams, then can't we solve that just by moving the table closer to the viewport?

The overcrowding alone doesn't seem bad enough to justify replacing the tables.

Steve pointed out to me (this is not in his original elog, although you can see it in the photo if you look closely), that we can't really move the table legs any closer to the chamber.  We have maybe 3" of clearance between the table leg and the blue support tube that supports the bottom of the stack.  Therefore, we can't just

So Steve's proposal is to leave the legs exactly where they are, and just put a larger table on those legs.  This leaves 9" unsupported on the chamber side, and 3" unsupported on the far side.  The tables are 4" thick. 

Steve also mentions that we will lose 1.5" on all 4 sides of the table, with the new acrylic boxes, so we'll be down to 1'9" unless we get the larger table, in which case we'd have 2'9", and 3'9" on the long direction.

I would like to see a sketch of the end tables, so we can see if 1'9" x 3'9" is enough.  Manasa is working on a new end table layout in parallel to the ringdown stuff.  If we're actually concerned about the input angle of the oplevs, then to fix that we need to either get the bigger table and hang it off the edge of the legs, or perhaps as Dmass suggested, get a "doggy cone collar", and give ourselves a larger opening angle of access to the viewport, from the current table location.

 

  7178   Tue Aug 14 14:26:40 2012 SteveUpdateCamerascameras touched up

 I optimized the TM views with illuminator light on quad1  It actually looks better there.

I'll post a dark-  OSEM light only in jpg tomorrow.  ETMY camera is malfunctioning in dark condition now.

 

Attachment 1: cameras.png
cameras.png
  7177   Tue Aug 14 13:21:34 2012 JenneUpdateCDSIPC senders no nothing about rates of IPC receivers, we need to filter signals appropriately

Quote:

Quote:

When signals are transmitted between the models running at different rates, no AI or AA filters are automatically applied. We need to fix our models.

This is known, but we just haven't fully groked it yet.  We need to look closely at every place we have IPCs between models running at different rates.  The sender has no information about receivers, so it can't reasonably do anything to pre-filter the signal on it's own.

So for transmission from:

  • faster -> slower models: add anti-aliasing on the sender side
  • slower -> faster models: add anti-imaging on the receiver side

 *sigh* This is one of those things that I meant to take care of months ago, but haven't yet.  I agree that it needs doing.  It's been on my whiteboard to-do list for a long time now.  Bad Jenne for not taking care of it.

  7176   Tue Aug 14 11:49:15 2012 DenUpdateCDSDebugging of c1sus machine and c1rfm models

Quote:

 

  We might just need to reduce the load on c1rfm, maybe by introducing a c1rfm2?

 

 A huge data flow goes from PEM to OAF through RFM. I think we need to make PEM and OAF run on the same machine and transmit signals through the shared memory.

  7175   Tue Aug 14 11:46:22 2012 JamieUpdateCDSIPC senders know nothing about rates of IPC receivers, we need to filter signals appropriately

Quote:

When signals are transmitted between the models running at different rates, no AI or AA filters are automatically applied. We need to fix our models.

ai.png

This is known, but we just haven't fully groked it yet.  We need to look closely at every place we have IPCs between models running at different rates.  The sender has no information about receivers, so it can't reasonably do anything to pre-filter the signal on it's own.

So for transmission from:

  • faster -> slower models: add anti-aliasing on the sender side
  • slower -> faster models: add anti-imaging on the receiver side
  7174   Tue Aug 14 11:39:13 2012 Jamie, Rolf, AlexUpdateCDSDebugging of c1sus machine and c1rfm models

Rolf and Alex came over this morning to see if they could help debug some issues we have been seeing with IPC transmission between the c1sus and c1lsc machines.

c1oaf, which runs on c1lsc, sees a lot of transmission errors on it's dolphin receivers from c1rfm, which runs on c1sus.  Their speculation is that c1rfm is trying to process too many channels, and it's not able to read off all the RFM channels and retransmit them over dolphin to c1lsc before the end of cycle.  To test this they turned off all RFM reads on c1rfm and the dolphin receiver errors on c1lsc all went away.  We ran into other problems before I had a chance to pester them about what the take-away is here.  We might just need to reduce the load on c1rfm, maybe by introducing a c1rfm2?

We then tried to debug an issue in the c1sus machine where models would occasionally run slow for a cycle, or run slow when a different model on the machine was loaded or unloaded.  The suspect was BIOS settings.  Unfortunately, we ran into trouble when we tried to tweak the BIOS setting on c1sus.  We found that all the serial/COM ports were on, which is usually a big no-no for the RTS (the interrupts cause many cycle delays).  However, turning off the COM ports prevented the machine from booting at all.  This was a big mystery.  The machine seemed to be acting flaky in general as well, since the boot (pre-kernel) would hang in various places after different reboots.  Alex went to grab us a spare machine that we're going to try swapping out this afternoon.

  7173   Tue Aug 14 11:33:14 2012 Jamie Alex DenUpdateCDSAI and AA filters

When signals are transmitted between the models running at different rates, no AI or AA filters are automatically applied. We need to fix our models.

ai.png

  7172   Tue Aug 14 08:43:42 2012 SteveUpdateIOOlaser off and on

The janitor accidentally hit the laser emergency kill switch at room 103  entry door. It did shut down the PSL laser. The laser was turned back on.

Attachment 1: 1day.png
1day.png
  7171   Tue Aug 14 04:53:45 2012 YoichiSummaryLSCX-Arm noise spectrum

Yoichi, Rana

Here is the noise spectrum of the X-arm error signal along with the TRX DC power fluctuations.

The spectra were taken while the whitening filters for POX11 were OFF.

EDIT (Integrity Fairy): Shall we assume these units are "Intergalactic translational qubits/sqrt(Hz)"?

Attachment 1: xarm-spectrum.png
xarm-spectrum.png
  7170   Tue Aug 14 04:37:06 2012 YoichiSummaryLSCXARM Open Loop Gain

Yoichi, Rana

Here is the open loop gain of the XARM loop.

The reference is from the pre-upgrade era. We get the extra phase delay because we have two anti-aliasing filters. One is the hardware filter at about 7kHz for 16kHz sampling. This filter should have been replaced to the one for 64kHz sampling but it has not yet happened. The second one is the software anti-aliasing filter applied when down sampling from 64kHz to 16kHz. So we have double AA filters, which are the culprits for the extra phase delay.

We should either replace the hardware AA filter to the 64kHz one (preferred way), or change the software AA filter to a less aggressive one (easier temporary fix).

Attachment 1: xarm-opltf.png
xarm-opltf.png
  7169   Tue Aug 14 04:32:49 2012 rana, yoichiUpdateLockingPOX signal sometimes looks very funny

 The alignment was way off. We moved the PZT, the BS, and the x arm to get it to lock. Along the way we noticed that giving the ETM and POS offsets makes it tilt a lot. The DC coil balancing is no good at all.

After locking, we tuned up the X arm filters in the LSC and activated the filter module triggers.  I would attach a screenshot of the trigger screen, but sadly it has no snapshot button on it.

WE changed the integrator into a double integrator with a complex zero pair. We also replaced the 1:50 boost with a 2nd order complex pole:zero pair. And added a 18 Hz RG. These were all set by looking at the error point spectra and minimizing the RMS. Hopefully, this kind of work will all be obsolete once we get the optimal feedback code. For now, the arm is very stable - we're leaving it locked overnight since the filter triggering seems to work well.

The loop kept oscillating, so we turned the xarm gain down from the 0.3 that we found it at down to 0.045. We measured the loop gain using our old xarm loopgain DTT template (which is in the Templates directory, not in /users/IAmAnAmateur/secret/secret/bozo/). It shows that we are missing ~20 deg of phase at the peak of the phase bubble compared to the old days. We guess that its because of the downsample/upsample digital AA filters which we now have in addition to the 7kHz hardware AA/AI which we still have from the pre-upgrade times). We (Jamie) have to think about how to rationalize this: we cannot survive with double AA/AI.

Another big hindrance in the lock acquisition is that the whitening filters were on. Because the WG is set to 45 dB, the ADCs are getting saturated when the flashes are large. We should have the whitening filters switch after acquiring lock.

Also, why are all the camera views of the ITMs and ETMs different? Steve, please go back and make them all the same (angles, aperture, lenses, etc.). Without them being the same, we cannot compare them.

ETMXF_1028975007.bmp

ETMXT_1028975105.bmpAS_1028975166.bmp

 I have found the video capture scripts in Yuta's personal directory. This is illegal, of course. All useful scripts (even when in development) go into the shared scripts directory. As a punishment, I have added some nasty typos to a couple of his other scripts and then backdated the timestamps so that he cannot find it easily.

 Also, I fixed the "mcup" script. After the ringdown people inserted the pickoff for MC2 trans, no one adjusted the thresholds in the MC autolocker. I've fixed mcup to trigger at 7000 cts. This should be changed back if the pickoff is removed someday. MC WFS now coming on.

Attachment 1: ITMX_1028974969.bmp
  7168   Tue Aug 14 00:42:40 2012 JenneUpdateLockingPOX signal sometimes looks very funny

I'm trying to lock / align the Xarm, and POX 11 I looks funny sometimes.

I attach 2 screenshots so you can see what I mean.  I'm leaving them uncropped so that you can see the only thing that has changed is the LSC enable / disable button. 

The situation:

PRM, SRM, ITMY, ETMY all misaligned.  BS, ITMX, ETMX aligned so that most of the time I can't lock better than 04, bad in yaw, but very occasionally I'll get lucky and catch a 00.  When the LSC enable switch is ON (2nd attachment), the POX signal (green trace in dataviewer in both attachments) looks almost square-ish, and definitely funny.  It doesn't seem to correspond directly to flashing in the cavity (red trace in dataviewer in both attachments).  However when I disable the LSC, POX goes back to looking normal - 1st attachment.  Right around -5 seconds in the 1st attachment, I disabled the LSC.

I don't really know what this means.

Attachment 1: POX_13Aug2012_LSCdisabled_pox_is_normalish.png
POX_13Aug2012_LSCdisabled_pox_is_normalish.png
Attachment 2: POX_13Aug2012_LSCenabled_pox_is_squareish_funny.png
POX_13Aug2012_LSCenabled_pox_is_squareish_funny.png
  7167   Mon Aug 13 23:06:08 2012 JenneUpdateSUSSimplant left on

Simplant for ETMX was left on, so I didn't have control of ETMX.  Not cool.  The IFO should be left in it's 'regular' state (all optics restored to saved alignments, no simplant, LSC/ALS/ASS loops off) if you're not actively working on it.

What this did point out, however, is that we need a big ol' indicator on the IFO_ALIGN / LSC / Watchdog / Overview screens to indicate that simplant is on for a particular optic, or whatever simplant might be controlling that takes away 'regular' control.  I probably would have continued being frustrated and confused for a lot longer if Eric didn't mention that simplant could have been left on.  Thanks Eric!

Symptoms, which perhaps would have eventually pointed me to simplant, were that there was some weird moving beam on the AS camera that was flashing fabry-perot fringes, and the POX signal looked like junk. After some looking around, I noticed that ETMX, while it claimed to have all the damping loops on, and the oplev on, was swinging a lot (rms levels of 4 - 7, rather than the usual < 2 ).  I said something out loud, and Eric suggested looking at Simplant.  After putting Simplant back to Reality, things are back to normal.

 

 

  7166   Mon Aug 13 21:47:30 2012 YaakovUpdateSTACISTwo changes to STACIS noise budget

In eLog 7148 (http://nodus.ligo.caltech.edu:8080/40m/7148), Koji pointed out that the op-amp and SR560 noise values (which I took from specs and then multiplied by the geophone calibration factor to get m/s/rtHz) were waaay too low. My error was an extra multiplication factor in the plotting script.

The other change was recalculating the ADC noise by splitting a signal into two ADC channels and subtracting the time series (then taking the PSD and converting to m/s/rtHz). It compares well to the value I got by terminating the ADC channels, which was the ADC noise line in my last eLog.

Both these changes are included in the below plot:

noise_budget_8-13.bmpnoise_budget_8-13.fig

Attachment 1: noise_budget_8-13.bmp
  7165   Mon Aug 13 20:12:29 2012 jamieUpdateCDSc1sup model moved to c1lsc machine

I moved the c1sup simplant model to the c1lsc machine, where there was one remaining available processor.  This requires changing a bunch of IPC routing in the c1sus and c1lsp models.  I have rebuilt and installed the models, and have restarted c1sup, but have not restarted c1sus and c1lsp since they're currently in use.  I'll restart them first thing tomorrow.

  7164   Mon Aug 13 19:29:10 2012 ManasaSummary Ringdown measurements

I tried to make ringdown measurements at the IMC using the DC falling edge as the trigger. Input to the MC was switched off by changing the polarity of the MC servo. But it does not seem to give the needed data as there seem to be several DC falling edges as soon as the polarity is switched. We should think about a better trigger or try to setup data recording from the oscilloscope seamlessly.

Also an ethernet cable has been connected to the router from the oscilloscope at the MC trans, but has not been set up to record data yet.

  7163   Mon Aug 13 18:00:30 2012 jamieUpdateGenerallarger optical tables at the ends

Quote:

I'm proposing larger optical tables at the ends to avoid the existing overcrowding. This would allow the initial pointing and optical level beams to set up correctly.

The existing table is 4 x 2 would be replaced by 4' x 3'   We would lose only ~3" space  toward exist door.

I'm working on the new ACRYLIC TABLE COVER for each end that will cost around $4k ea.  The new cover should fit the larger table.

Let me know what you think.

I'm not sure I see the motivation.  The tables are a little tight, but not that much.  If the issue is the incidence angle of the IP and OPLEV beams, then can't we solve that just by moving the table closer to the viewport?

The overcrowding alone doesn't seem bad enough to justify replacing the tables.

  7162   Mon Aug 13 17:31:19 2012 jamieUpdateCDSmysterious stuck test points on c1spx model

Quote:

Unfortunately this didn't fix the issue either.  We're still not seeing any channels for c1spx.

So I was wrong, the channels are showing up.  I had forgotten that they are showing up under C1SUP, not C1SPX.

  7161   Mon Aug 13 16:58:07 2012 jamieUpdateCDSmysterious stuck test points on c1spx model

We were not able to open up any test points in the revived c1spx model (dcuid 61).

Looking at the GDS_TP screen we found that every test point was being held open (C1:FEC-61_GDS_MON_?).  Tried closing all test points, awg and otherwise, with the diag comnand line (diag -l), but it would crash when we attempted to look at the test points for node 61.

Rebuild, install, restart of the model had no affect.  As soon as awgtpman came back up all the testpoints were full again.

I called Alex and he said he had seen this issue before as a problem with the mbuf kernel module.  Somehow the mbuf module was holding those memory locations open and not freeing them.

He suggested we reboot the machine or restart mbuf.  I used the following procedure to restart mbuf:

  • log into c1iscex as controls
  • sudo /etc/init.d/monit stop (needed so that monit doesn't auto-restart the awgtpman processes)
  • rtcds stop all
  • sudo /etc/init.d/mx_stream stop
  • sudo rmmod mbuf
  • sudo modprobe mbuf
  • sudo /etc/init.d/mx_stream start
  • sudo /etc/init.d/monit start
  • rtcds start all

Once this was done, all the test points were cleared.

Alex seems to think this issue is fixed in a newer version of mbuf.  I should probably rebuild and install the updated mbuf kernel module at some point soon to prevent this happening again.

Unfortunately this isn't the end of the story, though.  While the test points were cleared, the channels were still not available from c1spx.

I looked in the framebuilder logs to see if I could see anything suspicious.  Grep'ing for the DCUID (61), I found something that looked a little problematic:

...
GDS server NODE=25 HOST=c1iscex DCUID=61
GDS server NODE=28 HOST=c1ioo DCUID=28
GDS server NODE=33 HOST=c1ioo DCUID=33
GDS server NODE=34 HOST=c1ioo DCUID=34
GDS server NODE=36 HOST=c1sus DCUID=36
GDS server NODE=38 HOST=c1sus DCUID=38
GDS server NODE=39 HOST=c1sus DCUID=39
GDS server NODE=40 HOST=c1lsc DCUID=40
GDS server NODE=42 HOST=c1lsc DCUID=42
GDS server NODE=45 HOST=c1iscex DCUID=45
GDS server NODE=46 HOST=c1iscey DCUID=46
GDS server NODE=47 HOST=c1iscey DCUID=47
GDS server NODE=48 HOST=c1lsc DCUID=48
GDS server NODE=50 HOST=c1lsc DCUID=50
GDS server NODE=60 HOST=c1lsc DCUID=60
GDS server NODE=61 HOST=c1iscex DCUID=61
...

Note that two nodes, 25 and 61, are associated with the same dcuid.  25 was the old dcuid of c1spx, before I renumbered it.  I tracked this down to the target/gds/param/testpoint.par file which had the following:

[C-node25]
hostname=c1iscex
system=c1spx
...
[C-node61]
hostname=c1iscex
system=c1spx

It appears that this file is just amended with new dcuids, so dcuid changes can show up in duplicate.  I removed the offending old stanza and tried restarting fb again...

Unfortunately this didn't fix the issue either.  We're still not seeing any channels for c1spx.

  7160   Mon Aug 13 15:31:09 2012 steveUpdateGenerallarger optical tables at the ends

I'm proposing larger optical tables at the ends to avoid the existing overcrowding. This would allow the initial pointing and optical level beams to set up correctly.

The existing table is 4 x 2 would be replaced by 4' x 3'   We would lose only ~3" space  toward exist door.

I'm working on the new ACRYLIC TABLE COVER for each end that will cost around $4k ea.  The new cover should fit the larger table.

Let me know what you think.

Attachment 1: ETMYtable.jpg
ETMYtable.jpg
Attachment 2: ETMY4X3.jpg
ETMY4X3.jpg
  7159   Mon Aug 13 12:17:41 2012 ManasaConfigurationIOOPD from AP table removed

The PD (pda255) at the AP table, close to the MC refl , which Steve mentioned to be not in use, has been removed from the table for testing.

  7158   Mon Aug 13 09:59:05 2012 KojiUpdateGeneralMysterious banging on emergency door

You mean 5000?

Quote:

Probably, security. You can call 5555 and ask them. Otherwise you can ask them to come and check everything.

 

  7157   Mon Aug 13 01:33:55 2012 DenUpdateGeneralMysterious banging on emergency door

Quote:

[Masha, Sasha]

Sorry to spam the e-log, but did someone come knock loudly on the emergency exit door a few moments ago? It gave Sasha and I quite a fright, and we are rather worried.

 Probably, security. You can call 5555 and ask them. Otherwise you can ask them to come and check everything.

  7156   Mon Aug 13 00:33:06 2012 MashaUpdateGeneralMysterious banging on emergency door

[Masha, Sasha]

Sorry to spam the e-log, but did someone come knock loudly on the emergency exit door a few moments ago? It gave Sasha and I quite a fright, and we are rather worried.

  7155   Sun Aug 12 10:34:45 2012 KojiUpdateSAFETYexit door left unlocked

I unlocked the door on Tuesday in order to move the red cart.
After that I confirmed that the door was locked.

Quote:

Caltech security called me at 1am Sunday. Control room emergency exit door was found unlocked!

It is your responsibility to lock door if you unlocked it ! 

 

  7154   Sun Aug 12 01:21:26 2012 steveUpdateSAFETYexit door left unlocked

Caltech security called me at 1am Sunday. Control room emergency exit door was found unlocked!

It is your responsibility to lock door if you unlocked it !

 

  7153   Sat Aug 11 18:57:07 2012 DenUpdatePEMseismometer location

STS-2 - end of X arm

GUR 2 - isolation box

TRILLIUM - 1Y3 (DC power supply uses 1Y3 AC power, please do not close the door completely)

GUR 1 - end of Y arm

Now we have several "triangular seismic antennas". Different configurations can be chosen to compare the results.

  7152   Sat Aug 11 18:05:49 2012 SashaUpdateSimulationsSim_Plant Working!

Quote:

Sim_Plant going okay. Adding seismic noise tomorrow - we'll see what happens. The gain is still semi-off, but I know how to fix it - its just nice to have it gained up while I play with noise.

P.S. JAMIE DO YOU NOTICE HOW PRETTY MY GRAPH IS?

Developed some seismic noise. I adapted the seismic noise filters we used for the MC model way back when.  They looked questionable to begin with, but I added some poles/zeroes to make it more accurate (see Attached).

Attachment 1: seismic_noise1.jpg
seismic_noise1.jpg
  7151   Sat Aug 11 01:10:26 2012 SashaUpdateSimulationsSim_Plant Working!

Sim_Plant going okay. Adding seismic noise tomorrow - we'll see what happens. The gain is still semi-off, but I know how to fix it - its just nice to have it gained up while I play with noise.

P.S. JAMIE DO YOU NOTICE HOW PRETTY MY GRAPH IS?

Attachment 1: Plant_sen.jpg
Plant_sen.jpg
  7150   Fri Aug 10 21:37:15 2012 DenUpdatePEMgur, sts noise

 Using Guralp, STS-2 and Trillium I compared Gur and STS-2 self-noise assuming that Trillium noise is not worse then STS-2 noise.

gur_sts_noise.png

Interesting that STS-2 (or Trillium if its noise is worse) noise is not too much better then Guralp noise.

  7149   Fri Aug 10 19:49:11 2012 EricSummaryLockingMichelson Locking Procedure and Measurements

Today I worked on locking the Michelson. Here's what I did:

 

  1. Open Data Viewer and Restore Settings /users/Templates/JenneLockingDataviewer/MICH.xml. This opens the C1:LSC-ASDC_OUT and C1:LSC-AS55_Q_ERR plots.

  2. Check the LSC screen to verify that the path between the Servo Filter Modules and the SUS Ctrls are outlined in green. If not turn on the OUT button within the Filter Servo Modules, enable LSC mode, and turn on the SUS Ctrls for the BS.

  3. Misalign all optics other than BS and one of ITMX and ITMY. The ITMY was already well-aligned from my work on locking the YARM, so I actually chose to misalign ITMY at first.

  4. Restore BS and ITMX. Use the AS camera on the video screen as your guide when aligning ITMX.

  5. Adjust pitch and yaw of ITMX until a bright, circular spot appears near the middle of the AS camera.

  6. Now restore ITMY and adjust pitch and yaw until a second circular spot appears on the AS camera.

  7. Adjust both ITMX and ITMY until both bright spots occupy the same location. If the spots remain bright when they are in the same location you are locking onto a bright fringe actually, and need to flip the sign of the gain on the MICH servo filter modules. I had to do this today in fact, as discussed in ELOG 7145.

  8. If the sign is correct, the two beams should interfere destructively and the formerly bright spots will form a comparatively dark spot. The shape of the spot will likely be two bright lobes separated by a dark middle.

  9. C1:LSC-ASDC_OUT should be a roughly flat signal, and the goal now is to minimize the magnitude of this signal. The smaller this signal, the darker the AS camera should look. Decent target values for C1:LSC-ASDC_OUT are around 0.10 to 0.05.

 

Once I did this, I made measurements by exciting C1:SUS-ITMY_LSC_EXC and measuring with C1:LSC-AS55_Q_ERR. I ran a logarithmic swept sine response from 1 to 1000 Hz again, with an envelope amplitude dependence. Again I looked at the measured transfer function and coherence. I was able to get good coherence, but it was somewhat erratic in that it dipped low at high frequency multiple times.

  7148   Fri Aug 10 18:11:55 2012 YaakovUpdateSTACISCorrected noise budget, plan for external actuation

I hope you're not all tired of the STACIs noise budgets, because I have another one! Here, the main difference is my modeling of the geophone sensitivity according to a predicted physical model for the system (just a damped oscillator) instead of trying to fit it to the accelerometer motion signal with more arbitrary functions.

The result of this calibration is shown below (accel and geo signals taken for 5 minutes at the same time, in granite and foam):

sensor_comp.pngsensor_comp.fig

The m/s/V sensitivity function I am using is g*[(w^2-2idww(0)-w(0)^2)/w^2], where g (the high freq. m/s/V sensitivity) was 2.5*10^-5 and d (damping) was set to 2.

Now, the recalculated noise plot looks like this:

noise_budget_8-10.pngnoise_budget_8-10.fig

The accel. specs I took from the Wilcoxon spec sheet, and the geo specs I found in https://dcc.ligo.org/public/0028/T950046/000/T950046-00.pdf, a LIGO document about the STACIS. The geo noise was measured for the STACIS geo and their pre-amp, while I was using the SR560 as the pre-amp. If anything, my noise should be lower, since the SR560 noise spec is lower than what I estimated for the STACIS geophone pre-amp, so I'm not sure about that order of magnitude difference between the experimental and expected geo noise. A sign that my noise values are at least reasonable is that the geophone noise flattens out above the geophone's resonant frequency (4.5 Hz), as Jan pointed out it should.

The sensor noise (either accel. or geo.) is the dominating signal below 1 Hz in the STACIS platform measurement, which then limits the closed loop performance at those frequencies. Since the noises I am finding are looking reasonable, I think it's fair to definitively state that accelerometers will not significantly help at low frequencies (there may be at most a factor of 2 lower noise below 1 Hz for the accel., but I need more data to say for sure).

The plan right now is to concentrate on using the STACIS as actuators, perhaps with seismometers on the ground and a feedforward signal sent into the high voltage amplifier.

I took the transfer function of the high voltage board itself (no pre-amp included) by driving the PZTs with a swept sine and measuring the accelerometer response (which I am now fairly confident is calibrated correctly). The input point was the signal IN on the extender board, but with the geophones disconnected from the pre-amp.

hv_bode.pnghv_bode.fig

I took the coherence at just a few single frequencies (you can't do coherence measurements in swept sine mode on the SR785) to make sure I was really driving the PZTs, and it was near 1 (998, 999.9, etc) at the frequencies at which I drove. Without the extra notches at 1 Hz (which may be real, it's coherent there too), it looks like a 2-pole high pass filter (goes from -180 to 180 deg, approx. an f^2 dependence). This transfer function should be taken into account by the feedforward algorithm.

The current plan is to make a box with a switch that allows geophone feedback and/or external signals into the high voltage amplifier. It would act sort of like the extender card, except more compact so it could fit into the STACIS. It also would have the advantage of not having to reroute the power, since those lines from the pre-amp could all still be connected (see eLog 7118: http://nodus.ligo.caltech.edu:8080/40m/7118).

  7147   Fri Aug 10 17:38:29 2012 DenUpdatePEMclassify seismic c code

Quote:

Den and I also had trouble with a simple for loop in our model, so we talked to Alex who noted that the -O3 compiler unravels for loops in a buggy way. Thus, we have compiled c1pem using the -O compiler. 

Alex also modified RCG script to generate -O in the Makefile for c1pem model:

controls@pianosa:/opt/rtcds/rtscore/release/src/epics/util 127$ svn diff
feCodeGen.pl 
Index: 
feCodeGen.pl
===================================================================
--- 
feCodeGen.pl (revision 2999)
+++ 
feCodeGen.pl (working copy)
@@ -3183,7 +3183,12 @@

print OUTM "\n";
}
print OUTM "ALL \+= user_mmap \$(TARGET_RTL)\n";
+# do not optimize c1pem
+if ($skeleton eq "c1pem") {
+print OUTM "EXTRA_CFLAGS += -O -w -I../../include\n";
+} else {
print OUTM "EXTRA_CFLAGS += -O3 -w -I../../include\n";
+}
print OUTM "EXTRA_CFLAGS += -I/opt/gm/include\n";
print OUTM "EXTRA_CFLAGS += -I/opt/mx/include\n";

  7146   Fri Aug 10 17:17:41 2012 Alex Masha DenUpdatePEMclassify seismic c code

Den and I installed a module in the c1pem model which has a feedforward neural network to classify seismic disturbance (10 means quiet, 20 truck, 30 earthquake). There is a channel SEIS_CLASS which should specify the class of the seismic signal. The code works for signals sampled at 256 Hz, so an anti-aliasing filter must be installed in order to decimate from the 2048 model.

The models were compiling slowly, so Alex removed the archiving feature (gzip and tar were taking a lot of time).

Den and I also had trouble with a simple for loop in our model, so we talked to Alex who noted that the -O3 compiler unravels for loops in a buggy way. Thus, we have compiled c1pem using the -O compiler.

PS: the Trilium seismometer now has legs.

  7145   Fri Aug 10 16:39:44 2012 EricSummaryLockingMichelson Locking

I'm working on locking the Michelson now in order to put an excitation on one of the input test masses and measure the resulting error signal at the anti-symmetric port. I aligned the beams from ITMX and ITMY by looking at the AS camera with the video screens, but the fringes were not destructively interfering. Jenne advised that I look at the gain on the MICH servo filter modules in the LSC screen. We flipped the sign on the gain (it was 0.120 and it is now -0.120) and the fringes destructively interfered as desired after this change.

For purposes of documentation, I locked the YARM earlier in the morning before moving on to the Michelson. The purpose of this was to put another excitation on C1:SUS-ETMY_LSC_EXC and then measure the error signal on C1:LSC-POY11_I_ERR.

  7144   Fri Aug 10 15:05:52 2012 ManasaConfigurationIOOMC trans optics configured

Quote:

Quote:

Quote:

Quote:

  The PDA255 is a good ringdown detector - Steve can find one in the 40m if you ask him nicely.

 We found a PDA255 but it doesn't seem to work. I am not sure if that is one you are mentioning...but I'll ask Steve tomorrow!

 I double checked the PDA255 found at the 40m and it is broken/bad. Also there was no success hunting PDs at Bridge. So the MC trans is still in the same configuration. Nothing has changed. I'll try doing ringdown measurements with PDA400 today.

Can you explain more what "broken/bad" means?  Is there no signal?  Is it noisy?  Glitch?  etc.

 The PD saturates the oscilloscope just by switching on the power; with no real signal at all. But Steve helped locating a PD that is not being used at the AP table. So I will check it and replace the current one if it works!

  7143   Fri Aug 10 11:08:26 2012 jamieUpdateComputersFE Status

Quote:

The c1lsc and c1sus screens are red in the front-end status. I restarted the frame builder, and hit the "global diag reset" button, but to no avail. Yesterday, the only thing Den and I did to c1sus was install a new c1pem model. I got rid of the changes and switched to the old one (I ran rtcds build, install, restart), but the status is still the same.

 The issue you're seeing here is stalled mx_stream processes on the front ends.  On the troublesome front ends you can log in and restart the mx_streams with the "mxstreamrestart" command.

  7142   Fri Aug 10 11:05:33 2012 jamieConfigurationIOOMC trans optics configured

Quote:

Quote:

Quote:

  The PDA255 is a good ringdown detector - Steve can find one in the 40m if you ask him nicely.

 We found a PDA255 but it doesn't seem to work. I am not sure if that is one you are mentioning...but I'll ask Steve tomorrow!

 I double checked the PDA255 found at the 40m and it is broken/bad. Also there was no success hunting PDs at Bridge. So the MC trans is still in the same configuration. Nothing has changed. I'll try doing ringdown measurements with PDA400 today.

Can you explain more what "broken/bad" means?  Is there no signal?  Is it noisy?  Glitch?  etc.

  7141   Fri Aug 10 11:00:52 2012 SashaUpdateSimulationsMessing with ETMX

I've been trying to get the simPlant model to work, and my main method of testing is switching between the real ETMX and the simulated ETMX and comparing the resulting power spectrum (the closer the two are, the more our simulation works). While the simPlant is on, ETMX is NOT BEING DAMPED. I started this ~Wednesday, and the testing will continue today, then hopefully we'll get a similiar simPlant up for ITMX (at which point, testing will continue for both ITMX and ETMX).

TL;DR: ETMX is not being continuously damped, XARM will likely be exhibiting some wonky behavior next week.

  7140   Fri Aug 10 09:54:51 2012 ManasaConfigurationIOOMC trans optics configured

Quote:

Quote:

  The PDA255 is a good ringdown detector - Steve can find one in the 40m if you ask him nicely.

 We found a PDA255 but it doesn't seem to work. I am not sure if that is one you are mentioning...but I'll ask Steve tomorrow!

 I double checked the PDA255 found at the 40m and it is broken/bad. Also there was no success hunting PDs at Bridge. So the MC trans is still in the same configuration. Nothing has changed. I'll try doing ringdown measurements with PDA400 today.

  7139   Fri Aug 10 09:51:51 2012 EricSummaryLockingYARM Locking and Measurements

I forgot to post this last night, but I locked the YARM again yesterday and misaligned the other optics. I took measurements on ITMY and ETMY with DTT again as well. At the end of the day I aligned the rest of the optics before I left.

  7138   Fri Aug 10 09:47:19 2012 MashaUpdateComputersFE Status

The c1lsc and c1sus screens are red in the front-end status. I restarted the frame builder, and hit the "global diag reset" button, but to no avail. Yesterday, the only thing Den and I did to c1sus was install a new c1pem model. I got rid of the changes and switched to the old one (I ran rtcds build, install, restart), but the status is still the same.

  7137   Thu Aug 9 23:50:09 2012 JenneUpdateASSASS matrix measured, first ASS test

Koji pointed out that I was being silly, and rather than actually misaligning the optics (by, say, changing their IFO Align sliders) I was changing the location of the actuation node by changing the coil output gains.  Now I see nice signals at the I_OUT of each of the demodulators (so far I've only looked at the YARM).

I've measured and inverted the matrix by taking the nominal values of the demodulator outputs when the optics are all by-hand optimally aligned, then one-by-one misaligning an optic's angle (pitch or yaw), and looking at the demod outputs that result.  Repeat with each misalignment DoF for each of the 4 rows of the matrix.  Then I set the pit/yaw coupling elements of the matrix to zero.  Then invert the matrix, put it in, and see what happens.  So far, the yaw DoFs converged to zero, but the pitch ones didn't.  I'll play with it more and think some more tomorrow.

ELOG V3.1.3-