After an alignment, long time needed for signals to converge in PRMI, and with multiple locklosses at LOWNOISE_ASC....
Wondering if we should back out the change to ISC_DRMI Jenne notes here.
Jeff B Reloaded ISC_DRMI for this change on Saturday night. Attached is a trend showing BS/PR3 pit/yaw gains. When ISC_DRMI was reloaded we have kept Pitch gains for BS/PR3 at 0. I reckon this is one of the changes Jenne notes.
I don't have much experience with making edits to Guardian, so I will begin looking at the guardian code regarding this change and see if I can figure it out.
OK, I have where the change for ISC_DRMI is, but I'm not totally sure of how to back out. (I'm working on finding channels to trend to determine what we had been doing.).
But want to show where I believe the change is:
Bring up the ISC_DRMI node's Main Screen & click the Edit button. When opening it took me close to where the change is at: ISC_DRMI.py. Here is the area in question:
##################################################
# STATES: INIT / DOWN
##################################################
Line 41:
for sus in ['BS', 'PR3']:
# Treat P and Y the same, JCD 24Jan2020, alog 54709
ezca['SUS-%s_M1_LOCK_%s_RSET'%(sus, py)] = 2
#if py == 'P':
# ezca.get_LIGOFilter('SUS-%s_M1_LOCK_P'%sus).switch_on('FM1')
#elif py == 'Y':
# ezca['SUS-%s_M1_LOCK_Y_RSET'%sus] = 2
# PRM, SRM length M2 feedback
for sus in ['PRM','SRM']:
ezca['SUS-%s_M2_LOCK_L_RSET'%sus] = 2
time.sleep(0.1)
# reset the gains (BS and PR3 only reset yaw b/c wire heating)
for py in ['P','Y']:
for sus in ['IM4', 'SRM', 'SR2', 'PRM', 'PR2']:
ezca['SUS-%s_M1_LOCK_%s_GAIN'%(sus,py)] = 1
ezca['SUS-BS_M1_LOCK_Y_GAIN'] = -1
ezca['SUS-PR3_M1_LOCK_Y_GAIN'] = 1
In the above plot, the Pit gain for BS & PR3 went to 0 after the Reload and has stayed there. Do we want BS/PR3 pit gains to be -1 & 1 respectively? (And were those pit gains just kept at -1 & 1 or was it toggled via guardian? I'm seeing that these gains for these optics (& others) during DOWN scripts, but not sure where that happens.)
Still going to investigate the ISC_DRMI python code. (as PRMI is waiting forever for signals to converge.). If I make changes to the code, I'll try my best to add comments explaining what I try to change.
After another LOWNOISE_ASC lockloss, bit the bullet and made CHANGES to ISC_DRMI.py.
Here is the changes/reversions made:
1) REVERSION to ISC_DRMI.py to what we used to do for BS/PR3 (basically just commenting/uncommenting lines already there):
for sus in ['BS', 'PR3']:
# Treat P and Y the same, JCD 24Jan2020, alog 54709
#ezca['SUS-%s_M1_LOCK_%s_RSET'%(sus, py)] = 2
#Revert to treating P differently for BS/PR3,CG 27Jan2020, alog54743
if py == 'P':
ezca.get_LIGOFilter('SUS-%s_M1_LOCK_P'%sus).switch_on('FM1')
elif py == 'Y':
ezca['SUS-%s_M1_LOCK_Y_RSET'%sus] = 2
I'm still wondering if the FM1 filter is being reverted correctly.
2) I tried changing the pit gains to BS/PR3 by hand, but running the DOWN script took them back to 0.
ADDITION made to ISC_DRMI.py:
#Adding pit gain setting for BS/PR3, CG 27Jan2020, alog54743
ezca['SUS-BS_M1_LOCK_P_GAIN'] = -1
ezca['SUS-PR3_M1_LOCK_P_GAIN'] = 1
ezca['SUS-BS_M1_LOCK_Y_GAIN'] = -1
ezca['SUS-PR3_M1_LOCK_Y_GAIN'] = 1
After SAVING the changes, I hit LOAD on ISC_DRMI, & then ran DOWN on ISC_LOCK.
And now making first attempt at locking (so far, DRMI locked on its first attempt...which it hadn't done this shift).
As a sidenote observation, looking at the BNS range plot of the last 24hrs (see attached), one can see 4-similar-looking locklosses in the last day at LOWNOISE_ASC:
Just an observation as I was waiting for an Initial Alignment to complete.
Started off locking attempts this shift, but taking H1 to DOWN.
Initial Observations:
This is going to be a long night.
NOTE: winds have picked up with gusts over 40mph in the last 30min.
After lockloss at CHECK AS SHUTTERS:
Attached is snapshot of ndscope. The two spots to look at are when pop18 (pink) & 90 (green) go into oscilations/drop:
I'm not used to seeing these effects. What's different??
Selected NOMINAL LOW NOISE & waited to see how it goes (also crossed fingers). Jeff last made it to LOW NOISE ASC...Hoping to get that far!!
At a wits end now. Will try an Initial Alignment next.
![]()
11:14 Initial Alignment run and successfully completed.
After an Initial Alignment.
TITLE: 01/27 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Jeff
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 24mph Gusts, 22mph 5min avg
Primary useism: 0.05 μm/s
Secondary useism: 0.37 μm/s
QUICK SUMMARY:
H1 Is Down:
Jeff gave me a summary of the issues he's had with locking as he fought valiently to bring it back over the last half of his shift. I just took H1 to DOWN. Will try a fresh start at locking as-is post-DOWN, but after that, if there are issues, I'll begin an alignment, check alogs for issues over the last week to see if this sheds light, and so on.
Another Network Issue:
As Jeff was getting ready to leave, he noticed he was no longer connected to the LHO GC Staff wifi network (and I was not the GC Staff wifi via my laptop or phone either.) This sounds different to Niko's CDS network issue from yesterday.
I cannot glean any ideas from the CDS Overview (which makes sense since this issue appears to be related tothe GC-network).
Operator TeamSpeak: We are not logged into this. So I phoned the LLO opearator to notify them of our situation.
Since this is just GC-related, I'm not going to wake Richard/Dave up about this & only going to send an email to cds admin about this and leave it for morning. Currently I have access to the internet (i.e. email, alog, etc.) via CDS web browsers so will next move to working on H1.
This sounds like a similar issue (see here, here)to what I had about 6-weeks ago where Richard brought us back when he got in (although for that GC-outage we also had some phones down (I confirmed my office phone was fine).
I'm tagging FRS on this alog due to the GC Network connectivity issue.
For the second evening the IFO broke lock just before mid shift. Last night at 03:36 (19:36)and this evening at 03:39 (19:39). As with last evening's recovery, on the first time through, the locking sequence appears to be having trouble with DRMI_1F and PRMI. For now, continuing with hands off relocking.
Had to run the PSL weekly report the old fashion way, due to missing /channel connection problems. Error message posted below. PSL: SysStat: All Green, except LASER panel. Missing EPIC links Frontend Output power: ? Frontend Watch: ? HPO Watch: N/A PMC: Locked: 25 days, 6 hours, 5 minutes Reflected power: 11.6w Transmitted power: 52.1W Total Power: 63.7W ISS: Diffracted power: 2.532% Last saturation event: 0 days, 3 hours, 43 minutes FSS: Locked: 0 days, 3 hours, 43 minutes Trans PD: 5.405V , TPD: 0.012Vpp Closing FAMIS #11049
TITLE: 01/26 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC STATE of H1: Observing at 118Mpc INCOMING OPERATOR: Jeff SHIFT SUMMARY: One lock loss from observing. Took three attempts to get back to NLN, but no intervention was required. Rode through a series of earthquakes in Japan. LOG: 20:34 UTC Lock loss from observing. 20:47 UTC Lock loss from RESONANCE. 21:15 UTC Lock loss from MOVE_SPOTS. 21:53 UTC NLN. 21:54 UTC Observing. No SDF differences. 22:41 UTC Changed SEI_CONF from WINDY to EARTH_QUAKE for a 5.5 magnitude earthquake in Japan. 23:57 UTC Set SEI_CONF back to WINDY.
FAMIS 12884 There is a broad peak around 60 Hz in the ETMX ST2 spectra. Is this expected? ETMY_ST1_CPSINF_H2 may be elevated.
Have remained locked and in observing. No issues.
TITLE: 01/26 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Observing at 117Mpc
OUTGOING OPERATOR: Niko
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 4mph Gusts, 3mph 5min avg
Primary useism: 0.04 μm/s
Secondary useism: 0.45 μm/s
QUICK SUMMARY: No issues.
TITLE: 01/26 Owl Shift 08:00 – 16:00 (00:00-08:00), all times posted in UTC
STATE of H1: Observing
INCOMING OPERATOR: Patrick
SHIFT SUMMARY: Sudden lockloss followed by FSS locking trouble. After re-locking gccore-0ran out of disk space and had to be restarted. Locked and Observing 3 hours.
LOG:
09:49 (01:49) Switching EQ configuration to WINDY after 5.7 in Aleutians
10:36 (02:36) Changing ETMX mode 13 gain from 0 to 15
10:45 (02:45) Sudden lockloss, FSS unlocked
14:15? (06:15) CDS workstations stopped connecting to the internet.
15:30 (07:30) gccore-0 router restarted, internet up and running
Noticed that the internet had stopped working for CDS workstations and was unsure of how to fix it. Richard came onto the site and restarted the gccore-0 router (the one that was already on) in room 163, apparently it had run out of disk space. Everything seems to be working fine now, no events or EQ's missed.
Not sure why this change occurred during the re-locking process. Accepting sdf diffs to go into Observe.
Something is rounding these values. Their actual values should be the higher precision ones, but I also don't think that it really matters other than from a consistency standpoint. I'll look into this.
I believe that I found this discrepancy in lscparams.py. It wasn't the code that was rounding it, but it must have been a human. The filter medm only displays the offset values to the precision of 10*-1, even though the actual value of it could be much more. Ex: offset value actual = 10.15, displayed = 10.2
Either way, the place in the code that was doing it I have changed and reloaded the appropriate nodes.