TITLE: 02/01 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:
IFO is in LOCKING in ACQUIRE_PRMI
Two locklosses today:
One due to ETM Glitch - alog 82566
One due to EQ - alog 82567
Otherwise, calm shift.
LOG:
None
TITLE: 01/31 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Ibrahim
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 17mph Gusts, 13mph 3min avg
Primary useism: 0.10 μm/s
Secondary useism: 0.56 μm/s
QUICK SUMMARY: H1 just recently lost lock from a M5.5 EQ out of Ecuador and relocking will start soon.
Earthquake caused Lockloss (5.5 from Ecuador). While we would usually survive this, high microseism meant we were mor susceptible.
ETM Glitch caused lockloss - tagged by Lockloss Tool
Ibrahim, Sheila
Low range coherence check due to the low range we've been having in this last lock. Attached below.
Shown is worse range for 10Hz to 45Hz compared to Dec 15 '24, with the coherence showing CHARD P as elevated.
Fri Jan 31 10:11:27 2025 INFO: Fill completed in 11min 23secs
Gerardo confirmed a good fill curbside. TCmins [-85C, -84C] OAT (2C, 35F) DeltaTempTime 10:11:36
Jennie W, Elenna, Camilla, Mayank
Today we had a longer commissioning period so we could heat up the TSAMS on OM2 without causing glitches during oberving as the heat up happens, see alog #78618 for details of these.
Method
17:20:16 UTC Camilla and Mayank started heating up OM2 after losing lock. This prevented us from taking darm offset step measurements beforehand.
We took the first darm offset step at 19:24:10 UTC about 1 hr 41 mins into lock.
We were going to take a squeezed data set of FIS, FIAS and No SQZ but we lost lock while in FIS.
After we lost lock we started cooling down OM2 to its nominal state at 19:49:21 UTC.
Then we took the second DARM offset step measurement when we were almost at the nominal cool state, around 31 mins into lock.
DARM Offset Step Method
This measurement script turns all the PCAL lines off except 410 and 255 Hz and increases their amplitude so they show up very strongly in DARM.
Then the fringe offset is varied in the DC readout loop to change the controlled power level on the output DCPDs (which is nominally set to 40mA during NLN).
The two PCAL lines allow us to measure the optical gain of the interferometer as we change this output power and thus the carrier light coming from the arms to the output of the IFO.
Results
The data for the hot state is saved in /ligo/gitcommon/labutils/darm_offset_step/data/darm_offset_steps_2025_Jan_30_19_24_10_UTC.pkl
The analysed pdf showing the plot of DCPD sum power vs. optical gain, optical gain vs. darm offset, and power into HAM6 vs. DCPD sum power is saved in /ligo/gitcommon/labutils/darm_offset_step/figures/all_plots_plot_darm_optical_gain_vs_dcpd_sum_1422300272_Jan_30th__OM2_Hot_state_1_hr_41m_into_lock_.pdf
The contrast defect (taken from the first graph) averaged between the two calculations for each line is (0.211 + 0.177) / 2 = 0.194 +/- 0.064 mW.
The equation for anti-symmetric port power taken from the third graph
P_AS = 1.485*P_DCPD + 688.147 mW
The data for the cold state is saved in /ligo/gitcommon/labutils/darm_offset_step/data/darm_offset_steps_2025_Jan_30_21_30_34_UTC.pkl
The analysed pdf showing the plot of DCPD sum power vs. optical gain, optical gain vs. darm offset, and power into HAM6 vs. DCPD sum power is saved in /ligo/gitcommon/labutils/darm_offset_step/figures/all_plots_plot_darm_optical_gain_vs_dcpd_sum_1422307856_Jan_30th__cold_OM2_31m_into_lock.pdf
The contrast defect averaged between the two calculations for each line is(0.213 + 0.224) / 2 = 0.219 +/- 0.088 mW.
And the equation for anti-symmetric port power is
P_AS = 1.533*P_DCPD + 669.724 mW.
Analysis
This contrast defect of 0.2 mW is much lower than the previous measurement from October 2024 with OM2 cold which was around 0.7 mW. The contrast defect does not seem to change much by heating up OM2, this makes sense as the curvature of OM2 should not change the wavefront matching between the arms. I am unsure why our arms are better mode-matched to each other compared to October last year though.
The HAM 6 throughput for the TM00 mode in the hot state is 1/1.485 = 67.3 %, for the cold state it is lower at 65.2 %. Does this mean the interferometer mode-matching to the OMC is better in the hot state? Compared to the throughput calculated for the October measurement which was 82%, this implies the IFO/OMC mode-matching has decresed since October. The junk light at the anti-symmetric port is now around 679 mW which is an increase of (((688+670)/2) - 656 ) / 656 = 3.5% compared to October. Further thinking/analysis needed.
I compared the alignment of the SRM and SR2 mirrors at the hot state and cold state.
SRM_P did not change. SRM_Y moved down by 3 mircoradians. SR2_P decreased by less than a microradian. SR2_Y decreased by about 2 microradians.
kappa_C increased by 0.018/0.976 = 1.8 % from the hot state to the cold state. The first cursor in the attached photo is just before we did the DARM offset step in the hot state, the second is in the cold state a similar amount of time into lock ( 1hr 40 mins) as the first cursor.
TITLE: 01/31 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 154Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 8mph Gusts, 4mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.32 μm/s
QUICK SUMMARY:
IFO is in NLN and OBSERVING as of 13:38 UTC (13:30 hr lock)
Getting some PI-24 ring ups that seem to have dropped us out of observing temporarily.
TITLE: 01/31 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 153Mpc
INCOMING OPERATOR: Tony
SHIFT SUMMARY: Observing at 155Mpc and have been Locked for 3.5 hours. Not sure what caused the lockloss earlier. Relocking generally went well - no issues with ALSX, but ALSY did look like garbage like it's been looking lately, but I noticed that although it looked like garbage, as soon as I went into an initial alignment it immediately locked, looked great and was very stable (ndscope1). Not sure if that's been the case every time but it was strange.
LOG:
00:30 Out of Observing due to SQZ unlocking
- For some reason it looks like NO_SQUEEZING had been selected when it lost lock - seems like an accidental click? (ndscope2)
00:36 Observing
01:05 Lockloss
- ALSY issues
- Went to run an initial alignment and all of a sudden ALSY is looking great!???
- No issues with ALSY after IA
02:33 NOMINAL_LOW_NOISE
02:36 Observing
Lockloss @ 01/31 01:05 UTC
02:36 Observing
TITLE: 01/30 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 159Mpc
INCOMING OPERATOR: Oli
SHIFT SUMMARY:
Highlight of today was H1 being down for a 5.5hr Commissioning break, but it started with H1 down from a lockloss and there was a lockloss in the middle of this down time.
ALSx continued to have Autocenter issue (fix w/ FORCE button). ALSy also would look bad after locklosses, but something happens with Full & Manual Alignment that stabilizes it for locking (mostly). If there is still an issue, holding at LOCKING ARMS GREEN and waiting for ALS WFS to settle before moving on seemed to help.
Microseism continues to fall over the last 16hrs.
LOG:
TITLE: 01/31 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 157Mpc
OUTGOING OPERATOR: Corey
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 4mph Gusts, 2mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.28 μm/s
QUICK SUMMARY:
Observing at 156Mpc and have been Locked for over 3 hours. Secondary microseism is coming down and wind is low.
I turned on the filters for the esd etmx glitches, while we were relocking. These filters multiply to 1 so shouldn't cause any issues, the turn on didn't affect the ALS lock at the time. I have accepted the changes in the safe sdf. Still need to figure out the limit to try to ride out the glitches, so there is no effective change to the IFO at the moment. SDF changes will need to be accepted in OBSERVE, when we get there.
Here are the SUSETMx SDF diffs ACCEPTED from Jim's work noted above.
Mayank, Sheila, Jennie W, Ryan S, Elenna, Jenne, Camilla, Robert.
Follow on from 82401, mostly copied Jenne's 77968.
As soon as we started setup, the IFO unlocked from an EQ and we decided to do this with the IFO unlocked.
Ryan locked green arms in initial alignment and offloaded. Took ISC_LOCK to PR2_SPOT_MOVE (when you move PR3 it calculates and moves PR2, PRM and IM4).
Green beatnotes were low but improved when we started moving. Steps taken: Move PR3 Yaw with sliders until ALS_C_COMM_A beatnote decreased to ~-14 and then used pico A_8_X to bring it back. Repeated until PR3 M1 pitch was 1-2urad off and then Mayank brought back pitch with PR3 sliders. Repeated moving PR3 yaw sliders and picos.
Started with PR3 (Pitch,Yaw) at (-122, 96), went to (-125.9, 39.5), were aiming for Yaw at -34. But, at (-124, 68) we lost the beam on AS_AIR, whoops.
Once we realized that we fell off AS_AIR so took PR3 back to last time we had light on it (68urad in yaw slider), ignoring green arms with the plan of moving back to 38urad by moving SR2 to keep light on AS_AIR. Moved SR2 in single bounce (ITMY misaligned) to increase light on AS_AIR. We couldn’t go any further in PR3 yaw with keeping light on AS AIR so we decided to revert green picos to work with 68urad on PR3. WE took PR3 back to (-125.9, 39.5) and reversed our steps of sliders and picos.
After we got here, Ryan offloaded green arms and we tried to go to initial alignment. No flashes on init align in X arm or y-arm (touched BS for y-arm). We would usually be able to improve alignment while watching AS_AIR but the beam wasn’t clearly on AS_AIR. Improved beam on AS_AIR by moving SR2/3.
Ran SR2 align in ALIGN_IFO GRD. This seemed to make some clipping worse, are we clipping in SR2? Still working on SR2 alignment. Maybe we should update the ISC_LOCK PR2_SPOT_MOVE state to have SR2/3 follow align so that we don't loose AS_C and AS_AIR.
Regarding "Improved beam on AS_AIR by moving SR2/3."
We found that by moving SR2/3 by hand, or by engaging SR2 align and moving SR3 (SR2 follows), we can make improvements in the AS_C NSUM and the AS_C yaw position, but that clearly does not fix all the problems with input align and the terrible beam shape we saw on the AS AIR camera. This leads us to believe that part of the problem is upstream, as in even if we fix everything at the output, we may have caused some other clipping problem in the PRC.
Sheila and I tried adjusting the pointing of PR2 to see if we could improve the input align issues, but that seemed to have very little effect.
I think that a possible reason why our PR2 spot moves have gone poorly is because the PR2 spot move function in the guardian does not have the correct constants to ensure the spot moves on PR2 and not on the other optics.
Looking back in time, the PR2 spot move function was first written by Stefan in 2016 (as I can find, see: 28420, 28442). Looking at his code and the current guardian code which was originally copied from his code, the adjustment values are exactly the same:
pitPR3toPR2=-9.2;
yawPR3toPR2=+9.2;
pitPR3toIM4=56;
yawPR3toIM4=11;
pitPR3toPRM=1.5;
yawPR3toPRM=2.2;
These differ from the values you would calculate from the ray transfer matrix, which Stefan notes in a comment in 28442. My guess is that the difference in those values is related to whatever calibration we add into the optics sliders.
Also, Jeff updated the IM slider calibrations to microradians last April, see: 77211. I can't find any alog (so far) that reports an update to the PR2 spot move values in the guardian to account for this recalibration.
Sheila pointed me to the May 20, 2024 spot move where she says she updated the adjustment values from the guardian: 77949. However, the values she uses in this alog are not reported, and it doesn't look like the guardian numbers actually changed. I looked at the saved ndscope from that time and eyeballed the values to be approximately:
yawPR3toIM4 = 0.875
yawPR3toPR2 = 10
yawPR3toPRM = 2
You can check the attached screenshot to see how I calculated these values. These numbers are clearly different compared to the numbers above, so I don't really know what happened here. But, it seems that if we want to do a PR2 spot move again, we should check to make sure we are adjusting the optics appropriately.
You can also find the template for this scope in "/ligo/home/sheila.dwyer/ndscope/PR2_spot_move_jennie.yaml" if you want to check yourself.
[Matthew Camilla Louis Sheila]
There is concern that the CO2 laser proposed for the CHETA design has enough intensity noise to saturate the ESD preventing lock.
By calibrating the displacement noise projected from CHETA RIN data into counts at the L3_ADC, using the DARM loop OLG and transfer function between DeltaL_ctrl and L3_ADC, we can get a rough estimate of whether we expect the CHETA noise to saturate the ESDs. This is done by looking at the RMS of the cts/rtHz of CHETA noise at the ESD and comparing it to the 25% of saturation level (2^19 counts).
Figure 1 is the loop model for mapping the displament noise (CHETA RIN) to ESD counts, Figure 2 is a plot of the darm olg, Figure 3 is plot of the tf from deltaL_ctrl to L3_adc.
Figure 4 is the projection of CHETA RIN to the ADC counts, showing that we do not estimate CHETA is likely to saturate the ESDs.
Next steps are to see if we estimate CHETA nosie to saturate the DCPDs at different power up stages.
[M. Todd, J. Kissel]
After measuring very low values for the coherence of the channels used to estimate the transfer function from H1:CAL-DELTAL_CTRL to H1:CAL-CS_DARM_FE_ETMX_L3_ESDOUTF_UL_OUT, it seemed better to go to the calibration model and use pydarm to do this calibration instead.
After making this change, the results are slightly more convincing, saying that we still do not expect CHETA to saturate the ESDs on the ETMX test-mass, however it is around 3% of the saturation level (2**19). The python code used to make this analysis as well as accompanying plots are listed below.
We do however worry about CHETA possibly saturating the coils on the L2 stage, as the noise is around 19% of the saturation level (2**19). This will require some more thought/testing. HOWEVER, this is during the Nominal Low Noise state (pydarm models NLN), and during lock-acquistion we expect that with the additional lowpass filters for the actuation stages we could have some more wiggle room with this.
Much of this code utilizes the pydarm model constructed from pydarm_report_H1.ini found at /ligo/groups/cal/H1/reports/20250123T211118Z/pydarm_H1.ini
The details about how to use the pydarm model and the transfer functions it contains can be found in Jeff's alog
Figures:
Code:
[Edit!]
After noticing an error in the way that the RMS was calculated, I've fixed the code and updated the plots. Fortunately, this does not affect anything upstream (transfer functions and asd calibrations, etc.) but it does inform a better estimate of whether we expect CHETA to saturate the ESDs.
Updated plots:
1) !cheta_in_esds.pdf
2) !cheta_in_coilsL2.pdf
3) !cheta_in_coilsL1.pdf
For more details/summary, refer to alog 82631
Here're the bare-bones instructions to run the DARM loop critique -- an automated set of plots that were inspired by the presentations given over the years that compare the transfer functions of the DARM loop between the two sites, e.g. G1501372, G1700316, G2000149. (0) Conda activate the latest pydarm environment. ~$ conda activate /ligo/groups/cal/conda/pydarm This is a symbolic link to the latest tagged version of pydarm. () ~$ which pydarm /ligo/groups/cal/conda/pydarm/bin/pydarm () ~$ pydarm --version 20240821.0 () ~$ ipython In [1]: import pydarm In [2]: pydarm.__version__ Out [2]: '20240821.0' Note the version of pydarm is the same on the command line and within the ipython session *because* we activated the correct pydarm conda environment. The command line pydarm internally activates this environment automatically, but any old ipython session may not have the right version of pydarm if you just import "from scratch" without making sure you're in the right environment first. So -- any time you're running script or python session pyDARM these days -- make sure that you've activated the conda environment. Is this the right version? check https://git.ligo.org/Calibration/pydarm/-/tags see if that version is the latest, i.e. the top of the list. It is. And this will *always* be true, by process of deploying the latest tag (see deploy script). To compare previous versions of tags, go to https://git.ligo.org/Calibration/pydarm/-/compare?from=master&to=master and change the drop-down menu to compare one tag to the other. If you want to activate an environment with an older version of pydarm, then head to the folder /ligo/groups/cal/conda/ and activate the environment you like. (1) Grab the DARM loop model parameter sets that you want to plot and/or compare. If at LHO, wanting H1 parameter files, then (back out on the command line, not in yet in a python session) Find the list of reports and tags: () ~$ pydarm ls -r From that list, find the model parameters installed in the front-end: () ~$ pydarm ls -r | exported Once you find what you like, go into that report directory, e.g. () ~$ cd /ligo/groups/cal/H1/reports/20240927T211612Z Look for pydarm_H1.ini, and copy it somewhere you like, or at least store where it lives. If you're at LHO, want L1 parameter files, then the easiest thing is to download it from the web. Head to the https://ldas-jobs.ligo-la.caltech.edu/~cal/ and scroll down to the list of all reports, and find the entry that's been exported most recently e.g. 20240408T200652Z, and download the pydarm_L1.ini and save it to a known location. (2) Start critiquing: ~$ ipython In [1]: from pydarm.darm import DARMModel In [2]: d = DARMModel('/ligo/groups/cal/H1/reports/20240927T211612Z/pydarm_H1.ini') # Plot a single parameter file's model: In [3]: d.plot(filename='/ligo/home/jeffrey.kissel/2025-01-21/20240927T211612Z_pydarm_H1_critique.pdf',label=['H1']) # Compare against another, say, previous version of the model d_prenewdarm = DARMModel('/ligo/groups/cal/H1/reports/20231027T203619Z/pydarm_H1.ini') from pydarm.plot import critique critique(d,d_prenewdarm,filename='/ligo/home/jeffrey.kissel/2025-01-21/20240927T211612Z_vs_20231027T203619Z_pydarm_H1_critique.pdf',label=['H1 20240927T211612Z', 'H1 20231027T203619Z']) # Compare two IFOs: In [9]: d_H1 = DARMModel('/ligo/groups/cal/H1/reports/20240927T211612Z/pydarm_H1.ini') In [10]: d_L1 = DARMModel('/ligo/home/jeffrey.kissel/2025-01-21/20240408T200652Z_pydarm_L1.ini') critique(d_H1,d_L1,filename='/ligo/home/jeffrey.kissel/2025-01-21/20240927T211612Z_H1_vs_20240408T200652Z_L1_critique.pdf',label=['H1 20240927T211612Z','L1 20240408T200652Z']) # Compare one IFO's parameters, while updating one of the parameters on the fly In [9]: d_H1 = DARMModel('/ligo/groups/cal/H1/reports/20240927T211612Z/pydarm_H1.ini') In [10]: d_H1_moreAA = DARMModel('/ligo/groups/cal/H1/reports/20240927T211612Z/pydarm_H1.ini') #Intentionally the same # Update the parameter you want, In [6]: d_H1_moreAA.sensing.omc_filter_noncompensating_modules Out[6]: [[9, 10], [9, 10]] In [7]: d_H1_moreAA.sensing.omc_filter_noncompensating_modules = [[9,10,10],[9,10,10]] In [8]: critique(d_H1,d_H1_moreAA,filename='/ligo/home/jeffrey.kissel/2025-01-21/20240927T211612Z_H1_vs_20240927T211612Z_H1_2x16kDigitalAA_critique.pdf',label=['Nominal','1x More 16k AA'])
For the record, this DARM model object, "d" mentioned above literally contains everything about the DARM loop.
So if you want parts of the DARM loop, then you can ask for things like
$ conda activate /ligo/groups/cal/conda/pydarm
$ ipython
: import pydarm
: pydarm.__version__
'20240821.0'
: from pydarm.darm import DARMModel
: d = DARMModel('/ligo/groups/cal/H1/reports/20240927T211612Z/pydarm_H1.ini')
: import numpy as np
: freq = np.logspace(1,6,2500)
: G = d.compute_darm_olg(freq) # Open Loop Gain == G = A*C*D
: R = d.compute_response_function(freq) # Response Function == (1+G)/C = (1/C) + D*[A_T + A_P + A_U]
: C = d.sensing.compute_sensing(freq) # Sensing Function, C
: D = d.digital.compute_response(freq) # DARM filter bank, D
: A = d.actuation.compute_actuation(freq) # Total super actuator, A
And if you need more compartmentalized transfer functions, you can explore the methods available in
darm.py (for things like the overall loop shape)
sensing.py (for detailed components of the sensing function)
actuation.py (for detailed components of the actuation function)
Fwiw the "pydarm model" command on the command line will also produce frequency response plots of these DARM model transfer functions.
Sheila, Mayank
We wanted to double check the calibration of IM4 trans into power on PRM, similar to 63812 and 62213
I have updated the IM4 trans calibration with this additional factor of 0.9566. I engaged FM8 in the IM4 trans nsum filter bank, which is now labeled "alog82260".
This indicates that at 60.1 W input power from the PSL, we have 56.6 W of power on the PRM.
Screenshots show the new filter in IM4 trans NSUM, SDF in safe, and SDF in observe.
Sheila will add her code shortly.
code used to check this calibration is attached
H1 back to observing at 01:17 UTC. Automatic relock after opting for an initial alignment.