Robert, Dave:
I have cleared the stuck excitations on h1pemcs and h1pemey together with their testpoints.
Posted are the one year trends of the BOSEMs INMON on the ZM suspensions. There are zoomed and unzoomed plots.
TITLE: 04/15 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Unknown
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
SEI_CONF state: SC_OFF_NOBRSXY
Wind: 16mph Gusts, 9mph 5min avg
Primary useism: 0.05 μm/s
Secondary useism: 0.12 μm/s
QUICK SUMMARY:
Today, I completed all terminations within the Vertex+XBM HEPTA control panel and, also, brought it up to the current revision (I think!). Initial testing demonstrated newly introduced gremlins most of which turned out to be the result of intermittent or opened connections resulting from having disturbed and or strained the existing "push-to-connect" type terminations whilst completing the newest terminations. The remaining unresolved issue is that selecting REMOTE from the HEPTA control panel results in the HEPTA pump starting. I did not troubleshoot this issue today but will next time. Also, testing of the 2 1/2" intake gate valve was disappointing at first and lead me down some troubleshooting "rabbit holes" but eventually I figured out that the "air-to-open, spring-to-close" actuator was just really sticky. Once I upped the supply air pressure to 70psi and cycled it 6 or 8 times, it began to act as expected even after returning to the nominal 50psi.
Cheryl, Rahul
We have finished taking transfer function measuremnts for 4 triple suspensions today, namely: PRM, SR2, SRM and MC1. All the supensions looks healthy and free of rubbing. The magnitude of the tf for PRM pitch and yaw tf measurement looks lower than that of the template. The resonant peaks are at the right place hence we believe everything is fine with this suspension too.
The templates are stored at the following locations,
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Data
2020-04-14_1500_H1SUSPRM_M1_WhiteNoise_L_0p01to50Hz.xml
2020-04-14_1500_H1SUSPRM_M1_WhiteNoise_P_0p01to50Hz.xml
2020-04-14_1500_H1SUSPRM_M1_WhiteNoise_R_0p01to50Hz.xml
2020-04-14_1500_H1SUSPRM_M1_WhiteNoise_T_0p01to50Hz.xml
2020-04-14_1500_H1SUSPRM_M1_WhiteNoise_V_0p01to50Hz.xml
2020-04-14_1500_H1SUSPRM_M1_WhiteNoise_Y_0p01to50Hz.xml
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SR2/SAGM1/Data
2020-04-14_1800_H1SUSSR2_M1_WhiteNoise_L_0p01to50Hz.xml
2020-04-14_1800_H1SUSSR2_M1_WhiteNoise_P_0p01to50Hz.xml
2020-04-14_1800_H1SUSSR2_M1_WhiteNoise_R_0p01to50Hz.xml
2020-04-14_1800_H1SUSSR2_M1_WhiteNoise_T_0p01to50Hz.xml
2020-04-14_1800_H1SUSSR2_M1_WhiteNoise_V_0p01to50Hz.xml
2020-04-14_1800_H1SUSSR2_M1_WhiteNoise_Y_0p01to50Hz.xml
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/SRM/SAGM1/Data
2020-04-14_2000_H1SUSSRM_M1_WhiteNoise_L_0p01to50Hz.xml
2020-04-14_2000_H1SUSSRM_M1_WhiteNoise_P_0p01to50Hz.xml
2020-04-14_2000_H1SUSSRM_M1_WhiteNoise_R_0p01to50Hz.xml
2020-04-14_2000_H1SUSSRM_M1_WhiteNoise_T_0p01to50Hz.xml
2020-04-14_2000_H1SUSSRM_M1_WhiteNoise_V_0p01to50Hz.xml
2020-04-14_2000_H1SUSSRM_M1_WhiteNoise_Y_0p01to50Hz.xml
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/MC1/SAGM1/Data
2020-04-14_2100_H1SUSMC1_M1_WhiteNoise_L_0p01to50Hz.xml
2020-04-14_2100_H1SUSMC1_M1_WhiteNoise_P_0p01to50Hz.xml
2020-04-14_2100_H1SUSMC1_M1_WhiteNoise_R_0p01to50Hz.xml
2020-04-14_2100_H1SUSMC1_M1_WhiteNoise_T_0p01to50Hz.xml
2020-04-14_2100_H1SUSMC1_M1_WhiteNoise_V_0p01to50Hz.xml
2020-04-14_2100_H1SUSMC1_M1_WhiteNoise_Y_0p01to50Hz.xml
We did a re-check on the PRM by re-running the Pitch and Yaw dof. This time we did not change the gain in M1_Test for P and Y dof (typically we change them to unity before running the measurements). As a result, the measurement ties up well with the reference as shown in the plot attached below. To sum it up, PRM is also healthy and free of any rubbing.
The new templates are stored at the following location,
/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Data
2020-04-15_1400_H1SUSPRM_M1_WhiteNoise_P_0p01to50Hz.xml
2020-04-15_1400_H1SUSPRM_M1_WhiteNoise_Y_0p01to50Hz.xml
In the dtt I have updated the reference to match the results with P and Y dof gain (in M1_Test filter bank) set to 1.0, given below is the correct template for future use.
2020-04-15_1500_H1SUSPRM_M1_WhiteNoise_P_reference_updated_0p01to50Hz.xml
2020-04-15_1500_H1SUSPRM_M1_WhiteNoise_Y_reference_updated_0p01to50Hz.xml
Finally exporting and processing this data for H1 SUS MC1, and along the way improving the templates, as I continuing the campaign to keep up librarianship with the history of all SUS (and today motivated by understanding the diversity in pitch mode frequencies among the builds). See attached .pdf for "individual" comparison against the model, which includes cross-coupling and OSEM basis response. (I agree with the assessment that the SUS looked healthy at this time.) To look in to the future of this SUS, see comments to LHO aLOG 57155, which compare this measurement against previous 2018 data and future 2020-10-29 data. In short -- they all look happily the same (because we haven't really touched this SUS since 2017).
Finally processing this 2020-04-14_1500 data (as well as some 2018-06_07_1648 data that had been taken but never aLOGed) for H1SUSPRM. Note that both 2018-01-03_2138 and 2018-06_07_1648 data sets suffered from the confusion about accidentally leaving the misalignment offset calibration gains of 1.875 and 2.681 ON in the TEST P and TEST Y filter banks, hence the confusion leading in to the 2020-04-14_1500 data that tripped up Cheryl and Rahul mentioned in the above comment LHO:55920. As such -- although they report a healthy suspension otherwise, I don't show those errant data sets in the collection of PRM measurements attached here. The collection *does* however include a future measurement from 2020-10-29_1600 (LHO:57155) which is also healthy. PRM has been good for quite some time! Excellent!
Finally processing these 2020-04-14_1800 measurements for H1 SUS SR2. Only posting individual measurements here. Look for "2021-11-23_1530" for comparison against other measurements (spoiler: SR2 has looked healthy at least 2018-05-02!).
J. Kissel And to complete the analysis of this collection of data, I've processed the 2020-04-14_2000 data for H1SUSSRM. Individual data and comparison against its past and one other sus of the same type attached. I concur that the SUS is healthy and unchanged at this time. (The cross-coupling of the Second, 2.2 Hz Roll Mode in to the transverse DOF that appears in the 2019 and 2020 measurements is not alarming: these T and R DOFs are fundamentally cross-coupled, and this "extra" feature goes away when the SUS is damped. I see no other issues.)
I have added an indicator of currently active nomachine sessions to the MEDM and reordered the columns to show the username first.
FRS 14496 Dave, Patrick:
The hourly autoburt was not backing up the IOC on opslogin0 (nomachine remote desktop session data). I tracked this to the local EPICS Gateway which runs on the autoburt virtual-machine (needed to prevent a broadcast storm every hour) not having the 10.22 subnet in its CA_ADDR_LIST. I extended this list to include 10.22.15.255 (note this is a 10.22.0.0/20 subnet) and restarted the gateway.
I also discovered that the h1brsex snap files were empty, with Patrick we tracked this to an incorrect target/h1brsex/h1brsexepics/autoBurt.req file. This was corrected.
I'm keeping FRS14496 opened as the BRS SDF snaps are empty until that system is fully installed (covered by FRS13236)
Completed generating a digital photo layout for ISCTEX (D2000144). Attached you will find two versions:
Making these layout takes a bit of time and is tedious to cut/paste each optical component individually, but once a layout is complete, it is much easier and quicker to add/remove items within a few minutes per component. At home I only had photos from Feb 2015, so this is what I worked with (I referenced the layout drawing D1201448v9 which is from March 2015; the latter is an older drawing version for H1 ISCTEX where we now use D1800270).
I can update this layout to what we currently have once I can get to work and upload photos off a camera/hard drive.
Currently photo layouts exist for ISCTEX & also the PSL (D1301029 from Feb 2013)
Next up: ISCTEY (D2000160).
I'm also referencing all of these layouts here: E2000219 (I don't have TCS tables on them, but if I could get access to them, it would be nice to make layouts for them as well.)
After finding some more recent photos (3/26/19) on my computer, I have updated D2000144 to a version 2. This updated version basically has the remake/update of the Hartman Beam Path. I also saw a handful of items which I missed in v1, so I added a couple of items on the table.
I modified the IFO_NOTIFY Guardian node to watch the SEI and SUS for any Watch Dog trips and notify if so. It will be cleared when all WDs are reset. I removed all the other tests that IFO_NOTIFY had for this temporary configuration. We can easily add more tests for this Phase 3 configuration of IFO_NOTIFY if we think of them.
People can sign up to receive these via the Lock Loss Alert medm screen.
I forgot to mention that I tested this on ZM1 by setting the trip level low, letting it trip, getting the alarm, and then resetting it all.
Weekly flow checks show both the PSL Crystal and Diode chillers are still running. Flow ranges look good.
I have finished taking transfer function measurements for HLTS (PR3, SR3) and HSTS (PR2): all 6 dof. Looking at the attached plots, I can confirm that these three suspensions are healthy and free of any rubbing.
I have stored the templates at the following locations,
/ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/SAGM1/Data/
2020-04-13_1700_H1SUSPR3_M1_WhiteNoise_L_0p01to50Hz.xml
2020-04-13_1700_H1SUSPR3_M1_WhiteNoise_P_0p01to50Hz.xml
2020-04-13_1700_H1SUSPR3_M1_WhiteNoise_R_0p01to50Hz.xml
2020-04-13_1700_H1SUSPR3_M1_WhiteNoise_T_0p01to50Hz.xml
2020-04-13_1700_H1SUSPR3_M1_WhiteNoise_V_0p01to50Hz.xml
2020-04-13_1700_H1SUSPR3_M1_WhiteNoise_Y_0p01to50Hz.xml
/ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/SR3/SAGM1/Data/
2020-04-13_1800_H1SUSSR3_M1_WhiteNoise_L_0p01to50Hz.xml
2020-04-13_1800_H1SUSSR3_M1_WhiteNoise_P_0p01to50Hz.xml
2020-04-13_1800_H1SUSSR3_M1_WhiteNoise_R_0p01to50Hz.xml
2020-04-13_1800_H1SUSSR3_M1_WhiteNoise_T_0p01to50Hz.xml
2020-04-13_1800_H1SUSSR3_M1_WhiteNoise_V_0p01to50Hz.xml
2020-04-13_1800_H1SUSSR3_M1_WhiteNoise_Y_0p01to50Hz.xml
ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PR2/SAGM1/Data/
2020-04-13_2200_H1SUSPR2_M1_WhiteNoise_L_0p01to50Hz.xml
2020-04-13_2200_H1SUSPR2_M1_WhiteNoise_P_0p01to50Hz.xml
2020-04-13_2200_H1SUSPR2_M1_WhiteNoise_R_0p01to50Hz.xml
2020-04-13_2200_H1SUSPR2_M1_WhiteNoise_T_0p01to50Hz.xml
2020-04-13_2200_H1SUSPR2_M1_WhiteNoise_V_0p01to50Hz.xml
2020-04-13_2200_H1SUSPR2_M1_WhiteNoise_Y_0p01to50Hz.xml
Finally processed this data (as well as the preceding 2018-06-07 data, which was never aLOGged). I concur that PR2 looks healthy during these measurements.
Issues with Access System both at LSB and OSB.
In the LSB we replaced a communications cable per vendor specs and updated the settings to each door. We confirmed each door responded by unlocking each door using a fob.
Chris. S. reported all doors in the OSB did not unlock using the fob. Richard verified/updated the settings for each door and I confirmed all OSB doors responded.
While onsite heard sewage pump alarm and acknowledged the alarm. Bubba was notified.
F. Clara, R. McCarthy
One of the things that SEI/DETCHAR have been working on is developing tools to give more real time early warning for large earthquakes like the Montana and Idaho earthquakes. The USGS has a server network that allows grabbing near real time ground motion data from different sites, so Anne Baer, Grace Johns and Ryan Fisher have been developing an Anaconda package to view eq-band timeseries from different sites. The plot this produces is shown in the attached screen shot. The plot gathers data in 2 second increments and runs like an ndscope, just fewer controls at the moment. I don't think you can scroll through past data or resize in real time. This morning DaveB helped me get this set up to run on an ops machine.
The idea is to monitor ground motion at stations the are between the site and likely earthquakes, hopefully to get a few minutes early warning. SEISMON and the USGS webpage have about a 10 minute lag (depending on where the earthquake is) between the earthquake and the report showing up in the database.
The process I had to go through was:
1. Make an alias in my bashrc by adding this line:
alias setupanaconda="source /opt/rtcds/userapps/release/cds/h1/scripts/setup_anaconda"
Then open a new terminal, run setupanaconda then type:
conda init bash
2. In a new terminal, use the new alias to active conda, then activate Dave's eq_fence environment:
(base) jim.warner@opslogin0:~ 0$ setupanaconda
(base) jim.warner@opslogin0:~ 0$ conda activate eq_fence
You will tell this was successful if (base) on the terminal line is replaced by (eq_fence).
3. Then run the plotter:
(eq_fence) jim.warner@opslogin0:~ 0$ seedlink-plotter -s "IU_COR:00BHZ, US_BMO:00BHZ, US_MSO:00BHZ, US_NEW:00BHZ, US_HLID:00BHZ" -b 30m --seedlink_server "rtserve.iris.washington.edu:18000" --update_time 2s
This will get you a live version of the attached plot. It gathers some data first, and the is a characteristic filter turn on transient for the first ~ minute or so of data, which is shown in the attached screen shot. I'd like to put this up on one of the NUCs so we can try running it for a few days and see if it blows anything up.
Also, this script pulls data from USGS servers, so we maybe don't want a dozen people just running this.
These checks were not made due to Phase-3. Closing FAMIS #13501
These checks were not made due to Phase 3. Closing FAMIS #13011
The following CPS is listed as over threshold (all others OK & all spectra attached):
* But it should also be noted that V1's Stage 1 spectra is similarly above all other CPSs for high frequency (similarly to V1's Stage 2 listed above).
Cheryl, Rahul
We have finished measuring the spectra (ASDs) for the top mass OSEMs for ETMX, ITMX and BS. They all look fine (and healthy). I am also attaching a comparison plot for each SUS from 2013-14.
This completes the spectra measurements for all top mass QUADs and BS.
The templates for the QUADs and BS is stored at the following location,
BS
/ligo/svncommon/SusSVN/sus/trunk/BSFM/Common/MatlabTools/plotbsfm_spectra.m
QUADs
/ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/MatlabTools/plotquad_spectra.m
Jenne, Cheryl, Jim and Rahul
We have re-measured the transfer function (for Pitch dof only) for all the QUADs and Beam Splitter after Jim changed the HEPI to offline state. We can confirm that all the suspension looks healthy and is free of any rubbing.
Please find the plots attached below.
Note - during the tf measurements the ISI (stage 1) has damping loop turned ON. We are not rubbing with the isolation loops are ON then we should also not be rubbing when they OFF (Jim stated that the isolation loops do not affect their DC position).
The motivation for this re-measurements comes come Cheryl's alog (55848) which suggested that L2 stage for ETMY is rubbing.
Cheryl, Stuart, Arnaud, Rahul
EDIT: (04/09/2020): I have re-run these (ETMY/ITMY) analysis after Arnaud suggested that I offset the Damping ON/OFF gps time by few mins and let things stabilize. The results from yesterday looked like damping ON/OFF measurements were taken with a transient in the signal.
Attached below are the amplitude spectral density for the Top mass OSEMs for the ETMY and ITMY suspensions. The plot compares the state when the damping was OFF (for an hour) and then ON. For comparison, I am also attaching the results from 2013-14 for ETMYand ITMY.
The noise floor for both ETMY and ITMY above 10 Hz is of the order of ~5e-11 m/rtHz (for the LTV dofs) and ~e-10 m/rtHz (for RPY dofs). There are no resonant peaks observed above 10Hz for the M0 stage osems. The resonant peaks are lower when the damping is ON.
However on comparing the 2020 results with that of 2013-14 (posted by J. Kissel alog 13184), I see that the noise floor in 2013 drops off by several orders of magnitude after 50Hz. I don't see this drop in my results taken today (maybe Jeff or Stuart/Arnaud can comment on this).
The spectrum were taken using a Matlab file stored at the following location,
/ligo/svncommon/SusSVN/sus/trunk/QUAD/Common/MatlabTools/plotquad_spectra.m
The matlab script used over here had few issues which was resolved swiftly by Stuart and Arnaud (from LLO). 24 out of 39 channels worked fine and the rest had some issues in the .m file (which is now fixed according to Stuart's email later in the evening).
Comments from J. Kissel: These OSEM spectra scripts are grabbing data from the frames (nds1 probably). In 2013 we were only storing the top-mass OSEMs at some ridiculously low sampling frequency — probably 128 Hz. As such, the Nyquist frequency was around ~50 Hz. Near Nyquist, the data aquisition system always applies a very aggressive digital down sampling / anti-aliasing filter. The filter is computed from the *ratio* between the rate at which the front-end model runs (in the SUS’s case this is 16 kHz) and the requested rate that the data is stored (in the this case 128 Hz). Thus, the data is filtered with the 128x filter show in the figure on page 3 of <https://dcc.ligo.org/LIGO-T1600059>.
Since then, we’ve up’d the rate by 2, to 256Hz, which means the Nyquist is *just* off the edge of your plot which goes to 100 Hz. And thus you don’t see the influence of the 64x filter.
