Today I spent time locking the YARM in order to calibrate the arm cavity. Here's what I did:

1. Misalign all optics other than the beam splitter, ITMY, ETMY and PZT2

2. Restore BS, ITMY, ETMY, and PZT2

3. Open Dataviewer and run /users/Templates/JenneLockingDataviewer/Yarm.xml from the Restore Settings. This opens the signals C1:LSC-POY11_I_ERR (the Pound-Drever-Hall error signal for this measurement) and C1:LSC-TRY_OUT (the light transmitted through ETMY) in the plot window.

4. Adjust ITMY and ETMY pitch and yaw using the video screens looking at AS and ETMYT as a first, rough guide. It can be helpful at first to increase the gain on the YARM servo filter module in the C1LSC control screen to about 0.3 and decrease it back down to 0.1 as the beam becomes better aligned. You know when to decrease this gain when fuzzy, small oscillations appear on the C1:LSC-TRY_OUT signal. If the mode cleaner is locked you should see a bright spot on the AS camera.

5. Tinker with pitch and yaw while looking at the AS screen until you see a reasonably good circular spot without other fringes extending from a bright center.

6. The overall goal is to maximize C1:LSC-TRY_OUT because the power transmitted through EMTY is proportional to the power within the cavity. A decent target value is 0.85 and today I was able to get it to just over 0.80 at best. At first there will probably be small spikes in C1:LSC-TRY_OUT. You want to adjust pitch and yaw until the deviation in the signal from zero is no longer just a spike, but a sustained, flat signal above zero. By this time there should be light showing up on the ETMYT camera as well.

7. Once that happens, continue to successively adjust ITMY and ETMY doing the pitch adjustments on both first, and then the yaw adjustments, or vice versa. You can also tweak the PZT2 pitch and yaw. Once you've got C1:LSC-TRY_OUT as large as possible, you've locked the cavity.

I saved the pitch and yaw settings I ended up with for ITMY, ETMY, BS and PZT2 in the IFO_ALIGN screen. Before the end of the day I think Jenne restored the rest of the previously misaligned optics because they were restored when I got back from dinner.

I also worked on calibrating the YARM. I opened up DTT using C1:LSC-POY11_I_ERR as the measurement channel and C1:SUS-ITMY_LSC_EXC as the excitation channel. I ran a logarithmic swept sine response measurement with 100 points and an amplitude of 25. The mode cleaner kept losing its lock all day, and if this happened while making this measurement I tried to pause the sweep as quickly as possible. I analyzed the the transfer function and the coherence function that the sweep produced, and thought that some of the odd behavior was due to losing the lock and getting back to a slightly different locked state when resuming the measurement. The measured transfer function and coherence plots are attached below. Both the transfer function and the coherence look good above roughly 30 Hz, but do not look correct at low frequencies. There's also a roll-off in the measured transfer function around 200 Hz, while in the model the magnitude of the transfer function drops only after the corner frequency of the cavity, around several kHz. I have attached a plot of the roughly analogous transfer function from the DARM control loop model (the gains are very large due to the large arm cavity gain and the ADC conversion factor of 2^16/(20 V) ). The measured and the modeled transfer functions are slightly different in that the model does not include the individual mirrors, while the excitation was imposed on ITMY for the measurement.

The next steps are to figure out what's happening in DTT with the transfer function and coherence at low frequencies, and to understand the differences between the model and the measurement.

 Here's the same plots in pdf format now. I originally posted them as jpg because I couldn't open the resulting pdf from DTT on rosalba, but I could open the jpg. I'll look into overlaying the measured and modeled curves as well.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I modified my Simulink model of the YARM to match the new filter modules Rana installed on YARM. I also scaled the open loop transfer function of the model to fit the measured open loop transfer function at the unity gain frequency, as shown in the figure below. From this I produced the length response function correctly scaled, also shown below.  Then I applied the calibration factor to the YARM data measured in /users/Templates/Y-Arm_120815.xml. Both the uncalibrated and calibrated spectra are included below.

[Eric, Riju]

Summary: Routing Fibers on AP table for Photo Diode Frequency Response Measurement System

Objective: We are to set-up one simultaneous transfer-function measurement system for all the RF-PDs present in 40m lab. A diode laser output is to be divided by 1x16 fiber splitter and to be sent to all the PDs through single-mode fiber. The transfer function of the PDs will be measured using network analyzer. The output of the PDs will be fed to network analyzer via one RF-switch.

Work Done So Far: We routed the fibers on AP table. Fibers from RF PDS - namely  MC REFL PD, AS55, REFL11, REFL33, REFL55, REFL165, have been connected to the 1x16 fiber splitter. All the cables are lying on the table now, so they are not blocking any beam.

We will soon upload the schematic diagram of the set up.

Missing Component: Digital Fiber Power Meter, Thorlab PM20C

