40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 74 of 339 Not logged in
ID Date Author Type Category Subject
13357   Wed Oct 4 17:38:25 2017 gautamUpdateLSCFS725 for Marconi stabilization

I've located the Stanford Research FS725 Rb reference unit. The question is where to put it. This afternoon Steve and I put it inside the little electronics rack next to 1X3, but in hindsight, this probably isn't such a great place for a timing reference as there are a bunch of Sorensen power supplies in there (and presumably the accompanying harmonics from these switching supplies).

The unit itself was repaired in 2015, and powering it on, it locked to the internal reference within a few minutes as prescribed in the manual.

13356   Wed Oct 4 17:18:15 2017 gautamUpdateCDSFree DAC channels in c1lsc

There are at least 5 free DAC channels (4 if you discount the one channel from these that I am hijacking) available in the 1Y2 electronics rack.

Jamie's nice wiring diagram shows the topology - the actual DAC card sits in 1Y3 inside the c1lsc expansion chassis (while the c1lsc frontend itself is in 1X4). The output of the DAC goes via SCSI to an interface box (D080303) and then to some dewhitening/AI boards (D000316). There are a total of 16 DAC channels available, out of which 8 are used for the TTs, 2 are used for the DAFI model, and one is labeleld "From c1ioo 1X2" (I don't know what this one is for). So I'm going to use some of these channels for measuring the coupling of oscillator noise and intensity noise to MICH in the DRMI lock.

The de-whitening/AI board seems to be old - it has 2x 800Hz Butterworth LPFs and no notch for the clock frequency, but maybe this doesn't matter for the tests I have in mind. The AI board available on 1X2 is more modern but routing the DAC channels from 1Y2 to it is going to be some work.

I'm going to add my testpoint to c1daf given that it seems to be the least critical model on c1lsc.

EDIT: testpoints added to c1daf don't show up in the list of available channels - there was some issue with this model while we were getting the new RTCDS going. So I'm moving my temporary testpoint to c1cal instead.

13355   Tue Oct 3 19:39:10 2017 gautamUpdateCDSslow machine bootfest

Eurocrate key turning reboots for c1susaux, c1auxex,c1auxey, c1iscaux, c1iscaux2 and c1aux. Usual precautions were taken for ITMX. Did burtrestore for c1iscaux andc1iscaux2  in order to restore the LSC PD whitening gains.

Un-related to this work: input pointing into PMC was tweaked as the PMC_REFL spot was pretty bright.

13354   Tue Oct 3 01:58:32 2017 johannesHowToCamerasCCD calibration

Disclaimer: Wrong calibration factors! See https://nodus.ligo.caltech.edu:8081/40m/13391

The factors were indeed enormously off. The correct table reads:

 Camera IP Calibration Factor CF 192.168.113.152 85.8 pW*s 192.168.113.153 78.3 pW*s

I did subtract a 'dark' frame from the images, though not in the sense of your point 1, just an exposure of identical duration with the laser turned off. This was mostly to reduce the effect of residual light, but given similar initial conditions would somewhat compensate for the offset that pre-existing charge and electronics noise put on the pixel values. The white field is of course a difference story.

I wonder how close we can get to a white field by putting a thin piece of paper in front of the camera without lenses and illuminate it from the other side. A problem is of course the coherence if we use a laser source... Or we scrap any sort of screen/paper and illuminate directly with a strongly divergent beam? Then there wouldn't be a specular pattern.

I'm not sure I understand your point about the 1.5V/A. Just to make sure we're talking about the same thing I made a crude drawing:

The PD sees plenty of light at all times, and the 1.5V/uW came from a comparative measurement PD<-->Ophir (which took the place of the CCD) while adjusting the power deflected with the AOM, so it doesn't have immediate connection to the conversion gain of silicon in this case. I can't remember the gain setting of the PD, but I believe it was 0dB, 20dB at most.

Attachment 1: gige_calibration.pdf
13353   Tue Oct 3 01:32:39 2017 gautamUpdateLSCLaser intensity noise coupling to MICH (simulated)

GV Oct 6: This coupling is probably not correct - Finesse outputs TF magnitude in units of W/W, and not W/RIN

Since I was foiled (by lack of DAC) in my attempt to measure the coupling of laser intensity noise to MICH in the DRMI (no arms) configuration, I decided to try understanding the effect with a simulation.

For this purpose, I used my DRMI Finesse model - this had mirror positions tuned for locking and photodiode demod phases tuned to give a sensing matrix model that wasn't too far from an actual measurement (within factor of a few). So the model seems okay for a first pass at estimating this coupling.

Measuring transfer functions in Finesse is straightforward - use the fsig command to modulate some quantity (in this case the input beam intensity), and use the pd2 detector to demodulate the effect of this modulation at the port of interest (in this case AS55_Q).

**Note that to apply a modulation to an input beam (i.e. Laser) in Finesse, the keyword for the "type" argument given to fsig is "amp" and not "amplitude" as the manual would had me believe. In fact, there seem to be quite a few such caveats. The best way to figure this out is to go to the pykat installation directory, find the file components.py, and look for the fsig_name for the component of interest. It is also indicated in the same file, via the canFsig argument, if that property of the component can be modulated for transfer function measurements.

Attachment #1 shows the result of such a sweep.

To estimate what the actual contribution to the displacement noise is, I used the DQ-ed MC transmission (recorded at 1024Hz) from the DRMI lock, computed the ASD using scipy.signal.welch, divided by the nominal MC transmission of ~15,000 counts to convert to RIN/rtHz. The RIN was then multiplied by the above calculated coupling function, and divided by the sensing matrix element for AS55_Q (in units of W/m) to give the curve shown in Attachment #2. If we believe the simulation, then Laser Intensity Noise shouldn't be the limiting noise between 10Hz-1kHz.

I will of course measure the actual coupling and see how it lines up with Attachment #1 - would be a nice additional validation of the Finesse model. I will also try using the Finesse model to estimate some other coupling transfer functions (e.g. Laser Frequency Noise, Oscillator Noise).

 Quote: The absence of evidence is not evidence of absence.

Attachment 1: MICH_intensityNoiseCoupling.pdf
Attachment 2: MICH_intensityNoiseASD.pdf
13352   Mon Oct 2 23:16:05 2017 gautamHowToCamerasCCD calibration

Going through some astronomy CCD calibration resources ([1]-[3]), I gather that there are in general 3 distinct types of correction that are applied:

1. Dark frames --- this would be what we get with a "zero duration" capture, some documents further subdivide this into various categories like thermal noise in the CCD / readout electronics, poissonian offsets on individual pixels etc.
2. Bias frames --- this effect is attributed to the charge applied to the CCD array prior to the readout.
3. Flat-field calibration --- this effect accounts for the non-uniform responsivity of individual pixels on the CCDs.

The flat-field calibration seems to be the most complicated - the idea is to use a source of known radiance, and capture an image of this known radiance with the CCD. Then assuming we know the source radiance well enough, we can use some math to back out what the actual response function of individual pixels are. Then, for an actual image, we would divide by this response-map to get the actual image. There are a number of assumptions that go into this, such as:

• We know the source radiance perfectly (I guess we are assuming that the white paper is a Lambertian scatterer so we know its BRDF, and hence the radiance, perfectly, although the work that Jigyas and Amani did this summer suggest that white paper isn't really a Lambertian scatterer).
• There is only one wavelength incident on the CCD.
• We can neglect the effects of dust on the telescope/CCD array itself, which would obviously modify the responsivity of the CCD, and is presumably not stationary. Best we can do is try and keep the setup as clean as possible during installation.

I am not sure what error is incurred by ignoring 2 and 3 in the list at the beginning of this elog, perhaps this won't affect our ability to estimate the scattered power from the test-masses to within a factor of 2. But it may be worth it to do these additional calibration steps.

I also wonder what the uncertainty in the 1.5V/A number for the photodiode is (i.e. how much do we trust the Ophir power meter at low power levels?). The datasheet for the PDA100A says the transimpedance gain at 60dB gain is 1.5 MV/A (into high impedance load), and the Si responsivity at 1064nm is ~0.25A/W, so naively I would expect 0.375 V/uW which is ~factor of 4 lower. Is there a reason to trust one method over the other?

Also, are the calibration factor units correct? Jigyasa reported something like 0.5nW s / ct in her report.

 Camera IP Calibration Factor CF 192.168.113.152 8.58 W*s 192.168.113.153 7.83 W*s

The incident power can be calculated as Pin =CF*Total(Counts-DarkCounts)/ExposureTime.

References:

[1] http://www.astrophoto.net/calibration.php

[2] https://www.eso.org/~ohainaut/ccd/

[3] http://www.astro.ufl.edu/~lee/ast325/handouts/ccd.pdf

13351   Mon Oct 2 19:03:49 2017 gautamUpdateCDS[Solved] c1ioo DC errors

This did the trick - I simply ran

sudo systemctl restart daqd_*

on FB1, and now all the CDS overview lights are green again.

I thought I had done this already, but I realize that I was supposed to restart the daqd processes on FB1 (which is where they are running) and not on c1ioo .

Thanks Jamie for the speedy resolution!

Quote:
 Quote: This time the model came back up but I saw a "0x2000" error in the GDS overview MEDM screen. Since there are no DACs installed in the c1ioo expansion chassis, I thought perhaps the problem had to do with the fact that there was a "DAC_0" block in the c1x03 simulink diagram - so I deleted this block, recompiled c1x03, and for good measure, restarted all (three) models on c1ioo. Now, however, I get the same 0x2000 error on both the c1x03 and c1als GDS overview MEDM screens (see Attachment #1).

From page 21 of T1100625, DAQ status "0x2000" means that the channel list is out of sync between the front end and the daqd.  This usually happens when you add channels to the model and don't restart the daqd processes, which sounds like it might be applicable here.

It looks like open-mx is loaded fine (via "rtcds lsmod"), even though the systemd unit is complaining.  I think this is because the open-mx service is old style and is not intended for module loading/unloading with the new style systemd stuff.

Attachment 1: CDSoverview.png
13350   Mon Oct 2 18:50:55 2017 jamieUpdateCDSc1ioo DC errors
 Quote: This time the model came back up but I saw a "0x2000" error in the GDS overview MEDM screen. Since there are no DACs installed in the c1ioo expansion chassis, I thought perhaps the problem had to do with the fact that there was a "DAC_0" block in the c1x03 simulink diagram - so I deleted this block, recompiled c1x03, and for good measure, restarted all (three) models on c1ioo. Now, however, I get the same 0x2000 error on both the c1x03 and c1als GDS overview MEDM screens (see Attachment #1).

From page 21 of T1100625, DAQ status "0x2000" means that the channel list is out of sync between the front end and the daqd.  This usually happens when you add channels to the model and don't restart the daqd processes, which sounds like it might be applicable here.

It looks like open-mx is loaded fine (via "rtcds lsmod"), even though the systemd unit is complaining.  I think this is because the open-mx service is old style and is not intended for module loading/unloading with the new style systemd stuff.

13349   Mon Oct 2 18:08:10 2017 gautamUpdateCDSc1ioo DC errors

I was trying to set up a DAC channel to interface with the AOM driver on the PSL table.

• It would have been most convenient to use channels from c1ioo given proximity to the PSL table.
• Looking at the 1X2 rack, it looked like there were indeed some spare DAC channels available.
• So I thought I'd run a test by adding some TPs to the c1als model (because it seems to have the most head room in terms of CPU time used).
• I added the DAC_0 block from CDS_PARTS library to c1als model (after confirming that the same part existed in the IOP model, c1x03).
• Model recompiled fine (I ran rtcds make c1als and rtcds install c1als on c1ioo).
• However, I got a bunch of errors when I tried to restart the model with rtcds restart c1als. The model itself never came up.
• Looking at dmesg, I saw stuff like
[4072817.132040] c1als: Failed to allocate DAC channel. [4072817.132040] c1als: DAC local 0 global 16 channel 4 is already allocated. [4072817.132040] c1als: Failed to allocate DAC channel. [4072817.132040] c1als: DAC local 0 global 16 channel 5 is already allocated. [4072817.132040] c1als: Failed to allocate DAC channel. [4072817.132040] c1als: DAC local 0 global 16 channel 6 is already allocated. [4072817.132040] c1als: Failed to allocate DAC channel. [4072817.132040] c1als: DAC local 0 global 16 channel 7 is already allocated. [4073325.317369] c1als: Setting stop_working_threads to 1
• Looking more closely at the log messages, it seemed like rtcds could not find any DAC cards on c1ioo.
• I went back to 1X2 and looked inside the expansion chassis. I could only find two ADC cards and 1 BIO card installed. The SCSI cable labelled ("DAC 0") running from the rear of the expansion chassis to the 1U SCSI->40pin IDE breakout chassis wasn't actually connected to anything inside the expansion chassis.
• I then undid my changes (i.e. deleted all parts I added in the simulink diagram), and recompiled c1als.
• This time the model came back up but I saw a "0x2000" error in the GDS overview MEDM screen.
• Since there are no DACs installed in the c1ioo expansion chassis, I thought perhaps the problem had to do with the fact that there was a "DAC_0" block in the c1x03 simulink diagram - so I deleted this block, recompiled c1x03, and for good measure, restarted all (three) models on c1ioo.
• Now, however, I get the same 0x2000 error on both the c1x03 and c1als GDS overview MEDM screens (see Attachment #1).
• An elog search revealed that perhaps this error is related to DAQ channels being specified without recording rates (e.g. 16384, 2048 etc). There were a few DAQ channels inside c1als which didn't have recording rates specified, so I added the rates, and restarted the models, but the errors persist.
• According to the RCG runtime diagnostics document, T1100625 (which admittedly is for RCG v 2.7 while we are running v3.4), this error has to do with a mismatch between the DAQ config files read by the RTS and the DAQD system, but I'm not sure how to debug this further.
• I also suspect there is something wrong with the mx processes:
controls@c1ioo:~ 130$sudo systemctl status mx ● open-mx.service - LSB: starts Open-MX driver Loaded: loaded (/etc/init.d/open-mx) Active: failed (Result: exit-code) since Tue 2017-10-03 00:27:32 UTC; 34min ago Process: 29572 ExecStop=/etc/init.d/open-mx stop (code=exited, status=1/FAILURE) Process: 32507 ExecStart=/etc/init.d/open-mx start (code=exited, status=1/FAILURE) Oct 03 00:27:32 c1ioo systemd[1]: Starting LSB: starts Open-MX driver... Oct 03 00:27:32 c1ioo open-mx[32507]: Loading Open-MX driver (with ifnames=eth1 ) Oct 03 00:27:32 c1ioo open-mx[32507]: insmod: ERROR: could not insert module /opt/3.2.88-csp/open-mx-1.5.4/modules/3.2.88-csp/open-mx.ko: File exists Oct 03 00:27:32 c1ioo systemd[1]: open-mx.service: control process exited, code=exited status=1 Oct 03 00:27:32 c1ioo systemd[1]: Failed to start LSB: starts Open-MX driver. Oct 03 00:27:32 c1ioo systemd[1]: Unit open-mx.service entered failed state. • Not sure if this is related to the DC error though. Attachment 1: c1ioo_CDS_errors.png 13348 Mon Oct 2 12:44:45 2017 johannesUpdateCamerasBasler 120gm calibration Disclaimer: Wrong calibration factors! See https://nodus.ligo.caltech.edu:8081/40m/13391 The two acA640-120gm Basler GigE-Cams have been calibrated. I used the collimated output of a fiber that carried the auxiliary laser light from the PSL table. With a non-polarizing beam splitter some of the light was picked off onto a PD, and I modified the RF amplitude of the AOM drive signal to vary the power coming out of the fiber. The fiber output was directed at a white paper, which was placed 1.06m from the front of the lens tube assembly, which is where the focal plane is. Using the Pylon Viewer App I made sure that the entirety of the beam spot was imaged onto the CCD. Since the camera sensor is 1/4" across, I removed the camera from the lens tube and instead placed the Ophir power meter head at the position of the sensor and measured the power reported versus PD voltage, which turned out to be 1.5 V/uW. The camera was put back in place and I used the Pypylon package Gautam had stumbled upon to sweep the exposure time from 100us to 10ms at different light power settings including no laser light at all for background subtraction, and rather than keeping the full bitmap data for O(100s) of images I recorded only the quantities 1. Pixel Max 2. Pixel Sum 3. Pixel Mean 4. Pixel Standard Deviation 5. Pixel Median I performed this procedure for both the 152 and 153 cameras and plotted the pixel sum and the pixel max vs the exposure time. All the exposures were taken at a gain setting of 100, which is the smallest possible setting (out of 100-600). To obtain the calibration factor I use the input power Pin=75nW in the 'safe' region 1ms to 10ms where the pixel sum looks smooth and the CCD is reportedly not saturated.  Camera IP Calibration Factor CF 192.168.113.152 8.58 W*s 192.168.113.153 7.83 W*s The incident power can be calculated as Pin =CF*Total(Counts-DarkCounts)/ExposureTime. Attachment 1: calib_20170930_152.pdf Attachment 2: calib_20170930_153.pdf 13347 Fri Sep 29 18:36:25 2017 gautamUpdateLSCDAC noise measurement (again) BS connections and damping restored. Quote: I am running some more measurements of the DAC noise, for which I've shut down the BS watchdog. Some of the cables on the coil driver side have been disconnected. I will restore these tomorrow. 13346 Fri Sep 29 11:16:52 2017 SteveUpdateALSY End table corrected The first Faraday isolater rejected beam path from the NPRO is fixed. Attachment 1: ETMYf1.jpg 13345 Fri Sep 29 11:07:16 2017 gautamUpdateCDS40m files backup situation The FB1 dd backup process seems to have finished too - but I got the following message: dd: error writing ‘/dev/sdc’: No space left on device 30523666+0 records in 30523665+0 records out 2000398934016 bytes (2.0 TB) copied, 50865.1 s, 39.3 MB/s Running lsblk shows the following: controls@fb1:~ 32$ lsblk NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT sdb      8:16   0 23.5T  0 disk └─sdb1   8:17   0 23.5T  0 part /frames sda      8:0    0    2T  0 disk ├─sda1   8:1    0  476M  0 part /boot ├─sda2   8:2    0 18.6G  0 part /var ├─sda3   8:3    0  8.4G  0 part [SWAP] └─sda4   8:4    0    2T  0 part / sdc      8:32   0  1.8T  0 disk ├─sdc1   8:33   0  476M  0 part ├─sdc2   8:34   0 18.6G  0 part ├─sdc3   8:35   0  8.4G  0 part └─sdc4   8:36   0  1.8T  0 part

While I am able to mount /dev/sdc1, I can't mount /dev/sdc4, for which I get the error message

controls@fb1:~ 0$sudo mount /dev/sdc4 /mnt/HGSTbackup/ mount: wrong fs type, bad option, bad superblock on /dev/sdc4, missing codepage or helper program, or other error  In some cases useful info is found in syslog - try dmesg | tail or so. Looking at dmesg, it looks like this error is related to the fact that we are trying to clone a 2TB disk onto a 1.8TB disk - it complains about block size exceeding device size. So if we either have to get a larger disk (4TB?) to do the dd backup, or do the backing up some other way (e.g. unmount /frames RAID, delete everything in /frames, and then do dd, as Jamie suggested). If I understand correctly, unmounting /frames RAID will require that we stop all the daqd processes for the duration of the dd backup  Quote: sudo dd if=/dev/sda of=/dev/sdb bs=64K conv=noerror,sync in a tmux session on nodus (as I did for chiara and FB1, latter backup is still running). Edit: unmounting /frames won't help, since dd makes a bit for bit copy of the drive being cloned. So we need a drive with size that is >= that of the drive we are trying to clone. On FB1, this is /dev/sda, which has a size of 2TB. The HGST drive we got has an advertised size of 2TB, but looks like actually only 1.8TB is available. So I think we need to order a 4TB drive. 13344 Fri Sep 29 09:43:52 2017 jamieHowToCDSpyawg  Quote: I've modified the __init.py__ file located at /ligo/apps/linux-x86_64/cdsutils-480/lib/python2.7/site-packages/cdsutils/__init__.py so that you can now simply import pyawg from cdsutils. On the control room workstations, iPython is set up such that cdsutils is automatically imported as "cds". Now this import also includes the pyawg stuff. So to use some pyawg function, you would just do (for example): exc=cds.awg.ArbitraryLoop(excChan,excit,rate=fs) One could also explicitly do the import if cdsutils isn't automatically imported: from cdsutils import awg pyawg-away! Linking this useful instructional elog from Chris here: https://nodus.ligo.caltech.edu:8081/Cryo_Lab/1748 ? Why aren't you able to just import 'awg' directly? You shouldn't have to import it through cdsutils. Something must be funny with the config. 13343 Thu Sep 28 23:50:04 2017 gautamUpdateLSCDAC noise measurement (again) I am running some more measurements of the DAC noise, for which I've shut down the BS watchdog. Some of the cables on the coil driver side have been disconnected. I will restore these tomorrow. As Rana pointed out to me, one important fact to keep in mind w.r.t. DAC noise is that it can be non-linear. So the RMS of the DAC noise in a higher frequency band (say 60-100Hz) can be affected by the RMS of the requested DAC signal in some lower frequency band (say 10-20Hz). One test to see if this hypothesis can explain the difference @100Hz between the ITMX channels and BS channels I observed a couple of days ago is to see if the noise around 100Hz becomes lower when I enable a 20-40Hz bandstop in the digital signal chain. 13342 Thu Sep 28 23:47:38 2017 gautamUpdateCDS40m files backup situation The nodus backup too is now complete - however, I am unable to mount the backup disk anywhere. I tried on a couple of different machines (optimus, chiara and pianosa), but always get the same error: mount: unknown filesystem type 'LVM2_member' The disk itself is being recognized, and I can see the partitions when I run lsblk, but I can't get the disk to actually mount. Doing a web-search, I came across a few blog posts that look like the problem can be resolved using the vgchange utility - but I am not sure what exactly this does so I am holding off on trying. To clarify, I performed the cloning by running sudo dd if=/dev/sda of=/dev/sdb bs=64K conv=noerror,sync in a tmux session on nodus (as I did for chiara and FB1, latter backup is still running). 13341 Thu Sep 28 23:32:38 2017 gautamHowToCDSpyawg I've modified the __init.py__ file located at /ligo/apps/linux-x86_64/cdsutils-480/lib/python2.7/site-packages/cdsutils/__init__.py so that you can now simply import pyawg from cdsutils. On the control room workstations, iPython is set up such that cdsutils is automatically imported as "cds". Now this import also includes the pyawg stuff. So to use some pyawg function, you would just do (for example): exc=cds.awg.ArbitraryLoop(excChan,excit,rate=fs) One could also explicitly do the import if cdsutils isn't automatically imported: from cdsutils import awg pyawg-away! Linking this useful instructional elog from Chris here: https://nodus.ligo.caltech.edu:8081/Cryo_Lab/1748 13340 Thu Sep 28 11:13:32 2017 jamieUpdateCDS40m files backup situation  Quote: After consulting with Jamie, we reached the conclusion that the reason why the root of FB1 is so huge is because of the way the RAID for /frames is setup. Based on my googling, I couldn't find a way to exclude the nfs stuff while doing a backup using dd, which isn't all that surprising because dd is supposed to make an exact replica of the disk being cloned, including any empty space. So we don't have that flexibility with dd. The advantage of using dd is that if it works, we have a plug-and-play clone of the boot disk and root filesystem which we can use in the event of a hard-disk failure. One option would be to stop all the daqd processes, unmount /frames, and then do a dd backup of the true boot disk and root filesystem. Another option would be to use rsync to do the backup - this way we can selectively copy the files we want and ignore the nfs stuff. I suspect this is what we will have to do for the second layer of backup we have planned, which will be run as a daily cron job. But I don't think this approach will give us a plug-and-play replacement disk in the event of a disk failure. Third option is to use one of the 2TB HGST drives, and just do a dd backup - some of this will be /frames, but that's okay I guess. This is not quite right. First of all, /frames is not NFS. It's a mount of a local filesystem that happens to be on a RAID. Second, the frames RAID is mounted at /frames. If you do a dd of the underlying block device (in this case /dev/sda*, you're not going to copy anything that's mounted on top of it. What i was saying about /frames is that I believe there is data in the underlying directory /frames that the frames RAID is mounted on top of. In order to not get that in the copy of /dev/sda4 you would need to unmount the frames RAID from /frames, and delete everything from the /frames directory. This would not harm the frames RAID at all. But it doesn't really matter because the backup disk has space to cover the whole thing so just don't worry about it. Just dd /dev/sda to the backup disk and you'll just be copying the root filesystem, which is what we want. 13339 Thu Sep 28 10:33:46 2017 gautamUpdateCDS40m files backup situation After consulting with Jamie, we reached the conclusion that the reason why the root of FB1 is so huge is because of the way the RAID for /frames is setup. Based on my googling, I couldn't find a way to exclude the nfs stuff while doing a backup using dd, which isn't all that surprising because dd is supposed to make an exact replica of the disk being cloned, including any empty space. So we don't have that flexibility with dd. The advantage of using dd is that if it works, we have a plug-and-play clone of the boot disk and root filesystem which we can use in the event of a hard-disk failure. 1. One option would be to stop all the daqd processes, unmount /frames, and then do a dd backup of the true boot disk and root filesystem. 2. Another option would be to use rsync to do the backup - this way we can selectively copy the files we want and ignore the nfs stuff. I suspect this is what we will have to do for the second layer of backup we have planned, which will be run as a daily cron job. But I don't think this approach will give us a plug-and-play replacement disk in the event of a disk failure. 3. Third option is to use one of the 2TB HGST drives, and just do a dd backup - some of this will be /frames, but that's okay I guess. I am trying option 3 now. dd however does requrie that the destination drive size be >= source drive size - I'm not sure if this is true for the HGST drives. lsblk suggests that the drive size is 1.8TB, while the boot disk, /dev/sda, is 2TB. Let's see if it works. Backup of chiara is done. I checked that I could mount the external drive at /mnt and access the files. We should still do a check of trying to boot from the LaCie backup disk, need another computer for that. nodus backup is still not complete according to the console - there is no progress indicator so we just have to wait I guess. Quote: Backups of the root filesystems of chiara and nodus are underway right now. I am backing them up to the 1 TB LaCie external hard drives we recently acquired. We also wanted to do a backup of the root of FB1 - but I'm not sure if dd will work with the external hard drive, because I think it requires the backup disk size (for us, 1TB) to be >= origin disk size (which on FB1, according to df -h, is 2TB). Unsure why the root filesystem of FB is so big, I'm checking with Jamie what we expect it to be. Anyways we have also acquired 2TB HGST SATA drives, which I will use if the LaCie disks aren't an option. 13338 Thu Sep 28 06:35:44 2017 ChrisUpdateLSCDAC noise measurement (again) Since you're monitoring two channels simultaneously, you could try subtracting them, as an alternative to carving out bandstops. 1. Drive both channels with the same time series 2. Tweak the filter module gains if needed to equalize the analog outputs 3. Apply SR785 user math to subtract the two channels (or A-B mode of a single input, if you're not using that already?) 4. Measure the residual, which should be the incoherent part containing DAC + coil driver noise Subtraction can conceal certain annoying effects (like numerical noise or level crossing glitches) that remain coherent for two identical outputs. It might be worth experimenting with a differential offset or sinusoid, to try to break up that kind of coherence if it exists. 13337 Wed Sep 27 23:44:45 2017 gautamUpdateALSProposed PM measurement setup Attachment #1 is a sketch of the proposed setup to measure the PM response of the EX NPRO. Previously, this measurement was done via PLL. In this approach, we will need to calibrate the DFD output into units of phase, in order to calibrate the transfer function measurement into rad/V. The idea is to repeat the same measurement technique used for the AM - take ~50 1 average measurements with the AG4395, and look at the statistics. Some more notes: • Delay line box is passive, just contains a length of cable. • IQ Demodulation is done using an aLIGO 1U chassis unit, with the actual demod board electronics being D0902745 • The RF beatnote amplitude out of the IR beat PD is ~ -8dBm. • The ZHL-3A amplifiers have gain of 24dB, so the amplified beat should be ~16dBm • At the LSC rack, the amplified beat is split into two - one path goes to the LO input of D0902745 (so at most 13dBm), the other goes through the delay line. • On the demod board, the LO signal is amplified with a AP1053, rated at 10dB gain, max output of 26dBm, so the signal levels should be fine for us, even though the schematic says the nominal LO level is 10dBm - moreover, I've ignored cable losses, insertion losses etc so we should be well within spec. • The mixer is PE4140. The datasheet quotes LO levels of 17dBm for all the "nominal" tests, we should be within a couple of dBm of this number. • There is no maximum value specified for the RF input signal level to the mixer on the datasheet, but I expect it to be <10dBm. • We should park the beatnote around 30MHz as this should be well within the operational ranges for the various components in the signal chain. Attachment 1: IMG_7609.JPG 13336 Wed Sep 27 22:25:21 2017 gautamUpdateLSCDAC noise measurement (again) Attachment #1: Summary of results of measurements made on Friday. There is a lot in this plot, here is a breakdown: • I drove the excitation points of the coil output filter banks with raw time-series data downloaded during a DRMI lock with pyawg. Today during the meeting, Rana pointed out that we could just acquire median (as opposed to mean since the former is more immune to glitches during the averaging process) spectra during a lock, and then do the ifft in python to generate time series data for pyawg. Another advantage of doing it this way is that we don't need to store a large (~200MB in my case) file of 16k data for numerous channels. But since I already had this file, I decided against changing the methodology for this round of tests. Time series plots of the signals do not show any large glitches. • The SR785 was used in dual channel mode to acquire spectra from 2 coil driver outputs simultaneously, in the interest of saving time. Input range was set to -32dbVpk, AC coupled, which was the smallest value that worked for the given signal profile. Spectra were taken from DC-200Hz, with 801 points, 25 averages. The DB15 output of the coil driver board was connected to a DB15 breakout board, and then a BNC->Pomona mini-grabber adapter was used to connect to the SR785 input. The newly acquired linear power supplies for the GPIB box mean that spurious 60Hz harmonics were not present. • Initially, I had planned to enable various bandstops from 20Hz-200Hz, to get a more complete profile of the noise. But in the end, I only used two elliptic bandstops (6th order, 60dB stopband attenuation): 60-90Hz, for which data is plotted in red and 90-200Hz, for which data is plotted in green • I've used the same noise model as I used here, plotted in dashed grey (summed with SR785 noise at the above input range, with input terminated via 50ohm terminator) - but had to tweak the parameters to get the curve to line up with the measurement. It looks like there is considerable variation between DAC channels, and certainly between the ITMX channels and the BS channels as groups. • I took the measurement in two conditions - with the coil de-whitening off (left column) and coil de-whitening on (right column). Note that the input to the excitation was acquired at the IN1 of the relevant filter bank, and since the de-whitening happens downstream of this, we don't have to do anything special. • In the right column, I have also plotted the LISO modelled noise, which was shown to match well with the measured curve, admittedly only for one channel (for the coil driver alone, so I am not taking into account the noise of the de-whitening board - I will fix this once I dig up that data). Some remarks: 1. According to this measurement, the de-whitening filters are the same on the ITMX channels and BS channels. So I don't understand the difference in the right column for BS and ITMX channels. 2. While there is considerable variation between channels and also between ITMX and BS, there is certainly >6dB of reduction in the DAC noise when the de-whitening is engaged. However, no improvement was seen in the MICH error signal spectrum between 60-300Hz. So we have to continue to investigate other noises that can explain the noise in that band. 3. Also, the realized improvement in DAC noise by turning on the coil de-whitening seems marginal - the low pass has gain of ~-80dB at 100Hz, but we seem to be hitting some sort of electronics noise in all channels at the level of ~100nV/rtHz (assuming the actual DAC noise doesn't degrade significantly when the digital simulated de-whitening filter is engaged). 4. It remains to do the test for the ITMY channels. 5. It would be useful to visualize the incoherent sum of all these channels - this is what should go into the MICH displacement NB. To be added. 6. I'm currently loading pyawg from my user directory. Need to figure out a place to put this and add it to$PATH.

Data + code for this plot will be attached later.

Attachment 1: coilNoises.pdf
13335   Wed Sep 27 00:20:19 2017 gautamUpdateALSMore AM sweeps

Attachment #1: Result of AM sweeps with EX laser crystal at nominal operating temperature ~ 31.75 C.

Attachment #2: Tarball of data for Attachment #1.

Attachment #3: Result of AM sweeps with EX laser crystal at higher operating temperature ~ 40.95 C.

Attachment #4: Tarball of data for Attachment #2.

Remarks:

• Confirmed that PDA 55 is in the "0dB" setting - the actual dial is unmarked, and has 5 states. I guessed that the left-most one is 0dB, and checked that if I twiddled the dial by one state to the right, the DC level on the scope increased by 10dB as advertized. Didn't check all the states.
• DC level is ~2.3V on a high-impedance scope. So it will be ~1.15V to a 50ohm load, which is what the DC block is. The inverse of this value is used to calibrate the vertical axis of the TF measurement to RIN/V.
• Input R (split RF source signal) attenuation: 20dB. Input A (PDA55 output) attenuation: 0dB.
• Main problem is still network hangups when trying to do many sweeps.
• Seems to persist even when I connect the GPIB box to one of the network switches - so don't think we can blame the WiFi.
• Need to explore possibility of speedup - takes >2hours to run ~50scans!

To-do:

• Overlay median and uncertainty plots for the two temp. settings. There is a visible diference in both the locations and depths/heights of various notches/peaks in the AM profile.
• Repeat test with a fast focusing lens to focus the beam more tightly on the PD active area to confirm that the measured AM is indeed due to the PZT drive and not from beam-jitter (presently, spot diameter is ~0.5x active area diameter, to eye).
• Get the PM data.
• Depending on what the PM data looks like, do a more fine-grained scan around some promising AM notches / PM peaks.
Attachment 1: TFAG4395A_26-09-2017_202344_FourSquare.pdf
Attachment 2: lowTemp.tgz
Attachment 3: TFAG4395A_26-09-2017_231630_FourSquare.pdf
Attachment 4: highTemp.tgz
13334   Tue Sep 26 22:11:08 2017 johannesUpdateCameraspost-vent camera capture comparison

I configured the remaining GigE-Camera to work on the 40m network. We currently have 3 operational Basler cameras:

The 120gm's have been assigned the IPs 192.168.113.152  (was already configured) and 192.168.113.153 (freshly configured) and have been labeled accordingly. Note that it was not necessary to connect the out-of-the-box camera directly to a dedicated ethernet adapter whose IP was set manually to 169.254.0.XXX as pointed out in earlier posts - a few seconds after connecting the camera to the control room switch (with PoE adapter to power it) the camera showed up in the configuration software tool which is launched via

/opt/rtcds/caltech/c1/scripts/GigE/pylon5/bin/./IpConfigurator

and can be assigned a corrected, static IP.

We have a plethora of 2" tubes for the lens assembly, but not a great variety of focal lengths for 2" lenses. Present with the camera gear were two f=250 mm and one f=150 mm 2" lenses with a NIR broadband AR coating

To determine the lens positions relativ to the sensor I assumed that the camera we're setting up looks at its test mass from a distance of 1m. Using the two available focal lengths we can look for solutions which have reasonable lens separations <~10cm and suitable magnification. We primarily want to image the central mirror area onto a 1/4" sized sensor, which can be achieved with a magnification of ~1/8.

I chose a lens separation of 6cm, which gives a theoretical magnification of -.12 and a sensor-lens 2 distance of 7.95 cm. I placed the lenses accordingly in the tubes and checked the focusing with Gautam's help:

It's pretty close to what we would expect. We will do the calibration using the auxiliary laser on the PSL table. For this I temporarily routed a fiber from the PSL enclosure to the SP table. Since the main cable hole is sort of cramped it's going in through a gap near the ceiling instead.

Attachment 1: lens_distance.pdf
13333   Tue Sep 26 19:10:13 2017 gautamUpdateALSFiber ALS setup neatened

[steve, gautam]

The Fiber ALS box has been installed on the existing shelf on the PSL table. We had to re-arrange some existing cabling to make this possible, but the end result seems okay (to me). The box lid was also re-installed.

Some stuff that still needs to be fixed:

1. Power supply to ZHL amplifiers - it is coming from a table-top DC supply currently, we should hook these up to the Sorensens.
2. We should probably extend the corrugated fiber protection tubing for the three fibers all the way up to the shelf.

Beat spectrum post changes to follow.

Quote:

Is it better to mount the box in the PSL under the existing shelf, or in a nearby PSL rack?

 Quote: Further characterization needs to be done, but the results of this test are encouraging. If we are able to get this kind of out of loop ALS noise with the IR beat, perhaps we can avoid having to frequently fine-tune the green beat alignment on the PSL table. It would also be ideal to mount this whole 1U setup in an electronics rack instead of leaving it on the PSL table

Attachment 1: IMG_7605.JPG
13332   Tue Sep 26 15:55:20 2017 gautamUpdateCDS40m files backup situation

Backups of the root filesystems of chiara and nodus are underway right now. I am backing them up to the 1 TB LaCie external hard drives we recently acquired.

I first initialized the drives by hooking them up to my computer and running the setup.app file. After this, plugging the drive into the respective machine and running lsblk, I was able to see the mount point of the external drive. To actually initialize the backup, I ran the following command from a tmux session called ddBackupLaCie:

sudo dd if=/dev/sda of=/dev/sdb bs=64K conv=noerror,sync

Here, /dev/sda is the disk with the root filesystem, and /dev/sdb is the external hard-drive. The installed version of dd is 8.13, and from version 8.21 onwards, there is a progress flag available, but I didn't want to go through the exercise of upgrading coreutils on multiple machines, so we just have to wait till the backup finishes.

We also wanted to do a backup of the root of FB1 - but I'm not sure if dd will work with the external hard drive, because I think it requires the backup disk size (for us, 1TB) to be >= origin disk size (which on FB1, according to df -h, is 2TB). Unsure why the root filesystem of FB is so big, I'm checking with Jamie what we expect it to be. Anyways we have also acquired 2TB HGST SATA drives, which I will use if the LaCie disks aren't an option.

13331   Tue Sep 26 13:40:45 2017 gautamUpdateCDSNDS2 server restarted on megatron

Gabriele reported problems with the nds2 server again. I restarted it again.

update: had to do it again at 1730 today - unclear why nds2 is so flaky. Log files don't suggest anything obvious to me...

 Quote: I was unable to download data using nds2. Gabriele had reported similar problems a week ago but I hadn't followed up on this. I repeated steps 5-7 from elog 13161, and now it seems that I can get data from the nds2 servers again. Unclear why the nds2 server had to be restarted. I wonder if this is somehow related to the mysterious acromag EPICS server tmux session dropout.

13330   Mon Sep 25 17:56:33 2017 johannesUpdateComputer Scripts / Programstransmitted power during lossmap

I had to do a reboot + burt restore of c1psl today. It was unresponsive and I couldn't get the PMC to lock. I also had to slightly realign the PMC, and the IMC was too misaligned for the autolocker to catch lock. Adjusting it manually, it was predominantly MC1 PIT that was off. The YARM locked on a 10 mode and had to be aligned manually as well.

I left a script running on Donnatella that tilts ETMX and thus moves the beam on ITMX. I'm monitoring the transmitted power to evaluate sane thresholds for the demodulation offsets in a lossmap measurement. The script will return the IFO to normal after it is done and will take <2 hours to complete (no real clue, but there's no way it takes longer than that for ~50 datapoints).

13329   Sun Sep 24 20:47:15 2017 ranaUpdateComputer Scripts / ProgramsRF TF Uncertainties

I have made several changes to Craig's script for better pythonism. Its more robust with different libraries and syntaxes and makes a tarball by default (w/o a command line flag). These kinds of general util scripts will be going into a general use folder in the git.ligo.org/40m/ team area so that it can be used throughout the LSC.

I don't think we need/want a coherence calculation, so I have not included it. Usually, we use coherence to estimate the uncertainty, and here we are just plotting it directly from the dist of the sweeps so coherence seems superfluous.

Attachment 1: TFAG4395A_21-09-2017_115547_FourSquare.pdf
Attachment 2: TFAG4395A_21-09-2017_115547.tgz
13328   Fri Sep 22 18:12:27 2017 gautamUpdateLSCDAC noise measurement (again)

I've been working on setting up some scripts for measuring the DAC noise.

In all the DRMI noise budgets I've posted, the coil-driver noise contribution has been based on this measurement, which could be improved in a couple of ways:

• The measurement was made at the output of the AI board - we can make the measurement at the output of the coil driver board, which will be a closer reflection of the actual current noise at the OSEM coils.
• The measurement was made by driving the DAC with shaped random noise - but we can record the signal to the coils during a lock and make the noise measurement by using awg to drive the coil with this signal, with elliptic bandstops at appropriate frequencies to reveal the electronics noise.
1. The IN1 signals to the coils aren't DQ-ed, but ideally this is the signal we want to inject into the coil_EXC channel for this measurement - so I re-locked the DRMI a couple of nights ago and downloaded the coil IN1 channel data for ~5mins for the ITMs and BS.
2. AWGGUI supposedly has a feature that allows you to drive an EXC channel with an arbitrary signal - but I couldn't figure out how to get this working. I did find some examples of this kind of application using the Python awg packages, so I cobbled together some scripts that allows me to drive some channels and place elliptic bandstop filters as I required.
3. I wasted quite a bit of time trying to implement these signals in Python using available scipy functions, on account of me being a DSP n00b . When trying to design discrete-time filters, of course numerical precision errors become important. Initially I was trying to do everything in the "Transfer function (numerator-denominator)" basis, but as Rana pointed out, the way to go is using SOSs. Fortunately, this is a simple additional argument to the relevant python functions, after which elliptic bandstop filter design was trivial.
4. The actual test was done as follows:
• Save EPICS PIT/YAW offsets, set them to 0, disable Oplev servos, and then shut down optic watchdog once the optic is somewhat damped. This is to avoid the optics getting a large kick when disconnecting the DB15 connector from the coil driver board output.
• Disconnect above-mentioned DB15 connector from the appropriate coil driver board output.
• Turn off inputs to coils in filter module EPICs screens. Since the full signal (local damping servo output + Oplev servo output + LSC servo output) to the coil during a DRMI lock will be injected as an excitation, we don't need any other input.
• Use scripts (which I will upload to a git repo soon) to set up the appropriate excitation.
• To measure the spectrum, I used a DB15 breakout board with test-points soldered on and some mini-grabber-to-BNC adaptors, in order to interface the SR785 to the coil driver output. We can use the two input channels of the SR785 to simultaneously measure two coil driver board output channels to save some time.
• Take a measurement of the SR785 noise (at the appropriate "Input Range" setting) with inputs terminated to estimate the analyzer noise floor.
• Just for kicks, I made the measurement with the de-whitening both OFF/ON.

I only managed to get in measurements for the BS and ITMX today. ITMY to be measured later, and data/analysis to follow.

The ITMX and BS alignments have been restored after this work in case anyone else wants to work with the IFO.

Some slow machine reboots were required today - c1susaux was down, and later, the MC autolocker got stuck because of c1iool0 being unresponsive. I thought we had removed all dependency of the autolocker on c1iool0 when we moved the "IFO-STATE" EPICS variable to the c1ioo model, but clearly there is still some dependancy. To be investigated.

13327   Thu Sep 21 15:23:04 2017 gautamOmnistructureALSLong cable from LSC->IOO

[steve,gautam]

We laid out a 45m long BNC cable from the LSC rack to the IOO rack via overhead cable trays. There is ~5m excess length on either side, which have been coiled up and cable-tied for now. The ends are labelled "TO LSC RACK" and "TO IOO RACK" on the appropriate ends. This is to facilitate hooking up the output of the DFD for making a PM measurement of the AUX X laser. There is already a long cable that runs from the IOO rack to the X end.

13326   Thu Sep 21 01:55:16 2017 ranaUpdateALSX End table of Shame

Image #1: No - we do not use magnetic mounts for beam dumps. Use a real clamp. It has to be rigid. "its not going anywhere" is a nonsense statement; this is about vibration amplitude of nanometers.

Image #2: No - we do not use sticky tape to put black glass beam dumps in place ever, anywhere. Rigid dumps only.

Image #3: Please do not ruin our nice black glass with double sticky tape. We want to keep the surfaces clean. This one and a few of the other Mickey Mouse black glass dumps on this table were dirty with fingerprints and so very useless.

Image #4: This one was worst of all: a piece of black glass was sticky taped to the wall. Shameful.

Please do not do any work on this table without elogging. Please never again do any of these type of beam dumping - they are all illegal. Better to not dump beams than to do this kind of thing.

All dumps have to be rigidly mounted. There is no finger contacting black glass or razor dumps - if you do, you might as well throw it in the garbage.

Attachment 1: 20170921_003143.jpg
Attachment 2: 20170921_002430.jpg
Attachment 3: 20170921_002243.jpg
Attachment 4: 20170921_001906.jpg
13325   Thu Sep 21 01:32:00 2017 gautamUpdateALSAUX X Innolight AM measurement running

[rana,gautam]

We set up a measurement of the AUX X laser AM today. Some notes:

• PDA 55 that was installed as a power monitor for the AUX X laser has been moved into the main green beam path - it is just upstream of the green shutter for this measurement.
• AUX X laser power into the doubling crystal was adjusted by rotating HWP upstream of IR Faraday (original angle was 100, now it is 120), until the DC level of the PDA 55 output was ~2.5V on a scope (high impedance).
• BNC-T was installed at the PZT input of the Innolight - one arm of the T is terminated to ground via 50 ohms. The purpose of this is to always have the output of the power splitter from the network analyzer RF source drive a 50 ohm load.
• The output of the Green PDH servo to the Innolight PZT was disconnected downstream of the summing Pomona box - it is now connected to one output of a power splitter (borrowed from SR function generator used to drive the PZT) connected to the RF source output of the AG4395.
• Other output of power splitter connected to input R of AG4395.
• PDA55 output has been disconnected from CH5 of the AA board. It is connected to input A of the AG4395 via DC block.

Attachment #1 shows a preliminary scan from tonight - we looked at the region 10kHz-10MHz, with an IF bandwidth of 100Hz, 16 averages, and 801 log-spaced frequencies. The idea was to get an idea of where some promising notches in the AM lie, and do more fine-bandwidth scans around those points. Data + code used to generate this plot in Attachment #2.

Rana points out that some of the AM could also be coming from beam jitter - so to put this hypothesis to test, we will put a lens to focus the spot more tightly onto the PD, repeat the measurement, and see if we get different results.

There were a whole bunch of little illegal things Rana spotted on the EX table which he will make a separate post about.

I am running 40 more scans with the same params for some statistics - should be done by the morning.

 Quote: I borrowed the HP impedance test kit from Rich Abbott today. The purpose is to profile the impedance of the NPRO PZTs, as part of the AUX PDH servo investigations. It is presently at the X-end. I will do the test in the coming days.

Update 12:00 21 Sep: Attachment #3 shows schematically the arrangement we use for the AM measurement. A similar sketch for the proposed PM measurement strategy to follow. After lunch, Steve and I will lay out a longish BNC cable from the LSC rack to the IOO rack, from where there is already a long cable running to the X end. This is to facilitate the PM measurement.

Update 18:30 21 Sep: Attachment #4 was generated using Craig's nice plotting utility. The TF magnitude plot was converted to RIN/V by dividing by the DC voltage of the PDA 55 of ~2.3V (assumption is that there isn't significant difference between the DC gain and RF transimpedance gain of the PDA 55 in the measurement band) The right-hand columns are generated by calculating the deviation of individual measurements from the mean value. We're working on improving this utility and aesthetics - specifically use these statistics to compute coherence, this is a work in progress. Git repo details to follow.

There are only 23 measurements (I was aiming for 40) because of some network connectivity issue due to which the script stalled - this is also something to look into. But this sample already suggests that these measurement parameters give consistent results on repeated measurements above 100kHz.

TO CHECK: PDA 55 is in 0dB gain setting, at which it has a BW of 10MHz (claimed in datasheet).

Some math about relation between coherence $\gamma_{xy}(f)$ and standard deviation of transfer function measurements:

$\mathrm{SNR}(f) = \sqrt{\frac{\gamma_{xy}^{2}(f)}{1-\gamma_{xy}^{2}(f)}}$

$\sigma_{xy}^{2} = \frac{1-\gamma_{xy}^{2}(f)}{2N\gamma_{xy}^{2}(f)}|H(f)|^2$  --- relation to variance in TF magnitude. We estimate the variance using the usual variance estimator, and can then back out the coherence using this relation.

$\sigma_{\theta_{xy}} = \mathrm{tan}^{-1}\left [ \sqrt{\frac{1-\gamma_{xy}^{2}(f)}{2N\gamma_{xy}^{2}(f)}} \right ]$ --- relation to variance in TF phase. Should give a coherence profile that is consistent with that obtained using the preceeding equation.

It remains to code all of this up into Craig's plotting utility.

Attachment 1: Innolight_AM.pdf
Attachment 2: Innolight_AM.tar.gz
Attachment 3: IMG_7599.JPG
Attachment 4: 20170921_203741_TFAG4395A_21-09-2017_115547_FourSquare.pdf
13324   Wed Sep 20 16:14:17 2017 gautamUpdateEquipment loanImpedance test kit borrowed from Downs

I borrowed the HP impedance test kit from Rich Abbott today. The purpose is to profile the impedance of the NPRO PZTs, as part of the AUX PDH servo investigations. It is presently at the X-end. I will do the test in the coming days.

13323   Wed Sep 20 15:49:26 2017 ranaOmnistructureComputersnew internet

Larry Wallace hooked up a new switch (Brocade FWS 648G) today which is our 40m lab interface to the outside world internet. Its faster.

He then, just now, switched over the cables which were going to the old one into the new one, including NODUS and the NAT Router. CDS machines can still connect to the outside world.

In the next week or two, he'll install a new NAT for us so that we can have high speed comm from CDS to the world.

13322   Tue Sep 19 14:00:41 2017 SteveUpdatePEMearthquakes

No sus tripped. Seimometers do not see the 5.3M  ?

 Quote: Southern Mexio is still shaking..... so as we

Attachment 1: 7.1MX5.3J.png
13321   Tue Sep 19 11:05:26 2017 SteveUpdateVACRGA scan at day 334

Attachment 1: RGAscan334d.png
13320   Mon Sep 18 18:40:34 2017 gautamUpdateCDSFB wiper script

I did a further check on the wiper script by changing the "percent_keep" from 85.0 to 75.0, and running the script in "dry_run" mode again. The script then output to console the names of all the files it would delete in order to free up the required amount of space (but didn't actually delete any files as it was a dry run). Seemed to be sensible.

To set up the cron job, I did the following on FB1:

• crontab -e opened up the crontab
• Copied over a script called "wiper.cron" from /opt/rtcds/caltech/c1/target/fb to /opt/rtcds/caltech/c1/target/daqd. This essentially contains a bunch of instructions to run the wiper script with the --delete flag, and write the console output to a log file.
• Added the following line: 33 3 * * * /opt/rtcds/caltech/c1/target/daqd/wiper.cron. So the cron job should be executed at 3:33AM everyday.
• The cron daemon seems to be running - sudo systemctl status cron.service yields the following output:
controls@fb1:~ 0$sudo systemctl status cron.service ● cron.service - Regular background program processing daemon Loaded: loaded (/lib/systemd/system/cron.service; enabled) Active: active (running) since Mon 2017-09-18 18:16:58 PDT; 27min ago Docs: man:cron(8) Main PID: 30183 (cron) CGroup: /system.slice/cron.service └─30183 /usr/sbin/cron -f Sep 18 18:16:58 fb1 cron[30183]: (CRON) INFO (Skipping @reboot jobs -- not system startup) Sep 18 18:17:01 fb1 CRON[30205]: pam_unix(cron:session): session opened for user root by (uid=0) Sep 18 18:17:01 fb1 CRON[30206]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Sep 18 18:17:01 fb1 CRON[30205]: pam_unix(cron:session): session closed for user root Sep 18 18:25:01 fb1 CRON[30820]: pam_unix(cron:session): session opened for user root by (uid=0) Sep 18 18:25:01 fb1 CRON[30821]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) Sep 18 18:25:01 fb1 CRON[30820]: pam_unix(cron:session): session closed for user root Sep 18 18:35:01 fb1 CRON[31515]: pam_unix(cron:session): session opened for user root by (uid=0) Sep 18 18:35:01 fb1 CRON[31516]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1) Sep 18 18:35:01 fb1 CRON[31515]: pam_unix(cron:session): session closed for user root • crontab -l on FB1 now shows the following: controls@fb1:~ 0$ crontab -l # Edit this file to introduce tasks to be run by cron. # # Each task to run has to be defined through a single line # indicating with different fields when the task will be run # and what command to run for the task # # To define the time you can provide concrete values for # minute (m), hour (h), day of month (dom), month (mon), # and day of week (dow) or use '*' in these fields (for 'any').# # Notice that tasks will be started based on the cron's system # daemon's notion of time and timezones. # # Output of the crontab jobs (including errors) is sent through # email to the user the crontab file belongs to (unless redirected). # # For example, you can run a backup of all your user accounts # at 5 a.m every week with: # 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/ # # For more information see the manual pages of crontab(5) and cron(8) # # m h  dom mon dow   command 33 3 * * * /opt/rtcds/caltech/c1/target/daqd/wiper.cron

Let's see if this works.

 Quote: Since the script seems to be working now, I am going to set it up on FB1's crontab. Thanks Chris!.

13319   Mon Sep 18 17:51:26 2017 gautamUpdateCDSFB wiper script

It is a little different - specifically, the way the splitting of the output of the "du" command into disk usage and directory is different (see Attachment #1). Apart from this, some of the parameters (e.g. what percentage to keep free) are different.

I changed the percentages to match what we had here, and edited a couple of other lines to print out the files that will be deleted. The dry run seemed to work okay, it produced the output below. Not sure why "df -h" reports a different use percentage though...

Since the script seems to be working now, I am going to set it up on FB1's crontab. Thanks Chris!.

controls@fb1:/opt/rtcds/caltech/c1/target/daqd 0$./wiper.pl Mon Sep 18 17:47:06 PDT 2017 Dry run, will not remove any files!!! You need to rerun this with --delete argument to really delete frame files Directory disk usage: /frames/trend/minute_raw 47126124k /frames/trend/minute 22900668k /frames/trend/second 760359168k /frames/full 19337278516k Combined 20167664476k or 19694984m or 19233Gb /frames size 25097525144k at 80.36% /frames is below keep value of 85.00% Will not delete any files df reported usage 80.36% controls@fb1:/opt/rtcds/caltech/c1/target/daqd 0$ df -h Filesystem                        Size  Used Avail Use% Mounted on /dev/sda4                         2.0T  1.7T  152G  92% / udev                               10M     0   10M   0% /dev tmpfs                              13G  177M   13G   2% /run tmpfs                              32G     0   32G   0% /dev/shm tmpfs                             5.0M     0  5.0M   0% /run/lock tmpfs                              32G     0   32G   0% /sys/fs/cgroup /dev/sda2                          19G  3.7G   14G  21% /var /dev/sda1                         461M   65M  373M  15% /boot /dev/sdb1                          24T   19T  3.5T  85% /frames 192.168.113.104:/home/cds/rtcds   2.0T  1.6T  291G  85% /opt/rtcds 192.168.113.104:/home/cds/rtapps  2.0T  1.6T  291G  85% /opt/rtapps tmpfs                             6.3G     0  6.3G   0% /run/user/1001
 Quote: Attached is the version of the wiper script we use on the CryoLab cymac. It works with perl v5.20.2. Is this different from what you have?

Attachment 1: perlDiff.png
13318   Mon Sep 18 17:30:54 2017 ChrisUpdateCDSFB wiper script

Attached is the version of the wiper script we use on the CryoLab cymac. It works with perl v5.20.2. Is this different from what you have?

Attachment 1: wiper.pl
#!/usr/bin/perl
use File::Basename;

print "\n" .  date . "\n";
# Dry run, do not delete anything
$dry_run = 1; if ($ARGV[0] eq "--delete") { $dry_run = 0; } print "Dry run, will not remove any files!!!\n" if$dry_run;

... 184 more lines ...
13317   Mon Sep 18 17:17:49 2017 gautamUpdateCDSFB wiper script

After trying to debug this issue using the Perl debugger, I concluded that the problem is in the part of the code that splits the output of the "du" command into directory and disk usage. For whatever, reason, this isn't working. The version of perl running on the new FB1 machine is 5.20.2, whereas I suspect the version running on the old FB machine was 5.14.2 (which is the version on all the Ubuntu 12 workstations and megatron). Unclear whether downgrading the Perl version is the right way to go.

The FB1 disk is now getting close to full, the usage is up to 85% today.

Quote:

Before I go down a Perl rabbit hole, has anyone seen such an error or is aware of some reason why this might not work on the new FB? Am I even using the correct scripts?

13316   Mon Sep 18 15:00:15 2017 rana, gautamFrogsComputer Scripts / Programsgateway PWD change

We implemented the post-SURF-season nodus password change today.

New password can be found at the usual location.

13315   Sat Sep 16 10:56:19 2017 ranaUpdateLSCCoil de-whitening switching investigation

The absence of evidence is not evidence of absence.

13314   Fri Sep 15 17:08:58 2017 gautamUpdateLSCCoil de-whitening switching investigation

I downloaded a segment of data from the time when the DRMI was locked with the BS and ITM coil driver de-whitening switched on, and looked at coherence between MC transmission and the MICH error signal. Attachment #1 doesn't show any broadband high coherence between 60-300Hz, so it cannot explain the noise in the full range between 60-300Hz.

The DQ channel for the MC transmission is recorded at 1024 kHz, so to calculate the coherence, I had to decimate the 16K MICH data.

Since we have the AOM installed, I suppose we can actually measure the intensity noise coupling to MICH by driving a line in the AOM.

I also checked for coherence in the 60-300Hz band between MICH/PRCL and MICH/SRCL, and didn't see any appreciable coherence. Need to think about this more.

 Quote: Rana suggested checking coherence with MC transmission to see if this could be laser intensity noise.
Attachment 1: DRMI_IntensityNoise.pdf
13313   Fri Sep 15 16:00:33 2017 gautamUpdateLSCSensing measurement

I've been working on analyzing the data from the DRMI locks last week.

Here are the results of the sensing measurement.

Details:

1. The sensing measurement is done by using the existing sensing matrix infrastructure to drive the actuators for the various DoFs at specific frequencies (notches at these frequencies are turned on in the control loops during the measurement).
2. All the analysis is done offline - I just note down the times at which the sensing lines are turned on and then download the data later. The amplitudes of the oscillators are chosen by looking at the LSC PD error signal spectra "live" in DTT, and by increasing the amplitude until the peak height is ~10x above the nominal level around that frequency. This analysis was done on ~600seconds of data.
3. The actual sensing elements in the various PDs are calculated as follows:
• Calculate the Fourier coefficients at the excitation frequency using the definition of the complex DFT in both the LSC PD signal and the actuator signal (both are in counts). Windowing is "Tukey", and FFT length used is 1 second.
• Take their ratio
• Convert to suitable units (in this case V/m) knowing (i) The actuator discriminant in cts/m and (ii) the cts/V ADC calibration factor. Any whitening gain on the PD is taken into account as well.
• If required, we can convert this to W/m as well, knowing (i) the PD responsivity and (ii) the demodulation chain gain.
• Most of this stuff has been scripted by EricQ and is maintained in the pynoisesub git repo.

The plotting utility is a work in progress - I've basically adapted EricQs scripts and added a few features like plotting the uncertainties in magnitude and phase of the calculated sensing elements. Possible further stuff to implement:

• Only plot those elements which have good coherence in the measurement data. At present, the scripts check the coherence and prompt the user if there is poor coherence in a particular channel, but no vetos are done.
• The uncertainty calculation is done rather naively now - it is just the standard deviation in the fourier coefficient determined from various bins. I am told that Bendat and Piersol has the required math. It would be good to also incorporate the uncertainties in the actuator calibration. These are calculated using the python uncertainties package for now.
• Print a summary of the parameters used in the calculation, as well as sensing elements + uncertainty in cts/m, V/m and W/m, on a separate page.
• Some aesthetics can be improved - I've had some trouble getting the tick intervals to cooperate so I left it as is for the moment.

Also, the value I've used for the BS actuator calibration is not a measured one - rather, I estimated what it will be by scaling the old value by the same ratio which the ITMs have changed by post de-whitening board mods. The ITM actuator coefficients were recently  measured here. I will re-do the BS calibrations over the weekend.

Noise budgeting to follow - it looks like I didn't set the AS55 demod phase to the previously determined optimal value of -82degrees, I had left it at -42 degrees. To be fixed for the next round of locking.

Attachment 1: DRMI1f_Sep5.pdf
13312   Fri Sep 15 15:54:28 2017 gautamUpdateCDSFB wiper script

A wiper script is not yet set up for our new Frame-Builder. The disk usage is ~80% now, so I think we should start running a wiper script that manages overall disk usage and deletes old frame files to this end.

From what I could find on the elog, the way this was done was by running a cron job on FB. There is a perl script, /opt/rtcds/caltech/c1/target/fb/wiper.pl, which from what I could understand, runs a bunch of du commands on different directories to determine if there is a need to delete any files.

I copied this script over to /opt/rtcds/caltech/c1/target/daqd/wiper.pl. This is the directory in which all the new FB stuff resides. Conveniently, the script has a "dry-run" option, which I tried running on FB1. However, I get the following error message:

Fri Sep 15 15:44:45 PDT 2017
Dry run, will not remove any files!!!
You need to rerun this with --delete argument to really delete frame files
Directory disk usage:
/frames/trend/minute_rawk
Combined 0k or 0m or 0Gb
Illegal division by zero at ./wiper.pl line 98.

So it would seem that for some reason, the du commands aren't working. From what I could tell, there aren't any directory paths specific to the old FB machine that need to be changed. I believe the script was working prior to the FB disk crash - unfortunately it doesn't look like this script was under version control but I don't think any changes have been made to this script.

Before I go down a Perl rabbit hole, has anyone seen such an error or is aware of some reason why this might not work on the new FB? Am I even using the correct scripts?

13311   Tue Sep 12 11:44:16 2017 KiraUpdatePEMtemp sensor update

Got it to work. A cable was broken and the AD586 also broke at the same time so it took a while to find the problem. I had to create a makeshift cable out of three parts so once I replace it for an actual cable, it will be good to go for a test.

Quote:

Today, I stuck on the sensors to a metal block using a flag, rubber bands, and some thermal paste (1st attachment). I then wrapped the whole thing in about 4 layers of insulation and a lot of tape (2nd attachment). The only things leading out of the box were the three connections to the sensors and a thermometer. I then connected the wires to their respective places on the board of the sensor. To get the readings out we would need to use an ADC. Gautam and I checked to make sure the ADC we have inside the lab goes from -10V to 10V so that it would be able to measure the 3V value the sensor typically measures. We then tried to connect all three sensors to a DC source simultaneously, but unfortunately one of them seems to have disconnected somewhere during the process, as it only showed 1.2V instead of 3V. I plan to fix this tomorrow morning so that we can hopefully set this up soon.

 Quote: I took off the AD590 and attached it to two long wires leading out from the board. This will allow us to attach the sensor to a metal block and not have to stick the whole board to it. I have also completed three identical copies of this and it's pretty much ready to be tested. According to Craig and Andrew's elog here, the sensor is very noisy and they added in a low pass filter to fix that, so that's something to consider for the final version of the circuit. I'll test what I have so far and see how that goes. We still need to figure out how to get readings from the sensors. To attach the sensor to the metal block, I'll use some thermal paste and fasteners. I'll also put a thermometer on the block to record the actual temperature. I'll then wrap it in some insulation we have in the lab and have only some wires leading out of it to make measurements. I'll leave this setup overnight and record the outputs for about a full day. The fluctuations between the sensors will then indicate the noise of each individual sensor.

13310   Mon Sep 11 23:31:50 2017 johannesUpdateCameraspost-vent camera capture comparison

The latest pre-unintended vent captures of the test mass face cameras were taken on June 2nd, 2017. Only exposures for ITMYF, ETMYF, and ETMXF exist in /users/sensoray/SensorayCaptures/. I took new captures for those three after locking the arms and having the dither-alignment on for 5+ minutes (exposures were taken after turning the dithering off). The capture script is choking on ITMXF, saying the channel can't lock on. Maybe that's why there's also no reference image for it. Capturing QUAD3, which shows ITMXF in the lower right corner, works, but we don't have a capture for reference. I also recorded dark fields after closing the PSL shutter. Naturally, these don't subtract out as well for the three-month old pictures, but it's actually not terrible and qualitatively one can still compare the subtracted images

Visually, ITMYF and ETMYF do not show a dramatic difference between then and now. ETMXF however, does. To get a numerical estimate for the difference in counts, I worked with the subtracted images and placed an aperture about 1.5x the size of the visible beam blob. I summed up the pixel values inside and subtracted the sum of the pixel values of an equally sized area from the upper left corner of the respective image, which looks free of subtraction artifacts and looks qualitatively similar to the background in the central region.

The pixel sum has gone up by about 50% between the exposures. I still have to do the same for the YARM optics but don't expect such a large discrepancy. Unfortunately we're missing those ITMYF expsures...

All pictures are organized in this format:

 Pre-vent exposure Post-vent exposure Pre-vent subtracted Post-vent subtracted

ETMXF

Attachment 11: ETMXF_pre_sub.bmp
13309   Mon Sep 11 16:46:09 2017 SteveUpdatePEMearthquakes
 Quote: I was trying to get a lossmap measurement over the weekend but had some trouble first with the IMC and then with the PMC. For the IMC: It was a bit too misaligned to catch and maintain lock, but I had a hard time improving the alignment by hand. Fortunately, turning on the WFS quickly once it was locked restored the transmission to nominal levels and made it maintain the lock for longer, but only for several minutes, not enough for a lossmap scan (can take up to an hour). Using the WFS information I manually realigned the IMC, which made locking easier but wouldn't help with staying locked. For the PMC: The PZT feedback signal had railed and the PMC had been unlocked for 8+ hours. The PMC medm screen controls were generally responsive (I could see the modes on the CCDs changing) but I just couldn't get it locked. c1psl was responding to ping but refusing telnet so I keyed the crate, followed by a burt restore and finally it worked. After the PMC came back the IMC has already maintained lock for more than an hour, so I'm now running the first lossmap measurements.

Southern Mexio is still shaking..... so as we

Attachment 1: M5.4eq.png
13308   Mon Sep 11 15:58:02 2017 SteveUpdateGeneralNPRO for repair

This NPRO has a tripping power output******

" Hi Eric,

I checked with the Engineer as Vincent is travelling.

“The lasers have serial number below 2000 which we cannot repair them, we only can repair NPRO laser has serial number 2000 or later.”

Thanks,

Betty-Ann Watt

Customer Service Professional
Global Customer Service/Communication & Commercial Optical Products "

www.lumentum.com

Attachment 1: NPRO_tripping.jpg
ELOG V3.1.3-