O1 days 108-110
No restarts reported on any of these days. No CDS front end or DAQ maintenance Tues 5th.
Bottom line: I don't see this mass centering made any difference. Although I did get the mass within spec, and it remains so, it was difficult as in it took many attempts. This may still indicate that the machine is not well enough leveled or still something more difficult to fix.
Attached are spectra of the STS2-B (ITMY) and STS2-C (HAM5) and coherences between them early Tuesday and Wednesday morning to compare them before and after the centering done yesterday, I adjusted the times to avoid an EQ Tuesday am. STS2-A remains rotated out of position so is not included in this comparison.
The attached spectra and coherences don't reveal any great improvement from the centering. The reference traces are after and the current traces are before the centering. The coherence and ASD continues to show that the Y channel looks pretty good and the X and Z channels much less so. If you look at the STS2 channel/axis orientations (see second attachment,) you'll see that the Y channel does not use the U axis sensor, and, the centering of the U axis was the problem axis. This is why I want to play with the level of the U axis and continue this examination.
Ops Owl Summary: 8:00-16:00UTC
State of H1: unlocked
Commissioners: Jenne, Sheila (fellow), JeffK
Shift Summary:
9:00 Lock and Observing finally
11:45 I realize the LVEA lights were still on, LLO is still down, so briefly out of Observe and I go turn them off, back to Observing right as LLO comes back up
13:45 An earthquake in Mexico knocks us out
14:15 Start trying to lock
15:00 Richard arrives and starts spreading sand around parking lot
15:00 I start initial alignment, high microseism is making locking difficult
Currently in observing at about 75 Mpc. So far everything looks better than last night. Sheila did some ASC tweeking before she left and it seems to have prevented the POP decay so far. Microseism is high-ish, wind is low. EX ISI is occasionally ringing up but I think the microseism is maybe to high to switch to higher blends.
Sheila, Cheryl, Jenne
When Cheryl locked the interferometer after maintence day and calibration work was done this afternoon, the recycling gain was again low, (POP_A_LF around 15500 cnts), around the level we have started at in locks where the recycling gain degraded until loosing the lock over the last few days. (When the recyclcing gain is stable this is normally around 16500 cnts). Since LLO was not locked, we took some time to open the refl beam diverter and look at the camera for a msalignement.
We then opened the PRC1 ASC loops (POP A to PRM, slow loop) and moved PRM by hand, very slowly so that the CHARD and CSOFT loops had time to catch up. We moved PRMI pit alignment slider from -1419 to -1405 urad, and yaw from 518 to 537 urad. This increased POP A by about 400 counts. At the slightly better recycling gain the offsets on POP A were -0.35 for Yaw and -0.3 for pitch. As Cheryl mentioned in her alog, we lost the lock for reasons I don't really understand while adjusting pitch. There didn't seem to be any environmental problem, so it would seem likely that it was my PRM pitch adjustment that is to blame, but I was not doing anything different from what I had been doing for the previous half hour.
We may want to try these QPD offsets as a new set point for the PRC1 loop, depending on what the reccyling gain looks like when Jim finishes locking.
Cheryl and I also spent some time debugging the PRMI branch, which has had some bugs in it for a while that have probably been causing problems.
This lock also started with low recycling gain, and Jim and I decided to try changing the soft loop offsets instead of repeating the PRM expiriment. I added offsets to DSOFT P and CSOFT P (the normal offsets are still in the TMS QPDs, I have not touched those.)
The current offset in DSOFT P is 0.04, while CSOFT P has an offset of -0.02. It seems like we could probably keep moving CSOFT to more negative offsets and keep improving the recycling gain, but we decided just to go to observing and see what happens over the course of the lock. POP A LF is now at around 15600 counts.
If anyone wants to revert this in the morning, just set H1:ASC-DSOFT_PIT_OFFSET and H1:ASC-CSOFT_PIT_OFFSET to zero.
Ops Eve Summary: 00:00-08:00UTC, 16:00-23:59PT
State of H1: unlocked
Commissioners: Jenne, Sheila (fellow), JeffK
Incoming Operator: JimW
Shift Summary:
J. Kissel In efforts to finally nail down the mysterious "zero" around 50 [Hz] in the UIM (see LHO aLOG 24296), I've measured the TOP, UIM, and PUM driver using three different measurement configurations. The hope is that, with this "matrix" of differences, we can find out what's going on with the UIM to see if its something specific to the driver, or specific to the OSEM chain upstream of the driver. From what I've seen watching the measurements go by on the SR785, both the TOP and PUM stage show similar zero-like behavior as the UIM, though the TOP mass has a pole-like behavior above the zero and eventually rolls off. Both the PUM and the UIM look as though they are rolling up to "infinity" by 10 [kHz], without even a phase shift indicating their might be a pole "soon" in frequency. More detailed analysis and plots to come. The data has been committed to the repo here: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PostO1/H1/Measurements/Electronics/ EYPUMDriver/2016-01-05/TFSR785*.txt EYTOPDriver/2016-01-05/TFSR785*.txt EYUIMDriver/2016-01-05/TFSR785*.txt where the key to each driver's measurement set is in the log files, /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PostO1/H1/Measurements/Electronics/ EYPUMDriver/2016-01-05/2016-01-05_EYTOP_Measurement_log.txt EYTOPDriver/2016-01-05/2016-01-05_EYUIM_Measurement_log.txt EYUIMDriver/2016-01-05/2016-01-05_EYPUM_Measurement_log.txt I also attach a white board sketch that indicates each of the measurement configurations. (0) [Not shown] The "reference" measurement is identical to the reference setup shown in page 2 of the 2nd attachment in 18518, which is divided out of every transfer function to get rid of the response of the differential driver. (1) This is measuring the response of the coil driver as it is typically measured on the bench by CDS. It uses a differential to single-ended receiver and the 40 [ohm] internal load (as I only found out later, the documentation on this box, D1000931 leaves something to be desired), so the response differs from configuration (2) only by a scale factor of 2. (2) This is measuring the response of the coil driver as is typically done in the field when the OSEM and/or satellite amplifier is not available. The box (D1100278) is, as far as the coil chain is concerned, only a two 20 [ohm] (for a total of 40 [Ohm]) resistor load. (3) This is the "real life" scenario, where we measure the response of the driver with the full SatAmp and OSEM included as a load on the output of the driver. It is in this configuration is where the magic happens, apparently.
Since the IFO has decided to give up on Calibration Week, I've put together some .graffle diagrams of what I show in the whiteboard picture above such that a future user and/or LLO can more clearly replicate my results, if need be (or they don't trust what Evan G's is about to post). Also note for future me, the source code for these diagrams lives in /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/PostO1/H1/Measurements/Electronics/EYTOPDriver/2016-01-05/ CoilDriverChassisSetup_BenchTestSetup.graffle CoilDriverChassisSetup_DummyOsemChain.graffle CoilDriverChassisSetup_RealOsemChain.graffle
Summary:
I plotted the results of Jeff's measurements for the H1 End Y driver electronics for the top, UIM, and PUM masses. All show odd behavior at high frequencies that we cannot model as an ideal inductor.
Details:
For each measurement of a given mass' driver electronics (TOP, UIM, or PUM), I divided the measured BOSEM (for TOP/UIM) or AOSEM (for PUM) transfer functions (normalized) by the corresponding transfer function for when there is a dummy 40 ohm resistor terminating the output of the drive electronics (also normalized). In addition to plotting the results of the measurements, I also investigated the high frequency behavior. Nominally, we expect to observe the inductance of the BOSEMs or AOSEMs as a simple zero--the high frequency dependence goes as f. Instead, we observe different dependences for the BOSEMs of the top and UIM masses and the AOSEMs of the UIM (state 1 and 3). We attempted to fit by hand some zero-pole models to these Bode plots but were unsuccessful to replicate the high frequency dependence.
After notifying the operator I drove past the CS @ 00:02 and arrived at Y-Mid station @ 00:07.
Started filling CP3 @ 00:08, opened the exhaust check valve bypass valve, then opened LLCV bypass valve 1/2 turn, started to notice flow @ 00:18. and closed the LLCV bypass valve @ 00:19.
5 minutes later I closed the exhaust check valve bypass valve.
Started driving back from Y-Mid @ 00:26, arrived at the CS @ 00:30.
TITLE: 1/5 DAY Shift: 16:00-00:00UTC (08:00-04:00PDT), all times posted in UTC
STATE of H1: DOWN
Incoming Operator: Cheryl
Support: Jenne (locking commissioner), Kiwamu fixing Dark Michelson (yay!)
Quick Summary:
Maintenance was fairly busy, but part of it included Calibration work. And Calibration work is going to go to around 4:30. Towards the end of the shift, Jeff/Kiwamu gave us the OK to run an Intial Alignment. Gary T. (visiting from LLO) did the honor of doing the alignment (only note here was that for Input Align, we took the XARM gain to 0.2 to lock the Xarm)....oh, and Dark Michelson locked up for the first time in weeks!
Leaving ISC_LOCK in DOWN while Jeff finishes up his ETMy coil driver work.
Maintenance/Shift Activities: (all times PST)
Jenne, Kiwamu,
We have spent some time today trying to fix the long-standing issue with MICH_DARK (which started on 20th of December as far as I know, alog 24349) because we needed to fix it for a calibration measurement scheduled in this week.
We finally fixed it and now MICH_DARK locks.
The reason why it has been not locking seems to be due to too high sensing noise in ASAIR_A which kept saturating the beam splitter's DACs (assuming that the digital filters and DACs of the beam splitter have been unchanged). I have checked the whitening filters and gain of ASAIR_A, but they have been unchanged at least in the past 4 months or so. I don't have quantitative comparison of the noise floor back then and now. So at this point we have no idea why the sensing noise increased.
Anyways, we have inserted two extra low-passes in order to shave off sensing noise above the unity gain frequency (which is typically somewhere between 4 and 10 Hz). These low-passes fixed the issue. I have not changed any foton filters; I have recycled unused filters. The first filter resides in LSC-MICH FM5, and the second in BS_ISCINF FM6. In addition, I adjusted the gains of the MICH loop so that it smoothly grabs a fringe. Now the initial acquisition gain is -333 and the final one is -500. We have edited the following guardian codes, both of which are checked into svn: ALIGN_IFO.py, lscparams.py and ISC_DRMI.py. The guardian was tested 5 or 6 times with the new settings and we have not seen a failure yet.
Patrick, Jim, Dave:
we investigated the conlog crash at 16:00 PDT Friday 31st Dec 2015. As Patrick logged, h1conlog1-master syslogged that the kernel applied a leap second at that time. Looking at other machines we noticed that all systems which are NTP clients to the CDS NTP server (a Symmetricom SyncServer S250 unit with GPS antenna) similarly logged the leap second being appied whereas machines not using this NTP server did not.
The details of the conlog crash are: UNIX TIME (seconds since the 01jan1970 epoch) repeats a second when a leap second is added, we had a noisy channel being monitored by conlog which changed every second around this time resulting in conlog attempting to update the database with two events one second apart but with the same time stamp which crashed conlog and alerted us to the problem.
We then verified that all the clocks and computer times within CDS have the correct time, and they are indeed correct.
We logged into the Symmetricom NTP server and viewed the logs (attached). It shows that it reported the leap second addtion 30th June 2015 (correct) and 31st December 2015 (incorrect).
We are assuming that all the computer clocks did leap by one second at 16:00:00 PST Friday 31st December 2015, but then skewed back to the correct time soon after.
We are planning on upgrading to a new NTP server soon and donate the old server to GC.
Pipes under the beam tube have been rerouted to allow access under the tube with a pallet jack. This relocation required a brief shutdown of the instrument air which caused some alarms. The control room was notified in advance of the shutdown. The instrument air is back to normal operation.
No new news here--Everyone chugging along. Attached is 40 days of the first pressure sensor on the Pump Station manifold and the control output to the motor.
Remarks: All four CS pumps have a perfect flatlined output (showing only one,) no this is not news. EX's excess noise continues in evidence, notice the ~15 days of quieter readings. At EndY, the daily and weekly glitches continue as before.
No indications of pump output loss.
Attached is a plot of the STS2's Mass Positions. Finally got them all centered (something below 5000cts)
Found that ETMY did not have the Binary I/O cable from the Bin Output to the STS2 Interface so this was not going to re-center remotely anyway. Vincent pulled that cable but we don't quite understand. I can tell you though that the recentering does not work via the medm/cable but the signal select and period select toggling does work... We've left that cable unplugged and did the centering at ETMY via the front panel button.
C. Cahillane I have constructed the uncertainty budget of LHO at GPSTime = 1135136350. The kappa values are given at 11546. Just a reminder on the differences between the calibration versions (according to me and my results): C00 = Sensing, Actuation, and Digital filters given by DARMmodel (I used the DARMparams from GPSTime = 1127083151) C01 = No kappa corrections, but static frequency dependence corrected. C02 = Kappa_tst and kappa_C corrected, as well as static frequency dependence corrected. Kappa_pu and cavity pole f_c NOT corrected. C03 = "Perfect" calibration, i.e. all kappas and static frequency dependence corrected. All comparisons between calibration versions have the C03 "Perfect" calibration in the denominator. C03 represents the best possible knowledge of the detector according to the calibration group. All others have some known systematic errors. For C01, strain magnitude uncertainty is below 7% and strain phase uncertainty is below 3.5 degrees. (See PDF 1 Plot 2) For C01, maximum strain magnitude error over C03 is 0.95 and maximum strain phase error over C03 is below 3 degrees. (See PDF 1 Plot 1)
Here are the trends of the PSL data froim the past 20 days. In reponse to Jeff K's request for more commentary on this data I have conversed with the expert(s) and Jason agreed to provide more analysis.
After reviewing the trends I posted yesterday I determined that the ITMy and SR3 oplevs needed re-centering. This is now complete. The old and new pitch/yaw values for these oplevs are below.
| Old (µrad) | New (µrad) | |||
| Pitch | Yaw | Pitch | Yaw | |
| ITMy | -11.1 | -12.1 | -0.2 | 0.0 |
| SR3 | -13.8 | +5.2 | -0.2 | -0.1 |
This completes LHO WP #5676.
svn up at .../SusSVN/sus/trunk/QUAD/Common/MatlabTools/QuadModel_Production
All current model features are summarized in a table in G1401132.
The main change in existing features is that the top mass damping now sees both the suspension and the cage, as in real life because we use OSEMs. Consequently, if you input seismic noise to a damped suspension it will enter both mechanically as usual, as well as through the damping loops. See Seismic_Noise_Propagation_2016_01_01.pdf. Page 1 shows longitudinal transfer functions from seismic noise to the test mass with and without the OSEMs seeing the cage. The second page shows the ratio of these transfer functions. Note that the ratio is greater than a factor of 2 at 4.5 Hz. Beyond 10 Hz the maximum is about 20% at about 10.5 Hz.
1. Additional inputs and outputs added to reflect the relative nature of the OSEMs - i.e. they measure relative displacements and actuate between two points
2. Suspension point reaction forces
The discussion above is one consequence of the first new feature. Another is that you can now make transfer functions between seismic noise and the top mass OSEMs, which is dramatically different from the seismic noise to top mass transfer function. See Seismic_to_Top_OSEMs_2016_01_01-2.pdf. These are obtainable in the model with the new 'toposem' field in the 'out' structure given by the generate_QUAD_Model_Production function.
The second new feature is that there are now outputs for the suspension point reaction forces on the ISI. These are obtainable in the model with the new 'suspoint' field in the 'out' structure given by the generate_QUAD_Model_Production function. These reaction forces allow us to dynamically couple the quad model to the ISI model. Thus, if we wanted, we can make one big ISI-SUS model.
This update includes significant under-the-hood modifications to how the pieces of the model are put together. Essentially, Simulink files now define the connections and signal flow, where previously this was all done with append/connect commands in the generate script. The motivation for this change is to make the model more extensible and maintanable by humans. The append/connect commands had become virtually unreadable with the dozens of inputs and outputs now in the model. Now someone can look at a more intuitive graphical representation in a simulink file to read or modify how the model is layed out.
There are 4 simulink files defining the 4 possible layouts of the quad model:
rev 7359: now reads foton files for main chain and reaction damping
rev 7436: Changed hard coded DAMP gains to get the correct values for LHO ETMX specifically.
rev 7508: Restored damping filter choice for P to level 2.1 filters as opposed to Keita's modification. Cleaned up error checking code on foton filter files, and allowed handling of filter archive files and files with the full path.
rev 7639: renaming lho etmy parameter file
rev 7642: Adding custom parameter file for each quad. Each one is a copy of h1etmy at this point, since that one has the most available data.
rev 7646: added ability to read live filters from sites, and ability to load custom parameter files for each suspension
rev 7652: updated to allow damping filters from sites from a specific gps time (in addition to the live reading option)
planned future revision - seismic noise will progate through the damping filters as in real life. i.e the OSEMs are relative sensors and measure the displacement between the cage and the suspension.
rev 7920: big update - added sus point reaction forces, top OSEMs act between cage and sus, replaced append/connect command with simulink files
no recent (at least 4 years) functional changes have been made to this file.
- rev 2731: name of file changed to quadopt_fiber.m, removing the date to avoid confusion with Mark Barton's Mathametica files.
- rev 6374: updated based on H1ETM fit in 10089.
- rev 7392: updated pend.ln to provide as-built CM heights according to T1500046
- rev 7912: the update described in this log, where the solidworks values for the inertias of the test mass and pum were put into the model, and the model was then refit. Same as h1etmy.m.
- rev 7640: created the H1ETMY parameter file based on the fit discussed in 10089.
- rev 7911: the update described in this log, where the solidworks values for the inertias of the test mass and pum were put into the model, and the model was then refit. Same as quadopt_fiber.m.
The quad model was tagged on the SVN both before and after this update. The tagged models are at
before this update: /ligo/svncommon/SusSVN/sus/trunk/Common/SusModelTags/Matlab/quadmodelproduction-rev7652_ssmake4pv2eMB5f_fiber-rev3601_fiber-rev7913_released-2016-01-01.mat This version reflects the model after the previous recent update discussed in log 24456, which updated the test mass and PUM inertias with solidworks values. No model features were changed in this update. After this update /ligo/svncommon/SusSVN/sus/trunk/Common/SusModelTags/Matlab/quadmodelproduction-rev7920_ssmake4pv2eMB5f_fiber-rev3601_fiber-rev7913_released-2016-01-01.mat
The tags were created using the following script:
/ligo/svncommon/SusSVN/sus/trunk/Common/MatlabTools/tagsusdynamicalmodel.m rev 7923
Just as an FYI, I have done this svn update.
MInor updates and fixes:
1) The simulink files were generating warnings in Matlab 2012b because they were saved in 2013a. I resaved them in 2012b, recommited, and the problem has gone away. Matlab versions 2013a and 2015b are fine as well. No promises for versions earlier than 2012b.
2) While fixing the simulink diagrams, I added some extra inputs based on a disucssion with Brian Lantz. These are 'osem like' force inputs acting between the top mass and the cage for the purpose of testing the reaction force outputs on the ISI. These will not impact any prior features of the model.
The conlog process on h1conlog1-master failed soon after the UTC new year. I'm pretty sure it did the same last year but I could not find an alog confirming this. I followed the wiki instructions on restarting the master process. I did initially try to mysqlcheck the databases, but after 40 minutes I abandoned that. I started the conlog process on the master and configured it for the channel list. After a couple of minutes all the channels were connected and the queue size went down to zero. H1 was out of lock at the time due to an earthquake.
For next year's occurance, here is the log file error this time around
root@h1conlog1-master:~# grep conlog: /var/log/syslog
Dec 31 16:00:12 h1conlog1-master conlog: ../conlog.cpp: 301: process_cac_messages: MySQL Exception: Error: Duplicate entry 'H1:SUS-SR3_M1_DITHER_P_OFFSET-1451606400000453212-3' for key 'PRIMARY': Error code: 1062: SQLState: 23000: Exiting.
Dec 31 16:00:12 h1conlog1-master conlog: ../conlog.cpp: 331: process_cas: Exception: boost: mutex lock failed in pthread_mutex_lock: Invalid argument Exiting.
This indicates that it tried to write an entry for H1:SUS-SR3_M1_DITHER_P_OFFSET twice with the same Unix time stamp of 1451606400.000453212. This corresponds to Fri, 01 Jan 2016 00:00:00 GMT. I'm guessing there was a leap second applied.
of course there was no actual leap second scheduled for Dec 31 2015, so we need to take a closer look at what happened here.
The previous line before the error reports the application of a leap second. I'm not sure why, since you are right, none were scheduled. Dec 31 15:59:59 h1conlog1-master kernel: [14099669.303998] Clock: inserting leap second 23:59:60 UTC Dec 31 16:00:12 h1conlog1-master conlog: ../conlog.cpp: 301: process_cac_messages: MySQL Exception: Error: Duplicate entry 'H1:SUS-SR3_M1_DITHER_P_OFFSET-1451606400000453212-3' for key 'PRIMARY': Error code: 1062: SQLState: 23000: Exiting. Dec 31 16:00:12 h1conlog1-master conlog: ../conlog.cpp: 331: process_cas: Exception: boost: mutex lock failed in pthread_mutex_lock: Invalid argument Exiting.