This week I took more data for the calibration of YARM. The summary of measurements taken is:

1. Peak-to-peak on Michelson
2. Michelson open loop
3. Excite ITMY and measure on AS55_Q_ERR
4. Excite ITMY and measure on POY11_I_ERR
5. Excite ETMY and measure on POY11_I_ERR
6. YARM open loop

Then I worked on comparing these measurements to the Simulink model of the interferometer control loop. The measured open loop transfer function of the YARM matched well with the model above about 20 Hz, after the gain was scaled properly to fit the data. Next is to fit the length response function of the model and the measurements, and then use DTT to calibrate the arm cavity's power spectrum.

Jenne, Mike and I installed all of the post holders we could today including: REFL11, REFL33, REFL55, AS55, MCRef, POX11 and POP55.  We did not install AS110, POY or REFL165 because there are interferences that will require moving stuff around. We also did not mount POP22 because it is a peely wally ThorLabs PD that will be replaced by a strong, straight and right thinking LIGO PD in the fullness of time.  We did move it out of the way however which is no more than it deserves. Next step this afternoon Mike and I will install all of the telescopes and launching hardware.  Then with the help of Steve we will begin routing the fibers.  The splitter module will be here by next Monday, the laser by the following Friday and then we will light up the fibers. 

Mike and I installed all of the telescopes and launching hardware for REFL11, REFL33, REFL55, AS55, MCRef, POX11 and POP55. On Monday afternoon Steve will work with us on the fiber routing.  Steve is buying some protective covers for the fibers.

1064 nm Semiconductor Laser Fiber Distribution System and Mirror Tomography

Below threshold these Semiconductor Fabry-Perot lasers have an axial mode structure with a spacing of about a THz. As you turn up the current to above threshold the first mode to oscillate saturates the gain down on all the modes and only it oscillates.  The laser I have here in my office (a backup for the one you have at the 40 meter) has a wavelength of 1064.9 nm at 70 Degrees C.  We should be able to temperature tune it down to 1064.3 nm although this could be a bit tedious the first time we do it. The specifications claim a "spectrum width" of 1.097 nm which I believe is the temperature tuning range.  I don’t know what the line width is but it will be single frequency and we shouldn’t have mode hoping problems.  So we should be able to use it in the “Mirror Tomography” experiment.  You might want to use some sort of polarization diversity to avoid the problems of fiber polarization drift.

There have been 2 student projects on using the fiber distributed PD frequency response at1064 nm laser.

“Automated Photodiode Frequency Response Measurement System,” Alexander Cole - T1300618

“Final Report: Automated Photodiode Frequency Response Measurement System for Caltech 40m lab,” Nichin Sreekantaswamy - P140021

I’ll look up a few more references and add include them in the next elog.

Eric

Overall Design

A schematic of the overall subsystem diagran in attachment.

RF and Optical Connections

Starting at the top left corner is the diode laser module.  This laser has an input which allows it to be amplitude modulated.  The output of the laser is coupled into an optical fiber which is connectorized with an FC/APC connector and is connected to the input port of a 1 by 16 Optical Fiber Splitter. The Splitter produces 16 optical fiber outputs dividing the input laser power into 16 roughly equal optical optical fiber outputs.  These optical fibers are routed to the Photodiode Receivers (PD) which are the devices under test. All of the PDs are illuminated simultaneously with amplitude modulated light. The Optical Fiber outputs each have a collimating fiber telescope which is used to focus the light onto the PDs. Optical Fiber CH1 is routed to a broadband flat response reference photodiode which is used to provide a reference to the HP-4395A Network Analyzer.  The other Channel outputs are connected to an RF switch which can be programmed to select one of 16 inputs as the output.  The selected outputs can then be sent into channel A of the RF Network Analyzer. 

RF Switch

The RF switch consists of two 8 by 1 Multiplexers (National Instruments PXI-254x) slotted into a PXI Chassis (National Instruments PXI-1033).  The Multiplexers have 8 RF inputs and one RF output and can be programmed through the PXI Chassis to select one and only one of the 8 inputs to be routed to the RF output.) The first 8 Channels are connected to the first 8 inputs of the first Multiplexer.  The first Multiplexer’s output is then connected to the Channel 1 input of the second Multiplexer. The remaining PD outputs are connected to the remaining inputs of the second Multiplexer. The output of the second Multiplexer is connected to the A channel of the RF Network Analyzer.  Thus it is possible to select any one of the PD RF outputs for analysis.

Software

Something on this tomorrow.

We conducted a beam scan on the AP table of the AS beam. We used a lens to focus the beam onto a power meter, and slowly moved a razor blade across the beam using a micrometer, vertically and horizontally both in front of and behind the beam. We also had to block the beam next to the AS beam in order to do this, but is unblocked now. Mike will begin curve fitting the data to try and see if there is a different spot size given by the x-axis vs. the y-axis, and if the lens has any effect.

