Very encouraging results from the test last night.  The new configuration did not crash once overnight, and seemed to write out full, second trend, and minute trend frames without issue.  However, full validity of all the written out frames has not been confirmed.

overview

The configuration under test involves two separate daqd binaries instead of one.  We usually run with what is referred to as a "framebuilder" (fb) configuration:

• fb: a single daqd binary that:
  • collect the data from the front ends
  • coallate full data into frame file format
  • calculates trend data
  • writes frame files to disk.

The current configuration separates the tasks into multiple separate binaries: a "data concentrator" (dc) and a "frame writer" (fw):

• dc:
  • collect data from front ends
  • coallate full data into frame file format
  • broadcasts frame files over local network
• fw:
  • receives frame files from broadcast
  • calculates trend data
  • writes frame files to disk

This configuration is more like what is run at the sites, where all the various components are separate and run on separate hardware.  In our case, I tried just running the two binaries on the same machine, with the broadcast going over the loopback interface.  None of the systems that use separated daqd tasks see the failures that we've been seeing with the all-in-one fb configuration (and other sites like AEI have also seen).

My guess  is that there's some busted semaphore somewhere in daqd that's being shared between the concentrator and writer components.  The writer component probably aquires the lock while it's writing out the frame, which prevents the concentrator for doing what it needs to be doing while the frame is being written out.  That causes the concentrator to lock up and die if the frame writing takes too long (which it seems to almost necessarily do, especially when trend frames are also being written out).

results

The current configuration hasn't been tweaked or optimized at all.  There is of course basically no documentation on the meaning of the various daqdrc directives.  Hopefully I can get Keith Thorne to help me figure out a well optimized configuration.

There is at least one problem whereby the fw component is issuing an excessively large number of re-transmission requests:

2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 6 packets; port 7097
2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 8 packets; port 7097
2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 3 packets; port 7097
2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 5 packets; port 7097
2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 5 packets; port 7097
2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 5 packets; port 7097
2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 5 packets; port 7097
2016-06-15_09:46:22 [Wed Jun 15 09:46:22 2016] Ask for retransmission of 6 packets; port 7097
2016-06-15_09:46:23 [Wed Jun 15 09:46:23 2016] Ask for retransmission of 1 packets; port 7097

It's unclear why.  Presumably the retransmissions requests are being honored, and the fw eventually gets the data it needs.  Otherwise I would hope that there would be the appropriate errors.

The data is being written out as expected:

 full/11500: total 182G
drwxr-xr-x  2 controls controls 132K Jun 15 09:37 .
-rw-r--r--  1 controls controls  69M Jun 15 09:37 C-R-1150043856-16.gwf
-rw-r--r--  1 controls controls  68M Jun 15 09:37 C-R-1150043840-16.gwf
-rw-r--r--  1 controls controls  68M Jun 15 09:37 C-R-1150043824-16.gwf
-rw-r--r--  1 controls controls  69M Jun 15 09:36 C-R-1150043808-16.gwf
-rw-r--r--  1 controls controls  69M Jun 15 09:36 C-R-1150043792-16.gwf
-rw-r--r--  1 controls controls  68M Jun 15 09:36 C-R-1150043776-16.gwf
-rw-r--r--  1 controls controls  68M Jun 15 09:36 C-R-1150043760-16.gwf
-rw-r--r--  1 controls controls  69M Jun 15 09:35 C-R-1150043744-16.gwf

 trend/second/11500: total 11G
drwxr-xr-x  2 controls controls 4.0K Jun 15 09:29 .
-rw-r--r--  1 controls controls 148M Jun 15 09:29 C-T-1150042800-600.gwf
-rw-r--r--  1 controls controls 148M Jun 15 09:19 C-T-1150042200-600.gwf
-rw-r--r--  1 controls controls 148M Jun 15 09:09 C-T-1150041600-600.gwf
-rw-r--r--  1 controls controls 148M Jun 15 08:59 C-T-1150041000-600.gwf
-rw-r--r--  1 controls controls 148M Jun 15 08:49 C-T-1150040400-600.gwf
-rw-r--r--  1 controls controls 148M Jun 15 08:39 C-T-1150039800-600.gwf
-rw-r--r--  1 controls controls 148M Jun 15 08:29 C-T-1150039200-600.gwf
-rw-r--r--  1 controls controls 148M Jun 15 08:19 C-T-1150038600-600.gwf

 trend/minute/11500: total 152M
