(Kyle, Gerardo)
We pumped the annulus system for 4 hours, we got down to 5.0X10^-5 torr at the pump cart. Pumping will continue on Thursday.
Kyle, Gerardo Accessed BSC3 annulus ion pump via Genie snorkel man lift -> Used high output high voltage supply (60 mA) in an attempt to burn up internal shorting element without success -> Removed and replaced ion pump -> will pump with all day on Thursday maintenance with pump cart
Scott L. & Ed P. Cleaned and vacuumed all beam tube supports from single door south to X-1-4 double door. Cleaned 34 meters of beam tube in the same direction. Continuous monitoring of beam tube pressures by the control room operator and regular checks by the vacuum crew.
(Times are in PST)
602 P. King - Running transfer function measurements with H1 PSL ISS
713 P. King - Finished
730 Karen, Cris - LVEA
745 Jeff - LVEA to work on storage boxes
804 Andres - LVEA to meet up with Jeff
851 Doug, Bubba - LVEA
852 P. King, Ed M., Jason - PSL
857 Corey - To Squeezer Bay and Mech Room
901 Nutsinee - ETMY
908 Filberto - LVEA by the Y arm
915 Betsy, Gary, Guido - West Bay
919 Matt H. - LVEA Looking for 3IFO parts
933 Travis - Meet up with Betsy
934 Nutsinee - Back from EY
940 Dave B. - LVEA 3IFO Inventory
943 Greg - LVEA to find parts
946 Karen - To EY
946 Cris - To MX
952 Kyle, Gerrardo - LVEA to start the annulus pump on HAM1 and to use the snorkel lift by BSC3
954 Hugh - Opening large equipment access door in LVEA
959 P. King, Ed M., Jason - Out of PSL
1000 PraxAir - Delivery
1025 Mitchell - West Bay
1039 Richard - Out of EY Vac Supply Room Emergency Egress
1057 Karen - Leaving EY
*1114 Kyle, Gerrardo bumped BSC3 with genie lift (tripped WD)
1117 Filberto - MY to drop off cables
1120 Kyle - Banging annulus pump with hammer
1125 Mitch - Out of W Bay for lunch
1146 Andres, Jeff - Out of LVEA for the day
1159 Corey - Out of the Squeezer Bay for lunch, will return after
1202 Dave B. - DAQ restart
1203 Gerrardo - EX to pick up parts
1230 Gerrardo - Back from EX
1305 Cris - To EX
1311 Gary - LVEA
1345 Mitchell - To West Bay
1417 Jeff - LVEA
1435 Jeff - Out
1441 Sudarshan - To EY
1442 Travis - Both Mids
1501 Mitchell - Out
1507 Travis - Back from Mids, to LVEA
1515 Matt H., Eric - LVEA
1517 Corey - Out of SB
1557 Matt H., Eric - Out of LVEA, to Mids
Friday morning Jim and I unlocked WHAM1 HEPI and closed the position loops. It looks like this reduces peaks at 2.5 & ~3.75hz, may have some gain peaking reinjection around 1hz and shows good pitch & yaw motion reduction below 1hz as seen by the RM1_M1_DAMP IN1s.
The attached ASD shows the RM1_M1_DAMP_L/Y/P_IN1_DQs. The lower plot group has a couple HAM1 L4Cs. The thicker light colored reference traces are from Thursday 0800utc and the dark thin current traces are from Saturday 0800utc. There is a peak in the RMs at 6hz that may be amplified in the current traces; it is hard to tell but the ISI may be amplifying that peak.
J. Kissel, H. Radkins A little more information, after discussing this with Hugh. - Recall that the H2 L4C is busted -- I've just opened an Integration Issue about it (see II #1022), but it's been confirmed busted as early as Oct 2014 (see LHO aLOG 14249). This means that we can't necessarily trust the X, Y, or RZ spectra -- matrices have not been recomputed to account for the dead sensor. - Recall that the RMs are on top of the HAM1 stack. The best information about the predicted performance of the 3-layered, viton cork, HAM1 stack is Peter's note, T1000310. This suggests that the horizontal stack resonance might be around 2.5 [Hz], and 7 [Hz] in vertical. I haven't been able to find any plots showing the predicted transmission. - Recall that RM1 and RM2 are oriented in such a way that there longitudinal direction is roughly aligned with the IFO's X direction (see D0901821). - Recall that RM1 and RM2 are HTTS's or Tip Tilts. They're longitudinal/pitch resonant frequencies are modeled to be at 1.3 / 1.6 [Hz], and have built in eddy current damping to control Transverse, Vertical, and Roll. The vertical mode is at 6.1 [Hz]. Transfer functions can be found modelled in T1200404. - The HTTS have BOSEMs for sensors, whose expected noise floor is roughly 6e-11 [m/rtHz] above 10 [Hz]. Scaled properly to Longitudinal, with four sensors, that's sqrt(1/4)*6e-11 [m] = 3e-11 [m/rtHz]. - OSEMs, in general, are *relative* position sensors. That means below the resonance of the SUS, the response to displacement falls off at lower frequencies as f^2, because there *is* no relative displacement between the sensor and the target. - We don't really expect that much information in P and Y on the RMs, with respect to the motion of the center of mass of the table. Maybe we can gleen some information from Yaw, but given that they're close to the edge of the table, it might be a good bit of transverse motion showing up... what I'm really saying is that these DOFs will be too messy to discern a good, diagonal, Cartesian, coupling mechanism. - The above data was taken with HAM1 either at air, or half-air -- some transient state of the HAM1 vacuum system. Further both of Hugh's spetra were taken at 08:00 UTC, which is midnight PST, which is well before the time when we can rule out the commissioning vanguard messing with/aligning the RMs and or having the RMs affected by locking transients. All the above being said -- I took some data two hours after each of Hugh's measurements -- i.e. 10:00 UTC, or 02:00a PST on Feb 26 2015 (when HEPI was locked) and on Feb 28 2015 (when HEPI was unlocked, position controlled with sensor correction ON -- LHO aLOG 16983 indicates the rapid turn on happed on Feb 27th). - I don't see nearly as much of a change in performance between the two times - I don't see the features at 2.5 and 3 [Hz] in either data set - One can argue that we see the 1.3 / 1.6 [Hz] modes of the suspension -- and *maybe* the well damped modes of the stack at 2.5 [Hz]. - We can *definitely* see the HTTS V mode at 6.1 [Hz]. There's a feaure just below this in the HEPI L4Cs -- but I don't think it's related to the HTTS mode - One could easily argue that the difference in motion between the HEPI locked vs. HEPI unlocked and ON between 0.5 and 5 [Hz] is the day-to-day difference in ground motion. - The BOSEMs on RMs 1 and 2 are meeting or beating their predicted sensor noise at ~20 [Hz] and above. I don't understand how RM1's noise can be so far below the prediced sensor noise below 0.1 [Hz] -- I don't trust it. - There is still ample coherence between 0.1 [Hz] and 10 [Hz] between the HEPI L4Cs and the BOSEMs. I think bother the lower and higher frequency edges where the coherence drops off is because the sensors get buried in their sensor noise, not because the real motion ceases to couple. Remember Jim has some data (see LHO aLOG 16983) that also shows ambiguous performance. He's got some more this morning with sensor correction ON vs. OFF, and will post later. So -- data is still fresh -- lots to think about -- lots of room for improvement.
Last night lock in DC readout lasted about one hour, with good stability of build ps on the on term. However, looking at the noise spectrogram, one can find some interesting non stationarities. The first plot is a spectrogram of the high frequency part, which is mostly stationary, except for a line at about 5 kHz which seems to ring down during the lock.
Between 800 and 1000 Hz we've always seen two broad peaks, see the second attached spectrogram. Those peaks are usually high at the beginning of some locks, and gets lower. Out first guess was that they get better because the alignment is improved. However, during last nigh lock there was no human intervention to improve the alignment, and the two peaks got smaller with a time constant of about 15 minutes. It seems unlikely that they are mechanical modes ringing down, since they are too broad. There seems to be some correlation with a much narrower peak at 300 Hz: this peak roughly decay with the same time constant.
I ran my brute force coherence, and remarkably there isn't any signal showing any significant coherence with the twin peaks.
The noise in the 100-300 Hz region is still non stationary, altough the situation is much better than before (closing DHARD with high gain helped). The third plot is a spectrogram of the region, showing the noise moving up and down in amplitude.
The fourth plot shows the band-limited RMS in the region between 100 and 200 Hz, after notching out the 120 and 180 Hz main lines. The blue trace is the measured BLRMS, while the red trace is the least square fit to it using all mirror local sensors (ETMs, ITMS, PR*, SR*, BS). The reconstruction is quite good, at least for most of the slower variations. Using the same kind of code described elsewhere, I produced a list of the channels ordered from the one that contributes most to the one less important. This is shown in the 5th attachment. The channels are listed in order of descending importance. The blue bar shows how much each channel contributes to the BLRMS fluctuations. It seems that most of the noise non stationary is caused by residual motion of the SRM and PRM.
Another way to look into what is causing the residual angular motion is to use directly the ASC signals instead of the local sensors. The advantage is that ASC signals should be much cleaner than the local sensor. The drawback is that it's more difficult to trace back to which angular d.o.f. is important. The 6th and 7th attachments shows respectively the BLRMS fit and the channel ranking using the ASC signals. First of all, the reconstruction of the BLRMS fluctuations seems to be more accurate. It looks like that most of the BLRMS fluctuation can be related to AS_B_RF45_Q_YAW, including both the linear and quadratic terms. This signal was not used for any ASC loop (we are using AS_A_RF45_Q for DHARD). This is a bit surprising, since the BLRMS fit using local sensors pointed to a picth motion as he largst contribution, while the ASC signals point to a yaw motion...
Looking again the the low frequency histogram (third attachment), there are at least two narrow lines that slowly move in frequency. They are at about 168 and 249 Hz. It seems to me that they move in a correlated way. They might be generated by some fan or other spinning electromechanical device. I can't find any coherence with environmental channels, but the lines are coherent with SRCL and LSC-POP_A_RF45_I
As part of the WFS auto-centering ECR and the EOM Driver ECR a couple of new channels were added:
Since the hardware is still in manufacturing, this currently connects to nothing.
J. Kissel, D. Barker, Hearing about LLO's miss-hap with an Dolphin PCIE, IPC error causing an errant ISI watchdog trip (LLO aLOG 17036) I was reminded of when Dave and Vincent had implemented an allowance for (what they thought was) 10 [errors / sec] during the H2OAT when such errors were triggering these types of false alarms all the time (see LHO aLOG 5373, or in WP 3698). Poking around the BSC-ISI models to see if any of that was still implemented (since it was all implemented at the top-level of the model, not a part of any library), I found that ISI ITMY still has some of this residual stuff, but the other 4 BSC-ISIs do not. Check out the first attachment for how it's implemented for ISI ITMY: -- the error rate spigot is fed into a comparator with a constant 150, and the output of the comparator is fed into the ISIPAYLOAD block. But this is sort of bogus. You cal tell that the *idea* was to send an error if the rate (in [errors/sec]) was higher than 150. But in the front end, running at 4096, the errors per *second* will either be 0 or 4096, and it's unclear what happens on a cycle-by-cycle basis. I like the idea, but the implementation doesn't really make sense. The second attachment shows the beam splitter's implementation, which is identical to the other 3, non-ITMY chamber's implementation -- and to how LLO has theirs implemented. The error rate is inverted, which means if the error rate zero, the payload block gets a 1 (for "running" or "OK"), and when the error rate is non-zero, the payload block gets a 0, and trips the payload flag because it thinks the model is 0xDEADBEEF. This is an OK implementation, but it only is really useful for that use case scenario, where the SUS model is permanently down, AND it's bad for the use case where there's a single drop in communication in any cycle within a second. Then I check to see what the HAMs are doing. Hooray! Something different! These guys have a block that I'd never seen before, an "ISI_RFM_ERROR_CONVERTER." This a part of the ${userapps}/isi/common/models/isipayloadwd.mdl library, which has the following helpful note above it: "Dolphin RFM error logic inverter. ISIPAYLOADWD is coded to work with EZCAREAD parts which use 0 for not connected, and 1 for connected. Dolphins RFM error channel reports errors per second so 0 is good (no errors) and or more is bad (up to the rate the code is running at)." Inside is a choice block, which passes 0 if the error rate from the IPC block is greater than 0, and 1 otherwise. So, this is really just a glorified version of what's implemented on the non-H1ISIITMY BSC chambers at LHO and LLO. And the same use-case flaws apply. We should (a) Make sure all chambers at both sites are doing the same thing, and (b) Allow for more than one cycle's worth of errors -- infact allow for several seconds worth of errors -- before tripping the ISI via the payload flag's IPC connection failure.
Added 128 channels. Removed 91.
Yesterday, after our snapshot fest from last week, I pushed all of the SUS safe.snap files to SDF. I then cross referenced a bunch of the ISC/LSC/ALS/IMC guardians and hand-tuned out channels that are already being monitored by them. There are still 2-6 channels showing differences on 6 of the SDF SUS monitors. I'll look at what commissioning is doing to either remedy or ignore them.
I've committed all of the sus safe.snaps to svn.
Reset the following HEPI L4C WD counters for normal Tuesday practice:
HAM3
HAM4
HAM5
ITMX
BS
ITMY
Attached is a picture of before the reset.
Bottom Line--When using Guardian, engaging the RZ loop twists the MICH too far. It may be doing the CPS Offset zeroing in a weird method. When the loops are engaged with the old Command Scripts, the RZ input does not get driven off and no bad RZ twist occurs.
Further, with MICH locked, the X & Y ST2 ISO loops are not stable--they ring up and trip. Without Mich Locked, the loops are stable.
Details: Let's start with the first attachment; it is 25 minutes of second trends. The Guardian turns on the Z loop after first LOAD_CART_BIAS_FOR_ISOLATION so this is the first thing to do. Manually one can do this on the CART_BIAS screen (Reset CPS offsets button.) In outward appearances, there is a difference in how this button and Guardian perform this operation; however, Jamie says no it doesn't. Maybe it is the slow ramping of the new setpoint. Anyway, my observation is that the residuals for this platform are always small. After the CPS offsets are Reset, the Guardian turns on the Z dof. The gain steps and the ramp times are the same for the Command Scripts and Guardian.
Using the Command Scripts, engaging the Z dof ISO is seen at point 1. Notice how at point 2, the RZ INMON is not doing anything awful while the Z loop is turned on and the RZ loop turns on (point 3) nicely and well behaved. However, when Guardian does this...
When Guardian turns things on at point 4, look at what happens to the RZ INMON. The Z_OUT16 is much larger when Guardian turns it on and the RZ_INMON is driven way off. And, even though the RZ_INMON is much lower by the time the RZ loop comes on, turning on the RZ loop at point 5 produces a too large an output--The RZ_OUT16 looks just like the OpLev Yaw.
You can see that the manual turn on of the Z then RZ loop was repeated a few times with the same result; like wise the Guardian turn on was similarly consistent. Of course, Guardian also turns on the X & Y DOFs when it engages the RZ loop and as I allude to in the summary above, these loops may be unstable. However, at this point I return you to the point of how the Z_OUT is so different for Guardian and how that impacts RZ_INMON all before the X Y & RZ loops are engaged.
I left the ST2 in fully isolated and later Ellie locked the MICH. After a minute or so, it didn't look stable and MICH was turned back off. Shortly after that the ISI tripped. So then we tested things. Ellie locked MICH and then I engaged the ST2 ISO Loops. Things were fine with the Command script turn on of Z and RZ but the ISI slowly rang up and tripped on either X or Y DOF even without the boost on.
Solution--Identify why the Command Script and Guardian do something different at the CPS Reset stage. Identify the loop instability.
This might be the MICH controllers beating on the ISI. I've attached a 4 page pdf, taken at t=0 is at GPS=1109443997 I think what is happening is: 1) ISI st2 X and Y ISO loops are off 2) MICH control gets turned on, and starts injecting lots of noise onto the ISI table 3) ISI isolation loop X (or Y) gets turned on, much higher BW than damping loop. 4) ISI iso loop tries to suppress the ISI motion. but the high freq motion is too big, and the actuators start saturating 5) after a few seconds, the WD trips. evidence: pg 1) The H1 actuator drive signal, it starts ramping up at ~T=65 seconds. the drive is getting bigger, but not in a classic oscillation sort of way. It grows to about T=72, then sort of levels off, until it gets tripped about T=82. pg 2) The WD state, at about T = 82. pg3) the GS-13 for X, pretty noisy, doesn't change as the loop comes on or when it turns off. - Implies that the main driver for the GS-13X is not the X isolation loop. pg4) Detail of the drive signal. not like a classic oscillation.
model restarts logged for Sun 01/Mar/2015
no restarts reported
model restarts logged for Mon 02/Mar/2015
2015_03_02 05:42 h1fw0
2015_03_02 12:01 h1broadcast0
one unexpected restart. DAQ broadcaster started to add 3 channels for DMT.
The DAQ broadcaster was configured to add 3 channels on Monday (the h1broadcast0 was restarted) and 1 channel today (pending full DAQ restart later).
Monday's channels:
Tuesday channel:
P. King, J. Oberling, E. Merilh
Summary
We went in to the H1 PSL this morning to touch up the FSS RefCav alignment; it had started to drift again. We checked 4 mirrors (M24 - M27) to see if their pitch adjustment screws were locked; we found M26 and M24 to be loose. Adjusting the pitch of M26 had no effect on the RefCav TPD voltage (and therefore we don't believe this mirror is the problem), but adjusting M24 pitch we were able to recover the RefCav TPD voltage to ~1.6V. Both adjustment screws were locked. We measured the power after WP4 and WP6, and measured the DC voltage of the RefCav Refl PD (RFPD) with the FSS locked and unlocked. We are going to continue to monitor the FSS RefCav TPD to see if the loose adjustment screw on M24 was the cause of our drift.
Details
At around 11:00pm PST on 2/27/2015 (last Friday) the RefCav TPD began to drift down again. By yesterday afternoon it was down to 1.1V (this roughly corresponds to ~11mW in the ALS beam path, see Peter's comment to alog 16887). This time we did not adjust the RefCav input periscope mirrors, since we adjusted and tightened them last time. We decided to look for unlocked pitch adjustment screws for mirrors in the FSS path, since the alignment adjustments we have been doing previously have been almost entirely in pitch. We started at M27 and worked back to M24 (see the PSL table layout in D0902114 for mirror locations).
We are going to continue to montior the RefCav TPD voltage to see if this loose adjuster screw on M24 was the cause of our drift.
After this adjustment we measured the laser power after WP4 (before the FSS AOM) and after WP6 (before the RefCav input periscope):
We also measured the DC voltage of the RefCav RFPD with the FSS locked and unlocked.
J. Kissel While poking around the CAL-CS model after the recent changes (see LHO aLOG 17034), I noticed two things: (1) All of the EPICs settings had been lost, even though I'd made sure to capture a safe.snap of the model before restarting the front end model. Not sure what happened there. In the mean time, I've burtrestored the model to 02:10a PST (i.e. before I got started, while DARM was locked, happy, and producing megaparsecs), which hopefully has captured / restored most of Kiwamu's hard work (LHO aLOGs 16698, 16733, 16780, 16798, and 16843). (2) Because of a version control mix up in the CAL_CS_MASTER.mdl library part, the names for the whitened versions of the closed-loop and open-loop DARM displacement signals, i.e. (what are now) H1:CAL-CS_DARM_RESIDUAL_WHITEN and H1:CAL-CS_DARM_DELTAL_EXTERNAL_WHITEN have changed since we last updated the h1calcs model. The bank names are now typo free -- but that means I've had to re-install the 1^5 : 100^5 (5 zeros at 1 [Hz], 5 poles at 100 [Hz]) whitening filter used to get above the double precision noise in frame storage (see LLO aLOG 16789). Maybe I'll ask my fellow detector engineers to help me get an SDF system up and running for this model, so we can better track the changes.
J. Kissel I've figured out what happened: when capturing the h1calcs safe.snap, I used the canned script /opt/rtcds/userapps/release/cds/common/scripts/makeSafeBackup which writes the output .snap file to the sanctioned location in the userapps repository. HOWEVER, because the h1calcs.mdl is relatively new, we (read as: ME, when I installed it) didn't remember to replace the automatically generated safe.snap file, here /opt/rtcds/lho/h1/target/h1calcs/h1calcsepics/burt/safe.snap with a soft link to the sanctioned userapps location, /opt/rtcds/userapps/release/cal/h1/burtfiles/h1calcs_safe.snap Perhaps I had gotten complacent, because I had thought that makeSafeBackup *makes* the softlink if it doesn't exist. But, looking at the code line-by-line, it may try to make the code, but if your account account doesn't have permission to *remove* a file created by controls (because we're forced to compile and install on the front-ends as controls), then it doesn't overwrite the file and create the softlink. Whichever, excuses, excuses -- I missed it. I've now (a) created the softlink by hand, (b) captured a NEW safe.snap to gather all of the new channels I added with the IMC/CARM upgrade as well as the typo-fix to the DARM channels, (c) ran an sdf_set_monitor over the entire file (d) pushed the "monitor all channels" safe.snap to the front end via the SDF system -- i.e. hitting the "load table only" button, because the "safe" is the file chosen by default to define the table, (e) confirmed there were NO channels unmonitored, and the only channels that show an error are some hardware injection channels that show up because of a known bug in the parsing of string channels, and (e) committed the newly SDF tagged safe.snap file to the userapps repo As I (or someone else) continue(s) to fill out the infrastructure for IMC and CARM, (and eventually MICH, SRCL and PRCL) we'll update the data base accordingly, but I don't expect DARM to change much for the forseeable future.
J. Kissel I'll file an aLOG later about the philosophy of design as I create the MEDM screens and fill out the infrastructure, but for now I'll indicate that I've completed the model / DAQ restarts necessary to install the infrastructure updates to the IMC / CARM calibration paths in the h1lsc, h1omc, h1susmc2, and h1calcs front-end models. A detailed log of what I've done is below. I've restarted the DAQ at ~07:31 UTC. - brought ISC LOCK and IMC LOCK guardians to DOWN - saved SUS MC2 alignment offsets - brought SUS MC2 to safe state - captured and committed safe.snaps for /opt/rtcds/userapps/release/ sus/h1/burtfiles/h1susmc2_safe.snap << -- used SDF system, following instructions in LHO aLOG 16949 lsc/h1/burtfiles/h1lsc_safe.snap << -- used "makeSafeBackup lsc h1lsc" omc/h1/burtfiles/h1omc_safe.snap << -- (as above) cal/h1/burtfiles/h1calcs_safe.snap << -- (as above) - compiled and installed relevant front-end models on h1build make h1lsc; confirmed success; make install-h1lsc; confirmed success; make h1omc; confirmed success; make install-h1omc; confirmed success; make h1susmc2; confirmed success; make install-h1susmc2; confirmed success; make h1calcs; confirmed sussess; make install-h1calcs; confimed success; - h1lsc has an IPC error before getting started, but cleared and stayed clear after diag reset (no other models had IPC errors reported) - brought HAM3 SEI to OFFLINE (with a spurious GS13 watchdog trip along the way) - restarted relevant front-end code on h1lsc0 -- cdsCode; starth1lsc This lit up the CDS overview with IPC errors as expected, on h1omc, oaf, lscaux, asc, ascimc, and the globally controlled sus (the MCs 1-3, PRs M&2, SRs M&2, BS, OMs, RMs, and TMs). Decided to complete model restarts before clearing errors. on h1omc -- starth1omc on h1calcs -- starth1calcs released the model still needs new IPC senders from MC2 before its IPC errors go away on h1sush34 -- starth1susmc2 on h1oaf0 -- starth1calcs - Hand-cleared all IPC error messages with a diag reset on all affected model's GDS_TP screens; confirmed no lingering errors were present. - cleared SUS MC2 and ISI HAM3 watchdogs from SUS model restart - brought HAM3 SEI up to ISOLATED (accompanied by another spurious GS13 watchdog trip) - brought SUS MC2 to ALIGNED - brought IMC_LOCK guardian back to LOCKED, confirmed successful relock of IMC, appearance of light on AS port in the same camera position it was when I got started - shutdown DAQ / FB / h1dc0 at 07:31 UTC to clear remaining DAQ errors; confirmed the only remaining error is from h1oaf model, who is now missing some CARM / IMC senders - committed all model changes to the userapps repo, ${userapps}/lsc/h1/models$ Sending h1lsc.mdl ${userapps}/omc/h1/models$ Sending h1omc.mdl ${userapps}/sus/h1/models$ Sending h1susmc2.mdl ${userapps}/cal/common/models$ Sending CAL_CS_MASTER.mdl ${userapps}/cal/h1/models$ Sending h1calcs.mdl Committed revision 9944. DONE!
J. Kissel, K. Izumi
What have I changed in the models?
LSC Model, lsc/h1/models/h1lsc.mdl (and omc/common/models/lscimc.mdl)
-- Inside the IMC (library) block,
- removed obsolete GUARD block (which removes many, now unused EPICs channels from the lsc model)
- removed obsolete FRINGE block (originally thought to be used to count the number of fringes passed in a given computation cycle,
never used in practice)
- removed redundant shipping of IMC L control signal from surrounding the IMC-MCL path, which now needs only be picked off of MC2
- removed now unnecessary flags between IMC-L / IMC-TRANS and IMC-MCL paths
- installed new spigot for shipping IMC common mode board's error signal (which starts as the "IMC-I") to CAL-CS front end model
-- Top-level
- removed all instances of IMC L control signal IPCs to cal CS model
- installed new IPC for IMC common mode board's error signal, called H1:LSC-CAL_IMC_ERR
- renamed IPC for digitized fast control signal (typically called some form of IMC-F) to H1:LSC-CAL_IMC_F_CTRL
OMC Model, omc/h1/models/h1omc.mdl (and omc/common/models/omclsc.mdl)
-- Inside the LSC (library) block,
- removed all spigots for CARM ERR and CARM CTRL signals surrounding the CARM bank (in the OMC model, this is really only meant for
the eventual, if necessary small corrections for CARM send to the ETMs, they'll now again, be gathered elsewhere to simplify the
calibration scheme)
-- Top-level
- installed new IPC sender for the IFO / REFL9 common mode board's error signal, called H1:OMC-CAL_CARM_ERR
- removed all former CARM ERR and CARM CTRL IPC senders
SUS MC2 model, sus/h1/models/h1susmc2.mdl
-- Top-level
- installed 3 new IPC senders for the "CTRL" output of the LOCK filters for each stage, to be fed to the CAL-CS model, called
H1:SUS-MC2_M1_LOCK_L_CTRL, H1:SUS-MC2_M2_LOCK_L_CTRL, and H1:SUS-MC2_M3_LOCK_L_CTRL.
CAL-CS model, cal/h1/models/h1calcs.mdl (and cal/common/models/CAL_CS_MASTER.mdl)
-- Top-level
- removed all former IPC recievers of various versions / pick-offs of the IMC control signals
- installed all new IPC receivers mentioned above,
Error Signals:
H1:LSC-CAL_IMC_ERR from h1lsc.mdl error signal for IMC when CARM is not locked Digitized IMC Common Mode Board signal (digitized after the sum of the two input signals)
H1:OMC-CAL_CARM_ERR from h1omc.mdl error signal for CARM when CARM is locked Digitized IFO / REFL9 Common Mode Board signal (digitized after the sum of the two input signals)
Control Signals
H1:LSC-CAL_IMC_F_CTRL from h1lsc.mdl "fast" control signal for IMC going to PSL Digitized IMC Common Mode Board signal that goes to PSL AOM, after all analog filtering on CM board
H1:SUS-MC2_M1_LOCK_L_CTRL from h1susmc2.mdl "slow", hierarchical control signal for M1 stage of MC2
H1:SUS-MC2_M2_LOCK_L_CTRL from h1susmc2.mdl "slow", hierarchical control signal for M2 stage of MC2
H1:SUS-MC2_M3_LOCK_L_CTRL from h1susmc2.mdl "slow", hierarchical control signal for M3 stage of MC2
- reconnected all of the IPCs to the newly reshuffled inputs to the CS block
-- Inside the CS (library) block
- Pulled out the CTRL signal calculation for the IMC since the sum of the FAST / F and SLOW / L is needed for both the IMC and
CARM calibration signals, depending on the configuration of the IFO. Put it in a new block called SUM_IMC_CTRL
- Pushed the output of SUM_IMC_CTRL to the now single CTRL inputs of SUM_IMC and SUM_CARM, where they're added to the respective
IMC and CARM error signals.
- Created new channels intended to be the "final answer," (though they're not yet stored in the frames, sothey don't yet have
the "_DQ" extension)
H1:CAL-CS_IMC_DELTAF (_DQ) --- open loop frequency noise for the IMC when CARM is not controlled
H1:CAL-CS_IMC_CTRL (_DQ) --- total frequency control signal sent to the IMC and PSL either when the error signal is either IMC or CARM
H1:CAL-CS_IMC_DELTAF (_DQ) --- open loop frequency noise for CARM when CARM is controlled
Gabriele, Sheila, Alexa, Evan
We have engaged the DHARD WFS Y (and P) at 3 Hz on resonance with a reduced oplev damping gain in the ETMs. Again, to start off we closed the DHARD Y WFS with 3 Hz BW at 50pm CARM offset. Since this loop is also stable at low BW, we will leave it in the low BW configuration at this point, so that we are at a 3 Hz BW on resonance.
We had tried engaging the new DHARD Y loops as described in LHO#17006. However, we quickly found that this configuration was unstable. So, we removed the partial plant inversion FM6 and took a plant TF. We found that the plant that Gabriele had measured with the oplevs was slighlty different than the @50pm plant (see Gabriele's comment). We adjusted FM6 accordingly to compenstate for the peaks seen between 1 and 5Hz. FM6 is now zpk([-0.3303+i*15.1459;-0.3303-i*15.1459;-1.9027+i*16.6711;-1.9027-i*16.6711; -0.2672+i*19.227;-0.2672-i*19.227],[-0.6659+i*18.7;-0.6659-i*18.7;-0.509+i*11.519; -0.509-i*11.519;-1.0404+i*15.4844; -1.0404-i*15.4844], 1)gain(0.469248).
To close the loop at low BW at 50pm CARM offset, we engage FM2, FM3, FM4, FM6, FM9 with a gain of 30. FM6 is described above, and the remaining filters are the same as in LHO#17006. With a gain of 360, this gives a UGF of 3 Hz and a phase margin of 36 deg.
On resoncance with a gain of 30, we measured that the UGF is 3.5 Hz with a phase margin of 36 deg.
This is in the guardian now.
In the first attached plot the blue circles show the measured DHARD plant transfer function, at 50 pm CARM offset. The red trace is a fit, which matches quite well the measurement. To be able to run the loop with a 3 Hz bandwidth and a simple controller like the one we used for pitch, we had to compensate for the two higher pole/zero pairs.
The second plot compares the DHARD plant measured today at 50pm using the ASC signals, with the one I measured on Saturday using only ETMY and its optical lever. They are clearly quite different. It's unclear to me why this happens. It can be that ETMX and ETMY are significantly different, and when driving DHARD we are using the sum of the two.
Sheila, Gabriele, Evan
We are on dc readout with the following loops locked (pitch and yaw):
dETM is high bandwidth (~3 Hz), as is BS. cETM is lower bandwidth (probably by a factor of 10 or so) because we found it was injecting noise into the DARM spectrum up to ~50 Hz. PRM is very low bandwidth (more than 30 s time constant; this is probably too long). IM4 and PR2 are something like 100 mHz or less.
The CHARD P,Y WFS have the same filters engaged as for the DHARD P, Y WFS respectively. The gains for CHARD (P,Y), are (-20, -40). If we want a 3 Hz BW, the open loop we took last night indicated we were about 10dB too low.
Here is an estimate of DAC noise propagated forward to the ETM ESDs. I've used Peter's recent DAC noise model, an ETM ESD force coefficient of 2×10−10 N/V2, a bias of 380 V on each ETM, and some hints from Jeff about the DAC → ESD signal chain.
Evidently this is somehow an overestimate, but the shape and magnitude are roughly in agreement with the spectrum between 50 and 100 Hz.
As a quick test of whether DAC noise is really a limiting source here, we could try ramping down the ETMY bias during full lock (since we're not using the ETMY ESD).
Also, Nic and Jamie have inquired about the uptick in the ASD above a few kilohertz. The noise there seems to be largely uncorrelated between the two DCPDs (see attachment), which seems to suggest that it's still shot noise. (Based on measurements that Dan and I took of the DCPD dark noise, I believe this feature is too big to be explained by excess noise in the DCPDs or their signal chain.)