Joe and I have taken control of the EPICS channels C1:PEM-Stacis_EEEX_geo and C1:PEM-Stacis_EEEY_geo since we heard that they are no longer in use.  We are currently 
using them to test the ability for the Snap camera code to read and write from EPICS channels.  Thus, the information being written to these channels is completely unrelated
to their names or previous use.  This is only temporary; we'll create our own channels for the camera code shortly (probably within the next couple of days).

- Eric

[Evan, Jenne]

Tonight we made an attempt at getting the PRM + ITMY aligned with correct input pointing. We steered the good PZT so that the input beam makes it through the aperture in front of ETMY. We then aligned the PRM so that the retroreflection of the input beam makes it back into the Faraday. After that we tried dithering the alignment of ITMY and the beamsplitter to see if we could see a spot flash across the AS port, but we saw nothing.

For the PRM alignment we set up a camera looking into the window at the Faraday in the IOO chamber; it's called FI_BACK. We stole a 50mm lens from the ETMY face camera.

We also tried looking for beam on IP_POS and IP_ANG. When the input beam is aligned to pass through the ETMY aperture, we can see beam on the steering mirrors preceding IP_POS, but it hits a mirror mount. When the input beam is aligned as it was on Monday, it clips on the ETMY aperture but makes it further along the IP_POS optical path.   In both cases, we weren't able to see any beam coming out for IP ANG. 

Adjusted focus on ETMYF camera so that the IR beam is in focus.

[Jenne, Evan]

Tonight we made a non-folded cavity between the PRM and PR2 as follows. I put down two dog clamps to constrain the original position of the PR2 mount. I then loosened the dog clamps holding the mount to the table and nudged the mount until we saw a few reasonably well-aligned bounces in the cavity. I then dogged down the mount.

We played with the PRM and TT2 steering until we saw flashes of TEM00. However, the resonance is not clean so we couldn't lock.

Since we changed the PRM alignment, we had to redo the last bit of steering for the PRM oplev into the photodiode. We also put a few ND filters on the POP camera.

[Manasa, Evan]

Manasa and I are trying to get the AS beam onto the AS camera with a focusing lens. Currently, the mirror immediately preceding the camera has been removed and the camera and lens are sitting directly behind the BS.

 I took out a short (~12 cm) SMA cable from the "LO input" path into the MC demod board in an attempt to maximize the power in Q and minimize the power in I. The path might benefit from being shortened a little more, but it's hard to tell since I is noisy. (In the attached plots, channel 1 is Q and channel 2 is I.)

Should you find it necessary to restore the original path length, the cable I took out is in the "SMA ONLY" tupperware and has a printed label with "5" on it.

I goofed on the transfer function requirement by not giving you the plant transfer function, which looks to be about 0.014 V/V, independent of frequency (PSL:1278). This needs to be compensated for in the electronic transfer function.

Comsol 4.3b is now installed under /cvs/cds/caltech/apps/linux64/COMSOL43b. I've left the existing Comsol 4.2 installation alone; according to the Comsol installation guide [PDF], it is unaffected by the new install. On megatron I've made a symlink so that you can call comsol in bash to start Comsol 4.3b.

The first time I ran comsol server, it asked me to choose a username/password combo, so I made it the same as the combo used to log on to megatron.

Edit: I've also added a ~/.screenrc on megatron (based on this Stackoverflow answer) so that I don't constantly go nuts trying to figure out if I'm already inside a screen session.

FYI, you can trick out matplotlib by creating a matplotlibrc config file. This allows you to set defaults for plot size, trace color, fonts, grids, etc., analogous to what is achieved in ATF:1840 for Matlab.

Note also that matplotlib supports LaTeX by default (if you have LaTeX installed), which means, for example, that you can include true square roots on your spectral densities:

plt.ylabel('Voltage spectral density (V/$\\sqrt{\\mathrm{Hz}}$)')

Since the backslash is used for escape characters in python, you must escape LaTeX backslashes.

For maximum effect, you can set the following lines in your matplotlibrc file:

text.usetex = True

text.latex.preamble = \usepackage{txfonts}

Then all text and mathematics in your plot will be sent through LaTeX for processing and will appear in Times.

Also, why is the conversion from watts to volts V = 50 * sqrt(W) and not V = sqrt(50 * W)?

[Rana, Nic, Evan]

We did some work today on getting the AOM back up and running so that we can implement an SR560-based ISS.

We've removed the 18 AWG wire that was previously used to power the driver and have replaced it with a 12 AWG twisted pair (black and white, enclosed in a single gray cladding). This pair runs into the PSL rack's 24 V terminal block with a 2 A fuse. We've also replaced the cable connecting the AOM to the driver; it's now RG405.