drwxr-xr-x 2 controls controls 4.0K Jun 15 07:27 .
-rw-r--r-- 1 controls controls  51M Jun 15 07:27 C-M-1150023600-7200.gwf
-rw-r--r-- 1 controls controls  51M Jun 15 04:31 C-M-1150012800-7200.gwf
-rw-r--r-- 1 controls controls  51M Jun 15 01:27 C-M-1150002000-7200.gwf

The frame sizes look more or less as expected, and they seem to be valid as determined with some quick checks with the framecpp command line utilities.

Visual inspection of rooftop GPS antennae:

The 2 GPS antennas are located on the north west corner of CES roof. Their condition looks well weathered. I'd be surprised if they work.

The BNC connector of the 1553 head is inside of the conduit so it is more likely to have a better connection than the other one.

I have not had a chance to look into the "GPS Time Server" unit.

Just to be clear, there's still quite a bit of work to fully transition the 40m to this new system/configuration.  Once we determine a good configuration we need to complete the install, and modify the setup to run the two binaries instead of just the one.  The data is also being written to a raid on the new fb1, and we need to decide if we should use this new raid, or try to figure out how to move the old jetstor raid to the new fb1 machine.

I wish to have stereo audio output for the DAF module. Hence, there needs to be a second output from the DAF. I added this second output to the model. Following are the details:

FiBox: It consists of two analog inputs which are digitized and multiplexed and transmitted optically. (only 1 fiber is needed due to multiplexing). Attachment 1 shows the fibox with its 2 analog inputs (one of which, is connected), and 1 fiber output. The output of the DAF goes to the FiBox. Until today, the Fibox recieved only 1 analog input. This analog signal comes from the DAC-8 (count starting from 0), which is located at "CH 1 OUT" SMA output in the "MONITORS" bin on the racks (attachment 2).

I have added another output channel to the DAF model both in software and in hardware. The DAF now also uses DAC-9 analog output which goes to the second analog input of the FiBox. The DAC-9 output is located at "CH 2 OUT" SMA output in the "MONITORS" bin on the racks (attachment 4).

After making the changes, the Fibox is shown in attacment 3.

Testing: The LSC input on passing through the DAF block is given through two different DAC outputs, to the same Fibox channel (one after the other), and the output is heard. More concrete testing will be done tomorrow. It will be as follows:

1) Currently, I need to search for a suitable cable that would connect the second channel of the output fibox to the audio mixer. After doing this, end to end testing of both channels will be done.

2) I could not access the AWG, probably because the DAQ was offline today afternoon. Using a signal from the AWG will give a more concrete testing of the stereo output.

3) After this, I will separate the two channels of the stereo completely (currectly they are seperated only at the DAF output stage)

4) I also will edit the medm gui appropriately.

PSL, BS, ITMY and ETMX the illuminators were left on over night.

NOT finished, last edited 7-7

Using the ALS green beat and armlength feedback I mapped an IR resonance of the Y-Arm by stepping through a ramp of offset values.

First I optimized the IR alignment with the dither scripts while LSC kept the arm on resonance, and then transitioned the length control to ALS. The beat frequency I obtained between the Y-arm green and the PSL was about 25 MHz. Then I applied a controlled ramp signal (stepping through small offset increments applied to LSC-ALSY_OFFSET, while logging the readback from channels LSC-TRY_OUT16 and ALS-Y_FC_SERVO_INMON with an averaging time of 1s.

The plots show the acquired data with fits to  and , respectively.

The fits, weighted with inverse rms uncertainty of the data points as reported by the cds system, returned HWHM = 0.6663 ± 0.0013 [offset units] and m = -0.007666 ± 0.000023 [MHz/offset unit], which gives a combined FWHM = 10,215 ± 36 Hz. The error is based purely on the fit and does not reflect uncertainties in the calibration of the phase tracker.

This yields a finesse of 388.4 ± 1.4, corresponding to a total loss (including transmissivities) of 16178 ± 58 ppm. These uncertainties include the reported accuracies of FSR and phase tracker calibration from elog 9804 and elog 11761.

The resulting loss is a little lower than that of elog 11712, which was done before the phase tracker re-calibration. Need to check for consistency.

I have installed a ZFL-500LN on the RF output of POY11. This should reduce the effect of the CM board voltage offsets by increasing the size of the error signal coming into the board. Checking with an oscilloscope at the LSC rack, the single arm PDH peak to peak voltage was something like 4mV, now it is something like 80mV. 

The setup is similar to the REFL165 situation, but with the amplifier in proximity with the PD, instead of at the end of a long cable at the LSC rack. 

The PD RF output is T'd between an 11MHz minicircuits bandpass filter and a 50 Ohm terminator (which makes sure that signals outside of the filter's passband don't get reflected back into the PD). The output of the filter is connected directly to the input of the ZFL-500LN, which is powered (temporarily) by picking off the +15V from the PD interface cable via Dsub15 breakout. (I say temporarily, as Koji is going to pick out some fancy pi-filter feedthrough which we can use to make a permanent power terminal on the PD housing.)

The max current draw of this amplifier is 60mA. Gazing at the LSC interface (D990543), I think the +15V on the DSUB cable is being passed from the eurocard crate; I don't see any 15V regulator, so maybe this is ok...

The free swinging PDH signal looked clean enough on a scope. Jamie is doing stuff with the framebuilder, so I can't look at spectra right now. However, turning the POY whitening gain down to +18dB from +45dB lets the Y arm lock on POY with all other settings nominal, which is about what we expect from the nominal +23dB gain of the amplifier.

I would see CM board offsets of ~5mV before, which was more a little more than a linewidth before this change. Now it will be 5% of that, and hopefully more manageable.

Summary

In a previous elog, I demonstrated that the RoC mismatch between ETMX and ETMY does not result in appreciable degradation in the mode overlap of the two arm modes. Koji suggested also checking the effect on the contrast defect. I'm attaching the results of this investigation (I've plotted the contrast,   rather than the contrast defect 1-C).

