Will make log entry when leaving. Also, BSC8 annulus ion pump railed again, same as back in May. See also, https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=27325 and https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=27385 Will likely replace pump during Tuesday Maintenance period
[Jenne, Carl, Terra]
To facilitate the damping of the 18kHz ETMX mode, we are currently locked at 50W using ETMY so that ETMX can be swapped to its low noise driver. SRM dither loop is open.
To do this, it's okay to (once IncreasePower is finished) go to Manual mode and select LowNoise_ESD_ETMY. Last week we lost lock trying to do this because this state also (used to) switch the L2 coil drivers to their low noise state, which we aren't ready for. So, the noise is acceptable for the lownoise ESDs, but not the low noise L2 drivers. On the to-do list is to decide where in the sequence to put the L2 switching.
PI and other work is ongoing.
For the L2 coil drivers, if I understand correctly you are set up to transition to the lowest noise (and lowest range) state, state 3. As an alternative you might transition to state 1, where the ACQ mode is switched OFF, but the low-pass remains OFF. I believe the low-pass is a 1 Hz pole, 10 Hz zero, so this would afford more range above 10 Hz than state 3, and still puts the L2 noise low enough that it's not a significant limit, at least for our O2 goal. See Chris W's entry 28264.
Ah, yes. I think you had mentioned this, but I forgot. I'll give that a try.
Kiwamu, Carl, Terra
18041 Hz (ETMY) successfully damped through several locks. 15542 Hz (ETMX) unstable after about 1 hour at 50 W but we cannot damp without going to LOWNOISE_ESD_ETMY.
We had a few ~1 hour locks at 50 W today, with a bit of time at 60 W.
18041: damped first with +30 phase, +30K gain but rang up in the second lock despite. Changing to zero phase damped it in the second lock and prevented any ring up during the third lock.
15542: rings up almost immediately at 60 W. Rings up after an hourish at 50 W. This mode belongs to ETMX but we've been sitting at INCREASE_POWER during locks so we cannot use the LNLV ETMX driver to damp.
Because ETMX PI couldn't be damped, I tested my ITM DARM charge measurement script, which broke lock. I know the cause and will be able to fix it for another attempt tomorrow.
The SUS_PI guardian is running again. It had got stuck with spm differences after the model restarts.
During these lock stretches settings for damping several modes were found and put in the gaurdian.
15522Hz ITMX (mode2) was ringing up at the end of the last lock aand was damped with gain -300 and phase -60 deg.
15541Hz ETMY (mode25) was stable but the driven up to find a damping gain 1000 and phase +60deg and the
18041Hz ETMY phase has been adjusted to 0 deg (gain stays 1000)
This is a quick note on the SRM dither loop.
The SRM dither loop does not seem to give us the optimum SRC alignment when the PSL power is above 50 W in this evening. I don't remember seeing this problem two days ago (28577). Today at one point, we had a lockloss at 50 W when slowly introducing an offset in the PRM pointing from 0 to 0.5 QPD count over 5 min. During this engagement process, AS90 kept decreasing while the carrier recycling gain kept increasing. In the next lock stretch, we opened up the SRM dither loop and started manually aligning SRM. At the optiumum point where the signal recycling gain (i.e., AS90 / POP90) was maximized, the dither-based error signals had a non-negligible offset in both pitch and yaw (on the order of 0.005 at the input of the control filters for both).
Kiwamu called, told me the laser was off.
In what is becoming an all too often occurrence, the laser tripped again around 9 pm last night.
The Beckhoff status screen is attached. I checked the chillers: crystal chiller was off, diode
chiller was still running.
Reset the laser, tried starting it. It failed.
Previously the suspect was perhaps one of the flow sensors in the power meter cooling circuit.
I decided to change one of the crystal chiller tripping points. I changed the exception time from
000 seconds to 001 seconds. Thinking that if a fast transient caused the exception then perhaps a
1 second delay might "filter" it out. If there was a real problem with the flow rate then 1 second
might not make much difference before things shut down. I need to check the chiller manual.
Tried restarting the laser again but it failed. I rebooted the Beckhoff PC and was then able
to start the laser. No sooner as I had left the diode room, I noticed that the crystal chiller
was complaining about a "flow sensor problem". I re-entered the diode room to check the laser status -
it was still on. So it appears that the change in exception time did the trick (for now).
My conclusion from this is that the vortex flow sensor in the crystal chiller is the prime suspect
at this stage and not a flow sensor in one of the laser's cooling circuits, since there is no external
signal feed back to the crystal chiller. If it were an external sensor, the interlock box would have
kicked in.
Title: 07/22/2016, Day Shift 23:00 – 07:00 (16:00 – 00:00) All times in UTC (PT) State of H1: IFO locked at INCREASE_POWER, 19.9W. Wind is a Moderate Breeze to Near Gale (18 - 38mph), and gusty. Seismic is elevated, as expected, at the End Stations. Microseism is low but has been rising for the past hour. Locking during the day shift has not been difficult. Commissioning: Commissioners are commissioning. Outgoing Operator: Travis Activity Log: All Times in UTC (PT) 23:00 (16:00) Take over from Travis Title: 07/22/2016, Day Shift 23:00 – 07:00 (16:00 – 00:00) All times in UTC (PT) Support: Jenne, Incoming Operator: N/A Shift Detail Summary: IFO is locked at DC_READOUT. No commissioners on site. No planned commissioning work tonight. I have locked the doors and turned off the light.
[Terra, Kiwamu, Carl]
We have demonstrated damping PI with the new architecture. the 15.009kHz ETMY mode (MODE26) was driven up with noise several times before getting teh settings correct for damping.
Since we're "stuck" at ~20W while Team PI finishes re-commissioining the new system, I asked JeffB to take us to NomLowNoise @20W so that we could make sure we can set the Intent Bit when we're ready to actually do so.
Unfortunately, the ISS second loop error signal wandered away and the 2nd loop unlocked. The IFO was still locked for almost 1 second, but the HARD ASC loops were very unhappy and caused some saturations that I believe caused the lockloss. I'm not sure why the 2nd loop ran away though.
Overfilled CP3 with the exhaust bypass valve fully open and the LLCV open to 100% via the MEDM screen (different method).
Flow was noted after 64 seconds, then the LLCV was returned to 24% open, and 3 minutes later the exhaust bypass valve was closed.
Note: This morning I drove to Y-Mid to monitor the behavior of CP3, to make sure that we were not dumping LN2 on the ground, after the drastic change on LLCV setting (before was 17 now it is set at 24% open), I spent 25 minutes there and only observed 1 "burp" of 1 second of LN2 gas visible as a steam cloud, no liquid was noted coming out of the exhaust line, so it appears that the system is good at 24% open.
Since we can't go all the way up in power right now (Team PI is working furiously so that we can soon), I took some time to see if I could move the SOFT offsets after the PRM had been moved to wring a bit more power recycling gain out of the interferometer.
The short answer is that yes, it seems like (at least at 20W) we can get a few % more recycling gain by re-optimizing the SOFT offsets after we've found the right spot for the PRM.
The longer answer is that it's tricky. Maybe this will go away once we go up in power, but right now I'm seeing a pretty high peak at the 28Hz that Sheila pointed out the other day, that is probably the PR3 bounce mode. It increases as I improve the recycling gain by moving combinations of PRM and Soft offsets. Eventually, suspensions start saturating and I see large harmonic peaks in the DARM spectrum - clearly this is no good. Since we weren't seeing this peak once we're stable at 40W, I'm hopeful that it won't be a problem, and we can get the extra few % of PRC gain. But, we probably won't know until we give it a try.
Note to self: minus for DsoftP, plus for CsoftP was the good direction (this moves Xarm only).
I don't know that it's super helpful, but attached is my StripTool showing the inputs of the Soft and PRC1 loops (so minus the respective offsets), and the resulting power recycling gain.
Also attached is a plot showing that the 28Hz mode is in all of the ASC loops, so however it's getting in, it's getting passed around like a bad cold.
Whilst observing the IMC trying to lock this morning and its moving the laser frequency around,
it appeared that in the lock acquisition phase as soon as light was resonating in the IMC cavity
the boost gain was engaged.
I asked TJ to insert a 2 second delay prior to engaging the IMC servo boost gain so that things
had a chance to settle down. Behaviourally things seemed better with the delay in.
TJ/Jason/Peter
TITLE: 07/22 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Jeff
SHIFT SUMMARY: After performing initial alignment this morning, the IFO has been locking well all day. We had a brief wrestling match with the FSS again, but since then, no issues.
LOG:
16:30 FSS oscillations, Peter and Jason looking at it
16:52 Richard to both ends electronics room
17:45 Richard back
22:07 Gerardo to CP3
I am working on the Noisebudget Model these days and made a summary of the WFS in use with calibrations:
| WFS |
Serial No. |
RF Trans. [Ω = V/A] |
Responsivity [A/W] |
Demod. Gain [dB] |
Whit. Gain [dB] (40W) |
ADC [cts/V] |
Digital Gain |
Cal [cts/W] |
|||||
|
Freq. |
Q1 |
Q2 |
Q3 |
Q4 |
AVE |
||||||||
|
REFL_A |
S1301242 |
9 MHz |
894 |
894 |
1069 |
974 |
958 |
0.85 |
21 |
21 |
1638 |
1 |
1.7E8 |
|
45 MHz |
642 |
662 |
657 |
634 |
649 |
21 |
1 |
1.14E8 |
|||||
|
REFL_B |
S1301243 |
9 MHz |
822 |
873 |
742 |
861 |
824.5 |
0.85 |
21 |
21 |
1638 |
1 |
1.44E8 |
|
45 MHz |
678 |
644 |
635 |
648 |
651 |
21 |
1 |
1.14E8 |
|||||
|
AS_A |
S1300635 |
36 MHz |
810 |
828 |
872 |
891 |
850 |
0.85 |
21 |
12 |
1638 |
1 |
5.3E7 |
|
45 MHz |
707 |
718 |
732 |
766 |
731 |
3 |
1 |
1.6E7 |
|||||
|
AS_B |
S1300634 |
36 MHz |
846 |
904 |
826 |
832 |
852 |
0.85 |
21 |
15 |
1638 |
1 |
7.5E7 |
|
45 MHz |
644 |
711 |
719 |
691 |
691 |
3 |
1 |
1.5E7 |
|||||
Calibration (from W to cts) = RF Trans. * ADC * Responsivity * Digital Gain * 10^(Demod. Gain + Whit. Gain)/20
Just a note for ASC WFS REFL_A: S1301242 was swapped out in 2022 for S1301248. See alog #63544.
Attached is a plot of the pre-modecleaner heater signals similar to that posted at LLO: PMC glitches. No glitches observed here. Jason/Peter
Just a theory here...But I believe the H2 coil driver needs attention.
H2 Drives off as RZ and X Loops, H2 only directly affects RZ and X. If it were the loops, of Actuator Drives would respond. Page 11 of attached show the CD I & V INMONs going wacky impacting the RZ and X(page 4) loops 1 or more seconds before the model responds.
I know this is long winded, you should see the stuff in the text file not preinted here as I went down other rabbit holes.
ITMX ISI Tripped Wednesday July 13 AM from M6.3 EQ in New Zealand. No other platforms tripped. The extra sensitivity of the ITMX to EQs is not new. Based on the ground Seismometer STS2-B, it looks like the trip occurred with the arrival of the S-Wave (Shear, not surface.) See page 1 of attachment. Based on the EPICS records, ST2 tripped first; based on the FIRSTTRIG_LATCH value, the Actuators hit their rail first.
Page 2: 80 seconds with the Actuator drives. The upper right graphs have the horizontals and verticals on the same plot. Given that there is no RX or RY loop closed, it makes sense that the three vertical drives are exactly the same. Leading up to the trip, the H1 and H3 drives appear to be getting a greater request from the loops compared to the corner2 horizontal. The H2 GS13 is parallel to the X arm and so contributes nothing to the Y DOF. The verticals are well behaved. However, a couple of seconds before the EPICS INMON registers the state change (1 to 2,) the H2 drive shoots almost straight to the rail. This delay makes sense with the 8192 saturations required before tripping on this 4k model. The upper left plot zooms out on the H2 drive as it ramps its way up to e7 before the watchdog trip takes it to zero. The H1 and H3 drives continue along until the trip when they start to ring. After the trip the three horizontals behave similarly. You might believe there is a kink in these other drives a few seconds earlier,...ehhh.
So the behavior of Drive2 may be of interest. Is this a coil driver problem or does it originate from up stream?
Upstream is the damping, isolation, and feedforward paths. There is no indication that the vertical loop is a problem and feedforward only goes to Z; and, there are no DQ channels for the damping loops—they will have to wait for further upstream examination. This leaves the isolation loops.
Page 3 shows 80 seconds of the Isolation loop inputs. The ITMX and ITMY IN1s are overlain on the same plots. Also shown are the horizontal ground motions; the vertical is uninteresting. The ground motion signals overlain on the isolation plots are scaled and shifted so as to be seen. This shows that both ITMX and ITMY X & Y DOFs are doing about the same and are fairly well correlated with the input ground motion hence the control loops are pretty much the same. I've also verified this looking at the Matlab Controller figures. Around xx8505 gps, the Y ground motion quickly increases, this may be the arrival of the s-wave. The Y loop responds but within several seconds, the response doesn't seem as reasonable and looks to be ringing up and getting behind the curve. The X gets hit with this some 30 seconds later. I don't know if the mostly flatish nature of the RZ loops is or is not remarkable. As well, is the scale of noise/buzz difference between ITMX and Y worth noting? Conversely, the Z DOFs seem to be responding to the same input but certainly drive harder on the ITMX.
So the H2 Drive goes wacky before the others. The X and RZ loops feed the H2 Drive and both those ISOs head off to the outer reaches. The Y loop sees a blip and then gets buzzy/noisy; the Z sees nothing. The H2 Drive is pushing the platform and the X and RZ motion is seen back at the ISO_IN1. It makes sense that the Y DOF would also see something if the H2 actuator is the only one pushing. The push on H2 Drive could produce canceling affects on the H1 and H3 sensors and not push that DOF iso off the page. If the RZ loop was driving it, the response would be the same on all Horz GS13s but they are not responding the same.
On page 4 the Drives and ISO Ins are plotted together for 4 seconds. Clearly the H2 Drive leads the other drives as already established. On the top plot of the ISOs, the X and RZ loops respond dramatically compared to the blip on Y. Further, the ISOs are scaled by 5 to emphasize their behavior before the Drive goes off. The Y loop looks to be trundling along but X and RZ and maybe more clearly RZ changes what it had been doing.
This might suggest the loops are causing this but the fact that only the H2 Drive reacts implies that circuit is more sensitive.
On page 5, only ISOs X and RZ are shown with the H2 Drive. On the top plot, the drive is scaled down to be visible with the zoomed in ISO loops. The RZ loop really seems to be headed somewhere bad before the drive freaks out. Again however, if the loop was the source, the other drives would be reacting similarly and they are not.
On Page 6, one sees the ITMY loops don't respond like the ITMX X and RZ loops--not caused by the common ground motion.
On pages 7 & 8, an interesting beat is seen on the HEPI L4C RZ loops. Otherwise nothing else on the HEPI IPS or L4Cs of either ITM.
Page 9, the GS13s of ITMY are overlain on the ITMX GS13s for 20 seconds showing the motion on the platform is nearly identical on the two ITMs.
On page 10, the horizontal GS13s of ITMX are plotted together (left middle graph) showing the relative magnitudes. This implies only corner 2 is being driven and the others are just seeing the rotation caused by the one corner.
Page 11 plots the H2 CD INMONs, 80 seconds to show the normal before some badness at the trip time.
Page 12 zooms into 10 seconds showing the Coil Driver current and voltage making some really ugly step and excursion one or more seconds before the RZ loop starts to head off. The model did not tell the coils to do this or it would be seen on the DRIVE. The RZ loop and the X loop (page 4) are responding to what the coil driver is doing to the platform. I'm pretty sure this tells us the coil driver is the source of this problem.
Maybe the coil driver is marginal in some way and when the extra demand of dealing with the work of the earthquake motion occurs, something lets go.
NDS2 Data Storage Timing Issue???
Attached is a ddt plot of the H2 INMONs, the ground motion, and the H2 MASTER DRIVE (the output of the model.) I had to go to NDS2 extraction as the full data is now gone from h1nds1.
On this ddt plot, the hump up to ~500cts on the I mon (RED) starts about 10 seconds whereas the rapid increase of MASTER_H2_DRIVE (violet?) is starting around 9ish seconds.
On page 11 of the pdf above, the ramp up of the Drive channel (center graph) clearly happens after the step in the I_INMON channel (upper middle channel.)
The INMON channels are slow whereas the DQ channels are fast...
I suspect my dataviewer looks are correct but...
Okay--false alarm on the timing, but a warning to DDT via NDS2 users looking for time series with mixed data rate (16 & 4k) channels---these are the conditions I was working under.
See the attached plot where the red trace is a 16hz FE channel and the reference in green is a 4kHz channel and the measurement setup has the stop frequency at 1 hz and BW of 0.01 hz. Lower in the attached is the fourier tools settings for the Blue data where the only thing changed from the green is to set the stop frequency to 7 hz. The reason for the change in the shape of the data may be obvious to many of you much sharper in your signal and fourier analysis than I but should serve as a warning to all those using DDT to display time series. I had to slow things way down due to the 16 hz channel and just went to and it greatly impact the accompanying fast channel. 2, 3 & 4 HZ stop frequency all produce the brown trace; 5, 6 & 7 all produce the Blue trace. 7 Hz was as high as it would go.