Here is an update to 19908 and Dave's 19808. See attached 21 days of trends: the SUS glitches are not tripping the ISI with the new model code.
WP 5396
ECR E1500325
II 1086
All the local ISI models have been successfully recompliled to svn rev 11156. This update allows clearing of the saturation count separately from the WD reset. Also, every minute, saturations older than one hour are dropped from the count total. If there are no saturations for the past hour, there will be no saturations totaled.
These models will be installed and then restarted tomorrow.
Rana pointed out to me that the PR3 and SR3 suspensions may still have some shift due to wire heating during locks (which we won't see until a lockloss, since we control the angles of mirrors during lock).
Attached are the oplev signals for PR3 and SR3 at the end of a few different lock stretches, labeled by the time of the end of the lock. The lock ending 3 Aug was 14+ hours. The lock ending 31 July was 10+ hours. The lock ending 23 July was 5+ hours. The lock ending 20 July was 6+ hours.
The PR3 shift is more significant than the SR3 shift, but that shouldn't be too surprising, since there is more power in the PRC than the SRC so there is going to be more scattered light around PR3. Also, PR3 has some ASC feedback to keep the pointing. SR3 does not have ASC feedback, but it does have a DC-coupled optical lever. SR3 shifts usually a few tenths of a microradian, but PR3 is often one or more microradians. Interestingly, the PR3 shift is larger for medium length locks (1 or 1.5 urad) than for very long locks (0.3 urad). I'm not at all sure why this is.
This is not the end of the world for us right now, since we won't be increasing the laser power for O1, however we expect that this drift will increase as we increase the laser power, so we may need to consider adding even more baffling to the recycling cavity folding mirrors during some future vent.
Note - The PR3 and SR3 have 2 different baffles in front of them which do different things. The PR3 HAS a baffle which specifically shields the wires from the beam. The SR3 does not have this particular baffle, however I believe we ave a spare which we could mount at some point if deemed necessary.
Attached is a picture of the PR3 "wire shielding baffle D1300957, showing how it shields the suspension wires at th PR3 optic stage. In fact, a picture of this baffle was taken from the controlroom and is in alog 8941.
The second attachment is a repost of the SR3 baffle picture from alog 16512.
from the pictures, it seems like we could get most of the rest of the baffling we need if the wire going under neath the barrel of PR3 were to be covered. Perhaps that's what accounts for the residual heating. Also, if it became a problem perhaps we can get an SR3 baffle with a slightly smaller hole to cover its wires.
PSL Status: SysStat: All Green, except VB program offline & LRA out of range Output power: 32.4w Frontend Watch: Green HPO Watch: Red PMC: Locked: 5 days, 2 hours, 3 minutes Reflected power: 2.1w Transmitted power: 22.8w Total Power: 24.9w ISS: Diffracted power: 9.2% Last saturation event: 0 days, 0 hours, 24 minutes FSS: Locked: 0 days, 0 hours, 24 minutes Trans PD: 1.384v
DarkhanT, RickS
We found that the DARM_CTRL excitation line reverted to old values on 7/31 (last Friday) at about 11:13 PDT, 18:13 UTC. Perhaps this was the result of an errant BURT restore, but we didn't find a record of one in a quick survey of the aLog.
When we set the lines last week (see this link), we didn't update the SDF (our bad!).
Today, we reset the frequency of the DARM_CTRL line and adjusted the amplitude to give us SNR ~100. We also adjusted the amplitude of the Pcal lines to adjust their SNRs to be near the design values.
The updated settings are:
| Excitation point | Freq.(Hz) | Amp.(cts.) |
Target SNR (10-sec. FFT) |
Range used.(%) |
| DARM_CTRL | 37.3 | 0.085 | 100 | ?? |
| PcalY | 36.7 | 125 | 100 | 0.3 |
| PcalY | 331.9 | 2900 | 100 | 6.9 |
| PcalY | 1083.7 | 15000 | 13 | 36 |
Wanted to know before Tuesday whether there were any reservoir level=>accumulator problems. All reservoir levels are unchanged. No HEPI maintenance tomorrow.
Late entry from last Tuesday's SUS front end restarts, here are the results of the 18bit DAC AUTOCALs performed by the IOP model. One card fails autocal, two take an addtional 1.2S to complete.
h1susb123
H1 was locked when I got in, so I brought ISC_LOCK to DOWN to get some locking practice.
It went up to CARM_ON_TR before stopping and notifying of "No IR in arms".
Sheila mentioned in a log a few weeks back to go to manual and then go back to the state PREP_TR_CARM, but that did not solve the issue and broke lock when I went back to CARM_ON_TR.
Brought it back up and got the same notification, and then I did exactly what I did last time.
While it was going up and down the last few times I was investigating some of the work the commissioners did last night, and I ended up using SDF to switch back some of the changes from alog20146
At this point I got Jenne involved and she worked hard trying to figure it out while I went to a training.
When Evan came in he admitted that he had forgotten to turn back on the Input to the H1ALS-C_REFL_DC_BIAS filter module.
This seemed to have solved the issue.
This filter module is not being monitored, so I added it to the SDF monitor and Jenne added it to the Guardian.
All seems to be good now, made it to COIL_DRIVERS before a commissioner accidentally lost lock.
Log Times – The time stamp on the headers of aLOG entries are in Local Time. After much discussion, the times in body of the log entries should be entered in UTC time, with a note to that effect. Example: “restarted XYZ at 15:45 UTC”. Betsy is giving operator training on the SDF system at 10:00 in the control room. The New LIGO Web page has launched. Prep work for the Tuesday maintenance window: Sub Systems are coordinating planned updates CDS: will swap a switch on the End-Y UIM Coil Driver VAC: will be regenerating the NEG pump at End-X FAC: will be moving several crates to Mid-X
Matt E and I were talking about the broadband noise that is showing up coherently in the OMC DC readout, increasing the noise by 15% or something above shot noise, at frequencies above ~80 Hz. The observation is that this noise increases as the input power is increased (i.e., the watts/rtHz on the OMC DC PDs goes up with higher input power). Amplitude noise on one or more RF sidebands is a plausible source of this noise (not a new idea), and we wanted to suggest specific tests be done to look for RF sideband noise. For example:
The OMC refl shutter is normally kept closed, but I have just opened it.
There have been some questions about how to run the HWS code.
The HWS code runs on one of three HWS computers, we have one at each end station and one at the corner station. I have set up a tmux session to run the HWS code constantly at the corner station. If the code is running, the heartbeat will flash on the TCS HWS ITMX/Y medm screens, and the seidel aberrations will update once a second on the HWS ITMX/Y CODE screen. To take a measurement using the HWS, in addition to having thr HWS code running, you also need to turn on the RCX link framegrabber power, the Dalsa 1M60 Camera power, and the Superluminescent diode (SLED) power switched on the HWS medm screen. To increase the lifetime of the SLED and to avoid injecting 1Hz noise into the PEM channels (we are working on filters on the camera power supply to fix this one), we are leaving the HWS hardware off if we are not using it.
If you want to stop or restart the corner station code for some reason, you can ssh into the cornerstation hws computer:
>> ssh -X controls@h1hwsmsr
and attach to the tmux session
>> tmux attach
This webpage (http://www.dayid.org/os/notes/tm.html) has a list of tmux commands. We are running two sessions, one for ITMX and one for ITMY. Go to the relevant session, go to the folder ~/temp, and run the HWS code with the command
>> Run_HWS_H1ITMX (or ITMY....)
Jim and Dave have installed tmux on the end station HWS computers (thanks guys), so the code is running at these computers now too. It is intialized with the command >> Run_HWS_H1ETMX or >>Run_HWS_H1ETMY in ~/temp, after you log into controls@h1hwsey (or h1hwsex).
There was a persistent excitation in:
H1:ALS-C_REFL_DC_BIAS_EXC
on h1lsc. This was presumably from an awg process left running by Evan on operator1 workstation.
I killed ALL testpoints on h1lsc (dcuid 10):
jameson.rollins@operator1:~ 0$ diag -l -z
supported capabilities: testing testpoints awg
diag> tp clear 10 *
test point cleared
diag>
Actually, you should clear the awg, then clear the test point. As it is now, there is still an awg slot with a sine excitation, but no test point.
I took down the IFO at 717 PST for locking training. The insiral range shows that it was locked for over 12 hours. Awesome!
Based on measurements of the DARM OLTF and the EY PUM/test crossover that Jeff and I took last week, we can estimate the current value of the EY ESD actuation coefficient. It is 1.45×10−10 N/V2, with a 20 % uncertainty. This is an 80 % increase compared to the previous value (0.8×10−10 N/V2) which was measured at the end of May.
This number mostly relies on the crossover measurement, since above 10 Hz, the effect in the OLTF of changing the actuation coefficient is largely the same as changing the optical gain. Additionally, this number requires us to assume a number for the PUM actuation coefficient. Here I assume that it has not changed since the May calibration (i.e., I use 7.0×10−13 m/ct at dc).
Note that the modeled crossover doesn't really agree well with the measurement above 80 Hz. More investigation is required, particularly since during ER7 we already knew there was an issue with the DARM model around 10 Hz. (This discrepancy is why I say the uncertainty in the coefficient is no better than 20 %.)
To generate this number, I took Jeff's ER7 calibration script and made a version (H1DARMXO.m) that models the crossover. Both scripts (and the parameters file for the July 25 measurement) live in the CalSVN under Runs/PreER8/H1/Scripts/DARMOLGTFs. All parameters were left the same as their ER7 values except for the optical gain (I use 1.0×106 ct/m), the DARM pole (I use 330 Hz), and the EY L3 drive strength (I use 11×10−15 m/ct at dc). By tuning the L3 drive strength to match the measured crossover, we can extract the ESD actuation coefficient, assuming the rest of the L3 signal chain has been well-characterized. This is how I get the number quoted above.
The 80 % increase is sort of consistent with the 70 % increase that we saw when retuning the L3 digital gain post-vent. Strictly speaking, that was a measurement of the relative strengths of EX and EY. However, the DARM OLTF (with the retuned EY L3 gain) stayed roughly the constant before and after the vent, indicating that this 70% increase really is a change in EY.
I would like to clarify the relationship between the above entry and Sudarshan's entry.
The above entry is making a statement about a number (in N/V2) which characterizes the force applied to the test mass given a certain amount of voltage applied to the ESD (both its bias and its quadrants).
Sudarshan's entry is making a statement about a number (in m/ct) which characterizes the test mass displament given a certan number of counts in the DARM control signal. Therefore, it includes not only the above ESD strength (in N/V2), but also the mechanical response of the test mass, the electronic driver transfer function, the DAC, and the digital control filters for EY. In particular, it includes the digital EY L3 drivealign gain, which was changed from 50 ct/ct to 30 ct/ct after the vent in order to compensate for an unknown* increase in some other part of the EY actuation chain. Therefore, we expect Sudarshan's number to be small; if the compensation had been done perfectly, we would expect 0% change.
*Although it is unknown, I hypothesize that it is due to the discharging of EY resulting in an increase in the ESD actuation coefficient (in N/V2).
Evan, Stefan Using a line at 6409.7Hz we found a null in the frequency noise coupling. Thus we took the REFL_9 to OMC_DCPD_A transfer function (plot 1). This is a nice modelling challenge - thus we spend some time calibrating it in meaningful units. Calibration: - OMC_DCPD_9 (H1:IOP-LSC0_MADC0_TP_CH12): - This is just a copy of the filters in the PDA filter module, plus the 13.7kHz 17.8kHz poles from preamp (alog 17647). We did not take into account the AA board, but it should be the same for both channels: - G=8.63151e-07 - P=0.87, 7.689, 7.689 - Z=10.07, 78.912, 90.642, 13700, 17800 - REFL9 (H1:IOP-LSC0_MADC1_TP_CH28): - The gain is 2900V/WattsRF (see alog 10661) x (12dB whitening) x 1638.4cts/V, plus a z=1,p=10Hz whitening filter (again, no AA board compensation) - G=5.2867e-08 = 1/(2900*3.9811*1683.4) - P=1 - Z=10 Plot 2 shows the 9 OMC_DCPD traces during heating, calibrated in A/rtHz The xml template is in LIGO-T1500414 https://dcc.ligo.org/T1500414
Kiwamu, Stefan, Evan
We are trying to minimize the coupling of frequency and intensity noise into DARM by tuning the central heating on the IX CP.
The following excitations have been set up:
The amplitudes were chosen so that each line has an SNR of 50 or so in OMC DCPD sum with a 10 s FFT. Each demodulator demodulates OMC DCPD sum at the appropriate frequency, and then lowpasses I and Q with a 100 mHz, 4th-order butterworth.
At 2015-08-03 01:19:45 Z we changed the IX CP heating power from 0.23 W to 0.36 W.
At 2015-08-03 02:57:25 Z we changed the IX CP heating power from 0.36 W to 0.53 W.
At 2015-08-03 04:26:20 Z we changed the IX CP heating power from 0.53 W to 0.41 W.
Additionally:
Stefan has reverted the rewiring on the CARM board.
We are leaving the injected frequency line on so we can watch it as the interferometer settles into its new thermal state.
Also, we further increased the ISS gains: the first loop went up by 10dB, the second loop by 6dB. No immediate noise improvement was visible in DARM.
I looked at OMC SUM/NULL during the long lock last night, after the frequency noise injection was turned off. There is no significant difference between the beginning and the end of the lock. The excess of noise was of the order of 10% shot noise level, similarly to the night before. The highest excess of noise I have seen is ~15%, corresponding to a few days ago , July 31st.