Details and methodology

• I used the same .kat file that I had made for the current configuration of the 40m, except that I set the reflectivities of the PRM and the SRM to 0. 
• Then, I traced the Y arm cavity mode back to the node at which the laser sits in my .kat file to determine what beam coming out of the laser would be 100% matched to the Y arm (code used to do this attached)
• I then set the beam coming out of the laser for the subsequent simulations to the value thus determined using the gauss command in finesse.
• I then varied the RoC of ETMX (I varied the sagittal and tangential RoCs simultaneously) between 50m and 70m. As per the wiki page, the spare ETMs have an RoC between 54 and 55m, while the current ETMs have an RoC of 60.26m and 59.48m for the Y and X arms respectively (I quote the values in the "ATF" column). Simultaneously, at each value of the RoC of ETMX, I swept the microscopic position of the ETMX HR surface through 2pi radians (-180 degrees to 180 degrees) using the phi functionalilty of finesse, while monitoring the power at the AS port of this configuration using a pd in finesse. This guarantees that I sweep through all the resonances. I then calculate the contrast using the above formula. I divided the parameter space into a grid of 50 points for the RoC of ETMX and 1000 points for the microscopic position of ETMX. 
• I fixed the RoC of ETMY as 57.6m in the simulations... Also, the maxtem option in the .kat file is set to 4 (i.e. higher order modes with indices m+n<=4 are accounted for...)

Result:

Attachment #1 shows the result of this scan (as mentioned earlier, I plot the contrast C and not the contrast defect 1-C, sorry for the wrong plot title but it takes ~30mins to run the simulation which is why I didn't want to do it agian). If the RoC of the spare ETMs is about 54m, the loss in contrast is about 0.5%. This is in good agreement with this technical note by Koji - it tells us to expect a contrast defect in the region of 0.5%-1% (depending on what parameter you use as the RoC of ETMY). 

Conclusion:

It doesn't seem that switching out the current ETM with one of the spare ETMs will result in dramatic degradation of the contrast defect...

Misc notes:

1. Regarding the phase command in Finesse - EricQ pointed out that the default value of this is 3, which as per the manual could give unphysical results sometimes. The flags "0" or "2" are guaranteed to yield physical results always according to the manual, so it is best to set this flag appropriately for all future Finesse simulaitons. 
2. I quickly poked around inside the cabinet near the EX table labelled "clean optics" to see if I could locate the spare ETMs. In my (non-exhaustive) search, I could not find it in any of the boxes labelled "2010 upgrade" or something to that effect. I did however find empty boxes for ETMU05 and ETMU07 which are the ETMs currently in the IFO... Does anyone know if I should look elsewhere for these?
   EDIT 17Jun2016: I have located ETMU06 and ETMU08, they are indeed in the cabinet at the X end...
