Displaying report 1-1 of 1.
Reports until 05:11, Monday 27 January 2020
H1 GRD (ISC)
corey.gray@LIGO.ORG - posted 05:11, Monday 27 January 2020 - last comment - 06:11, Monday 27 January 2020(54743)
Back Out ISC_DRMI Change?

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.

Images attached to this report
Comments related to this report
corey.gray@LIGO.ORG - 04:53, Monday 27 January 2020 (54744)

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.

corey.gray@LIGO.ORG - 06:11, Monday 27 January 2020 (54745)

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).  

Displaying report 1-1 of 1.