TITLE: 06/01 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: Jim
SHIFT SUMMARY: Locked at ENGAGE_REFL_POP_WFS most of the day with Kiwamu and Rana doing commissioning work,
LOG:
15:54 Ken to MY HVAC work
15:59 Kiwamu to EX resetting RMS UL WD
16:26 Kiwamu back
16:41 Rich and Fil to LVEA ESD work
17:19 Gerardo to MY and MX
17:24 Richard and Ken to MY
19:08 Gerardo done
19:37 Richard and Ken done
19:54 Fil to LVEA beer garden
20:27 Rich to LVEA
21:19 Rich out
Rana, Evan
WE measured the SRM to SRCL TF today to find the frequency and Q of the internal mode. Our hypothesis is that the thermal noise from the PEEK screws used to clamp the mirror into the mirror holder might be significant contribution to DARM.
The attached Bode plot shows the TF. The resonance frequency is ~3340 and the Q ~150. Our paper and pencil estimate is that this may be within an order of magnitude of DARM, depending upon the shape of the thermal noise spectrum. If its steeper than structural damping it could be very close.
"But isn't this ruled out by the DARM offset / noise test ?", you might be thinking. No! Since the SRCL->DARM coupling is a superposition of radiation pressure (1/f^2) and the 'HOM' flat coupling, there is a broad notch in the SRCL->DARM TF at ~80 Hz. So, we need to redo this test at ~50 Hz to see if the changing SRCL coupling shows up there.
Also recall that the SRCLFF is not doing the right thing for SRM displacement noise; it is designed to subtract SRC sensing noise. Stay tuned for an updated noise budget with SRM thermal noise added.
** see https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=27455 for pictures of the SRM compsoite mass.
The peak is also visible in the DARM spectrum. In this plot the peak is at 3335 instead of 3340 Hz. Why is there a 1.5% frequency shift?
Here are projected SRM thermal noise curves for structural and viscous damping.
Given a typical SRC coupling into DARM of 1×10−4 m/m at 40 Hz, 20 W of PSL power, and 13 pm of DARM offset (25019), this would imply a noise in DARM of 1×10−20 m/Hz1/2 at 40 Hz if the damping is structural.
When I modelled the optics in https://dcc.ligo.org/LIGO-T1500376 and in particular the surrogate SRM I had assumed optic was bonded. After looking again earlier with Rana and Betsy realised it is held with 2 set screws (Peek?) on barrell at 12 o'clock and two line contacts at 4 and 8 o'clcok. See https://dcc.ligo.org/LIGO-D1200886.
The previous bonded model for the SRM surrogate (I believe) had a fisrt mode predicted around 8k Hz. However, from a quick model I ran today (with the set screws etc ... ) the first mode appears to be around 3400 Hz. The mode is associated with the optic held with the peek screws. (Now I was doing model using remote desktop so I will need to check it again when I get a better connection, so more to follow on this. I will also post updated model, once I get back to Caltech.)
The ~3340Hz peak is also clearly visible in the PDA/PDB x-correlation spectrum. See alog 26345.
A couple of comments on this topic:
Danny, Matt (Peter F remotely)
Due to the issues currently seen at LHO, we were asked how the LLO SRM surrogate was put together and if we could add to the alog for a record of the process. The easiest way is to do it via photos (which we have of the assembly process).
IMG_1462....There are only two setscrews that hold the optic in place. Can be seen putting these in place below in the "cup" that holds the optic (eventually). Im not sure of the material but Peter F's speculation is that "I think those set screws must be the carbon-loaded PEEK type. The only other option I can think of for a black set screw would be carbon-steel, and it surely isn’t that."
IMG_1455...Here you seen the three main parts. The optic, the “cup” that the optic goes into and then the main mass the cup goes in. Note in the “cup” you see the two raised parts at around 4 and 8 o’clock that the setscrews ‘push’ the optic onto. So its not 'really' a three point contact, its 2 points (set screws) and 2 lines (in the holder)
IMG_1466...Here is the optic going into the cup making sure the fiducial on the optic lines up with the arrow on the cup
IMG_1470.....Optic now in the cup and doing up the setscrews that hold it in place. I cant remember how much we torqued it up (we only did it by hand). But as Peter F again speculated that perhaps we just did the setscrews up tighter than LHO
IMG_1475....Flipping the cup (with the optic in it) over and placing in main mass
IMG_1478....Cup now sitting in Main mass (without screws holding cup into main mass)
IMG_5172......the SRM surrogate installed into the suspension
It looks like there might be a mode in the L1 SRM at 2400 Hz. See the attached plot of SRCL error signal from January, along with DARM and the coherence. There is also a broad peak (hump) around 3500 Hz in SRCL, with very low coherence (0.04 or so) with DARM. The SRCL data has been scaled by 5e-5 here so that it lines up with DARM at 2400 Hz.
Here are two noise budgets showing the expected DARM noise assuming (1) structural (1/f1/2) SRM damping and (2) a hyperstructural (1/f3/4) SRM damping. This hyperstructural damping could explain the DARM noise around 30 to 40 Hz, but not the noise at 50 Hz and above.
I also attach an updated plot of the SRCL/DARM coupling during O1, showing the effect of the feedforward on both the control noise and on the cavity displacement noise (e.g., thermal noise). Above 20 Hz, the feeforward is not really making the displacement noise coupling any worse (compared to having the feedforward off).
Note that the PEEK thermal noise spectrum along with the SRCL/DARM coupling is able to explain quite well the appearance of the peak in DARM.
I am attaching noise budget data for the structural case in 27625.
CP4 exhaust flow meter is installed and reading out the following channels: Ch 6: H0:VAC-MY_CP3_FL201_DISCHARGE_FLOW_SLPM Ch 7: H0:VAC-MY_CP3_FL201_DISCHARGE_FLOW_MA
Note sure what data is supposed to live in the "MASTER_OUT" channels, but found today that IM1 has data and IM2-4 don't, and that seems like an issue, however, maybe they're this way for a reason, or maybe we there's an issue with the IM model(s)?
Plot attached.
The attached are 0.01Hz BW spectra of the BSC ISI's CPSs from this morning. This is looking for elevated noise floor. See logs 25713 & 25820 for an especially bad noise floor on the CPS noting the Stage 1 and Stage2 sensors have different scales and therefore noise floors.
While these are not as bad as the ETMY in the above linked logs from back in Feb/March; some are higher than their fellow sensors and maybe should be watched closely. They may need to have their cards cleaned up. The units of note are:
ETMX Stage1 V1; ITMX Stage2 H3; ITMY Stage2 V3.
ITMY also has another notable feature: A broad hump at 59Hz on Stage2 Corner2 H2 and V2 sensors.
There are other features evident, mainly narrow lines of varying heights and frequencies. First things first.
Template is found in /ligo/svncommon/SeiSVN/seismic/BSC-ISI/H1/Common/BSC_ISI_CPS_Sensor_Spectra.xml
The 59Hz hump on the ITMY Stage2 Corner2 sensors was at 90hz a week ago and steadily marched down to 59. It probably isn't doing too much harm at the moment but if it doesn't stop coming down... It might be interesting to see how far it goes but I think this needs action. A power cycle of the satellite rack is a good start. This will happen in a couple days anyway...
8:30 am local 1/2 turn open on LLCV bypass valve - took 54 sec. to overfill CP3. Ken and I changed the LLCV actuator right before hand and may have contributed to overfilling when decoupling to needle valve.
Ken, Chandra Removed pneumatic actuator from LLCV on CP3 and replaced with electronic version. Changed fuse to 2.5 A. Set to 19%. Need to remove shims.
The attached spectra suggests that the H3 performance is pretty indistinguishable from the other sensors and looks much better than the H3 sensor looked in March after some card swapping. We ended up with the same board in place ultimately and have done nothing since. I recommend we close 4424 and monitor.
Below are the past 10 day trends for thye PSL and it's environment. Unfortuntely it remains riddled with higher than normal incursions and the ongoing chiller woes.
This task has officially been added to FAMIS. Task Number was 6098.
I just reloaded all the coefficients in the TCS SIM model. None of the coefficients has been set for 4 days. It's likely the existing coefficients are being backed up but not in the SAFE.SNAP file.
I also just restored the CO2 QPD coefficients and the SIM_ITMX_SUB_DEFOCUS_CO2_GAIN to 3.57E-5
I forgot to post these yesterday. Perhaps we should move this task to Wednesday on the OPS checklist so as not to get lost in maintenance day activities. See attached screenshot for values before reset.
Good point. The Ops Check Sheet has been updated to move the HEPI WD Counter check to Wednesday. Thanks, Travis!
With the AC off in the PSL, and the laser restored, we are back to locking. Tonight we started to implement the high bandwidth hard loops that we made filters for over the weekend. The idea here to to make some ASC loops that will be high bandwidth and introduce noise into darm, but be relatively simple to keep stable as we power up. Then we can worry about a low noise loop only at our final power. The loop designs using Jenne's model are attached, they are the same filt ers for CHARD and DHARD so only CHARD is attached. Since the top mass damping was made more uniform today, 27464
the damping is probably not acurate in the model anymore. We were able to turn the CHARD yaw loop up to 10 Hz, (gain of -250) and turn the pit loop up to about 5 Hz, but there is something that is unstable when they are both high bandwidth. We checked that the gain of the MICH loop is not changing as we increase the gain in CHARD.
Driving an admixture of hard/soft is bad, as illustrated in these Bode plots. The left plot shows the PUM to UM TF in the optic basis, and the right one is in the hard/soft basis.
With different damping in the TOP stage, the actuation TF is different for each suspension and so we end up with some of these zeros that we see in the left plot. Matching the actuators should make the loop shapes more like the ones on the right, avoiding some of the multiple UGFs we see in measurements.
But what's a good way to make sure that we have pure hard/soft actuators? We don't have pure sensors.
Unfortunately the current RMS watchdog on the L2 stage of ETMX tripped at around 3:00 AM local this morning. This seems to have shut the drive signal of all four colis and therefore the ETMX mode was not damping at a good rate.
By the way, we were unable to untrip the watchdog from the control room using the SUS-ETMX_BIO_L2_RMSRESET channel. This seems to be a known issue (alog 20282). I drove to EX and power-cycled the PUM coil driver.
Travis opened an FRS for this issue of being unable to reset the watchdog of the current rms on the ETMX PUM (aka L2) driver.
Evan, Rana, Sheila
This afternoon there was a problem with the ITMX M0 BIO. The TEST/COIL enable indicator was red, and setting H1:SUS-ITMX_BIO_M0_CTENABLE to 0 and back to 1 could not make it green. Evan tried power cycling the coil driver, which did not work. We were able to reset this and damp the suspension again by setting the BIO state to 1, it seems that anything other than state 2 works.
This might be a hardware problem that needs to be fixed, but for now we can use the suspension like this.
Opened FRS Ticket 5616.
After the weekend power outage, we see that the ITMX M0 BIO settings are back to their nominal combo of:
STATE REQUEST 2.000
COIL TEST ENABLE 1.000
- And the BIT statuses all show green.
Toggling them to alternate 1.000 and 2.000 values respectively and back to niminal turns them from red back to green. Nothing seems to be stuck now and the ill combo that Sheila reported the other day above doesn't seem to be a problem now.
Evan and I spent most of the day trying to investigate the sudden locklosses we've had over the last 3 days.
1) We can stay locked for ~20 minutes with ALS and DRMI if we don't turn on the REFL WFS loops. If we turn these loops on we loose lock within a minute or so. Even with these loops off we are still not stable though, and saw last night that we can't make it through the lock acquisition sequence.
2)In almost every lockloss, you can see a glitch in SR3 M2 UR and LL noisemons just before the lockloss, which lines up well in time with glitches in POP18. Since the UR noisemon has a lot of 60 Hz noise, the glitches can only be seen there in the OUT16 channel, but the UR glitches are much larger. (We do not actuate on this stage at all). However, there are two reasons to be skeptical that this is the real problem:
It could be that the RF problem that started in the last few days somehow makes us more senstive to loosing lock because of tiny SR3 glitches, or that the noisemons are just showing some spurious signal which is related to the lockloss/ RF problems. Some lockloss plots are attached.
It seems like the thing to do would be trying to fix the RF problem, but we don't have many ideas for what to do.
We also tried running the Hang's automatic lockloss tool, but it is a little difficult to interpret the results from this. There are some AS 45 WFS channels that show up in the third plot that apprears, which could be related to either a glitchy SR3 or an RF problem.
One more thing: Nnds1 chrashed today and Dave helped us restart it over the phone.
For the three locklosses that Sheila plotted, there actually is something visible on the M3 OSEM in length. It looks like about two seconds of noise from 15 to 25 Hz; see first plot. There's also a huge ongoing burst of noise in the M2 UR NOISEMON that starts when POP18 starts to drop. The second through fourth attachments are these three channels plotted together, with causal whitening applied to the noisemon and osem. Maybe the OSEM is just witnessing the same electrical problem as is affecting the noisemon, because it does seem a bit high in frequency to be real. But I'm not sure. It seems like whatever these two channels are seeing has to be related to the lockloss even if it's not the cause. It's possible that the other M2 coils are glitching as well. None of the other noisemons look as healthy as UR, so they might not be as sensitive to what's going on.
RF "problem" is probably not a real RF problem.
Bad RFAM excess was only observed in out-of-loop RFAM sensor but not in the RFAM stabilization control signal. In the attached, top is out-of-loop, middle is the control signal, and the bottom is the error signal.
Anyway, whatever this low frequency excess is, it should come in after the RF splitter for in- and out-of-loop board. Since this is observed both in 9 and 45MHz RFAM chassis, it should be in the difference in how in- and out-of-loop boards are configured. See D0900761. I cannot pinpoint what that is but my guess is that this is some DC stuff coming into the out-of-loop board (e.g. auto bias adjustment feedback which only exists in out-of-loop).
Note that even if it's a real RFAM, 1ppm RIN at 0.5Hz is nothing assuming that the calibration of that channel is correct.
Correction: The glitches are visible on both the M2 and M3 OSEMs in length, also weakly in pitch on M3. The central frequency looks to be 20 Hz. The height of the peaks in length looks suspiciously similar between M2 and M3.
Just to be complete, I've made a PDF with several plots. Every time the noise in the noisemons comes on, POP18 drops and it looks like lock is lost. There are some times when the lock comes back with the noise still there, and the buildup of POP18 is depressed. When the noise ends, the buildup goes back up to its normal value. The burst of noise in the OSEMs seems to happen each time the noise in the noisemons pops up. The noise is in a few of the noisemons, on M2 and M3.