3. I'm attaching a zip file with all the code used to do this simulation. The phase flag has been appropriately set in the (only) .kat file. setLaserQparam.py was used to determine what beam parameter to assign to be perfectly matched to the Y arm. modeMatchCheck_ETM.py was used to generate the contrast as a function of the RoC of ETMX.
4. With regards to the remaining checks to be done - I will post results of my investigations into the HOM scans as a function of the RoC of the ETMs and also the folding mirrors shortly... 

After poking at the new configuration more, it also started to show instability.  I couldn't figure out how to make test points or excitations available in this configuration, and adding in the full set of test point channels, and trying to do simple things like plotting channels with dtt, the frame writer (fw) would fall over, apparetnly unable to keep up with the broadcast from the dc.

I've revered everything back to the old semi-working fb configuration, and will be kicking this to the CDS group to deal with.

There was only one razor blade beam dump labeled for atmospheric use left, but that's all we need. Steve is working on restocking. I placed the modified AOM mount on the PSL table near its intended location (near the AOM where it doesn't block any beams).

Things to keep in mind:

• The laser power needs to be turned down for the installation of the AOM. Current laser settings are: Crystal Temperature: 29.41 C, Diode Current: 2.1 A.
• The AOM driver must not be left unterminated when turned on (which it currently is and will be).
• The HEPA filters are currently running at ~50%. While the PSL enclosure is open for the work we'll set them to 100% and lower them after a job well done.

The setup:

The AOM has a deflection angle of about 20 mrad, which requires about 10cm of path for a separation of 2mm of the two beams. I need to survey closer and confirm, but I hope I can fit the beam dump in before the PMC (this of course also depends on the spot size). Alternatively, the PMC hopefully isn't resonant for anything remotely relevant at 80MHz offset, in which case we can also place the beam dump in its reflection path.

So this is the plan:

• Determine coupling efficiency into PMC for reference
• Turn down laser power
• No signal on AOM driver modulation input
• Mount AOM, place in beam path, and align
• Correct alignment into PMC?
• Secondary beam detectable? Adjust modulation input and laser power until detectable.
• Find a place for beam dump
• Confirm that primary beam is not clipping with PMC
• Turn up laser power
• Determine coupling efficiency with restored power to compare

Any thoughts? Based on the AOMs resting place I assumed that it is supposed to be installed before the PMC, but I'm actually not entirely sure where it was sitting before.

That sounds weird. If the ETMY RoC is 60 m, why would you use 57.6 m in the simulation? According to the phase map web page, it really is 60.2 m.

This was an oversight on my part. I've updated the .kat file to have all the optics have the RoC as per the phase map page. I then re-did the tracing of the Y arm cavity mode to determine the appropriate beam parameters at the laser in the simulation, and repeated the sweep of RoC of ETMX while holding RoC of ETMY fixed at 60.2m. The revised contrast defect plot is attached (this time it is the contrast defect, and not the contrast, but since I was running the simulation again I thought I may as well change the plot). 

As per this plot, if the ETMX RoC is ~54.8m (the closer of the two spares to 60.2m), the contrast defect is 0.9%, again in good agreement with what the note linked in the previous elog tells us to expect...

The retiling work has finished, Steve and I restored the N2 supply configuration to its normal state. The sequence of steps followed was:

1. Went to the X end and closed the following valves, roughly in this order: VAEE, VAEV, VABS, VABSCI, VASV, VASE, V4, V1.
2. Checked the RPM on the various turbo pump controllers to make sure they were in their nominal states
3. Disconnect the electrical connections to V1, V4, V5 and VA6 - just to make sure some spurious signal doesn't unintentionally open any of these valves while we are mucking around with the N2 supply
4. Close the valves on the N2 cylinders in the drill room. Disconnect the temporary nitrogen line (at this point, the N2 pressure to the IFO valves goes down from ~7-PSI to 0), reconnect the old supply chain, taking care that we aren't unintentionally loosening any of the Swagelock connections while unscrewing stuff
5. Replaced one of the N2 cylinders that was running low.
6. Reopen the cylinders, restore N2 pressure to IFO valves to ~70PSI.
7. Do steps 1-3 in reverse: i.e. reconnect power to all valves, open them in the reverse order we closed them while monitoring the state of the various turbo pumps. 
8. Acknowledged the error message on the C0VAC medm screen

Note: the valve isolating the RGA automatically shutoff during this work, possibly because it detected a pressure above its threshold - after checking the appropriate pressure gauges, we reopened this valve as well. 

The attached screenshot suggests that everything went as planned and that the vacuum system is back to normal...

Subham and I have placed the AOM back into the setup right in front of the PMC.

