VAC: Tuesday: Routing steel tubing at end stations for TMDS Run up turbo to replace gauge at end station FAC: Membranes for RO are on order, may be replaced Tuesday
In the first observation intent time from today, there are DAC glitches in MC2 M3. They don't obviously appear in DARM at the time we checked, but they do appear in a number of channels. The first plot is an Omega scan showing glitches in MC_L, and the second shows that they correspond to zero crossings in MC2 M3 control.
I grabbed Andy's images and lined them up in keynote. Thought folks might want to see how convincing this is for DAC zero crossing glitches.
Jim, Dave
we checked to see if the 18bit DAC card for SUS MC2 M3 happened to be close to the new DC power supply. It is not, in fact it is the furthest from the power supply.
At least twice tonight there has been glitching of MC2, similar to what Kiwamu described last week. It is visible in POP18 and AS90, as well as the MC2 witness sensors. I was not looking at the IMC REFL camera at the time, so I can't say whether it was the same kind of kick in yaw as before.
Observation Bit: Commissioning 16:07 Realign after Lockloss 18:10 Dick G. - Going into Optics Lab 19:20 Dick G. – Out of Optics Lab 20:10 IFO locked at LSC_FF 20:15 Observation bit set to Undisturbed 20:36 Lockloss Reason unknown 21:45 IFO locked at LSC_FF 21:50 Observation bit set to Undisturbed 22:03 Adjust ISS diffracted power from 12% to 8% 22:17 Lockloss – Reason unknown 22:21 Re-Start initial alignment after Lockloss 22:40 Complete initial alignment 22:43 Start Guardian locking 23:14 Lockloss – restart locking process 23:55 Lockloss at Engage_ASC 00:00 Due to problems locking left IFO in a down state. Very difficult to do initial alignment and to get the IFO to lock. There was a large amount of activity in the 1 -3Hz and 3 - 10Hz seismic ranges and several periods of higher winds (upper 30 mph and mid 20 mph). Large ring up in Bounce and Roll modes each time reached Engage_ASC stage. Limited success in suppressing these.
All times are Pacific Standard Time:
All locks are at 24W LASER Power:
Tried to reset the R0 water pump twice. No luck. It will remain off until Bubba can look at it on Monday morning.
IFO wasn't re-aligned all day. AS Air image had a bit of a bulge to it. It didn't seem to matter...much.
07:30 in a bit early. I was up. Why not?
07:31 Dan on site from last night. Looks like we had a nice 6-7 hour lock. Bounce, Roll and violin modes have been mercilessly beaten down to almost nothing and Dan sauys this is now the status quo. NICE!
08:17 IFO re-locked. Dan and I re-tweaked some bounce mode filters and did some dithering alignment to the OMC Intent bit set to undisturbed.
09:03 Jeff Kissel on site.
09:08 OIB set to comissioning
09:10 Jeff increasing DARM gain. (was too low)
09:24 OIB set to UNDISTURBED
10:25 Dan went home. He reduced the OMC dither gain in Guardian before he left because he noted that it was pushing a bit to hard on the mass.
10:30 went out to try and reset the RO pump. no luck.
10:35 Jeff noted that a small plane flew overhead.
11:02 Bubba called in about the RO pump status. The alarm is NOT ringing in the control room and he said the pump can stay off the rest of the day and he'll look at it tomorrow. Unless it becomes a nuisance ro we run out of potable water..don't worry about it.
11:54 Jeff went home. I'm singular.
12:00 ripples showing up on strip tool, probablty as a result of the 5.0 mag quake that struck the Aleutians at 18:07:45UTC? ( i don't think the timing is coincidental enough)
12:10 Got some SRM vocalizations, AS Air cam got a bit jittery but she's holding steady as a rock!(famous last words?)
12:50 HPI-PUMP_EX_DIFF_PRESSURE alarmed (Yellow).
13:39 both ITM oplevs and the BS oplev are showing oscillations in Pitch ~15min prior and also starting to wander up and down.
13:42 Lockloss. OIB auto-switched off.
13:56 Re-locked @ DC readout
14:10 Set the gain on ETMX_M0_DARM_DAMP_R to 200 to improve roll mode after lock settled awhile. Turned on DHARD_P filter 9 (:12^2) because Dan told me that it was a good idea. No Dither align on OMC this lock.
14:14 OIB set to UNDISTURBED
14:40 Oplevs starting to show "ringing" . This time it seems to be ETMY being the biggest offender with ITMY and ITMX tied for second place. The BS doesn't seem to be involved in this heat.
14:54 Lockloss
15:10 Re-locked. Adjusted/Engaged filters as before except turned gain on ETMX_M0_DARM_DAMP_R up to 500. I intitially set the gain at 300( then changed it to 500 after the intent bit was set) I then turned on dither alignment to OMC @ .07 master gain. Range about 58Mpc.
15:59 ETMY oplev showing large oscillation again. Lockloss. All yours Jeff.
The fastest lock-acquisition sequence in the West!
Tonight I worked on (re)commissioning the OMC alignment dither and measuring the AS power as a function of DARM offset.
OMC Alignment Dither
Since (re)commissioning the OMC ASC dither last month, the yaw loop had become unstable. In case this becomes a persistent problem, I've written a script that will measure the dither sensing matrix, invert, and loads the resulting control matrix into the appropriate fields in the DACTMAT matrix. (Not sure what DACTMAT means...I would have called it DITHER2DOF.) The script is here (I have committed it to the svn):
~userapps/release/omc/common/scripts/ditherDCsense.py
The script inserts DC offsets into the OMC ASC loops and measures the response in the dither error signals. It's gentle enough that it can be run in DC readout without breaking the lock. Using the script I recalculated the dither control matrix and turned the dither loops back on; a screenshot of the new control matrix is attached. They work, but I recommend very low gain - 0.05 on the OMC ASC master slider. This reduces the UGF of the loops enough that noise is not being injected into the OMC alignment; with the gain too high there is clear scattering noise at low frequencies. Enabling the dither gave the range a 1-2Mpc boost. For now this is not in the Guardian, but we should start using the dither alignment.
If you use the script, keep an eye on the OMC SUS and make sure the offsets to the ASC loops don't saturate the drive. If this happens your matrix will have a problem and you will not go to dither today.
Interestingly, the optimal alignment on the QPDs is different in the 2.3W and 23W states. Is this due to some junk light in the DRMI? For now I have left the QPD offsets to have the optimal low-power alignment, assuming that the dither will be engaged later on. At high power the dither alignment pushes the OMC in pitch such that the outputs to the DAC are ~90k counts. This seems like a lot to me, and we can't offload the drive anywhere, except perhaps some pico-motoring on the AS WFS to make the tip-tilts point the beam at a charitable angle. We need to work out a HAM6 centering scheme that doesn't use the OMC SUS.
DARM Offset Scan
With the alignment into the OMC optimized I scanned the DARM offset at 2.3W input power and measured the DCPD Sum. Plot attached; the curve is very well fit by a quadratic with a small static offset from the origin, about the same magnitude that Stefan, Keita and I observed two weeks ago - a few tenths of a picometer. So, no surprises. Note, the data points in the plot have error bars representing the 1-sigma statistical noise in the measurement, but they are too small to see.
In the second plot attached I have scaled the data to 125W input power, to make a comparison with Fig. 7 of the LSC design document (T1000298). From this simple scaling it looks as though the DARM resonance we observe is much narrower than in T1000298...but I think I'm forgetting what parameters are assumed in Fig 7. There was an error in my plotting - the data are a reasonable match to Fig 7 if a factor of 125/1.84 is applied to the DCPDSum, where 1.84 is the power incident on the PRM with 2.3W into the IMC. (Note on this log-scale plot you can see the slight assymmetry in the data points, indicating a static DARM offset.) Our standard low-noise, high-power configuration is 23W, and an offset of 1e-5 counts, which we think is 14pm. With these settings we get ~18mA in DCPD Sum.
Other Notes
Tonight I've been increasing the ETMX roll mode damping gain to 200. Also I've been engaging the DHARD rolloff filter (:12^2), this seems to improve the noise around 20Hz.
There is a very narrow line at exactly 3801Hz that I haven't seen before. There's no sign of aliasing - the high-frequency features in DARM, as measured by the 64kHz DCPD channels from the DAC, have not changed dramatically. The line has been slowly growing all night. This could be an 8th harmonic violin mode of ETMY, although the exact integer frequency is a little suspicious. I have added another notch to the ETMY_L3_LOCK filter bank, vStop8+9, but I have not turned it on.
J. Kissel I've taken a DARM Open Loop Gain TF for this lock stretch (after adjusting the DARM gain to match prior measurements). I'm going to start processing the past several DARM OLGTFs (see LHO aLOGs 18662, and 18709), including this one, using our new precise knowledge of the actuation scale factor (see LHO aLOGs 18711 and 18718). Since this is a DARM OLGTF with a new low noise ESD driver (though without the LP filter engaged), and the new hierarchical control scheme involving all three lower stages of ETMY, I figure I'd over-document it. Attached is a conlog and screen shot of the MEDMs for all the relevant digital filter banks and Binary IO Control involved in the DARM loop for this kind of lock stretch. Stay tuned! This darm OLGTF has been committed to the CalSVN under /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements/DARMOLGTFs/2015-05-31_H1_DARM_OLGTF_LHOaLOG18733_ETMYL3LPOFF.xml
model restarts logged for Sat 30/May/2015
no restarts reported.
Evening Shift Summary LVEA: Laser Hazard Observation Bit: Commissioning 16:00 Re-locking the IFO after several earthquakes 16:45 Dale – Locking the LSB and leaving 17:00 Kiwamu - Damping the bounce and roll modes before full locking 18:35 Jeff – Running PCal TFs 18:35 CS_WS_RO – alarm 18:40 – Bounce and roll modes low enough to try full locking 18:42 - Lost lock - Guardian recovering IFO 19:00 – Reset RO system 19:20 – IFO bounce & Roll modes low enough to try relocking 21:23 CS_WS_RO alarm – Will leave down for rest of the night 21:51 Jeff – Finished running TFs 21:52 Evan – Take IFO to 24.2w 22:00 Lost lock – Guardian recovering IFO 22:14 IFO locked at 24.2w 22:19 Lost lock – Guardian recovering IFO 22:36 IFO locked at 24.2w 22:42 Jeff - Turned down continuous wave injection by factor of 10 23:28 Set intent bit to Undistributed
I read your note.
How's 58Mpc sound? :)
On site today: Kiwamu. Jeff K, Darkhan, Sudarshan, Dale w/Tourgroup
08:00 Due to the 7.8 mag quake in Japan, the IFO is a RED light district. I have my morning work cut out for me!
08:12 untripped input triples and isi. Got IMC lock back. untripped remaining small suspensions and related isi on output.
08:15 begin untripping and damping quads. Then getting sei back up and isolating.
08:38 SEI back up and at nominal state(s). Time to asses the alignment.
08:40 Begin intial alignment
11:15 after fighting with SRCL and two phone calls to Sheila, it turns out my alignment was good after al and WFS finally decided to give me the lock I had been looking for!!! Kiwamu in.
11:17 initiate ISC_LOCK
11:50 Mich wouldn't lock. Kiwamu found that PR2 had drifted slightly while I had been trying to get SRC locked.
11:55 Mich finally locked for first time today! Probably won't be the la st.
11:58 Bounce mode rung up and broke the lock @ REFL_TRANS step.
12:20 Another Japan quake 6.4 @ 18:49UTC. riding the wave......
13:36 finally got DRMI locked again. There is still ringing from the quakes. We'll stay at this stage until things quiet down a bit more.
13:45 here we go again. Shooting for DC_READOUT
13:49 busted at ANALOG_CARM. Me thinks it's still a bit shaky. Gonna try and make it to resonance and camp for a bit.
14:02 no dice. Gonna try RF_DARM, a less lofty goal perhaps.
14:38 still no happy face.
15:03 Going to try to stop at CARM_10pm to try and engage some Roll/Bounce mode filters/damping
Got alarm on CS RO system.
Bubba talked me through a system reset.
CS RO system is back up and running.
To Reset RO System:
1). The RO system is located in the "water room", (through door to the right) in the Carpenter's shop
2). The RO Panel (OSMO 23G) is to the left just inside the door to the water room
3). Press the "mute" button to silence the alarm
4). Press the "Off" button to shutdown the RO system
5). Press the "On" button to restart the RO system
6). When the RO transfer pump starts - the pressure gauge should be reading around 58psi
The RO transfer pump is a red vertical pump on the floor half way down the back wall.
RO went down again an hour after reset. Left down over night - Bubba will look at it in the morning
J. Kissel, K. Kizumi, S. Karki While trying to commit our results from last night to the CalSVN, we discovered that every folder was complaining that the it was not a working copy of svn, e.g.: jeffrey.kissel@opsws5:/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Scripts$ svn st svn: warning: '.' is not a working copy Totally confused, we went to the trunk of the repo, and it said messages about discrepant svn client versions: /ligo/svncommon/CalSVN/aligocalibration$ svn st svn: The path '.' appears to be part of a Subversion 1.7 or greater working copy. Please upgrade your Subversion client to use this working copy. In order to make progress on the work stations (i.e. the h1boot server) Kiwamu made a back of the repo into /ligo/svncommon/CalSVN/aligocalibration_backup_20150530/ and made a fresh checkout of the repo, in the normal path: /ligo/svncommon/CalSVN/aligocalibration which regained its normal functionality. He then started digging around the log history to figure out what happened and found a bunch of commits from the LHO PCAL team yesterday evening... and then Sudarshan joined us for a happy (??) Saturday discovery. We've diagnosed the problem (a totally innocent user just doing what the computer told him to do -- he should not be blamed for any of this!!): Sudarshan was at the End Station trying to check in pictures of PCal camera on (new? old?) CDS Laptop called cdsmbp0. He tried to do an svn st just to check on things, and an svn update before he committed (very good!), but he got the following error message: [controls@cdsmbp0 Measurements]$ svn st svn: E155036: Please see the 'svn upgrade' command svn: E155036 Working copy '/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements' is too old (format 10, created by Subversion 1.6) [controls@cdsmbp0 Measurements]$ svn update svn: E155036: Please see the 'svn upgrade' command svn: E155036 Working copy '/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements' is too old (format 10, created by Subversion 1.6) He obediently then followed the instructions: [controls@cdsmbp0 Measurements]$ svn upgrade svn: E155019: Can't upgrade '/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements' as it is not a pre-1.7 working copy root, the root is '/ligo/svncommon/CalSVN/aligocalibration' [controls@cdsmbp0 Measurements]$ cd ../../../ [controls@cdsmbp0 Runs]$ cd ../../ [controls@cdsmbp0 aligocalibration]$ ls branches tages trunk [controls@cdsmbp0 aligocalibration]$ svn upgrade Upgraded '.' Upgraded 'trunk' Upgraded 'trunk/Runs/' #etc #etc #HERE'S A CRAZY BIT Upgraded 'trunk/Runs/PreER7/H1/Measurements/FreeSwingMich/2015-05-27' Upgraded 'trunk/Runs/PreER7/H1/Measurements/FreeSwingMich/2015-05-28' nfs server cdsfs0:/ligo: not responding # <<< what the heck?? nfs server cdsfs0:/ligo: is alive again Upgraded 'trunk/Runs/PreER7/H1/Measurements/DARMASDs/' # <<< OK... moving on... ?? Upgraded 'trunk/Runs/PreER7/H1/Measurements/ElectronicsMeasurements/' #etc #etc Upgraded 'branches' Upgraded 'tags' [controls@cdsmbp0 aligocalibration]$ This upgraded the hidden .svn configuration file in the entire repo in a way that is incompatible with any version of the svn client prior to 1.7. YUCK!! It turns out that every computer does not source the svn client binary from the h1boot server as I would have imagined -- so this laptop was using its own copy of the svn binary /usr/bin/svn, which was of a later version than what is normally used on the work stations: work stations: svn, version 1.6.17 (r1128011) compiled Aug 13 2014, 20:41:52 this laptop: svn, version 1.7.10 (r1485443) compiled Aug 13 2013, 15:31:22 What's worse, is that this "upgrade" to svn version 1.7.10 caused the entire h1boot server's copy repo to fail on the work stations as shown above immediately degrading the whole repo to just a normal unrepoed directory structure and it's not at all backward compatible. Even still more confusing -- svn version 1.6.17 doesn't even have an option to svn upgrade so we didn't believe (at first) what Sudarshan did was even possible. Thankfully - Sudarshan left the terminal open on this laptop so we were able to document everything that happened in great detail from this laptop's terminal session - Kiwmau has made the back up mentioned above, - *and* Sudarshan ran an svn st after the upgrade on this laptop, so we know everything that wasn't committed of was modified. (see attached) So nothing should be lost, we know the status of everything, and we can work to merge the backup back into the repo and move with out too much guess work. However -- the SysAdmins (don't worry -- this wasn't your fault either!! This is a *terrible* backward compatibility issue with the SVN clients. I blame them!!): We should make sure all computers on site running svn cleint 1.6.17. IF and when we want to upgrade to svn client 1.7 or higher, we need to be absolutely sure that we do it to all computers at once. OR we should demand that all computers are using a client that is hosted on the h1boot server, such that no computer is using an individual copy of an svn client. #scaryscaryscary #yakshaving
The SVN executable for workstations would not come from the H1 boot server, as that is running Gentoo at Linux kernel 2.6.34 for the front-ends. The workstations should be at Ubuntu 12 (kernel 3.2). Laptops can be problematic because they tend to be off for long stretches and so it is hard for CDS sys-admins to keep them updated. At LLO, Michael Thomas has been very good at using our Puppet server to keep the fixed workstations up to date with consistent package sets. Not sure how the Puppet practice is doing at LHO. We would certainly recommend users NOT use CDS laptops for SVN checkins. There should be sufficient workstations in VEAs and electronics rooms to address this.
This is a known issue. Mac Book Air laptops and mac-mini's are running Mac OS X which has SVN 1.7. Users should only use Ubunut workstations to perform SVN activities.
This sounds pretty scary.
For reference, I am running SVN version 1.7.19 on my laptop. But so far I haven't had any problems committing to or updating from the SusSVN.
The SusSVN is at Subversion version 1.6.17 (r1128011), as indicated at https://redoubt.ligo-wa.caltech.edu/svn/sus/.
J. Kissel, E. Merilh, D. Barker
There was an errant message for a pending filter change to be loaded in the H1OMC front-end model this morning that Ed and Dave wished to be cleared. Initially I thought this was because of Evan's changes last night who was widening a few notches for the stability high-frequency control of DARM, so reloaded the filter coefficients. However I've diffed the last three filter coefficient loads, and it appears as though there was now difference between the foton files in my load and the previous load:
jeffrey.kissel@opsws5:/opt/rtcds/lho/h1/chans/filter_archive/h1omc$ diff H1OMC_1117049961.txt H1OMC_1116981302.txt
jeffrey.kissel@opsws5:/opt/rtcds/lho/h1/chans/filter_archive/h1omc$ tconvert 1117049961
May 30 2015 19:39:05 UTC
jeffrey.kissel@opsws5:/opt/rtcds/lho/h1/chans/filter_archive/h1omc$ tconvert 1116981302
May 30 2015 00:34:46 UTC
whereas Evan's filter changes appear in the previous load:
jeffrey.kissel@opsws5:/opt/rtcds/lho/h1/chans/filter_archive/h1omc$ diff H1OMC_1116981165.txt H1OMC_1116981302.txt
132c132
< # DESIGN LSC_DARM 5 ellip("BandStop",4,1,80,1370,1570)ellip("BandStop",4,1,80,1900,2000)gain(1.25893)
---
> # DESIGN LSC_DARM 5 ellip("BandStop",4,1,80,1370,1570)ellip("BandStop",4,1,80,1900,2000)
137c137
< # DESIGN LSC_DARM 8 ellip("BandStop",4,1,100,480,527)ellip("BandStop",4,1,80,965,1040)gain(1.25893)
---
> # DESIGN LSC_DARM 8 ellip("BandStop",4,1,100,480,527)ellip("BandStop",4,1,80,965,1040)
156c156
< LSC_DARM 5 12 8 16384 0 vStop2,3 0.8566107853664323 -1.6767014787035512 0.9206465781685556 -1.7005774752522538 1.0000000000000000
---
> LSC_DARM 5 12 8 16384 0 vStop2,3 0.68042765313912 -1.6767014787035512 0.9206465781685556 -1.7005774752522538 1.0000000000000000
167c167
< LSC_DARM 8 12 8 16384 0 vStop0,1 0.9393306641627603 -1.9479818388350045 0.9800449573887594 -1.9633364657747414 0.9999999999999999
---
> LSC_DARM 8 12 8 16384 0 vStop0,1 0.7461341489699668 -1.9479818388350045 0.9800449573887594 -1.9633364657747414 0.9999999999999999
jeffrey.kissel@opsws5:/opt/rtcds/lho/h1/chans/filter_archive/h1omc$ tconvert 1116981165
May 30 2015 00:32:29 UTC
I don't know why the most recent two files see nothing when diffed.
As for the previous load: the violin notches in LSC-DARM have no gain normalization factors. There's nothing illegal about this, but it is bad filter hygiene. Together these two filters give almost 4 dB of attentuation to the entire loop.
I fixed this, loaded the coefficients, but then decided that maybe it was not a good idea to change the DARM gain while Kiwamu and Jeff were trying to calibrate the loop. So I unfixed it and loaded the coefficients again. That's why you see these coefficients disappear in the diff posted above.
Tonight I followed up on the work that Stefan & I started two weeks ago, and switched the power-up step in the Guardian to come after the transition to DC readout.
Now, the OMC is locked at 2.3W input power, DARM offset = 3.7e-5 counts / 52 pm. These settings were chosen to provide 20mA at the DCPD Sum. At the transition to DC readout, the overall OMC-READOUT_ERR_GAIN is set to match the DARM gain on AS_Q, and the power normalization is absorbed by the OMC-READOUT_PREF_OFFSET, as Stefan described in the earlier entry.
During the INCREASE_POWER step the DARM offset (which after the handoff is set via OMC-READOUT_X0_OFFSET, in picometers) is stepped down to maintain the same photocurrent out of the DCPDs. This *should* maintain the DARM gain through the quadratic scaling of DCPD Sum as a function of DARM offset...but it's not perfect. I tried this twice today, and after the power-up finished, the DARM loop gain was too low by 30%. Not sure if this is due to the initial gain matching before the handoff (this step still needs some work, maybe a tdssine measurement would be better), or some non-quadratic change in the response as we go from ~50pm to 16pm. Stefan, Keita and I observed a small static fringe offset, we should make a careful measurement of DCPDSum vs DARM offset to check that what we think is quadratic really is.
We believe this arrangement is an improvement, because locking the OMC and transitioning to DC readout is more robust at low power, and also I suspect the power-up is more stable on DC readout. I have increased the PSL waveplate velocity during the power-up (now it's 20, it was 10, not sure about the units), this worked without any trouble. I am leaving the IFO locked at 23W in the LSC_FF state, with the intent bit set to "Undisturbed." The range says 65Mpc - could it be true? Earlier tonight there was a slow angular drift that killed a 23W lock, I am not sure how long we will last. Also the ITMX oplev loop is ringing for quite some time after each lockloss, it may be a challenge for the IFO to relock on its own.
A screenshot of the new guardian sequence is attached. I committed the ISC_LOCK.py code before and after the change. I tested the new sequence twice without a hitch.
ITM oplev damping is now automated in the guardian. The down state turns the damping off. The LOCKING_ARMS_GREEN state turns it back on.
Jeff, Kiwamu,
This is a summary of the calibration of the ETMY suspension responses (in meters/counts) using the ALS diff VCO.
I have not evaluated systematic errors. The errors in this summary includes only statistical errors. The "models" I mean in this alog are the ones generated by the generate_QUAD_Model_Production matlab function in the suspension SVN. The model uses the "nominal" ESD force coefficient of 2e-10 [N/V^2]. The below is a summary of the results.
- - -
ETMY ESD is weaker than the model by 0.4242 +/- 0.0030
ETMY L2 is stronger than the model by 1.0344 +/- 0.0074
ETMY L1 is stronger than the model by 1.0269 +/- 0.0083
ETMX ESD is stronger than the model by 1.187 +/- 0.012
- - -
As for the ESDs, in terms of the force coefficient, they can be translated as
ETMY ESD force coeff. = 8.484 e-11 +/- 6.0e-13 [N/V^2]
ETMX ESD force coeff. = 2.374e-10 +/- 2.3e-12 [N/V^2]
[ETMY suspension responses]
I start from the results. See the attached two plots shown right below:
The first plot is a comparison of the measured response of all three stages with the models in units of [m/cnts]. Here "cnts" refers to the digital counts at the output of the ETMY_L1(2, 3)_LOCK_L filter bank. The second plot shows the ratio between the measured and modeled transfer functions. They are ratio of (measured) / (model). As you can see, the L1 and L2 stages agree with the model qualitatively. On the other hand, it is very clear that the ESD of ETMY is much weaker than what model predicts by a factor of 0.42. We don't know why this is so weak, but this is consistent with what the MICH free swing test says (see Jeff's alog for more details). Also, the L2 stage showed a phase lag of roughly 10 degrees. We don't know why at this point.
The steps for getting these results are something like the follows.
If the ETMY ESD was stronger and as strong as that of ETMX, the steps in full lock are unncessary because we could measure it in the ALS diff configuration. However as we learned (see alog 18656), the low-voltage ETMY ESD needs a low-noise configuration. Note that the measured responses in full lock are also used in Jeff's analysis which had started from free-swing MICH fringes. Also, from the point of view of data points, we probably can go up to about 20 Hz at which the ALS diff signal is completely covered by some sensor noise. This time the frequency bins are chosen such that we can share them with the MICH calibration technique which was severely limited to frequency below 7 Hz due to high semsor noise in the simple MIchelson configuration.
As for the statistical error analysis, we used:
For comparing the measured responses with the models, we assume that the models and measurements have the same transfer function shapes and therefore the scaling factor is the only parameter we estimate. Though, this assumption may not be true because we see a large differenence in the phase of the L2 stage.
For completeness, I attach all the relavant measured responses:
The ETMY suspension states (for all the measurements):
[ETMX ESD response]
At a different time, we measured the response of the ETMX ESD using a similar technique to the ETMY measurement. The steps went as follows.
Since the ETMX ESD does not use a low-voltage driver, the measurement can be complete only with the ALS diff loop closed. This is a big difference from the ETMY measurement which required low-noise stage for accessing the ETMY ESD.
The two plots shown below are the main results.
As shown in the first plot, overall, the measuement qualitatively agree with the model. The second plot shows the ratio of (measured) / (modeled). The absolute magnitude was larger than what the model predicted by a factor of 1.19. As mentioned earlier, the model uses a force coefficient of 2e-10 [N/V^2]. Unlike the ETMY ESD, the phase deviation (or perhaps I should say phase lag) is a bit larger than that of the ETMY for some unknown reason. The error propragation was done in the same fashion as that of the ETMY measurement (i.e. we included only coherence-based errors and VCO calibration error).
ETMX ESD configuration:
For completeness I post all the relevant transfer functions:
[ALS diff VCO calibration]
On this past Tuesday, Dick and I measured the VCO response. We hooked up an IFR 2023 A which was synchronized to a 10 MHz rf signal (which is synchronized to GPS) to the diff PLL input or the PFD rf input with an amplitude of 0 dBm in order to simulate the beat note signal. Even though we could read out the display of the IFO 2023A, we used an external frequency counter (H1:ALS-C_DIFF_VCO_FREQUENCY) which should be at least as accurate as 5 Hz (see for example alog 6972). We locked the PLL loop and manually swept the frequency of the IFR until the PLL unlocks. The speed of the sweep was roughtly 25 kHz/minutes. Then we recorded the output of the DIFF_PLL_CTRL filter bank. One thing we have to pay attention is that this filter already contaied calibration filters which were meant to calibrate the VCO into microns, but as we measured the calibration factor was wrong by roughly a factor of 3.
The setting for DIFF_PLL_CTRL
In theory FM3 should cancel the pole and zero at 1.4 and 40 Hz respectively in the VCO circuit. The meaured data is shown in the plot right below:
The data was then trancated such that the center frequency is located at 78.92 MHz with a range of +/- 30 kHz for a linear fitting purpose. Also, since we made a linear fitting at around 78.92 MHz, in any of the calibration measurement we tried to be as close as possible to this frequency by engaging the slow frequency couter servo to the ALS diff VCO, According to the fit the coefficient was of VCO -> PLL_CTRL was esimtimated to be 4.78268e-6 +-/ 0.002531e-6 [cnts/ Hz] using a least square fitting of gnuplot. These numbers were used for calibrating the ETM responses and estimating the errors.
Finally I attach a zip file which contains all the data (in ASCII not in xml), analysis codes and figures.
Now, all the relevant codes, data, xml templates and figures are checked in svn with more appropriate and organized names. They can be found in :
aligocalibration/trunk/Runs/PreER7/H1/Scripts/AlsDiffaligocalibration/trunk/Runs/PreER7/H1/Measurements/AlsDiffaligocalibration/trunk/Runs/PreER7/H1/Results/AlsDiffJeff asked me to turn the actuator responses into meter/counts at DC (techniqcally speaking at 1 mHz). Here are the numbers:
- - -
ETMY L1 = 5.150e-11 +/- 4.1e-13 [m/cnts]
ETMY L2 = 7.007e-13 +/- 5.0e-15 [m / cnts]
ETMY L3 = 6.432e-15 +/- 4.9e-17 [m/ cnts]
ETMX L3 = 3.593e-13 +/- 3.5e-15 [m/cnts]
Dan, Evan, Sheila
Tonight we started to look at the angle to length couplings of our test masses. We injected lines into pitch and yaw on the PUMs, and adjusted the A2L gains to minimize them. Using the math in the 40 meter alog and Jax's alog, we can estimate the miscentering from these measurements
| Gain P2L | vertical miscentering (mm) | Gain Y2L | horizontal miscentering (mm) | |
| ETMX | 1.6 | 21 | 1.1 | 14.4 |
| ETMY | 0.69 | 9 | -0.3 | -3.9 |
| ITMX | 2.4 | 31.5 | 1.15 | 15 |
| ITMY | 1.5 | 19.7 | N/A (-1.7 to -2) |
After we had adjusted these, we saw an improvement in the spectrum below 20 Hz. The line in the attached screen shot at 16.6 Hz with sidebands at half a hertz are the excitation. Keep in mind that this is on the new ESD driver and we haven't redone the calibration yet, but clearly this improved the noise below 20 Hz.
Earlier in the evening we were having difficuulty powering up because of a pitch instability at the main suspension resonant frequency that showed up in all the test masses. We moved the QPD offsets for pitch back to what they were may 15th, (they had been changed last tuesday). We then remeasured the miscentering for pitch only, things were a little bit better. Once we increased the power to 17 Watts, the IFO was stable and we repeated some of the measurements. We were able to power up to 23 Watts without seeing the instability twice, but lost the lock quickly for other reasons.
| Gain P2L | vertical miscentering (mm) | 17 Watts P2L | ||
| ETMX | 0.7 | 9.18 | 0.8 | |
| ETMY | -0.57 | -7.5 | -0.49 | |
| ITMX | 2.1 | 27.6 | 2.4 | |
| ITMY | 1.2 | 15.7 | NA |
DARM OLTF file attached. This template has reduced drive strength so that the ESD does not saturate in the LVLN state.
At last I was able to switch the DARM actuation over to ETMY at 25 W with the LPF engaged on the LVLN driver. We had discovered that the L1 LOCK filters on the ETMs were charging up because of small amounts of ringing in the lower stage filters. Therefore, the L1 filter for ETMX is zeroed after actuation is moved to ETMY, and the lock filters for ETMY are cleared after lockloss. Also, the INCREASE_POWER state now automatically increases the power to 25 W once again.
I tried the LOWNOISE_ESD_ETMY state at 25 W once, and it seemed to work. I then turned on some pieces of the LSC_FF state (namely the SRCL gain reduction, the SRCL cutoff, and the MICH FF). I am leaving the IFO locked with the intent bit undisturbed.
One last note: the power was 3 Watts in the spectrum attached, and to repeat, the calibration is not updated since the actuator change. They're working on it
The displacements in mm are wrong here, we were measureing from the PUM.
Another DARM OLTF, this time with the ETMY LPF off.
There are two DARM Open Loop Gain TFs attached as comments to this entry that represent the first two DARM OLGTFs taken with the new low noise ESD driver and the new L1L2L3 hierarchical control scheme. I've downloaded them and submitted them to the CalSVN for use later: - From LHO aLOG 18662, DcDarmLVLN.xml, measured starting 2015-05-28 13:17:00 UTC, has been copied to /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements/DARMOLGTFs/2015-05-28_H1_DARM_OLGTF_LHOaLOG18662_ETMYL3LPON.xml - From LHO aLOG 18709, DcDarmLVLN.xml, measured starting 2015-05-30 03:07:00 UTC, has been copied to /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PreER7/H1/Measurements/DARMOLGTFs/2015-05-30_H1_DARM_OLGTF_LHOaLOG18709_ETMYL3LPOFF.xml. I attach conlogs of all relevant DARM filter banks and BIO switches, where the date in the file name corresponds to each measurement.
Dan, Kiwamu, Evan
List of things done today:
This attachment shows the comparison between ETMX and ETMY L3 drives. Here the interferometer is locked using ETMX. For ETMY, offloading is disabled, and all shaping is disabled except for the LPF and summing network compensation. A gain of −50 has been inserted in ETMY L3 L2L.
