TITLE: 01/08 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Camilla
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 9mph Gusts, 6mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.25 μm/s
QUICK SUMMARY: Relocking now, almost there.
Wind has died back down to < 25mph. Locked and observing 14h30.
When I restarted the alarm handers at 08:12UTC the vacuum alarm didn't go off as normal so I wonder if the alarm handlers aren't connecting correctly (tagging CDS).
TITLE: 01/08 Owl Shift: 08:00-16:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 113Mpc
OUTGOING OPERATOR: Jim
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY
Wind: 29mph Gusts, 27mph 5min avg
Primary useism: 0.08 μm/s
Secondary useism: 0.28 μm/s
QUICK SUMMARY: Locked 10hours. Wind is picking up again, now sustained at 25-30mph.
TITLE: 01/08 Eve Shift: 00:00-08:00 UTC (16:00-00:00 PST), all times posted in UTC
STATE of H1: Observing at 115Mpc
INCOMING OPERATOR: Camilla
SHIFT SUMMARY: Quiet shift, other than the wind.
LOG:
Winds have been increasing through the evening, but didn't start affecting range until we started getting gusts to ~40mph.
There are 1 STS proof masses out of range ( > 2.0 [V] )!
STS B DOF X/U = 4.657 [V]
All other proof masses are within range ( < 2.0 [V] ):
STS A DOF X/U = -0.77 [V]
STS A DOF Y/V = -0.933 [V]
STS A DOF Z/W = -0.401 [V]
STS B DOF Y/V = -0.484 [V]
STS B DOF Z/W = -0.311 [V]
STS C DOF X/U = 0.36 [V]
STS C DOF Y/V = 0.861 [V]
STS C DOF Z/W = -0.113 [V]
STS EX DOF X/U = -0.124 [V]
STS EX DOF Y/V = 0.279 [V]
STS EX DOF Z/W = 0.203 [V]
STS EY DOF X/U = 0.454 [V]
STS EY DOF Y/V = -0.366 [V]
STS EY DOF Z/W = 0.682 [V]
Assessment complete.
Attached plot shows violin mode damping settings that are different than what guardian sets. All are damping well.
The guardian snapshot is not correct, not sure why, but it does not include IY mode18 who's gain in guardian is 0, and was set to 300 last night.
The GigE cameras have a configuration file that sets the Analog Gain. Today I changed the Analog Gains and Digital Gains, to show that in NLN these changes reduce the saturation of the cameras. Once the saturation is reduced, other features in the camera image are visible.
I reverted the changes, since they only apply to NLN. The NLN settings will most likely not work at low power, so settings for 2W and possibly 10W need to be identified, and all changes to the camera settings put into guardian, before using the gains I identified today.
To show the difference in the image quality, each attachment has the camera view with current settings on the left, and on the right is the camera view with new settings. The analog and digital gain settings are in the title of each image.
Changes in analog gains were split about evenly between increasing and decreasing the gain.
On IMC_TRANS, even with very low analog gain and very low didgal gain, the beam was saturated. To correct the saturation requires adding a filter to reduce the power on this camera.
Cameras I looked at today:
ETMX mode 9 was rung up and was successfully damped by applying a damping Gain of negative 10. Plots are attached below.
Cheryl and I have been watching the trends of several modes in the last few weeks. Many of the damping filters have also been tweaked and is in the process of being loaded (or already have). A detailed alog is due and will be posted asap.
TITLE: 01/08 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: Jim
SHIFT SUMMARY: Wind has died down significantly, relocking after maintenance was a non-issue.
LOG:
I've added and tested INCREASE_FLASHES that will now move the TMSs if necessary. The order it will adjust is: ETM P, ETM Y, TMS P, TMS Y. If the flashes ever get above the threshold, then it will stop and try to lock. Just as before, ISC_LOCK will attempt I.F. two times if it has to, before giving up and notifying to align by hand.
The downside with this state is that it can very slow. If the alignment is far off, the state will take its time getting there. This will be my next project if this current version works well.
The locking intervention document does not change, and please give me call if there are any issues.
Locking:
Recovered after maintenance day. I ran an initial alignment right away because of wind, earthquakes, and my testing of green locking automation moving the TMS. During initial alignment, Sheila loaded in a change from Jan. 2 (alog54240) for the triggering in SRY locking. This change allowed us to lock SRC. After initial alignment, there was no operator intervention in the locking.
SDFs
The fume hood in the optics lab was on until 2245 UTC. This may have been a noise source for the first ~30min of observation.
WP8507
Camilla, TJ, Dave:
The L2 Damp Mode Gains values are now available as EPICS channels. Previously they were listed in the lscparams.py file.
This was a two part install:
1. I created a new EPICS IOC to host the new channels. It is running on h1fescript0 and its details are available in this wiki page
2. TJ made a modification to VIOLIN_DAMPING.py to write the gains to the new channels.
Now H1 has locked, the gain values have been updated to the EPICS PVs. I created an MEDM to show the 80 values (20 per test mass).
MEDM is /opt/rtcds/userapps/trunk/cds/h1/medm/SUS_VIOLIN_MODE_GAINS.adl
Populating these channels is done from the VIOLIN_DAMPING Guardian node in the DAMPING_SETTINGS state. It reads the lascparams.py file to get the gain settings, and then puts them into these channels. This way they are updated every lock. The relavant code:
#set the settings for the modes that are damped on this test mass
for mode, setting in modes.items(): # iterates through modes in lscparams # Add the lscparams gain values to the NORMALGAIN chan
ezca['SUS-{}_L2_DAMP_MODE{}_NORMALGAIN'.format(sus, mode)] = setting['gain']
I didn't give credit where credit is due, the above code is from Camilla. I loaded it in and watched it work.
Continued with labeling of the ISC RF cables. Work was limited to the following racks:
Rack ISC-C3
Rack ISC-C4
Rack ISC-R1
No cables were disconnected.
NOTE: WIFI can be remotely enabled/disabled, and the script for the CDS overview WIFI ON/OFF indicator is being updated, but is not yet updated, so today WIFI in the LVEA was on, but the CDS medm was green, which indicates it's off. Moral of the story is to check with Carlos.
Attached below are the results for this month's OPLEV charge measurements performed on ETMX and ETMY.
The effective bias voltage on the ETMX is around 50V and 60V for pitch and Yaw respectively, for the 1st quadrant. These values have reduced from last months measurements. The bias voltage in other quadrants haven't changed much and are within acceptable values (i.e. 50V).
For the ETMY, the effective bias voltage on all 3 quadrant for both pitch and yaw are within acceptable values. There charge accumulation in the last one month is not significant.
After the measurements we complete, the sliders values were restored and SDF differences were removed.
J. Driggers, S. Dwyer, J. Kissel, T. Shaffer, B. Weaver The suspension models continue to be most difficult systems to reconcile, given that they are used by so many systems and guardians, and have so many special cases. Betsy's putting in a separate log about the reconciliation she did with the BSC SUS's, but I covered five things: (1) For SUS ETMY, while the UIM (L1) coil driver request state was 1.0 (i.e. with all low passes OFF), and all the filters in the COILOUTF banks were in their correct state to compensate for that analog configuration, the COILOUTF banks were showing filter module SDF differences. I accepted the DIFFs such that the safe.snap agrees with the correct state. (which, for ETMY actually points to the "down.snap" -- and it is *NOT* one of the suspensions where safe = down = OBSERVE because it is a globally controlled suspension). (Note, the actual state we want the UIM (L1) stage is different as a result of the DAC noise study performed by Keita in Nov 2019 -- see LHO aLOG 53376: ITMX : 4, ITMY : 4, ETMX : 1, ETMY : 2) Betsy and I have made sure that these QUADs' L1 coil drivers are *in* the above mentioned state *and* both the COILOUTF and STATEREQ are monitored. (2) The ETMX_L3_CAL_LINE clock gain (i.e. the ETMX calibration line on the TST (L3) stage) was set to 0.0, i.e. OFF. The calibration lines don't have an output switch, so they don't have a switch to turn their output off, which is how the SUS guardians make sure all outputs are OFF in the SAFE state normally. These lines -- in the O3 IFO DARM control configuration -- only need to be on ETMX, and since these calibration lines are such small amplitude, (on the order of 10 DAC counts RMS to each coil), I don't think it's an issue to just keep them all ON in the safe.snap. (3) SUS PR2 was especially tricky. This SUS is - touched by two separate guardians (ALIGN_IFO and ISC_DRMI), - the filter modules are forced to be (i.e. the only_on) *different* configurations when they are used ISC_DRMI (in PREP_DRMI_ASC) ezca.get_LIGOFilter('SUS-PR2_M1_LOCK_P').only_on('FM5','FM6', 'FM9', 'OUTPUT', 'LIMIT','DECIMATION') ezca.get_LIGOFilter('SUS-PR2_M1_LOCK_Y').only_on('FM5','FM6', 'FM9', 'OUTPUT', 'LIMIT','DECIMATION') ALIGN_IFO (in PREP_INPUT_ALIGN) ezca.get_LIGOFilter('SUS-PR2_M1_LOCK_P').only_on('DECIMATION','OUTPUT','FM2','FM6','INPUT') ezca.get_LIGOFilter('SUS-PR2_M1_LOCK_Y').only_on('DECIMATION','OUTPUT','FM2','FM6','INPUT') - the SDF says safe.snap value current value difference H1:SUS-PR2_M1_LOCK_P F1, F9, LT, OT, DC F2, F6, OT, DC F1, F2, F9, LT H1:SUS-PR2_M1_LOCK_Y F1, F9, LT, OT, DC F2, F6, OT, DC F1, F2, F9, LT - AND because these are filter modules and we have individual monitoring control over each switch, the INPUT, FM1, FM5, and FM6 are unmonitored. Yuck! For both pitch and yaw, these filters are FM1 z:p = [none]:0 integrator FM2 Cal gain only filter, gain(1.875) FM6 z:p = [none]:0 integrator FM9 -100dB gain only filter, gain(-100,"dB") Jenne and I have concluded that with FM1 and FM6 being identical filters, the FM1 difference is likely a result of the integrator moves for better ASC control -- namely moving the integrators down stream of other filters that switched in and out -- that was done in Sep 2019 LHO aLOG 51715. So, we performed the following action: - re-monitored specifically the FM1 switch. - briefly, - monitored everything, - changed the filter configuration to what ISC_DRMI (in PREP_DRMI_ASC) forces it to be -- because an initial align had been run between our last lock loss and this reconciliation, so it was in the ALIGN_IFO (in PREP_INPUT_ALIGN) configuration - accepted the changes, and then - unmonitored FM2, FM5, FM6, FM9, and the LIMIT buttons (i.e. all those controlled by *both* ALIGN_IFO and ISC_DRMI) - and notably left FM1 *monitored* since we no longer want this integrator ever to be on (since it's replaced that now in FM6). Finally, with PR2, there remained SUS-PR2_M3_LOCK_OUTSW_P SUS-PR2_M3_LOCK_OUTSW_Y which, again is requested to be in a different state (0.0 vs. 1.0 i.e. ON vs. OFF) in the prep states of ISC_DRMI and ALIGN_IFO. Since this is guardian forced to be in either state when needed, we've chosen to *unmonitor* it. (4) SR2 required a very similar operation as PR2, but the filter modules are different: - touched by two separate guarians (ALIGN_IFO and ISC_DRMI), - the filter modules are forced to be (i.e. the only_on) *different* configurations when they are used ISC_DRMI (in PREP_DRMI_ASC) ezca.get_LIGOFilter('SUS-SR2_M1_LOCK_P').only_on('OUTPUT','LIMIT', 'DECIMATION','FM3','FM5','FM8')#SED moved integrator from FM2 to FM5, Sept 2 2019 ezca.get_LIGOFilter('SUS-SR2_M1_LOCK_Y').only_on('OUTPUT','LIMIT','DECIMATION','FM3','FM5','FM8') ALIGN_IFO (in PREP_INPUT_ALIGN) ezca.get_LIGOFilter('SUS-SR2_M1_LOCK_P').only_on('FM5', 'FM2', 'INPUT', 'OUTPUT', 'DECIMATION', 'LIMIT') ezca.get_LIGOFilter('SUS-SR2_M1_LOCK_Y').only_on('FM5', 'FM2', 'INPUT', 'OUTPUT', 'DECIMATION', 'LIMIT') - the SDF says safe.snap value current value difference H1:SUS-PR2_M1_LOCK_P IN,F3,F5,F8,LT,OT,DC F2,F5,OT,DC F2,F3 H1:SUS-PR2_M1_LOCK_Y IN,F3,F5,F8,LT,OT,DC F2,F5,OT,DC F2,F3 - AND the INPUT and FM8 are unmonitored. So, I did the same actions: - briefly - monitored everything in these filter modules - set the filter module in the way that ISC_DRMI wants it (again because things were currently set how ALIGN_IFO wants it, and that's abnormal) - accepted the diffs - unmonitored everything the guardians touch: the input, FM2, FM3, FM5, and FM8 (I left the limiter, the output, and the decimation monitored, since both guardians want these switches ON.) - and unmonitored the M3 LOCK output switches, SUS-SR2_M3_LOCK_OUTSW_P SUS-SR2_M3_LOCK_OUTSW_Y (5) We are leaving several suspensions with some residual DIFFs in place for now: SUS_ETMX, SUS_ETMY, SUS_BS, SUS_PRM, SUS_SRM. These are globally controlled suspensions, and the channels in question are *almost* certainly controlled by guardian, but we'll tackle them next week.
I found the following command written by Dave in August 2019 (and remembered by Jenne today) to peruse the paths of SDF files very useful:
/ligo/cds/userscripts/sdf_files_report
Here's an example usage for the suspensions, to show what suspensions use what files:
$ sdf_files_report | grep sus
model_name: | safe | down | OBSERVE
h1susbs: | ->down | 10-Dec-2019 | 25-Jul-2019
h1susetmx: | ->down | 07-Jan-2020 | 06-Jan-2020
h1susetmxpi: | 25-Jun-2019 | none | 26-Jun-2019
h1susetmy: | ->down | 07-Jan-2020 | 06-Jan-2020
h1susetmypi: | 06-Aug-2019 | none | 01-Nov-2019
h1sushtts: | 13-Jun-2019 | none | ->safe
h1susim: | ->OBSERVE | none | 26-Dec-2019
h1susitmpi: | 08-Jan-2019 | none | 16-Mar-2019
h1susitmx: | ->down | 10-Sep-2019 | 26-Nov-2019
h1susitmy: | ->down | 10-Sep-2019 | 26-Nov-2019
h1susmc1: | ->OBSERVE | none | 07-Jan-2020
h1susmc2: | ->down | 17-Sep-2019 | 30-Sep-2019
h1susmc3: | ->OBSERVE | none | 07-Jan-2020
h1susomc: | ->OBSERVE | none | 10-Sep-2019
h1susopo: | 20-Dec-2019 | none | ->safe
h1suspr2: | ->down | 07-Jan-2020 | 03-Sep-2019
h1suspr3: | ->down | 17-Sep-2019 | 05-Jun-2019
h1susprm: | ->down | 29-Oct-2019 | 17-Sep-2019
h1susproc: | 30-Apr-2019 | none | 16-Mar-2019
h1susprocpi: | 03-Jul-2019 | none | ->safe
h1sussr2: | ->OBSERVE | 07-Feb-2018 | 07-Jan-2020
h1sussr3: | ->OBSERVE | none | 01-Nov-2019
h1sussrm: | ->down | 10-Dec-2019 | 01-Nov-2019
h1sustmsx: | ->OBSERVE | none | 07-Jan-2020
h1sustmsy: | ->OBSERVE | none | 07-Jan-2020
The arrow "->" indicates that the file in that column points to another column's file.
The date in a given column indicates when that file was last changed.
E.g. h1sussr2's safe.snap points to the OBSERVE.snap, and the OBSERVE.snap was last changed on 07-Jan-2019, i.e. today, because of the reconciliation work I did above.
We should use this function to make the SUS obey a consistent ethos. I can immediately think of two example ethos:
(1) that SUS touched by global control guardians (ISC_LOCK, ISC_DRMI, ALS_XARM, ALS_YARM, ALS_DIFF, ALS_COMM, SQZ_MANAGER, VIOLIN_DAMPING, IMC_LOCK, OMC_LOCK) should have a "down" file, separate from an "OBSERVE" file and the remaining SUS should only have an OBSERVE (i.e. the safe and/or down link to the OBSERVE).
or
(2) that we should carefully track (and unmonitor) what parts of the SUS are touched by global control guardians, and all SUS should have only one (an OBSERVE) snap file.
There are other options I'm sure -- which is why the SUS continues to be a confusing battle ground of all options, and people reconciling have differing opinions between them and even from (day-to-day with themselves!).
BUT -- this tool helps a lot! Thanks Dave!
Original mention -- LHO aLOG 50963.
Gerardo fixed this yesterday. This is the new normal.
Yes, this is the new norm. The modifications done to the alarm system is as follows, removed all channels related to H2 and the instrument air for the outer buildings (they were in constant alarm), removed some repeated channels and added some ommited channels. Also updated the guidance that aplies to alarms related to vacuum channels.