Steps undertaken:

1. The HEPA filters were turned off for some reason. They were turned back on, running at 100% while the enclosure was open.
2. Before the installation, after initial realignment, the PMC TRANSPD read out 748 mV.
3. The laser injection current was dialed down to 0.8 A (just above the threshold, judging by PMC cameras.
4. AOM was attached to the new mount while staying connected to its driver. Put in place, a clamp prevents the cable from moving anywhere near the main beam.
5. Aligned AOM to beam, centering the beam (by eye) on front and back apertures.
6. We then applied an offset to the AOM driver input, eventually increasing it to 0.5 V. A secondary beam became clearly visible below the primary beam.
7. In order to place the razor blade dump (stemming from a box, labeled "cleaned for atm use") before the PMC, where the beam separation was about 3 mm, to make sure we can hit the edged area, we had to place the dump at an angle, facing up.
8. Keeping the 0.5V offset on the driver input, with the lights off, we increased the laser diode current in steps of ~200 mA to its original value of 2.1A, while checking for any IR light scattered from the beam dump. Not a trace.
9. At original current setting, we realigned the beam into the PMC, and obtained 743 mV on the TRANSPD in the locked state.
10. Closed off PSL table, dialed HEPAs down to 50%

So, it seems that changing the ETMX for one of the spares will change the contrast defect from ~0.1% to 0.9%. True? Seems like that might be a big deal.

Good job Johannes and Subham.

No suspention lost damping.

I called https://www.endruntechnologies.com/pdf/USM3014-0000-000.pdf  and they said it's very likely just needs a software update. They will email Jamie the details.

I got the email from them.  There was apparently a bug that manifested on February 14 2016.  I'll try to software update today.

http://endruntechnologies.com/pdf/FSB160218.pdf
http://endruntechnologies.com/upgradetemplx.htm

I just upgraded the EndRun Technologies Tempus LX GPS receiver timing unit, and it seems to have fixed all the problems.  

Thanks to Steve for getting the info from EndRun.  There was indeed a bug in the firmware that was fixed with a firmware upgrade.

I upgraded both the system firmware and the firmware of the GPS subsystem:

Tempus LX GPS(root@Tempus:~)-> gntpversion 
Tempus LX GPS 6010-0044-000 v 5.70 - Wed Oct 1 04:28:34 UTC 2014
Tempus LX GPS(root@Tempus:~)-> gpsversion 
F/W 5.10 FPGA 0416
Tempus LX GPS(root@Tempus:~)->

After reboot the system is fully functional, displaying the correct time, and outputting the correct IRIG-B data, as confirmed by the VME timing unit.

I added a wiki page for the unit: https://wiki-40m.ligo.caltech.edu/NTP

Steve added this picture

Summary: The aim is to design an analog anti-aliasing (AA) filter placed before the ADC, whose function is to filter out components of the input spectrum that have frequencies higher than the Nyquist frequency. This needs to be done so that there is no contamination of aliased downconverted high-frequency signals into the ADC output. I have put down and simulated a circuit to do this, based on the spectra of a few interferometer signals that eric Provided. Attachment 1 shows such an input PSD, treated with whitening filter, before the AA. The sampling rate is 65536 Hz and hence the Nyquist freq. is 32768 Hz.

Motivation: Attachments 2 and 3 show the plot of required attenuation for various frequencies above the Nyquist. We can see a peak at 36 kHz, which will alias to about 29kHz. It will require about 70 dB attenuation here. This indicates that use of a notch filter combined with a low pass filter can be used.

Details of Schematic: Attachment 4 shows the schematic of a Boctor low pass notch filter, cascaded by a 2nd order LPF. The stopband frequency of the boctor filter can be tuned to around 36 kHz. Its main advantage for the boctor is better insensitivity to component value tolerances, use of a single op amp, and relatively independent tuning of parameters.  The various component values are calculated from here. The transfer functions for the circuit shown in attachment 4 were simulated using TINA - a spice based simulation software. The transfer function is shown in attachment 5.

A few more calculations: Attachment 6 shows the output psd after the signal has been treated with AA. Attachments 7 and 8 show the ratio of aliased downconverted signal and the unaliased signal of the output. Here, we can see that above about 13 kHz, the ratios go above -40dB, which is apparently undesirable. However, we also see from the transfer function of the filter that the gain falls to less than -20dB after about this frequency, and the aliased signals are atleast 20 dB lower than this, atleast upto about 29 kHz in attachment 7 and about 25 kHz in attachment 8. This means that the aliased signals are negligible as compared to the low frequencies even if they are not negligible as compared to the higher frequencies (above 13 kHz) into which they would get downconverted due to sampling. But these higher frequencies (above 13 kHz) themselves are small.

The filter overall, is 4th order. Considering this and the above discussion, I need to decide what changes to make in the existing schematic. For now, I could discuss with eric to finalize the opamp and start building the pcb board design.

That is what the simulation suggests... I repeated the simulation for a PRFPMI configuration (i.e. no SRM, everything else  as per the most up to date 40m numbers), and the conclusion is roughly the same - the contrast defect degrades from ~0.1% to ~1.4%... So I would say this is significant. I also attempted to see what the contribution of the asymmetry in loss in the arms is, by running over the simulation with the current loss numbers of 230ppm for Yarm and 484ppm for the X arm, split equally between the ITMs and ETMs for both cases, and then again with lossless arms - see attachment #1. While this is a factor, this plot seems to suggest that the RoC mismatch effect dominates the contrast defect...

With the newly amplified POY signal, locking the mode cleaner to the Y arm at ~30kHz bandwidth was quite straightforward. The offset jumps still happen, and are visible in POY11_I_ERR, but are never big enough to cause much power degradation in TRY (except when turning on CM board boosts, but its still not enough to lose lock). The script which accomplishes this is at scripts/YARM, and is in the svn. The MC2/AO crossover is at about 150Hz with 40deg margin.

For now, I'm using IN1 of the CM board, because I haven't removed the op27s that I put into IN2's gain stages. I believe the slew rate limitations of these prevent them from working completely during the offset jumps. I'll put AD829s back soon. 

At first, I had ITMX misalgined to use AS55 as an out of loop sensor, then I aligned and locked the X arm on POX to compare.

Weirdly enough, locking the mode cleaner to the Y arm with 30kHz UGF and two boosts on make no real visible difference in the X arm control signal. This is strange, as the whole point of this affair was to remove the presumably large influence of frequency noise on the X arm signals... Maybe this is injecting too much POY sensor noise?

"medm: command not found" error when run through command line both in pianosa and rossa in both editing and execution modes. It however gets executed and edited through the sitemap button. Don't know the source of the problem. Gautam did check the .bashrc file. aliases for SITEMAP and m40m are intact in the .bashrc file.

The workstations' .bashrc is a symbolic link to /users/controls/.bashrc

In it, someone commented out the critical line:

#source /ligo/cdscfg/workstationrc.sh

I uncommented it. medm (and all of the other things like cdsutils) work again.

I blame jamie.

I wiped down the cranes with wet towel and Mario our janitor did the chamber tops with the tubes.

The optical tabels were not touched.

The outside temp peaked at 44 C yesterday

Below 100 Hz, I suppose this means that the X arm is now limited by the quadrature sum of the X and Y arm seismic noise.

I have updated the DAFI with the following changes:

1) Separated both the channels of stereo output completely, as well as in the GUI.

