Sheila, Naoki, Vicky -- SQZ data with FIS and FDS.
NLG~11.0 (Gen SQZ=14.7dB), according to calibration from OPO_TRANS = 80 uW (this calibration is reasonably accurate).
Started 8:05 hours into lock. 3-4 hour set of measurements. Data times in bold.
|
sqz_config |
DTT reference |
gps_start |
clf_phase |
duration |
Notes |
|
No SQZ |
Ref 0 |
1375027288 |
-- |
1800 |
8:05 hours into lock. Start @ 16:01:10 UTC |
|
-- misalign FC |
--16:33:32 UTC |
--1375029230 |
-- |
-- |
ADF ON @ 16:36:37 UTC. There is 1.3 kHz ADF line in the data. |
|
Start in FIS & check if AS42 |
|
(opened bdiv @ 1375029851) |
→ we offloaded + froze ASC. Sheila walked ZM5/6 to optimize ASQZ alignment. |
||
|
FIS test asc ref |
Ref 3 |
1375029757 |
145.20 |
250 |
End = 1375030007. |
|
FIAS |
Ref 2 |
1375030889 |
234.06 |
900 |
Start @ 17:01:11 UTC, End = 1375031821, 17:16:44 |
|
FIS |
Ref 4 |
1375032085 |
150.21 |
900 |
Start @ 17:21:07 UTC, End @ 1375033006, 17:36:28 |
|
FIS +mid sqz |
Ref 5 |
1375033520 |
196.94 |
900 |
Start @ 17:21:07 UTC, End @ 1375033006, 17:36:28 |
|
FIS -mid sqz |
Ref 6 |
1375034605 |
0 |
900 |
Start @ 18:03:07 UTC, End @ 1375035601 |
|
-- relock FC |
-- |
Using FIS, sqz looks like CLF demod phase @ 150.76 deg |
|||
|
FDAS |
Ref 7 |
1375036671 |
239.07 |
900 |
Start @ 18:37:33 UTC, End = 1375037577, 18:52:39 |
|
FDS +mid |
Ref 8 |
1375037596 |
196.94 |
900 |
Start @ 18:52:58 UTC, End = 1375038540, 19:08:42 |
|
FDS -mid |
Ref 9 |
1375038782 |
0 |
900 |
Start @ 19:12:44 UTC, End = 1375039746, 19:28:48 |
|
FDS (no asc) |
Ref 10 |
1375040208 |
150.21 |
~5min |
Start @ 19:36:30 UTC, End = 1375040749, 19:45:31 |
|
FDS (with asc ON) |
Ref 11 |
1375041161 (sqz asc has settled) |
150.21 |
900 |
Start @ 19:52:23 UTC, End = 20:07 |
Total change in squeezer configuration: SQZ angle has changed from 145.2 --> 150.2 deg.
Attached the data times as a .py, for easier analysis.
Kevin, Sheila, Daniel, Vicky
Here is the squeezing dB data from this time, which shows the quantum noise reduction with squeezing, relative to a model of quantum noise without squeezing. To sanity check IFO parameters, here is the no-sqz quantum noise model (dashed purple) is plotted alongside the full budget (solid red), plotting CTN (the -. and -- green lines), and the technical non-quantum noise estimate (grey), using the no-sqz times taken in this dataset. IFO & SQZ parameters used for modelling are shown in the title.
Note: this squeezing subtraction (estimated quantum noise w/sqz - quantum noise model w/o sqz) is model-dependent. We are still working to use a cross-correlation estimate of the technical noise, so we can calculate the quantum noise without squeezing w/o relying on a shot noise model (b/c the model depends on optical gain / ifo readout losses). In this analysis, the method this is reversed: we use the quantum noise model to get an estimate of technical noise, then subtract that technical noise estimate from squeezed darm, to see the quantum noise reduction with squeezing. Specifically, in PSD here we do the following:
- tech noise = (meas darm no sqz) - (qn model no sqz) --> this is better to get it from the dcpds correlated noise (but correlated noise includes QRPN, need to account for that accurately)
- quantum noise w/sqz = (meas darm w/sqz - tech noise)
- sqz dB = 10*log10( (quantum noise w/sqz) / (gwinc qn model no sqz) )
How I set the IFO modeling parameters:
1) Homodyne / readout angle = - 10.7 degrees. This is constrainted to < -10.7deg from sheila's recent contrast defect measurement 71913.
2) SRCL detuning =0. It is likely small, though possibly non-zero; anyways, setting it to 0 for this analysis, while working with Louis to see the SRCL detuning from calibration measurements.
3) IFO readout efficiency - based on sqz wiki, expect ~13% broadband optical readout losses of the IFO signal, without squeezing. Based on no-sqz measured DARM, circulating arm powers in the 370-380kW range, homodyne angle < -10.7 deg, and negligible SRCL detuning -- here it is estimating 73% output efficiency (27% loss) to reconcile shot noise sensitivity with measured DARM at 1 kHz. With the no-sqz quantum noise model and 73% output efficiency, the estimated technical noise level is ~0.9e-20 m/rtHz at 1 kHz. This 1kHz technical noise estimate lands somewhere between Craig's correlated noise estimate 71333 (like 0.5-1e-20 m/rtHz @ 1kHz), Sheila's measurement of correlated dcpd noise 70891 (like 1.2e-20 m/rtHz @ 1kHz), recent noise budget projections, 72245, and a lil higher than Jenne's NonSENS noise budget 72578 (considering laser frequency noise ~0.3e-20m/rtHz at 1kHz). Given that subtracting the shot noise model suggests technical noise within a factor of 2-3 of other metrics, it lends at least some some confidence to the no-sqz quantum noise model w/excess output losses that impact optical gain.
Next question: How well constrained is the breakdown between readout / injection losses? Not all the IFO readout losses that affect optical gain have to be SQZ readout losses (two beams could have different alignments/mode-matchings through the IFO / AS port). But to look for sqz losses, it'd be helpful to have a hint of where to look, if we can find whether losses are IFO side or else SQZ side. I don't see a clear sign in our measurements either way.
--> I considered 3 scenarios:
1) Equal IFO readout losses 20% + SQZ injection losses 20%,
2) Using same IFO readout losses (71%) for SQZ, then rest is SQZ injection losses (9%),
3) All SQZ injection losses (35%) and perfect readout efficiency (100%).
Noticeable features that could distinguish between the two scenarios (high readout losses vs. high injection losses) are mostly the low frequency QRPN SQZ rotation+gain from the arm cavities optomechanics. If more quantum noise is injected to the IFO (so injection losses * gen sqz dB are higher), then the arm cavities have more sqz to rotate, and so we see the squeezing efficiencies increase at low freqencies as a result. Kevin has nice plots that show this (squeezing efficiency within the arm cavity bandwidth decreases w/injection losses but not with readout losses; or like Kevin says, injection losses source QRPN and shot noise, while readout losses only source shot noise.
Some next steps to understand in the analysis/models:
1) How is the squeezing relatively flat given the known mode-mismatches of both IFO-OMC and SQZ-IFO/OMC? It seems that hot OM2 curvature leads to ~10% IFO-OMC mode mismatch, while the SQZ PSAMS are railed without yet optimizing SQZ-OMC mode-matching, so SQZ-OMC is clearly not perfectly mode-matched either. What is the scenario where we get flat squeezing given the known mode mismatch?
2) Use cross-correlation to calculate squeezing dBs. Is the squeezing definitely flat, or is that an artifact of how we compare to a quantum noise model?
Small notes about this analysis:
-- for 8/2 data: for calibration, I am using GDS-CALIB_STRAIN_CLEAN, with the text-file magnitude correction from Vlad's alog 71787.
-- for no-sqz noise budgeting, I am plotting both what gwinc has as CTN, and a trace that is 1.3e-20m/rtHz at 100 Hz. Reminder of this alog from Kevin K. and Evan H. regarding the CTN gwinc noise budget update 68499, which dropped the CTN estimate from ~1.3e-20 m/rtHz previously (green -. trace) to the ~1.13e-20 m/rtHz calculated in gwinc now (green, -- dashed line).
Erik, Fil, Dave:
Yesterday Erik installed two Trip-lite PDU15NETLX units in EX, EY VEA to replace the failed Pulizzi units. He wrote a new EPICS IOC which controls these units via SSH.
Today I added these to the CDS AC power control MEDM screen. I also renamed the overview MEDM and the SITEMAP link to it, removing the Pulizzi name.
Note: because of the renaming, to get to the new screen you will have to restart your SITEMAP.
I have accepted some SDFs for unused-at-this-time EPICS values, to make comparison to offline mimics of the front end system a little easier. Since there is no online cleaning applied at this time, this does not actually change anything about data during Observe segments.
Exit gate is functional again.
Wed Aug 02 10:13:02 2023 INFO: Fill completed in 12min 58secs
Jordan confirmed a good fill curbside
Last night we went out of observing for ~1 second with 2 SDF diffs on syscssqz. I can't get the channels, but we will keep an eye out.
TITLE: 08/02 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 145Mpc
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 3mph Gusts, 1mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.04 μm/s
QUICK SUMMARY:
Following Channeles had SDF Diffs from earlier today. once accepted we were able to reach OBSERVING.
H1:ASC-DHARD_P_TRAMP
H1:ASC-DHARD_Y_TRAMP
Current IFO Status: NOMINAL_LOW_NOISE & OBSERVING
TITLE: 08/01 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 141Mpc
SHIFT SUMMARY:
(Almost) locked the entire shift, but unfortunately H1 had a lockloss during the last 30min of the shift! X-Arm has gone through at minimum 2 rounds of INCREASE FLASHES, and finally moving on. Have been chatting with Tony on the phone about the situation as he's getting ready for his shift. I'm hoping H1 will come back for him with no issues. Oh and for the last lockloss, there were no obvious reasons for the lockloss.
LOG:
At 0617utc (1117pmPT), H1 dropped out of OBSERVING due to a fast SQZ sdf diff (I took it back within 45seconds).
Tony and I were chatting at the time and I mentioned the situation and he pointed me to some recent (within the last week) similar instances where this happened with these Camilla alogs: 71653 & 71652.
Attached is a plot showing the same culprits (H1:SQZ-FIBR_SERVO_COMGAIN & H1:SQZ-FIBR_SERVO_FASTGAIN) dropping to lower value for 0.5secs and then returning to their normal value.
Do we need to not monitor these channels? Make an FRS?
At 00:00:02, received the Verbal: "Wap On in LVEA, EX, EY"
Not really sure what this was about. When I went to the sitemap -> CDS -> unifi wap screen, I saw that all were off (except MSR). On NDSCOPE it showed that for a brief time it looked like they went from a value of 2 to 0 back to 2. Not clear what this was about, but just found it odd and worth noting.
Closes FAMIS 25077. Last done in alog 71721.
Only have results for 3 of 4 Test Masses (ETMx measurement not available).
SUMMARY:
This evening we wanted to coordinate going out of Observing for L1 & H1 to run (2) calibration measurements (~30min). Unfortunately, I was not able to run the broadband measurement, but ran the simuLines measurement. It also took me extra time to return to Observing because it was not clear how to run this measurement with the new H1 Manager and H1 did not restore smoothly and had excitations which kept us out for a bit.
Attempt To Run Broadband PCAL measurement:
Vladimir and Jenne coordinated running 30min of calibration measurements at 5pm PT. I spent my first hour getting everything set up so I could quickly run the measurements.
corey.gray@cdsws13:~$ pydarm measure --run-headless bb
INFO | config file: /ligo/groups/cal/H1/ifo/pydarm_cmd_H1.yaml
INFO | available measurements:
pcal: PCal response, swept-sine (/ligo/groups/cal/H1/ifo/templates/PCALY2DARM_SS__template_)
ERROR: measurement 'pcal' template file not found: /ligo/groups/cal/H1/ifo/templates/PCALY2DARM_SS__template_
corey.gray@cdsws13:~$
After consulting with Jenne & Vladimir, we canceled attempting this measurement and moved on to the simuLines measurement.
simuLines script
Attached is a screenshot of the terminal and the testpoints which were on the board while it was running.
Delays In Restoring H1 & Returning to Observing:
Once simuLines was complete, I thought I could have H1_MANAGER restore H1 back to NLN, but after an attempt (or 2), that didn't work. So I had ISC_LOCK go to AUTO and then selected NLN and then took it to MANAGED. I then ran an INIT on H1_MANAGER, and I believe this restored H1. Still not sure if the latter is the preferred way.
Next, I followed the wiki instructions to work on CAL_AWG_LINES. It was in IDLE. But the wiki instructions said "Make sure CAL_AWG_LINES guardian is in state 10, LINES_ON, and you see its PCALY lines ON between 5 and 25 Hz." I believe I saw the PCALY lines, but we were in IDLE, so I toggled the Lines On/off via guardian per the instructions. But I could not go to Observing due to SDF Diff and CAL_AWG_LINES in bad state. Soooo...
But I still had excitations! (see attached) So, then I spent the next few minutes figuring out how to kill these excitations. Then finally returned to OBSERVING.
Since I'm not totally sure on the best way H1 should be restored in this sort of situation, I will not update that part of the wiki with regards to my experience tonight, due to:
Apologies -- with the amount of software work needed to convert CAL_AWG_LINES to front-end oscillators -- I forgot the most important part: human coordination! CAL_AWG_LINES is now deprecated with the addition of new front-end oscillators as of yesterday, Aug 01 2023 (2023-08-01) -- check out LHO:71881. That means one no longer has to do any funny business finagling CAL_AWG_LINES to drive the collection of low-frequency, 8. 11. 15. and 24 Hz, lines. I've now updated the wiki page that Corey cites -- see that TakingCalibrationMeasurements no longer has any mention of CAL_AWG_LINES. Indeed, you (Corey), did the right thing by reverting the PCALY_DARM_GAIN; that was the path thru which CAL_AWG_LINES drove the above mentioned 4 lines. I'll make sure there're no more guardians that are toggling this gain today.
Smooth sailing for H1. Ran a calibration measurement (and couldn't run the broadband one)---will alog specifics separately. H1 did ride through a 5.7M Tonga earthquake which is nice.
As noted in my maintenance summary alog, while FW0 was being restarted this morning FW1 spontaneously restarted itself at the same time. This is the first time we had seen this, and as far as we can tell it is a complete coincidence. Previous spontaneous FW restarts have happened at random times typically within 30 minutes of the orginal restart.
I have written a python script to report the individual missing frame files resulting from a FW restart, and reporting an error is these times coincide between FW0 and FW1.
Output for today:
FW0 Missing Frames [1374951040, 1374951104]
FW1 Missing Frames [1374950784, 1374950848, 1374951040, 1374951104]
ERROR: no frame written for GPS 1374951040!!!
ERROR: no frame written for GPS 1374951104!!!
h1digivideo3, the computer serving thew flicker cameras, ran out of memory. Camera 15 was taking up the bulk of the memory.
Before any action could be taken, the OS kill the Camera 15 server, which later restarted with a much smaller memory footprint, resolving the immediate issue.
Logs for Camera 15 were filled with queue overflow messages for both udpsink, the streaming portion of the server, and appsink, the centroid calculation. These might indicate the cause of the memory leak.
Other camera servers are also using large amounts of memory. We might want to restart these servers every Tuesday.
Out of the corner of my eye, I noticed some of the cameras flickering to blue (frozen). It's certainly happening to the OMC trans camera (which isn't so critical), but I think it was also happening to some of the cameras on Nuc35, although I can't say which of them were flickering. If either ETM or the BS camera freeze for a long time, we'll get pushed out of Observing as the camera servo guardian will transition us back to ADS. I ping-ed Dave and Patrick in the control room chat channel to see if they had any thoughts.
I've seen the ETM cameras go blue for a second or two a couple of times today, they go blue and then come back at the same time.
Erik, Tony, and Patrick were having a look at this earlier (and noted it in alog 71893). It seems to all be fine for now. It does look like the OMC trans camera (which is the camera 15 that they noticed restarting) came back with much higher than usual exposure. I have set H1:VID-CAM15_EXP_REQ back to its nominal (according to ndscope) value of 500, since we're out of Observe anyway for calibration measurements).
Sheila, Naoki, Brina, Genevieve
Pump AOM alignment
Today we went to SQZT0 and aligned the pump AOM to get more pump. First we made the ISS drivepoint 0 to get only 0th order beam and maximized its AOM throughput by alignment of AOM. The pump power after AOM was 23mW before alignment and it becomes 37mW after alignment. We also aligned the pump fiber. Although the SHG output power is only 49mW, the pump going to fiber is 31mW and the ISS can be locked with OPO trans of 80. Since the pump power is increased, we adjusted the OPO temperature. The fiber alignment might not be optimized and we will check it soon.
Issue of SHG demod signal
To check if we have mode hop on SQZ laser, we scanned SHG and checked the trans signal. We found no evidence of mode hop, but found the strange behavior of SHG demod signals. We found that the I signal, which is used for SHG lock, is much smaller than Q. We changed the demod phase, but the Q signal is always larger than the I signal.
To use the Q signal for SHG lock, we swapped the I and Q cables and maximized the Q signal by optimizing the demod phase and flipped the sign of servo. Although we should have 10 times larger signal with Q than I, the UGF of SHG with Q signal is around 250 Hz, which is almost the same as I signal. We suspect that the demod board has an issue and we will check it soon.
Finally, we switched back to the nominal I signal for SHG lock. We increased the SHG gain from -11 to 5 to have UGF around 1kHz. The SHG guardian is updated.
Sheila, Naoki, Genevieve, Brina
Here are some images from altering the phase of the SHG demod signal, the first image is where we began where the phase was not altered (0 degrees added), the second image we moved it by 45 deg, third image it was moved by 90 deg, and fourth image it was moved 180 deg. (yellow is the I signal, blue is the Q signal)
Channel one has a 50 terminator enabled. Not sure it matters because the signal is small but it will have some effect. Probe setup on channel 2?