J. Kissel, for B. Lantz and J. Harms There's been some interesting discussions on the DetChar mailing list about seasonal variation of ground motion around the world's network of gravitational wave observatories. Two things (of many) that have come out of it that might be of particular interest to LHO: - Jan Harm's data set from 2009/2010 T1500224, showing what I'm calling "meta" ASDs showing the percentile ASDs for each month over a year. - Brian Lantz has used that data, shown it in a slightly different way which can be found in SEI aLOG 766. More data is to come. Why do we care? It's merely to call attention to the fact that for the active isolation feed-back, (a) We shouldn't expect a "one (blend filter / sensor correction) filter fixes all" solution for both LHO and LLO. (b) Seasonal variations of the secondary microseismic may explain why we've needed to work harder at the microseism this past winter (i.e. use the 45 [mHz] DeRosa, LLO blend) and now we're doing just fine with a 90 [mHz] blend everywhere.
Dan, Keita, Stefan - Updated the OMC model with correct math and enough monitor points to be useful. - We tried commissioning the model sitting off fringe at 23W, but confused ourself a bit. Everything started to make sense when Keita pointed out that we have a fringe offset when sitting at zero digital offset, which manifests itself as different OMC trans DC power levels on the left and right side of the fringe. - With the nominal 1e-5 DARM ERR counts offset (about 14pm), we observed 18mAmp, while -1e-5 gives 15mAmp. Thus we have about 0.6pm fringe offset when the RF length signal is zeroed. - With that we laid out the strategy for setting up the parameters: 0) Set H1:OMC-READOUT_SIMPLE_GAIN to 0 (Turns off simple path.) 1) Estimate the minimum power at zero DARM offset to get a number for the contrast defect. It turns out this is close to 0, so 0 will do. 2) Pick the transition point. In our case 14pm. Thus set both XF (fringe length) and X0 (fringe offset) to 0. 3) Adjust H1:OMC-READOUT_PREF_OFFSET until H1:OMC-READOUT_STEP2 is equal to one on average. (H1:OMC-READOUT_STEP2 is the power normalized by the power at the transition point.) 4) Set H1:OMC-READOUT_X0OFFSET_GAIN to 1 now the .H1:OMC-READOUT_ERR_INMON signal is zero on average. 5) Use H1:OMC-READOUT_ERR_GAIN to match the gains in the RF sensor (H1:LSC-DARM_IN1) and the OMC path (H1:OMC-READOUT_ERR_OUT). 6) Set H1:LSC-OMC_DC_OFFSET to minus the H1:LSC-DARM_OFFSET. Now the offsets are matched. 7) Transition the input matrix. 8) Ramp H1:LSC-OMC_DC_OFFSET and H1:LSC-DARM_OFFSET to 0 (at the same time) - We had high winds for about two hours. But after that successfully tested the script that follows this logic.
Over the lock period last night, the CPS ASD appears to experience changes as time passes.
Just to focus on the BS, the ST2 Vertical between 1 and 5 hz see the largest variation. See the two attached images, the lower right panel is the ST2 Vertical. The lighter thicker colors are references before the CPS timing change on Tuesday. The finer darker traces are current running. I've look at the ITMY & ITMX too over the few hours of the lock loast night, and at some time or another, all the traces are at or below the reference, suggesting the CPS are okay.
Scott L. Ed P. Chris S. Cris M.(1/2 day) 5/14/15 Finished crevice cleaning and removed lights. Test results posted here. Hang lights in next section north, vacuum support tubes and spray bleach/water solution. Cleaned 49 meters ending 8.4 meters north of HNW-4-048. 5/15/15 Cleaned 73 meters today ending at HNW-4-052. Test results posted here. Tube pressures are continually monitored by control room operator during cleaning operations. Total tube cleaned to date is 3024 meters.
Just posting data that Fabrice had requested for a talk. The setup: I wanted to measure the performance of sensor correction on ETMX. I turned off the feed forward (which I've seen add some noise at .5hz, not much, but I've been meaning to investigate) and got .001 bw measurments with the sensor correction on and off. The ISI was fully isolated, with 45mhz blends in Y and 90mhz blends in X. On the first 3 spectra (X,Y &Z) black (ground),orange(st1 t240's) and red(st2 gs13's) are sensor correction on, brown (ground), blue (st1 t240's) and grey (st2 gs13's) are sensor correction off. In X&Y, we are using Ryan's .5hz notch sensor correction on the ISI and in Z we are using RichM's broadband low frequency sensor correction on hepi (fourth & fifth plots).
Daniel, Jim, Dave [WP5207]
As a dress rehersal for next weeks upgrade of all the IO Chassis, this afternoon we upgraded the FPGA firmware in the timing slave unit of h1pemmx.
We also used this to verify our set of procedures:
https://awiki.ligo-wa.caltech.edu/aLIGO/ProcedureToProgramIOChassisTimingSlave
Prior to h1pemmx, we had upgraded three IO Chassis on the DTS. We wanted to do one H1 chassis to see what the Beckhoff timing system reported as a version number (not available on DTS).
All went well with no problems. The reported Rev number went from 0 to 100, which is expected. The current Beckhoff code does not recognize 100 as a valid number, hence the "Firmware error", this will be fixed next Tuesday.
We timed the procedure, it takes about 15 minutes per chassis.
The Beckhoff MEDM for h1pemmx slave is shown below
Brute Force coherence report is available here for last night lock:
https://ldas-jobs.ligo.caltech.edu/~gabriele.vajente/bruco_1115716006/
Some highlights, which I find very interesting:
Not much is happening at higher frequency, at least for broad band coherence. However there are a lot of single frequency bins with significant coherence, and I can't list all of them here (I'm too lazy). So look into the table at your favorite line frequency, you might be rewarded with some coherence.
After the time that Gabriele looked at, the coherence of CARM with DARM went up to nearly 1 above 500 Hz (and 0.5 at 100 Hz). This seemed to continue for the rest of the lock. All of the loudest glitches, which had peak frequencies at about 200 Hz, showed up in CARM as well as DARM. What is going on? The first plot is a reproduction of Gabriele's coherence plot. The second is about a half hour later, and the third near the end of the lock. The last is a coherence spectrogram of CARM with DARM during this very loud glitch near the end of the lock, which showed up as strong in CARM as DARM.
LSC-CARM is not used anymore for any feedback to the IFO; we use it sometimes to make an audio channel out of DARM so that we can listen to the IFO. Stefan was tuning the audio filters after we hit the intent bit last night.
The actual feedback to MC2 from the CARM slow loop goes through the LSC-MCL filter bank. If you want an out of loop CARM sensor you can look at LSC-REFL_A_9I, for the error and control signals you can look at the common mode board channels, eg LSC-REFL_SERVO_ERR_DQ or CTRL_DQ
By the way, instead of stealing the CARM filter bank to process audio, you can apply the filter directly in the audio player:
$ cdsutils audio H1:CHANNEL-NAME -f 'filterspec'
where 'filterspec' is a filter design string, as you would type into Foton. (This was requested in CDS bug 797 and added in cdsutils r444.)
It seems unneccesarily confusing to use a named channel with a very clear symantic meaning for something other than it's intended purpose. Can we not just make some separate filter banks just for filtering audio output? Either that or use the built-in cdsutils audio filtering that Chris mentioned.
For historical reasons, the isolation loops that are installed on the BSC's were all quite different. I've been working on a consistent set of controllers for the ISI's and I've installed them on ETMX, ETMY and ITMX. I need to look in more detail at the BS, but ITMY needs to be redone, the filters in foton don't look anything like the ones Matlab says are installed, they look like Vincent's filters from several years ago. The ones I've done for ITMX are the cleanest plots, so I'm posting the comparison plots, Old_ITMX_controllers and New_ITMX_controllers pdfs. The goal was to get the unboosted isolation loops as similar as possible, use the same boosts every where and hopefully get all o the chambers to similar performance. Generally this resulted in loops with 30-45 hz UGF, 17-20 degrees of phase margin and gain peaking of 4-5. I was aiming for as close to a gain of 10 at 10hz as I could get and gains of 1000 at 1 hz.
I spent a bit of time this morning clearing out remaining SDF diffs in SUS, LSC, and ASC. This involved the usual alog hunt followed by some clarifications from commissioners. Things still showing diffs at the moment and why:
- We need to capture a new snap file for the OMC due to yesterday's model change which will clear out it's large SDF diff list.
- The ASCIMC still has one diff due to a 10e-17 size change in one value. I think this feature is due for an upgrade at some point, so until then, this 1 diff will be lingering.
- Same with ISCEX - there are 2 diffs with very small diffs which won't go away with the accept button. Will linger until update.
- We need some assistance with clearing the PSL diffs from team PSL.
- I've not paid much attention to the bottom monitors, namely ODC and CAL.
Comment posted to the wrong aLOG. Deleted!
With a lock stretch of over 7.5 hrs at ~23.2W & a range of ~57Mpc, here is a picture of last night's lock stretch. Just before 9am, H1 lost lock (no obvious reason, as we continued operating in an Undisturbed state), the Intent Bit was taken to Commissioning, and Ellie started SRCL work.
Here are the trends for the various DC, 18MHz and 90MHz powers. Some small variations are visible in the first hour, which are probably due to thermal loading.
Attached is a plot of the default lockloss file Travis and I ran for this lock. (time entered was 8:53:00am PST).
Sheila, Evan, Stefan - Reduced the whitening gain on both AS 36 ASC diodes. The new value is 24dB. We increase the input matrix values from 1 to 2 to compensate (for MICH and SRC1, i.e. the SRM loop). - We tried to phase the AS_A_36 quadrants by wiggling SRM in yaw and pitch, maximizing the I signal. Not sure how meaningful that was though, because the actual signal we ended up using was Q. - We switched the the sensor for SRC1_YAW (SRM) to 0.3*AS_A_36_Q + 0.3*AS_B_36I. This signal clearly reacted to our mysterious SRC cavity drifts, and had zero offset at the good locking point. - We increased the power to 23W. This is the maximum power currently available. With this new SRM yaw sensor the 23W was very stable. - The DARM offset was 14pm (or 1e-5 cts). - This gave us a recycling gain of 38. - Measured the open loop gain and verified the calibration. - This configuration was stable for 1h. - We took SRCL noise injections at: 8:46:15UTC and 8:59:40UTC (SRCL cut-off filter off and on) - We took MICH noise injections at: 8:52:15UTC and 8:55:40UTC (SRCL cut-off filter on and off) - Pushed the intent bit at 9:06:30 UTC. - The inspiral range seems quite remarkably flat at 57 Mpc. A stron indication that we are now purley electronics noise limited at low frequencies. To do tomorrow: - Explore DARM offset: the new OMC code is ready to install, and will allow on-the-fly OMC offset tuning. - Add the new ASC INMATRIX to Guardian. - Add the new DARM offset to Guardian. - Generate noise budget.
Attached is a new spectrum, before and after screenshots of the AS A 36 WFS phases, and 3 OLG measurements made at 3 different input powers.
Great progress, congratulations!!
I will take a closer look at the noise budget over the weekend, but it seems (roughly) that above 20 Hz we are currently limited by DAC→ESD noise and quantum noise. As usual, there is some uncertainty in coupling strength of the ESD to DARM, which may explain the discrepancy in the plot from 20 Hz to 100 Hz.
This is fantastic -- perfect timing for the low noise Electro-Static Driver installation next week!
Excellent news! Well done.
Looks like discharging and lower noise driver will do some good. Nice going.
Truly great progress. Nice work, LHO commissioning team!
Beautiful! Nice and stable as well! I was not able to change my slides for the invited LIGO talk at APS Northwest Section Meeting, but I did announce your success. Great timing too.
Well done all at LHO. That's great progress.
Here's the MEDM screen Stefan built for the new handoff code.
The OMC guardian and the ISC_lOCK guardian have been updated to follow the above script. After the transition to DC readout, the DARM offset is offloaded to the "fringe offset" in the OMC-READOUT path.
We were able to transition to DC readout at 2.2W, 3e-5 DARM offset, and increase the power to 22W while decreasing the DARM offset to 1e-5. This was done with only a casual regard for ramp times; the process was very robust. We have coded a step in INCREASE_POWER that changes the fringe offset to maintain 20mA in DCPD sum. Eventually, we will juggle the states in the ISC_LOCK guardian so we transition to DC before the power up, and then smoothly adjust the fringe offset during the power up sequence. We tested this once and it works well, but we didn't have the energy to perform a shuffling of guardian states. For now, we have left the guardian as usual, but the handoff from the OMC to DARM is performed using the new normalization path. It worked once, before we left.
We never reached low noise tonight, we lost lock a few times in the coil driver switching step. At least one of these locklosses was due to what appeared to be a guardian error, in which the ISC_LOCK guardian skipped the COIL_DRIVERS state, went to the ETMY ESD handoff, and then ran the ETMY ESD handoff *again* before losing the lock. See the second screenshot attached.
Here's my interpretation of what happend with the ISC_LOCK guardian (see comments in the screen shot below):
This is all kosher (i.e. no bug) assuming there was indeed a second request for LOWNOISE_ESD_ETMY at 7:20. If there wasn't, and the second request truly came out of nowhere, then that's weird. Where could it have come from?
If the second request was legitimate, i.e. it came from the operator, it might have been accidental, or the operator was maybe un-aware of the intended behavior (not unlikely given that behavior is probably not widely known). However, it might also indicate that the behavior is non-intuitive and/or problematic and should maybe be re-examined.
The same-state redirect behavior was added early in commissioning the SUS guardians. (It was actually added in response to some of the problems we've had handling the DC alignment biases, which is actually slated to change (ECR 746).) I'm not sure how widely this behavior is know or taken advantage of. It's not actually being used in the SUS guardians anymore. Given the current crappy MEDM UI, it's also quite easy to accidentally re-request the same state.
My intention was that all REQUESTable states be idempotent, e.g. it would never hurt anything to simply re-run them again. If we were to make sure that all requestable states really were idempotent, then the behavior is probably fine as is. This is actually quite easy to accomplish in this case by simply making the relevant non-idempotent action state
request=False
, and adding a new requestable idle state right after it.If this is too cumbersome, the we need to do some or all of the following:
I'm open to suggestions. Keeping the current behavior as is and being good about making all requestable idempotent gives us the most flexibility. It gets rid of the problem while retaining the option to use the functionality for the cases where it could be useful. It also requires more care when constructing the state graphs, though, and forces there to be more states (the later not necessarily being so bad imho).