2) Added text monitors for the inputs and outputs.

The stereo output is now ready except for a cable going from the second channel of the output fibox to the audio mixer.

Attached is the main DAF_OVERVIEW screen and its link button from the LSC screen labelled "DAFI"

I found an anti-aliasing circuit on the 40m wiki. It consists of A differential LPF made using THS4131 low noise differential op-amp (one of the main applications of which is preprocessing before the ADC), and a notch. I modified it to arrange for the desired bandwidth (about 8 kHz) and notch after the Nyquist frequency at 36 kHz. I simulated it to get the attached results:

Attachment 1: It shows the input PSD (same as the one posted in the previous elog), the filter transfer function, and The resulting output.

Attachment 2: The circuit schematic. The initial part using THS4131 is a differential LPF and the subsequent RC network is the notch.

Attachment 3: This shows the ratio of the aliased downconverted signal to the the in-band signal, representative of the contamination in each bin. Here too, the aliased signals are negligible as compared to the low frequencies but they are not negligible as compared to the higher frequencies (above 10 kHz) into which they would get downconverted due to sampling. However, here, the attenuation at 8kHz is less than 6 dB while in the previous circuit, it was about 12 dB. One problem with this circuit is at about 6kHz, there is aliased signal from the 65k to 98kHz band, but this can be taken care of by adding an LPF later.

I spent some time this afternoon reviving some of my CESAR/ESCOBAR shenanigans on the Y arm. I found it neccesary to adjust a few things.

