40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 177 of 341  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  7135   Thu Aug 9 12:31:36 2012 JenneUpdateASSASS rebuilt again
I was (in between Eric's measurements) driving the YARM ASS dithers, and noticed that instead of driving ITMY PIT, I was driving ITMX PIT. I looked in the model, and when I re-did the model after an svn revert a few days ago, it looks like I got the shmem parts for the ITM PIT signals backwards. I have fixed that, rebuilt, installed and restarted the ass model.
  7136   Thu Aug 9 12:55:15 2012 ZachUpdateelogelog was being a pain in the ass; I restarted it

The elog was not responding. I attempted to restart it by running .../start-elog.csh, but this didn't work (even after the usual ~2 times it needs).

Somehow pkill did not kill the daemon, so I kill -9'd it and that did the trick. I ran the start script once more and it came back online.

  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.

  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.

  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.

  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.

  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.

  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";

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

  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.

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

  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 !

 

  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 ! 

 

  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.

  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.

  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.

 

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

  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.

  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.

  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.

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

 

 

  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
  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
  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
  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

  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.

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

  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.

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

 

  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.

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

  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.

 

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

  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

  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
  7188   Wed Aug 15 09:09:45 2012 jamieUpdateLSCLSC whitening triggers

Quote:

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.

The unit delay delays for a single cycle, so I think that's not what you want.  I'm not sure that there's an existing part to add delays like that.

We also need to be a little clever about it, though, since we'll want it to flip off if we loose lock during the delay.

  7189   Wed Aug 15 10:40:16 2012 DenUpdateCDSaa filters

The lack of AA filter for MCL signal is RFM model strongly disturbed entering to OAF signal

aa.png

  7193   Wed Aug 15 13:24:12 2012 DenUpdateCDSRFM -> OAF

Transmission of signals between RFM and OAF is bad again. Now we do not see any errors in IPC_ERR monitors so models think that they get all data but the data is wrong

oaf.png

  7194   Wed Aug 15 16:01:47 2012 steveUpdateGenerallarger optical tables at the ends ?

The drawing of the 4' x 2'  table cover can be seen at entry  #6190 The new proposed wall #7106  The yellow acrylic would be ~ 0.25" thick and it will be the inside. It is not shown on the drawing.

Question remaining: should get a larger table 4' x 3' as outlined by red lines and make new cover to fit this

The oplev beam path needs larger incident angle to get in and out of the chamber: REMOVE BOTTLENECK for easy traffic

Moving the existing table closer to ETMY chamber - as Jamie suggested-  would help but there is no room for this solution.

The larger table solve this issue and leave more room for initial pointing, arm transmitted and future experiments.

Other benefits: no tube to make between table and chamber. It is easier to make the the larger box air tight.

The new isolation box with feed through, cover, seals will cost $4-5K ea

 

 

Attachment 1: bottleneck.jpg
bottleneck.jpg
  7196   Wed Aug 15 17:17:58 2012 Manasa, JanUpdateIOORingdown measurements

Finally ringdown at IMC conquered and oopsie that came out so clean!

The finesse of the cavity from the current ringdown measurement, F= 453, differs from the measurements made in the document dated 10/1/02 on dcc...not sure if things have changed since then.

While I thought that the bumps observed at the end of the ringdown might be because of the cavity trying to lock itself, Jan commented that they have always existed in these measurements and their source is not known yet.

Ringdown_815.jpg

  7197   Wed Aug 15 17:23:22 2012 jamieUpdateCDSfront end IOP models changed to reflect actual physical hardware

As Rolf pointed out when he was here yesterday, all of our IOPs are filled with parts for ADCs and DACs that don't actually exist in the system.  This was causing needless module error messages and IOP GDS screens that were full of red indicators.  All the IOP models were identically stuffed with 9 ADC parts, 8 DAC parts, and 4 BO parts, even though none of the actual front end IO chassis had physical configurations even remotely like that.  This was probably not causing any particular malfunctions, but it's not right nonetheless.

I went through each IOP, c1x0{1-5}, and changed them to reflect the actual physical hardware in those systems.  I have committed these changes to the svn, but I haven't rebuilt the models yet.  I'll need to be able to restart all models to test the changes, so I'm going to wait until we have a quiet time, probably next week.

  7198   Wed Aug 15 18:56:46 2012 YoichiUpdateIOOMC Servo Transfer Function Measurements

 I started working on the characterization of the MC servo.

The current MC servo topology is shown in the figure attached along with a simplified schematic diagram of the MC board. 

A usual way to measure the open loop gain of this servo is to inject a signal from, say, EXCA of the MC board and measure the transfer function from TP2A to TP1A. It works OK at frequencies around the UGF. The second attachment is the OPLTF measured in this way with the Agilent 4395A. The UGF is about 100kHz with the phase margin of 40 to 50 deg. 

Now we have two issues here. First, I expected the UGF to be more than 100kHz, like 300kHz or so. The phase babble is peaked around 100kHz. According to our old measurement (http://nodus.ligo.caltech.edu:8080/40m/1431) the phase babble peak was at a much higher frequency when the FSS was using the reference cavity. One reason could be that the MC is located much farther from the laser than the reference cavity, so that there is some phase lag caused by the time delay. I will make a model of the MC servo system later to check this theory.

The second issue is that, as you can see in the plot, the OPLTF measurement becomes noisy at lower frequencies. With 4395A, which has the minimum IFBW of 2Hz, OPLTF measurement below 10kHz was impossible with the traditional method. We could use SR785 with a long averaging time to improve the SNR, but it requires a patience which I don't have.

The measurement becomes difficult at low frequencies because the loop gain is too high. When the open loop gain (G) is high, the injected signal (x) from EXCA is immediately suppressed by a factor of 1/(1+G) at TP2A. This makes the injected signal hidden in other noises at TP2A.

How do we solve this problem ? Let's consider a simple servo model shown in the third attachment. A traditional OPLTF measurement is done by injecting a signal from EXC port and measuring the TF from TP2 to TP1. The problem was that at TP2, the signal is attenuated by 1/(1+G1*G2), which is too much when G (=G1*G2) is large. However, at TP3, the attenuated signal is amplified by G1. So the injected signal x becomes x*G1/(1+G) at TP3. If G1's contribution to the overall gain G is large enough,  the signal at TP3 is not so small. Then we can easily measure G2 using TP3 and TP1. In a typical situation, G1 is the transfer function of the electric circuits, which we can know either from standalone measurements or from model calculations, and G2 is an interferometer response, which we want to measure. So, by combining the knowledge of G1 and the measurement of G2, we can obtain the overall loop gain G even at lower frequencies.

 The final attachment shows an example of the measurement of G2. In our case, this is the transfer function from MC_Out_Mon to Q-Mon (see the first attachment) . G1 is the transfer function of the MC board. Since G1 is large at low frequencies, we can measure G2 down to 100Hz with a reasonable integration time (10000 cycles per point).

Last night, I took a bunch of TFs with this method. Now I'm analyzing the data to recover the overall gain G. I will post the results later.

Attachment 1: MC-Diagram.png
MC-Diagram.png
Attachment 2: OPLG-10kHz-1MHz.png
OPLG-10kHz-1MHz.png
Attachment 3: SimpleServoDiagram.png
SimpleServoDiagram.png
Attachment 4: OPTG-100Hz-1kHz.png
OPTG-100Hz-1kHz.png
  7199   Wed Aug 15 20:15:51 2012 JanUpdateIOORingdown measurements

Quote:

While I thought that the bumps observed at the end of the ringdown might be because of the cavity trying to lock itself, Jan commented that they have always existed in these measurements and their source is not known yet.

What I meant to say was that in all ringdown measurements that we observed today, the bumps were consistently part the ringdown, and that I have no explanation for the bumps. It should also be mentioned that fitting the bumpy part of the ringdown instead (we used the clean first 10us), the ringdown time is about twice as high. In either case, the ringdown time is significantly smaller than we have seen in documents about previous measurements.

We (basically I) also made one error when producing the plots. The yaxis label of the semi-logarithmic plot should be log(...), not log10(...).

ELOG V3.1.3-