Posted are the plots for the BSC and HAM ISI CPS noise spectra. All plots are near or below the reference and there are no particular CPS noted. Closed FAMIS task #6866
TCS-X: No additional water required, water level 29.0, 3.7 gpm, 20.1 deg. C.
TCS-Y: Found water level at 5.8, added 300 mL water, raised water level to 9.8, 4.0 gpm, 21.0 deg. C.
Not that it is a concern but attached is a plot of the Long Range Actuator (LRA) position versus the
laser room temperature. I only note it because the 32 micron travel is perhaps the longest I've seen
it move, and represents 64% of the available travel before a PZT reset.
The data dropout corresponds to the DAQ restart at 23:02 UTC yesterday.
Heat was increased into the LVEA on Wednesday morning - it would be interesting to see the correlation with the increase in the table temperature.
I tried a few things to look around for a useful signal for SRM ASC at 50W, and had no luck.
I am pretty convinced that there's no signal that's useful in REFL45 for the SRM. I couldn't get rid of the ~0.16 Hz oscillation that we see in the PRC1 and PRC2 control signals, which I tried in an effort to see something better in REFL45. (I tried adding res-gains in both PRC1 Pit and PRC2 pit, to no avail. Out of loop motion as measured by POPB didn't change.) I eventually tried "cheating" by lowpassing the REFL45A pitch and yaw I signals (these are not in-loop for anything), but there's really nothing at all there for the SRM. I also tried moving SR3 (after disabling the cage servo), but that also didn't really have a good signal anywhere but AS36B. Both SRM and SR3 have an okay signal in AS36B, but I was hoping to find something that wouldn't leave us back in the "sensing matrix of the day" regime.
Interestingly, the noise at high frequencies seems to get better when POPAIR90 is higher and rattier. I'm not sure right now why a misaligned SRC would help suppress frequency noise.
I tried Nutsinee's CSOFT offsets from the other night (alog 30085), and while they do seem to improve the sensitivity in the bottom of the bucket, they noticeably reduce the power recycling gain. I tried a few other offsets, but I think 0s everywhere for the SOFT loops is about the best in terms of power buildup. I was running a2l at each offset, and the calibration lines at 330 and 1100 Hz were roughly constant, so I don't think I was fooling myself too much. So, why do we get better sensitivity in the bucket with lower recycling gain (28 rather than 30)? I see the buildups go down in the arm transmissions as well as POPDC, so it really is a reduction in the recycling gain.
Note to self for the morning: Were good / bad range times really correlated with times when the AS90 dark offsets jumped? It vaguely seemed that way, but I need to check. The AS90 signal would occassionally pop up and be visible on the front tv striptool, even though it should be too low for that with the beam diverters closed. It was sudden jumps, not obviously related to alignment changes, so I think it was dark offset changes. If that's true, do we need to finally figure out why the electronics at the HAM6 rack are so finicky? No one was out in the LVEA, so I'm not sure why the offsets were changing.
TITLE: 10/05 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Ready to go to Observing when Jenne is done.
INCOMING OPERATOR: Travis
SHIFT SUMMARY: Locking has been going well. Unlocking has also been going well. No issues to report.
LOG:
23:02 DAQ restart
23:14 Nutsinee to LVEA Hartmann work
23:30 Initial alignment
0:02 Nutsinee out
5:50 Nutsinee filling TCSY chiller
6:00 End of shift due to Guardian training early shift start (22:00)
NOTE to Commissioners: In order to get Guardian to let us go to Observing we had to (and will have to fix later):
Earlier in the evening, we also changed the ISC_Lock parameters to request 60W from the LASER_PWR guardian, since that's what will give us the max ~48W that we can have for today. I've also changed the nominal to be this 60W value in the LaserPwr guardian, so that I can hopefully hit the intent bit before I leave.
DTT is once again not ramping down excitations. The exciting new "feature" here is that it's not just upon an Abort. Even when the measurement completes fully, it still just immediately stops the excitation.
This has caused 1 lockloss so far tonight, and 2 scary glitches that could have been locklosses.
I attach my DTT settings - Noise (Gauss), and I do have a ramp up/down times defined.
-----
Looking at it again (still running measurements, just hoping for the best when they complete), it looks like it waits and leaves the excitation on for the number of seconds set in the RampDown box, and then cuts it off. So, the excitation doesn't get suddenly cut off as soon as I click Abort, it gets suddenly cut off 3 seconds after I click Abort.
Your excitation contains a filter that rings like a bell long after the input has been cut off. Since the excitation and filter are implemented in the AWG on the front end, there's nothing DTT can really do about this, other than hold the excitation test point open until the program quits. The ramp down applies to the input to the filter, not the output.
Step response of filter for excitation, 500 seconds.
Both HWSX and HWSY centroid refernces re-initialized after IFO unlocked for 2 hours. ITMs, BS, and SR3 are all aligned.
16:49 Re-initialized HWSX centroids ref
16:51 Re-initialized HWSY centroids ref
Related: alog 30221
In addition to what Daniel has posted, I measured the coherence and DBB QPDs again, this time in nominal low noise.
Probably due to lower IFO noise, the coherence is larger and broader, extending down to 70Hz or so.
The differences between today and yesterday are:
I found that the OMC Trans camera's exposure was set very low (64). It was changed on 30 Sept, but I'm not sure if this was meant to be a permanent change, so I've increased it to 600. This saturates the center of the camera, but it's more familiar. If someone wanted to see the mode shape, we can turn the exposure back down.
J. Kissel In the interest of providing supporting evidence for SUS data storage rates (see newly minted T1600432), I've taken a look at the coil output spectrum at the output of RM1, RM2, OM1, OM2, and OM3 during the latest nominal-low-noise lock stretch using both the requested DAC output (M1_MASTER_[UL,LL,UR,LR]_OUT) and the voltage monitors (M1_VOLTMON_[UL,LL,UR,LR]). The messages: - On the OMs, for the current alignment scheme (OM1&2 used for 1-2 Hz BW "DC" centering on AS WFS; OM3 used at similar BW to center the beam onto the OMC breadboard), it's totally fine to store the OM VOLTMONs at the lowest possible "fast" rate of 256 Hz. There is no coherence between the output of these VOLTMONs and the requested drive (MASTER OUT) above ~5-10 Hz, and the requested drive is rolling off as a function of frequency. - On the RMs, for the current alignment scheme (RM1&2 used for 1-2 Hz BW "DC" centering on REFL WFS), the coil requested output is completely coherent with the VOLTMONs out to ~1 [kHz]. That's silly. I've informed Jenne of this and she's identified several places that are lacking sensible low-pass filtering, which she'll install now that she's got the infrastructure to do so (LHO aLOG 30247). Once this is rectified, I'll confirm in comment to this aLOG, but I suspect that it'll also be totally fine to store the RM VOLTMONs at the lowest possible "fast" rate of 256 Hz. - Because these poor suspensions are always the second last to be thought about, Ed's study of the coil driver monitors in support of FRS Ticket #5135 -- see LHO aLOGs 15176, 15312, and 17890 -- did not cover any of the RMs or OMs. As such, the problems with these monitors have not yet been called out explicitly. In doing this study, I've identified all of the problems with the HTTS VOLTMONS: - The following VOLTMONs are missing a factor of 2 in their gain (i.e. they're 2.0 lower than the expected, requested output): OM1 UR & LR RM1 UR & LR RM2 UL & LL. Because this fault seems to come in pairs on a given side of the optic, my guess is that 1/2 of a differential leg is not making contact or is busted. - The following VOLTMONs are just down-right busted and show garbage: RM1 LL RM2 LR. I'll leave it to CDS as to whether they want to create individual FRSs on these, or just add to FRS Ticket #5135. Details: I've calibrated both the requested drive and measured drive into Volts right at the output of the DAC. Remember, the HTTSs (i.e. the RMs and OMs) were ISC built suspensions, which had to be different -- they have 16-bit DACs, not 18-bit DACs. Also, the low-pass filter of the HAM-A driver is permanently jumpered ON. Thus, The DTT calibrations into DAC [V] are as follows: MASTER OUT Gain: 3.0518e-04 (from the DAC gain of 20 / 2^16 [V dac/ct]) Poles: (none) Zeros: (none) VOLTMON Gain: 2.7555e-04 (from ADC gain of 40 / 2^16 [V/ct] and the HAM-A driver gain of 1 / 2.215 [V dac/V out]) Poles: 10, 21 Zeros: 0.9, 212 More details of the HAM-A driver (D1100117) can be found in T1200264. Note for the attached ASDs, I faked the calibration of the factor-of-two busted channels by using a gain of 2 * 2.7e-4 = 5.5e-4 [V dac/ct]. The data templates in my home folder here: /ligo/home/jeffrey.kissel/2016-10-05/ 2016-10-05_H1SUSOM1_MASTEROUT_vs_VOLTMON.xml 2016-10-05_H1SUSOM2_MASTEROUT_vs_VOLTMON.xml 2016-10-05_H1SUSOM3_MASTEROUT_vs_VOLTMON.xml 2016-10-05_H1SUSRM1_MASTEROUT_vs_VOLTMON.xml 2016-10-05_H1SUSRM2_MASTEROUT_vs_VOLTMON.xml
model restarts logged for Tue 04/Oct/2016
2016_10_04 09:13 h1hpietmy
2016_10_04 09:13 h1iopseiey
2016_10_04 09:13 h1isietmy
2016_10_04 09:48 h1iopsusauxey
2016_10_04 09:48 h1susauxey
2016_10_04 10:10 h1iopsusauxey
2016_10_04 10:10 h1susauxey
2016_10_04 10:22 h1iopsusauxey
2016_10_04 10:23 h1iopsusauxey
2016_10_04 10:24 h1susauxey
2016_10_04 10:48 h1nds0
2016_10_04 11:04 h1nds0
h1seiey bio card swap. h1susauxey adc ribbon cable swap. h1nds0 mem upgrade.
The IFO node checks that all nodes in a list are in their nominal state, and if they are, then an operator can successfully click the intent bit to Observing. With Jamie's new addition to the python guardctrl client, we can grab a list of all nodes, and then subtract another list of "excluded" nodes that we do not need to watch in observing. The idea behind this exclude list is that a handful of nodes is easier to manage than 100 changing nodes.
Code is attached as a txt
late entry from yesterday
WP6211 h1seiey Binary Card Repacement
Richard, Fil, Jim:
h1seiey was powered cycled to replace its BIO card in the IO Chassis.
WP6213 h1susauxey ADC ribbon cable swap
Richard, Fil, Jim, Dave:
h1susauxey was powered down to replace the ribbon cables which connect ADC to interface cards for the second and third ADCs to fix 4000 count offset. We noted that the as-built drawing was out-of-date (needs updating). The replacement did not fully fix the problem. The 4000 count offset started in January 2016 when the h1susauxey IO Chassis was accidentally powered down during ESD-DAC work on h1susey.
WP6214 h1nds0 memory upgraded
Jamie, Dave, Jim
h1nds0 RAM was upgraded from 48GB to 72GB, this fixed Jamies nds client data errors.
h1guardian0 reboot
Jamie, Dave:
we rebooted the h1guardian0 machine, Jamie verfiied all guardian nodes came back correctly.
dns database change for conlog machine name changes
Patrick, Carlos, Jim.
CDS DNS was changed to reflect the new conlog machines names.
Check AUTOCAL status for all 18bit DACs
Dave:
I verified that all of the H1 18bit DACs successfully pass their autocalibration. This includes the PEM-DACs.
Attached is 30 day pressure trend along X/Y arms and chambers. The hump in pressures along x-arm was due to failing channel in ion pump #10 (IP10) at MX.
Since we're thinking about RAM (residual amplitude modulation), also known as RFAM (RF amplitude modulation), I did a quick Optickle simulation to see what effect RAM will have on some of our length degrees of freedom.
Here, all of the Optickle simulations plotted were run with 50W of PSL input power, and a +10pm DARM offset (+5pm for ETMX, -5pm for ETMY). So far, I've just plotted the vertex length degrees of freedom, but I'll do a similar simulation for CARM and DARM soon.
The bottom panel of each of the attached PDFs shows power buildups that are relevant for that degree of freedom. The other panels are the RF PDs that we use as error signals in full lock. PRCL uses POP_9_I, MICH uses POP_45_Q, and SRCL uses a combination of POP_9_I and POP_45_I.
One might note that even in the absence of RAM, the error signals do not have a zero crossing at 0m, and the power buildups for the carrier are not centered at zero. This is a result of our finite DARM offset. Removing the DARM offset centers things up closer to what your intuition would indicate.
I've used a RAM modulation depth of 1e-3, which is roughly what we had measured at the 40m some time ago. I haven't yet looked at Sheila's data from last night to update this value for us.
Interestingly, the RAM always pushes the lock point offsets in the same direction, regardless of DARM offset. But, the DARM offset changes which size of 0m each zero crossing is in the absence of RAM. So, with a positive DARM offset, having some RAM actually puts the zero crossing closer to 0m, while with a negative DARM offset the RAM pushes us farther away.
RAM in principle can have a complex phase (relative to the PM sidebands) including a negative sign.
The last time we measured this was in alog 15661.
I kind of think I saved the new alignment slider values after changing the alignment slider gains on Sept. 30th, but found them at the old values in SDF. I accepted the new values. Screenshot attached.
I also asked TJ to put the IM alignment check (IM1, IM2, IM3) back in DIAG_MAIN. While we moved the IMs it didn't make sense to have DIAG_MAIN show their alignment as an error, but now that we've had this IM alignment for about 10 days, it's stable enough to start tracking it again.
