Increase L3 low voltage ESD monitor channel sampling frequency
Betsy, Dave: WP5602
The models h1susauxe[x,y] were modified to increase the DAQ acquisition rate of the four L3_LVESDAMON quadrant channels (LL,LR,UL,UR) from 256Hz to 2048Hz. The LVESDAMON parts are defined in the common simulink file LVESD_STAGE_MONITOR_MASTER but their DAQ channel list is defined in the top level mdl file, so no common file change was needed.
After the restart of the models and the DAQ, I confirmed that the full data for these channels back when they were at 256Hz is no longer available from the control room NDS-1 CDS servers. Past trend data is available, just not past full data. After 3 weeks the NDS-1 frames will have cycled through and this will be moot point.
Clearing stuck test points
Dave:
I noticed that several frontends has stuck test points open. These were all cleared this morning. I tested the conditions which would leave testpoints stuck open, details in another alog.
2FA log into LHO DTS system
Dave, Larry, Jonathan, Carlos:
The LHO DMT system was further secured by requiring two factor authentication login. This required pre-distribution of keys to the primary DMT administrators.
Adding Beckhoff SDF channels to the DAQ
Jonathan, Dave: WP5603
The H1EDCU_SDF.ini file was expanded to cover the new Beckhoff SDF system.
DAQ restart
Dave:
The DAQ was restarted just once at 11:58 (end of maintenance). This restart covered the susaux model changes and the EDCU inclusion of the Beckhoff SDF channels. This was a clean restart with no problems.
This entry follows upon the entry 23167 where the frequency of the 3rd and 4th harmonic for the QUAD suspensions violin modes were identified. This entry is also complementary to Evan Hall's entry 22847 where similar Q's were measured with a different technique.
In this analysis, a line tracker (iWave) was applied over each of the identified 3rd and 4th harmonic frequencies (23167) on 21 hours of data during which the detector was continuously in Observing mode and with the damping filters turned off, data analysed started from 2015-10-21 21:30:00. The channel I used is H1:OMC-DCPD_SUM_OUT_DQ downsampled to 8192Hz in order to be able to handle the considerable ammount of data.
The line tracker was set to lock, on an automated way, to each of the monitored frequencies of interest. The tracker provides the frequency value which it is following and the amplitude of that frequency as a function of time. This information is provided in real time with the data being analysed. Although I automated the process the line tracker could not always lock to the mode of interest, in a few cases it locked to the wrong mode of higher amplitude and/or was not able to separate modes of high amplitude and close proximity. Therefore a targetted run had to follow the automated one.
The result of the analysis is summarised on the attached 'png' plots which shows; in each column the mode monitored with the top plot being the frequency tracked as a function of time and the bottom plot the 'log(Amplitude)' (Napierian or natural logarithm of the mode's amplitude). The red dashed lines are respectively the median of the tracked frequency and the fitted first order polynomial to the 'log' of the mode's ringdown.
Notice that monitoring 21 hours at 8192Hz resolution of 50 modes provide a huge ammount of data so here I only present a summary of the results, and this is also the reason why the plots shown are .png files.
The first order polynomial fitting of the ringdown was done using Matlab's 'polyfit' function which implements a least-squares minimization fitting. This function also provides an estimate of the covariance matrix of the fitted coeficients which is used to calculate the standard error or variance of the estimated coeficients for the linear fit of the log(Amp) ringdown. In particular only the slope of the fitted line is used to estimate Q = Pi * f0 / abs(slope_fit), where f0 is the median of the frequency tracked. The median of the tracked frequency has an observed uncertainty smaller than 1mHz which makes the Q relative uncertainty to be dominated by the slope fitting uncertainty as given by the covariance matrix of the fitted coefficients. Therefore the reported error on Q will be given by the uncertainty of the slope of the fit as:
(Delta(Q) / Q)^2 = (Delta(slope_fit) / abs(slope_fit))^2
Next I summarise the results in 4 columns (also on attached .txt files labelled 'Q_results_3Harm_1stFreq_2ndQ_3rdDeltaQ_4thEHresults' and ''Q_results_4Harm_1stFreq_2ndQ_3rdDeltaQ_4thEHresults); first is the mode frequency, second is my estimated Q, third is the estimated Q error, and 4th is Evan Hall's results from 22847 for comparison:
Mode frequency (Hz) Q (line tracker) Delta(Q) Q_from_22847
1.0e+09 *
0.000001456177151 1.055261277139490 0.000021679047341 1.060000000000000
0.000001456842619 1.011674961643711 0.000024977780728 1.020000000000000
0.000001461409317 0.547106388691582 0.000007012695846 0.550000000000000
0.000001461732469 1.000243995219630 0.000121822842175 1.000000000000000
0.000001461859533 0.673721968942594 0.000056781365996 0.644000000000000
0.000001462031866 1.015448724742734 0.000039055044799 1.030000000000000
0.000001462313302 1.109264503070151 0.000020406518349 1.120000000000000
0.000001462596624 0.879503445780186 0.000090574514768 0.921000000000000
0.000001463096689 0.881010088452959 0.000383879344618 0.995000000000000
0.000001463100039 0.990987050813072 0.000431799209313 0
0.000001467475846 1.089361798635816 0.000107769329936 1.130000000000000
0.000001467964869 0.979770107952095 0.000024671825593 1.000000000000000
0.000001470380790 0.886560854120574 0.000042794470546 0.894000000000000
0.000001470826225 1.046162403099169 0.000070957888675 1.040000000000000
0.000001471928631 1.433692732321030 0.000246428147278 1.280000000000000
0.000001472216373 1.036874013551553 0.000319968824557 1.070000000000000
0.000001472450299 1.116249774693906 0.000012761989599 1.130000000000000
0.000001474079863 1.178125176004288 0.000086507667346 1.170000000000000
0.000001475097416 1.001120432026481 0.000377881305540 0.935000000000000
0.000001475251394 1.148066981481587 0.000155330486516 1.160000000000000
0.000001478169574 0.781717093501666 0.000095725814070 0.830000000000000
0.000001482585386 0.865266831531971 0.000049369138115 0.879000000000000
0.000001484077440 0.912365853159565 0.000100741959112 0.914000000000000
0.000001484430000 0 0 0.796000000000000
0.000001484525699 0.821953404180692 0.000053588794283 0.836000000000000
0.000001484668763 1.396430023353472 0.000359948050123 1.270000000000000
0.000001922925589 0.806732893457201 0.000050155023271 0.812000000000000
0.000001923612098 0.904079503131098 0.000101465317927 0.856000000000000
0.000001923854589 0.730146274074320 0.000057632970265 0.741000000000000
0.000001923861257 1.045943198261562 0.000286910927180 1.000000000000000
0.000001924673359 0.656777206317145 0.000037377872702 0.675000000000000
0.000001924914736 0.822610665784300 0.000055143089987 0.845000000000000
0.000001926240582 0.877913538609440 0.000041733066792 0.888000000000000
0.000001927465534 1.193131464187697 0.000196087122798 1.080000000000000
0.000001928461859 0.491982285283618 0.000060799517584 0
0.000001929312799 1.014511076625149 0.000491391979504 0.742000000000000
0.000001931573475 0.770986524485489 0.000120874236513 0.778000000000000
0.000001932139817 0.721080850064806 0.000077175334498 0.739000000000000
0.000001932335653 0.723984558093199 0.000083370684684 0.713000000000000
0.000001932612502 0.802178526483954 0.000016727734773 0.806000000000000
0.000001940322842 0.727877169848855 0.000210139484624 0.778000000000000
0.000001940663844 0.923330707711907 0.000027923601820 0.941000000000000
0.000001941349656 0.922491569137019 0.000274707300452 0.906000000000000
0.000001942174877 1.171274720414585 0.000377051759607 1.050000000000000
0.000001942390477 1.094325186350570 0.000475289691312 0
0.000001943777687 0.914373092200222 0.000483429769721 0
0.000001946732789 0.732800137163962 0.000093031972218 0.677000000000000
0.000001954459289 0.803950536039718 0.000153319383649 0
0.000001955921818 0.684755442755530 0.000143761779921 0
0.000001957335075 0.651607142944878 0.000091322052084 0
0.000001959023577 0.785016144699797 0.000093723756453 0
NOTE: Although there are not big differences in results with entry 22847 for the 3rd harmonics, however some difference is observed on the Q's of 4th harmonics, also 7 more modes are reported here for the 4th harmonics.
Just to clarify, the period of time analysed in this entry was characterised by having the 3rd and 4th harmonics damping filters turned OFF but the filters for the fundamental and 2nd harmonics of the test masses were turned ON.
(Full DQ shift report can be found at: https://wiki.ligo.org/viewauth/DetChar/DataQuality/DQShiftLHO20151105) Data quality during 5 - 8 November was mostly very good, up until the return of RF45 problems in the last few (UTC) hours of 8 November. Range hovered at or near 80 Mpc (yay!). Duty factor for each day (5th - 8th): 79.5%, 87.2%, 63.9%, 55.8%. The last day lost a lot of time to an earthquake, then high microseism. Many of the "usual suspects" are still present: the very loud glitches, the EY magnetic glitches, and the wandering line at ~640 Hz (and its harmonic). Daily CBC ran smoothly each day (which makes me happy!), and results were encouraging. For the BNS mass range, all four days showed clean histograms with no significant outliers in NewSNR; maximum NewSNR of the four days: 7.31, 7.40, 7.24, 7.39. The BBH range was pretty darn good, too: maximum NewSNR for each of the four days: 7.92, 8.74, 8.54, 7.69. (Any day when this is below 8 is excellent. Even days where the loudest event is below 9 is not too bad.) These searches do indeed respond to loud glitches, but the chi-squared weighting that creates the NewSNR statistic is (mostly) able to push those glitch responses down to low values where they don't hurt anything.
Done with maintenance activities, I started IA about 15 min ago. Full steam ahead.
WP 5604
In an effort to understand noise vs tilt, I've rotated (Yawed) the subject unit -90 degrees such that the x channel represents -Y and the y channel represents +X. Now we need some wind to generate some tilt.
Reset the counts for the normal Tuesday task.
HAM4: 13462 counts
HAM5: 932 counts
I reset the H1 PSL Front End power watchdog at 17:09 UTC (09:09 PST).
I also added 150mL of water the the PSL crystal chiller, as I noticed it was low when coming out of the LDR.
I couldn't open up any new medm windows. Everything else seemed to be working fine though. I killed the sitemap process and restarted it, but this did not fix the issue. After the reboot it all worked well.
It seems like this work station in particular has been having issues lately...
Had the same problem occur around 01:00 (17:00). Closed all open applications and powered cycled terminal. Informed Dave & Carlos.
TITLE: "11/10 [DAY Shift]: 16:00-23:00UTC (08:00-16:00 PDT), all times posted in UTC"
STATE Of H1: Observing at 78Mpc for 7hrs
OUTGOING OPERATOR: Travis
QUICK SUMMARY: He had a quiet shift, timefor maintenance.
.
Out of Observing and into Maintenance. I flipped the bit a few minutes after the receiving bay roll up door was rolled up.
lhoepics.ligo-wa panic()'ed after out-of-memory killing all of the sshd processes, then parts of systemd. I rebooted it at 7:56AM PST (15:56 UTC).
Title: 11/10 Owl Shift 7:00-15:00 UTC (0:00-8:00 PST). All times in UTC.
State of H1: Observing
Shift Summary: After the lockloss early in my shift, it has been a very quiet night. Only one ETMy saturation that did not seem to be related to any RF45 business. No RF45 glitches that I witnessed. All is calm.
Incoming operator: Ed
Activity log:
8:32 Lockloss
8:45 PRMI to DRMI transition fails
9:11 Observing
15:30 Landscapers on site
16:00 Let the maintenance day begin!
This alog will present some plots to support a request that H1:LSC-MOD_RF45_AM_CTRL_OUT_DQ be added to the raw frames, because the other RF45 channels don't witness the problem well. I believe that's already known and expected. I plot two known times of RF45 problems. The first two plots are the channel we will request, the next two are the ERR channel, and the last two are the AC channel. We will also need this channel extracted from the commissioning frames and saved somewhere permanent. We'll look into how far back we need it, which I think will depend on when the driver was swapped.
Locking in Observing since the earlier lockloss. Going on 4 hours now.
Sometimes the problem with RF45 modulation can manifest in DARM as a wandering comb of harmonics or as a wandering band of excess noise. Here are a few plots of DARM and the RF45 modulation monitor during these times so people can recognize when this is happening in an Omega scan or spectrogram.
A bit of tuning up in PRMI and we are back to Observing. Note: PRMI to DRMI transition failed.
Nothing obvious, seismic and wind calm, ASC loops stable. VerbalAlarms announced MC2 saturation first.
Activity Log: All Times in UTC (PT) 00:00 (16:00) Take over from Ed 00:22 (16:22) Kyle & Gerardo – Back from X2-8 00:56 (16:56) Reset HAM4 & HAM5 L4C WD counters 07:20 (11:20) Kyle – On site, going down X-Arm to X2-8 to turn on generator 07:58 (11:58) Kyle – Leaving the site 08:00 (00:00) Turn over to Travis Title: 11/09/2015, Evening Shift 00:00 – 08:00 (16:00 – 00:00) All times in UTC (PT) Support: Marissa Incoming Operator: Travis Shift Summary: A good evening shift for IFO operations. The IFO has been locked a NOMINAL_LOW_NOISE, 22.1w, at 81Mpc and Observing for the past 8 plus hours. Winds have generally been a light to gentle breeze (4 to 12 Mph). Seismic activity has been low all shift. Microseism is holding steady at 0.4 um/s for the past 12 hours. There have been five ETM-Y saturations this evening, three occurring during the first half of the shift. No RF45 glitches have been observed.
Generator should run through the night and all day tomorrow (powering lights used as heat in preparation for closing 10" gate valve and subsequent install of BT ion pump tomorrow)