• PMC realigned 
• ETMY oplev centered
• Y End green realigned
• PSL/Y Green beat realigned

Afterwards, ALSY noise levels were good. 

Found PMC unlocked for many hours so I relocked it. IMC relocked by itself, but the input switch seems to be flickering to fast. Also the Keep Alive bit is not flashing. 

Using an RC to BNC connector from the inner drawer, I have added a second output cable going from the output Fibox in the control room to the audio mixer.

The fire alarm came on around 15:05  for about 2-3 minutes. We all  left the lab and counted heads.  I called Paul Mackel x2646 (cell 626/ 890- 3259) at Fire Protection Services. He said that this alarm test was planned and we should of got an email notice. Perhaps I missed that notes.

I got some QPR Nitrile gloves. They are LIGO approved.White nitrile gloves are naturally anti-static- 10⁹ ohms

Their touch not as good as laytex  gloves but try to use them.

Given the effect on the contrast defect, the consensus at the meeting Wednesday 6-22  was that we should continue to use the existing ETMX optic. 

Having investigated the mode-overlap as a function of RoC of the PRC and SRC folding mirrors, I've now been looking into possible stability issues, with the help of some code that EricQ wrote some time back for a similar investigation, but using Finesse to calculate the round trip Gouy phase and other relevant parameters for our current IFO configuration. 

To do so, I've been using:

1. Most up to date arm length measurements of 37.81m for the Y arm and 37.79m for the X arm
2. RoCs of all the mirrors from the phase map summary page
3. Loss numbers from our November investigations

As a first check, I used flat folding mirrors to see what the HOM coupling structure into the IFO is like (the idea being then to track the positions of HOM resonances in terms of CARM offset as I sweep the RoC of the folding mirror). 

However, just working with the flat folding mirror configuration suggests that there are order 2 22MHz and order 4 44MHz HOM resonances that are really close to the carrier resonance (see attached plots). This seems to be originating from the fact that the Y-arm length is 37.81m (while the "ideal" length is 37.795m), and also the fact that the ETM RoCs are ~3m larger than the design specification of 57m. Interestingly, this problem isn't completely mitigated if we use the ideal arm lengths, although the order 2 resonances do move further away from the carrier resonance, but are still around a CARM offset of +/- 2nm. If we use the design RoC for the ETMs of 57m, then the HOM resonances move completely off the scale of these plots... 

Set up gwsumm on optimus and generated summary pages from both L1 and C1 data. Still a few manual steps need to be taken during generation, not fully automated due to some network/username issues. nds2 now working from optimus after restarting nds2 server.

Found 1 out of 2 bluebird microphones in the 40m.

Found 60 EM172 microphones. Previous elog with details: 7777.

Made a dry run of the in-situ cleaning for a 3inch optic.

Attachment 1: The Al dummy mass is clamped in the suspension cage.
Attachment 2: The front surface was painted. The nominal brush with the FC bottle was used.
Attachment 3: Zoom in of the front surface.
Attachment 4: The back surface was painted.
Attachment 5: The back surface was peeled.
Attachment 6: The front surface was peeled too.
Attachment 7: The peeled layers.

Findings:

1. To paint a thick layer (particlarly on the rim) is the key to peel it nicely.

2. It was helpful for easier peeling to have mutiple peek tabs. Two tabs were sufficient for ~1" circle.

3. The nominal brush with the bottle was OK although one has to apply the liquid many times to cover such a large area. A larger brush may cause dripping.

4. The nominal brush was sufficiently long once the OSEMs are removed. In any case it is better to remove the OSEMs.