Also disconnected the power to the old Kalmus FSS crystal driver box and turned it off. It was powered illegally. Also disconnected the power connection between the Sorensen and the old ISS AA chassis since it was wired directly without any fuse (which is a code violation). It will stay off until someone uses a proper fuse and wiring to hook it back up.

Comsol 4.4 is now installed under /cvs/cds/caltech/apps/linux64/COMSOL44. I've left the other installations alone. I've changed the symlink on megatron so that comsol now starts Comsol 4.4.

The first time I ran comsol server, it asked me to choose a username/password combo, so I made it the same as the combo used to log on to megatron.

We should consider uninstalling some of the older Comsol versions; right now we have 4.0, 4.2, 4.3b, and 4.4 installed.

As of this writing, the DokuWiki appears to be working.

As you and I suspected, it looks like this was a clusterwhoops with the permissions for the NFS mount. Let's recap what happened in the past 24 hours:

1. Yesterday, 8 PM: I restart the Apache server, thereby resurrecting the SVN (now conveniently located at /export/home/svn). The DokuWikis remain borked.
2. Yesterday, 7 to 11 PM: Zach, Rana, and Jenne perform deep magic to get the front-end machines up and running again. This should be irrelevant for this Apache/SVN/DokuWiki witchcraft.
3. Today, morning: the townsfolk happily resume their svn up and svn ci festival.
4. Today, ca. 3 PM: Zach runs stopapache.sh to bring down Apache, thinking he can bring it back up momentarily with startapache.sh. But NFS is a jealous and vengeful god, and Apache now complains that it doesn't have permission to write to its logfiles, and therefore can't start httpd.
5. Today, 5 PM: "How can this be?", Zach and I ask. Apache had no problem starting up yesterday night, and to our knowledge nobody futzed with chiara's NFS mount of /home/cds. This change remains mysterious to us.

Despite the aforementioned mystery, Zach and I pressed on and tried to diagnose the permissions issue. We found that even if you are logged into nodus or pianosa or rossa or whatever as the controls user, the NFS mount saw us as the user nobody (in the group nogroup). If we created a file on the NFS mount, it was owned by nobody/nogroup. If we tried to modify a file on the NFS mount that was owned by controls/controls or controls/staff, we got a "permission denied" error, even if we tried with superuser privileges.

It turns out this has to do with the vagaries of NFS (scroll down to gotcha #4). We have all_squash enabled in /etc/exports , which means that no matter your username or group on nodus, rossa, pianosa, or harpischordsa, NFS coerces your UID/GID to chiara's nobody/nogroup. Anyway, the fix was to go into chiara's /etc/exports and change this

/home/cds 192.168.113.0/255.255.255.0(rw,sync,no_subtree_check,all_squash,insecure)

to this

/home/cds 192.168.113.0/255.255.255.0(rw,sync,no_subtree_check,all_squash,anonuid=1001,anongid=1001,insecure)

I went into local.php and changed $conf['useacl'] = 1; to $conf['useacl'] = 0; and it looks like the auth issue goes away (I've changed it back). This isn't a fix (we want to use access control), but it gives us a clue as to where the problem is.

[Rana, Evan]

This morning we took several TFs of the MC servo board using the HP4395A.

The 4395 source was teed, with one output of the tee going to 4395 R and the other output going to the board's IN1. We then took TFs of (4395 A) / (4395 R), where 4395 A was one of the following four points on the servo board:

• OUT2
• A TEST1
• B TEST1
• SERVO

For each of these points, we took a TF at two gain settings: IN1 and VCO gains both at 0 dB, and then IN1 and VCO gains both at 20 dB.

Before doing these measurements, we calibrated out the cable delay. Additionally, SERVO was always loaded with 50 Ω—either from the 4395 or from a terminator.

The attached png shows the servo board settings when these TFs were taken with the 0 dB gain settings. The settings for the 20 dB measurements are identical, except for the higher IN1 and VCO gains.

Patient One for this new system will be the MC servo card. The DCC number is D1400242. Currently, v1 is just the original drawing with no modifications. I've updated the DCC document tree at E1400326 accordingly.

It looks like we can use Jenne's information in 40m:9892 to deduce the modifications that have been made (alternatively, someone can just pull the board and examine it on the bench).

The attached zip file has a modified schematic of the MC servo card (011/MC), as deduced from Jenne's photos. Someone should go through and verify that the schematic is correct. Then it can go on the DCC as D1400242-v2.

To modify the schematic, I used Inkscape (the svg files for each sheet are included in the zip file). Then to generate the pdf, I ran

for i in sheet*.svg; do inkscape -A "${i/svg/pdf}" "$i"; done

pdftk sheet*.pdf cat output D1400242

Using the modified schematic (40m:10250), I've made a plot of the TFs I expect for G_IN1 = G_VCO = 0 dB, taking into account our 50 Ω loading of the board.

Evidently I'm somehow missing a factor of 2 in the gain of the overall TF, but the shapes of the expected vs. measured magnitudes agree quite well.

At 1 MHz, I expect we should have accumulated about 80 degrees of phase going through the servo board. In reality, we appear to have lost more like 105 degrees.

Wednesday night, there was ~0.4 V on the PMC transmission PD. I adjusted the steering mirrors into the PMC and got the transmission up to 0.81 V.

The SVN Apache server was not happy trying to read from /cvs/cds/caltech/svn/; it complains "Value too large for defined data type" when trying to modify certain files.

To remedy this, Eric ran an rsync job to copy over the svn directory to /export/home/svn/, which is directly on nodus rather than on the NFS mount.

Accordingly, I edited the httpd-ssl.conf file in /cvs/cds/caltech/apache/etc/ so that SVNPath points to /export/home/svn. The original config file is preserved as httpd-ssl.conf.old_20140609.

Then I started the Apache server using the instructions on the 40 m wiki (search "Apache"). The SVN now appears to be working fine; you can svn up and svn ci as necessary.

However, this means that we now need to start backing up /export/home/svn/, rather than the NFS-mounted directory.

I'd like to build off of Koji's instructions with a few useful tips I discovered while setting up my own summary page environment.

To only make a specified selection of tabs for the summary pages, copy only the corresponding .ini files into /home/albert.einstein/summary/config and run the gw_daily_summary_custom following Koji's instructions below. When asked for nodus's password either hit "enter" three times without providing the password or comment out this section of the code to stop the summary page creation process from taking current data files from nodus. This is especially helpful when the 40m is down (like it is now).

After running the summary page code, the pages can be viewed at https://ldas-jobs.ligo.caltech.edu/~albert.einstein/summary/day/YYYYMMDD/ and corresponding error logs can be found at ~/public_html/summary/logs/gw_summary_pipe_local-687496-0.err.

I've continued to make changes to the summary pages on my own environment, which I plan on implementing on the main summary pages when they are back online.

Motivation:

I created my own summary page environment and manipulated data from June 30 to make additional plots and change already existing plots. The main summary pages (https://nodus.ligo.caltech.edu:30889/detcharsummary/ or https://ldas-jobs.ligo.caltech.edu/~max.isi/summary/) are currently down due to the CDS upgrade, so my own summary page environment acts as a temporary playground to continue working on my SURF project. My summary pages can be found here (https://ldas-jobs.ligo.caltech.edu/~eve.chase/summary/day/20150630/); they contian identical plots to the main summary pages, except for the Summary tab. I'm open to suggestions, so I can make the summary pages as useful as possible.

What I did:

• SUS OpLev: For every already existing optical lever timeseries, I created a corresponding spectrum, showing all channels present in the original timeseries. The spectra are now placed to the right of their corresponding timeseries. I'm still playing with the axes to make sure I set the best ranges.
• SUSdrift: I added two new timeseries, DRMI SUS Pitch and DRMI SUS Yaw, to add to the four already-existing timeseries in this tab. These plots represent channels not previously displayed on the summary pages
• Minor changes
  • Added axis labels on IOO plot 6
  • Changes axis ranges of IOO: MC2 Trans QPD and IOO: IMC REFL RFPD DC
  • Changes axis label on PSL plot 6

Results:

So far, all of these changes have been properly implemented into my personal summary page environment. I would like some feedback as to how I can improve the summary pages.

Here is a list of suggested improvements to the summary pages. Let me know if there's something you'd like for me to add to this list!

• A lot of plots are missing axis labels and titles, and I often don't know what to call these labels. I could use some help with this.
• Check the weather and vacuum tabs to make sure that we're getting the expected output. Set the axis labels accordingly. 
• Investigate past periods of missing data on DataViewer to see if the problem was with the data requisition process, the summary page production process, or something else.
• Based on trends in data over the past three months, set axis ranges accordingly to encapsulate the full data range.
• Create a CDS tab to store statistics of our digital systems. We will use the CDS signals to determine when the digital system is running and when the minute trend is missing. This will allow us to exclude irrelevant parts of the data.
• Provide duty ratio statistics for the IMC.
• Set triggers for certain plots. For example, for channels C1:LSC-XARM OUT DQ and page 4 LIGO-T1500123–v1 C1:LSC-YARM OUT DQ to be plotted in the Arm LSC Control signals figures, C1:LSCTRX OUT DQ and C1:LSC-TRY OUT DQ must be higher than 0.5, thus acting as triggers.
• Include some flag or other marking indicating when data is not being represented at a certain time for specific plots.
• Maybe include some cool features like interactive plots.

- CDS Tab

We want to monitor the status of the digital control system.

1st plot
Title: EPICS DAQ Status
I wonder we can plot the binary numbers as statuses of the data acquisition for the realtime codes.
We want to use the status indicators. Like this:
https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20150722/plots/H1-MULTI_A8CE50_SEGMENTS-1121558417-86400.png

channels:
C1:DAQ-DC0_C1X04_STATUS
C1:DAQ-DC0_C1LSC_STATUS
C1:DAQ-DC0_C1ASS_STATUS
C1:DAQ-DC0_C1OAF_STATUS
C1:DAQ-DC0_C1CAL_STATUS

C1:DAQ-DC0_C1X02_STATUS
C1:DAQ-DC0_C1SUS_STATUS
C1:DAQ-DC0_C1MCS_STATUS
C1:DAQ-DC0_C1RFM_STATUS
C1:DAQ-DC0_C1PEM_STATUS

C1:DAQ-DC0_C1X03_STATUS
C1:DAQ-DC0_C1IOO_STATUS
C1:DAQ-DC0_C1ALS_STATUS

C1:DAQ-DC0_C1X01_STATUS
C1:DAQ-DC0_C1SCX_STATUS
C1:DAQ-DC0_C1ASX_STATUS

C1:DAQ-DC0_C1X05_STATUS
C1:DAQ-DC0_C1SCY_STATUS
C1:DAQ-DC0_C1TST_STATUS

1st plot
Title: IOP Fast Channel DAQ Status
These have two bits each. How can we handle it?
If we need to shrink it to a single bit take "AND" of them.
C1:FEC-40_FB_NET_STATUS (legend: c1x04, if a legend placable)
C1:FEC-20_FB_NET_STATUS (legend: c1x02)
C1:FEC-33_FB_NET_STATUS (legend: c1x03)
C1:FEC-19_FB_NET_STATUS (legend: c1x01)
C1:FEC-46_FB_NET_STATUS (legend: c1x05)

3rd plot
Title C1LSC CPU Meters
channels:
C1:FEC-40_CPU_METER (legend: c1x04)
C1:FEC-42_CPU_METER (legend: c1lsc)
C1:FEC-48_CPU_METER (legend: c1ass)
C1:FEC-22_CPU_METER (legend: c1oaf)
C1:FEC-50_CPU_METER (legend: c1cal)
The range is from 0 to 75 except for c1oaf that could go to 500.
Can we plot c1oaf with the value being devided by 8? (Then the legend should be c1oaf /8)

4th plot
Title C1SUS CPU Meters
channels:
C1:FEC-20_CPU_METER (legend: c1x02)
C1:FEC-21_CPU_METER (legend: c1sus)
C1:FEC-36_CPU_METER (legend: c1mcs)
C1:FEC-38_CPU_METER (legend: c1rfm)
C1:FEC-39_CPU_METER (legend: c1pem)
The range is be from 0 to 75 except for c1pem that could go to 500.
Can we plot c1pem with the value being devided by 8? (Then the legend should be c1pem /8)

5th plot
Title C1IOO CPU Meters
channels:
C1:FEC-33_CPU_METER (legend: c1x03)
C1:FEC-34_CPU_METER (legend: c1ioo)
C1:FEC-28_CPU_METER (legend: c1als)
The range is be from 0 to 75.

6th plot
Title C1ISCEX CPU Meters
channels:
C1:FEC-19_CPU_METER (legend: c1x01)
C1:FEC-45_CPU_METER (legend: c1scx)
C1:FEC-44_CPU_METER (legend: c1asx)
The range is be from 0 to 75.

7th plot
Title C1ISCEY CPU Meters
channels:
C1:FEC-46_CPU_METER (legend: c1x05)
C1:FEC-47_CPU_METER (legend: c1scy)
C1:FEC-91_CPU_METER (legend: c1tst)
The range is be from 0 to 75.

=====================

IOO

We want a duty ratio plot for the IMC. C1:IOO-MC_TRANS_SUM >1e4 is the good period.

Duty ratio plot looks like the right plot of the following link
https://ldas-jobs.ligo-wa.caltech.edu/~detchar/summary/day/20150722/lock/segments/

=====================

SUS: OPLEV

OL_PIT_INMON and OL_YAW_INMON are good for the slow drift monitor.
But their sampling rate is too slow for the PSDs.
Can you use
C1:SUS-ETM_OPLEV_PERROR
C1:SUS-ETM_OPLEV_YERROR
etc...
For the PSDs? They are 2kHz sampling DQ channels. You would be able to plot
it up to ~1kHz. In fact, we want to monitor the PSD from 100mHz to 1kHz.
How can you set up the resolution (=FFT length)?

=====================

LSC / ASC / ALS tabs

Let's make new tabs LSC, ASC, and ALS

LSC:

We should have a plot for
C1:LSC-TRX_OUT_DQ
C1:LSC-TRY_OUT_DQ
C1:LSC-POPDC_OUT_DQ
It's OK to use the minute trend for now.
You can check the range using dataviewer.

ASC:

Let's use
C1:SUS_MC1_ASCPIT_OUT16 (legend: IMC WFS)
C1:ASS-XARM_ITM_YAW_OSC_CLKGAIN (legend: XARM ASS)
C1:ASS-YARM_ITM_YAW_OSC_CLKGAIN (legend: YARM ASS)
C1:ASX-XARM_M1_PIT_OSC_CLKGAIN (legend: XARM Green ASS)
as the status indicators. There is no YARM Green ASS yet.

ALS:

Title: ALS Green transmission
We want a time series of
ALS-TRX_OUT16
ALS-TRY_OUT16

Title: ALS Green beatnote
Another time series
ALS-BEATX_FINE_Q_MON
ALS-BEATY_FINE_Q_MON

Title: Frequency monitor
We have frequency counter outputs, but I have to talk to Eric to know the channel names

The summary pages can still be found at https://nodus.ligo.caltech.edu:30889/detcharsummary/ (EDIT: in an older version of this post I listed an incorrect url). They are operational and include data from some channels for intermittent periods of time.

Motivation: to make the summary pages more informative and useful for all

What I did:

I have added tabs for ALS, ASC, and LSC subsystems. While there is currently no data on the plots, I plan on checking all channels with DataViewer to set appropriate axis ranges so that we can actually see the data.

I altered which channels are used to represent spectra for OpLev systems to more appropriately provide PSDs.

I've changed the check code status page to include "warning" labels. Previously, when the summary pages ran, resulting in a warning message, the check code status page would list this as an "error", implying that the summary pages were not properly produced.

Results:

All features were implemented, but I need to investigate some of these channels to understand why we aren't seeing many channels in the plots. I am working on some other changes to the summary pages, including providing a Locked status which will only show data in a timeseries for a selected period of time.

I've switches the ALS, ASC, and LSC plots on the summary pages from plotting raw frames, to plotting minute trends, instead. Now, the plots contain information, instead of being completely blank, but data is not recorded on the plots after 12UTC.

Typically, I make changes to the summary pages on my own version of the pages, found at https://ldas-jobs.ligo.caltech.edu/~eve.chase/summary/day/, where I change the summary pages for June 30 and then import such changes into the main summary pages. 

I've added states to the summary pages to only show data for times at which one certain channel is above a specified threshold. So far, I've incorporated states for the IOO tab to show when the mode cleaner is locked.

You can see these changes implemented in the IOO tab of my personal summary pages for June 30: https://ldas-jobs.ligo.caltech.edu/~eve.chase/summary/day/20150630/ioo/.

I've written a description of how to add states to summary pages here: https://wiki-40m.ligo.caltech.edu/DailySummaryHelp#How_to_Define_and_Implement_States.

I've fixed the ASC tab on the summary pages to populate the graphs with data without causing an error.

Motivation: The ASC tab was showing no data. It resulted in a name error when generated.

What I did:

A name error indicates a bad channel name in the plot definition. I identified two errors in the code:

1. I said C1:SUS_MC1_ASCPIT_OUT16.mean instead of C1:SUS-MC1_ASCPIT_OUT16.mean (underscore should be dash)
2. The channel C1:ASX-XARM_M1_PUT_OSC_CLKGAIN was resulting in a name error. I removed it.

Results:

The plots are not processing without error. However, no titles or axis labels are present on the plots- I'll work on adding these.

I’m working on a code to determine the Gaussianity of a PSD.

Motivation:

It can be difficult to distinguish between GW events and non-Gaussian noise, especially in burst searches. By characterizing noise Gaussianity, we can better recognize noise patterns and distinguish between GW events and noise.

What I did:

I analyzed an hour of S5 L1 data. First, I plotted a timeseries, just to see what I was working with. Then, I produced a PSD (technically, an ASD) for the timeseries using Welch’s method in Python.

I split the data segment into smaller time-chunks and then produced a PSD for each chunk. All PSDs were superimposed in one plot. Here’s a plot for 201 time-chunks of equal length:

For a specific frequency, I can view the spread in PSD value through the production of a histogram.

Results:

I’ve made histograms displaying varying PSD values for the 201 PSD plot at 100 Hz, 500 Hz, and 1kHz.

For Gaussian noise, an exponential decay plot is expected. I will continue this analysis by following the statistical method in Ando et al. 2003 to calculate specific values indicative of the Gaussianity of various distributions. I’ll then look at different periods of time in the S5 L1 data to find periods of time suggesting non-Gaussian behavior.

I've continued to work on my Gaussianity tests for S5 L1 data. 

Following the statistical measure in Ando et al. (2003), I've calculated the Laguerre coefficient, c2, for all frequencies present in my S5 L1 PSD as a metric of Gaussianity. When c2 is zero, the distribution is Gaussian. A positive c2 corresponds to glitchy noise, while a negative c2 suggests stationary noise.

Below is a plot displaying variation in c2 for this PSD:

By observing the c2 value and histogram of distribution of various PSD values at a given frequency, we can elucidate statistical differences in the Gaussian nature of noise at that frequency which are unclear in the standard PSD.

I made several small, nit-picky changes to the summary pages.

Motivation:

I'm still working on getting used to editing the summary pages. I also wanted to change some of the easy-to-alter cosmetics of the pages.

What I did:

I changed axis ranges, axis labels, and typos throughout the summary pages. Read below for an excrutiating list of the minor details of my alterations, if you wish:

• Changed axes on LSC control signals plots on the Summary tab (but will probably change these back to their original state)
• Moved an OpLev plot from the Sandbox tab to "Eve" tab
• Increased the y axis range on IOO MC2 Trans QPD and IMC REFLY RFPD DC plots (which may change when I better incorporate triggers into these plots)
• Fixed title on IOO Whitened Spectrogram and Rayleigh Spectrogram
• Fixed degree sign on Weather: Temperature and PSL Table Temperature
• Fixed percent sign on Weather: Humidity
•  

Results:

So far, everything looks good. I'll continue to make more changes later this week and hope to soon get on to more substatial changes.

Motivation:

My SURF project largely focuses on updating and improving the 40m summary pages. I began to explore and experiment with the already existing summary page code to better understand the required code and eventually lead to tangible improvements of the summary pages.

What I did:

I practiced moving from one tab of the summary pages to another. Specifically, I copied the ETM Optical Levers plot from SUS: OpLev to Sandbox, without removing it from its original location. Additionally, I created my own tab to further test the summary pages, titled “Eve”.

KA ed: The configuration files are located at /cvs/cds/caltech/chans/GWsummaries. It is under svn control.

Result:

All changed appeared on the summary pages without much hassle and without any errors.

i tried to commit something this afternoon and got the following error message:

Command: Commit 
Adding: C:\Caltech\Documents\40m-svn\nodus\frank 
Error: Commit failed (details follow): 
Error: Server sent unexpected return value (405 Method Not Allowed) in response to  
Error: MKCOL request for '/svn/!svn/wrk/d2523f8e-eda2-d847-b8e5-59c020170cec/trunk/frank' 
Finished!:  

anyone had this before? what's wrong?

we had to reboot the IOO VME crate right before lunch as the DAQ wasn't working correct meaning showing no real signals anymore, only strange noise. The framebuilder and everything else was working fine at that time.

• The channel used for the phase noise measurement stopped showing any useful signal right after midnight, so all the other IOO-MC signals.
  
• The data taken with those channels showed something like a 140 counts or so of steady offset with something which looked like the last bit fluctuating.
  
• Whatever signal we connected to the input it didn't change at all, floating/shorted input, sine wave etc.
• the other channels for the MC which we checked showed the same strange behaviour
  

As the other channels showed the same effect we decided to reboot the crate and everything was fine afterwards.

i took some pictures with the dinocam this afternoon. I used the laptop computer next to it using wireless lan connection to the caltech network to send the pictures to me.

The installed anti virus software was bitching about the old database and wanted to update that. As the installed virus definition database was from mid last year i agreed and started downloading the update. As the file was huge (~100MB) it wasn't finished when i left. computer is still running and probably waiting for instructions.

Will come back on the weekend to finalize the new virus definition file database installation.

I restarted the elog because i changed the configuration for the cryo-elog.

Used the "start-elog.csh" script in /cvs/cds/caltech/elog/

I finally managed to get long stretches of PRMI lock, up to many minutes. The lock is not yest very stable, it seems to me that we are limited by some yaw oscillation that I could not trace down. The oscillation is very well visible on POP.

Presently, PRCL is controlled with REFL55_I, while MICH is controlled with AS55_Q. This configuration is maybe not optimal from the point of view of phase noise couplings, but at least it works quite well. I believe that the limit on the length of locks is given by the angular oscillation. I attach to this entry few plots showing some of the lock stretches. The alignment is not optimal, as visible from a quite large TEM01 mode at the dark port.

Here are the parameters I used:

MICH gain -10   PRCL gain -0.1

Normalization of both error signal on POP22_I with factor 0.004

Triggering on POP22: in at 100, out at 20 for both MICH and PRCL.

POP55 demodulation phase -9

MICH and PRCL control signal limits at 2000 counts

There is a high frequency (628 Hz) oscillation going on when locked (very annoying on the speakers...), but reducing the gain made the lock less stable. I could go down to MICH=-1.5 and PRCL=-0.02, still being able to acquire the lock. But the oscillation was still there. I suspect that it is not due to the loops, but maybe some resonance of the suspension or payload (violin mode?). There is still some room for fine tuning...

Lock is acquired without problems and maintained for minutes.

Have a nice week-end!