The existing enclosure for seismometer at LIGO 40m lab is a cylindrical stainless steel can placed upside down over the seismometer. It has more empty space between the seismometer and the internal surface of enclosure which is not desirable(I'll quantitatively elaborate this statement once my temperature measuring setup is ready).

Stainless steel has a thermal conductivity in the range of 16.3 to 16.7 W/m/K and magnetic permeability 1.260e-6 H/m.Assuming an ambient temperature 298K, and the temperature inside the enclosure as 295K, as well as substituting all the values for dimesions and material properties of existing enclosure,
k=16.4 W/mK, μ=1.260e-6 H/m, L=2ft=0.6096m, b=r2 =0.5ft=0.1524m, thickness=5mm, a=r1 =0.1474m.
So by using the textbook relations(I have mentioned them in my report), the value of attenuation coefficient is 5.953584e-05 and the value of rate of heat transfer= 5.64913 kW. The attenuation coefficient value is quite better for steel but proper care needs to be taken to avoid heat transfer. For studying the variation of rate of heat transfer and attenuation with the thickness of enclosure material, I have plotted the following attached graphs for different materials which include hardened stainless steel, aluminium, pure iron and nanoperm-muMetal.

About Data Acquisation

I have already invested a lot of time to configure and use acromag busworks card over ethernet. So now I have made an arrangement to measure temperature by AD592CNZ temperature transducer IC. I would be using raspberry pi for acquiring data untill I figure out a way to use acromag busworks card for the same. This setup of acquiring logging temperature using raspberry pi is mostly ready except the calibration part.

I have taken out the heaters and temperature sensors from the enclosure which was made by Megan last summer. Soon I will test and configure those heaters.

We'll follow LIGO policy:
Our policy is to use first contact within 1 year of purchase for use in the interferometers.  For inspection use I am comfortable with out-of-date use.

GaryLinn offered their indate First Contact for use.

Hi Steve -

I found the doc I was looking for:

https://dcc.ligo.org/LIGO-E1200821

Specifically, you might find guidance in Section 5 and the pictures at the end of the doc.  This should work for Vacseal as well.

Good luck - it will take some time (hours to day or 2)...
I'll be interested to know how it goes.

GariLynn helped us develop this procedure so you could also ask her to cast an eye over the setup if you are worried.

-Betsy

ps: there is no existing fixture to hold SOS optic while soaking it
 

Praful Vasiceddy received 40m specific basic safety training.

In the attached photo from 2012, one can see the installed black glass baffle. According to the drawings (LIGO-DNNNXXX) this one has a clear aperture of 40 mm.

In (someplace ?) we have clean baffles with a 50 mm aperture which can be installed during this vent. In order to be more conservative, let us choose to swap these out for all 4 test masses during the upcoming vent using the green laser as an alignment guide, as Koji described at today's lunch meeting.

They are located at the top of E1 drawer cabinet

I've gone through the SOS suspension document (E970037) and some old elogs to get an idea of all the accesories we need for the process of suspending, aside from the tower itself, which Steve has already put together. Gautam and I have laid our eyes upon most of the critical pieces. Some other objects are unknown, and perhaps not strictly neccesary. 

Confirmed to exist:

• Guide rod gluing fixture
• 3 axis micrometer + microscope doohicky
• PZT buzzer (for fine standoff positioning)
• Winch fixture (the plate maybe doesn't fit perfectly on the top of the SOS tower, but one bolt will probably work)
• Spare guide rods and ruby standoffs
• Magnet+dumbell gluing fixture (in case we need to glue a new magnet+dumbell pair)
• Magnet to optic gluing fixture (including "pickle pickers"/grippers)
• 0.017" suspension wire
• HeNe laser + QPD + beam height target (confirmed working on scope)

In addition, I am told that we have a long ribbon cable that can run from the X end to the clean room to enable OSEM damping control while we do the pitch alignment.

Things mentioned in the procedure I have not found:

• Something called an "SOS set screw tool" (D961412)
  • Not mentioned specifically what this is for
• Edmund scientific pocket measuring microscope + bushing
  • Seems to be intended for centering OSEM holding plate on the magnet position. I found no mention of this use in 40m elogs. It can likely be done by eye
• SOS cleaning bracket (D970181)
  • This is likely for the old liquinox cleaning procedure. We'll be using first contact.

Some other tasks and their status:

• Check cleanroom table levelling:
  • Done via 12" spirit level, looks good
• Glue removal strategy / fixture
  • Steve is working on this
• Cut and apply viton tips to earthquake stops
  • Either gautam will do this, or we will use the current suspension's stops

Proposed Acetone soak dish for SOS epoxy softening.

It has good acces through 5" top ID. The set up is stable and teflon lined.

Materials: glass jar with SS cover, teflon bricks, 0.008" teflon wrapped "high density Drever bricks" and aluminum

Drever brick: I beleive it is a Tungsten alloy. We used it as vac-bat savor at the coffe can. It has high density, heavy and hard, it was never identified.

I will soak one brick  to see if it has any reaction ability with acetone.

NO means that only Glass and Teflon can be used for this fixture in  Acetone. We can not take a chance on the coating!

I guess the small surface area Aluminum dumbbell, guide rod and-or wire standoff, magnet and epoxy does not degrade the acetone such way that it effects our coating.

Not ot mention, that only the very edge of the coating would in this solution.