BSC ITMy CPS corner #2 (mostly H2, a little V2) look noisier than normal. First attachment is noisier ITMy BSC CPS (compare to last week). Notifying Hugh & Jim to see if this is a concern or normal.
All other BSC & HAM CPS's look nominal (plots attached) & closing FAMIS.
FRS was filed #11497.
TITLE: 09/19 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
Wind: 3mph Gusts, 2mph 5min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.08 μm/s
QUICK SUMMARY:
ITMx Binary I/O M0 Control Test Coil Enable for State 2 issue
This morning I noticed that an LSC glitch was perhaps was not getting cleared. Yesterday I had modified the auto_diag_reset script to no longer clear the end station SUS glitches (so if we have any, they will latch) but to continue to clear LSC glitches. I'll check today to ensure the script is running.
We have had no end station SUS glitches overnight since yesterday's upgrade of these machines from V2 to V4.
The diag_reset script was not running, I had a syntax error. It is now running again, clearing any h1lsc0 related glitches every minute. End station SUS glitches will latch on.
Danny, Georgia, Sheila, Hang, TVo
After fixing the mask today, the HWS ITMY shows that the clipping issue we've had before is now fixed and the heating profile is more circularly symmetric.
We still got a contrast defect of about 0.4%, but we didn't optimize the differential CO2 power because we saw an obvious pringle mode (HG20-HG02) that stems from astigmatism, this shows up pretty obviously when looking at the single bounce beams where ITMX looks good, but ITMY looks bad.
Sheila suggested that we should be able to scan the PR3 around the ITMY surface and see the astigmatism in the single bounce ITMY beam vary as we start to sweep over the center of the CO2 lensing. This worked a bit but we started clipping after moving the spot position on ITMY by about 5 mm so it gave use a direction to try to aim for when changing the alignment of the CO2 beam relative to the test mass.
Although this had confusing results because we once tried pico-ing to where we thought it should get better by doing a modulation of the laser power and seeing the deflection at the anti-symmetric port with the ASAIR camera, the astigmatism didn't seem to get better. Changing the picoing in the y-direction showed that the deflection went up whether or not we pico-ed up or down in counts so we thought we might be at a minimum, however, If we went through a minimum then we should see a phase change between the heating cycle and the deflection slope but we weren't able to observe this which makes it even more confusing.
In the end, there was still astigmatism after the pico-ing but Sheila suggested that the morning commissioning crew try to lock and see how these particular lenses change our locking scheme/setpoints
WP7815
Rolf, Keith, Dave, Jonathan, Jamie, Richard, Fil, Ed
Today we did a major upgrade to the CDS system:
After the IFO was placed in a safe state, we stopped all models and powered down all computers with Dolphin cards. We stopped DHCP running on the old boot server (h1boot) and started it on the new boot server (h1boot1). We rebooted all the non-Dolphin systems (SUS-AUX) to gt3.0.8/rcg3.4.2 and restarted the DAQ.
Rolf, Jonathan, Fil and Ed upgraded the MSR, Keith upgraded the software systems, Dave and Jamie upgraded the end stations. At each location:
The long-range Dolphin server (h1cdsrfm) had been installed on Monday, today its Dolphin cards (both local and at the end stations) were connected to their respective Dolphin switches.
The h1ioplsc0 model was modified to run as a timing server for h1oaf1.
We discovered timing issues with the mid station PEM systems. The remoteGPS function was not obtaining the correct time from h1dc0 via EPICS channel access. When this was turned off, the GPS time was one second too slow. A modified RCG-3.4.3 was installed to advance the GPS time by one second and h1ioppem[mx,my] were built against this. The Mid Station PEM systems are now running correctly.
*V4 computer upgrade:
Initially we were to upgrade 10 front end computers to V4. However we found that the V4 computers could not detect the cards in the IO Chassis if the OneStop fiber transceivers were from 2011 or earlier. Testing on h1iscex and h1susex showed that 2012 and 2015 fibers worked. Because running new OneStop fiber at the end stations is relatively easy (adjacent rooms, open access cable trays) , Fil and Ed ran two 2012 fibers at each end station for the SUS and ISC computer upgrade. Running new fibers between the MSR and CER in the corner station is more problematical, so the two computers which had been upgraded to V4 at that point were returned to their original hardware for now.
The upgrade was completed and the system handed over to the control room at 16:59 PDT.
Fixed:
Still To Do:
Install new h1oaf1 front end computer, this is a Dolphin only machine (no IRIG-B timing or IO Chassis) which will get its timing from h1ioplsc0.
Add to To Do List:
IPMI cables for h1sus[ex,ey] and h1isc[ex,ey] (new V4 computers)
At the end stations, the installed V4 machines only have USB ports, therefore the PS2-type KVM cables were replaced with USB-type cables at these locations.
Three modified models were restarted today:
h1isc[ex,ey] with Sheila's modifications (circulating power calculation)
h1pemcs, Dave added new Accelerometer channels
the ITMY optical lever is noisy (screenshot attached). It would be a good idea to check for mechanical interferences when there is an oppurtunity.
I did a walkthrough and a visual did not reveal any obvious mechanical coupling. Both piers were as isolated as usual. Spectrograms were examined and besides optical motion there was no broadband glitching evident. We'll keep an eye on this.
Created corresponding FRS Ticket 11493.
There seems to be a problem with the ITMX BIO, screenshot attached. It has been this way (H1:SUS-ITMX_BIO_M0_MON = 1535) since about 1:22 UTC, we don't know of any activity that would have caused a problem at that time.
setting H1:SUS-ITMX_BIO_M0_CTENABLE to 0 and back to 1 again doesn't fix the problem.
Opened FRS Ticket 11492 to record progress on this issue.
It was first thought to be a software issue, but it looks like it was a hardware problem. The ITMx Binary IO chasis in the CER was rebooted by the CDS team (Dave, Richard?) during the 1pm Commissioning Meeting & everything came back fine PLUS the ITMx binary IO issue was FIXED (so FRS can be CLOSED).
TJ, TVo, Danny
Because of the astigmatic heating of CO2Y on ITMY, we went out to the CO2Y table to modify the central mask position on the beam. The first attached figure is an initial mask placement over the CO2 beam. The removal of the shims amounting to a .023 inch downwards vertical shift of the mask moved the beam vertically upwards on the FLIR camera and better centered the CO2 profile (please see second figure). We plan on double checking / correcting alignment of the CO2Y beam on ITMY and make another contrast defect measurement as soon as possible.
Today Dave and company did the model restarts for the isc end station models, with the new matrix and filters intended for an calibrated circulating power channel.
I am loading a calibration based on 15431 with a couple of changes:
3 dB of whitening gain, which is what we currently use in full lock.
20 volts/32768 counts from the ADC, 1/2 Volts/volt for differential output, 1000 ohms transimpedance, 0.8A/W responsivity of the QPDs (I think this was a typo in the initial alog and this is really the responsivity, not the QE) means 2621440 counts/Watt on QP
Keita points out (3077) that the red beam leaving the ETM hits 4 silver mirrors on its way through TMS, each with a reflectivity of about 98%, then we have 5% transmission through M12 and a 50/50 splitter for the two QPDs, (T0900385), so we get 2.3% of the light leaving the ETMs on each QPD.
From the galaxy page, I think that our two ETMs have 3.8 and 3.9 ppm transmission each, I'm using 3.85 ppm as an average.
Besides the whitening gain, this gives 3.96 kW of arm circulating power per count on the QPDs.
The last line of this alog should say 3.96 counts per Watt circulating power in the arm, not kW.
Maintenance Day Activities:
This is a mid upgrade report. Daq restart at 11:54 localtime / 18:54 UTC. We had some test systems running, testing these systems to see if they could communicate w/ the daqd. h1pemmy could communicate, but h1susauxb123 could not. We were seeing 0xbad errors. This was indicative to a problem with the data between the front-end and the daqd. We tested: * gpstime was correct * mbuf was loaded * iop model was loaded and running * the data in the mbuf was being updated * mx_stream was reporting that data was being sent, we could see the heartbeat signal We restarted the daqd to give it a chance to pickup the changes made to the mx fabric and restarted mx_stream on the available front ends. At this point all systems that are up are reporting in w/ the daqd.
All SEI and SUS are down, CDS is down, we expect to be down most of the day for the upgrade. SDF, GRD, SUS medm snapshots attached.
Timeline This AM:
18-09-18 15:37 MarkD to EX
18-09-18 15:38 Carlos to EX and back
18-09-18 15:38 Mark to EY and back
18-09-18 15:38 all SEI and optics are down for the CDS upgrade
18-09-18 15:42 Richard heading to LVEA to talk to card access contractors
J. Kissel, D. Barker We've been periodically finding front-end modules that show differences when no one reports making changes. Upon looking at the diff provided by the RCG system (an awesome newish feature) between the loaded file, and the *to be* loaded file, there are TONs of differences. Upon close inspection, however, those changes are entirely superficial -- the header of the file where all filter banks in the model are recorded (in "some" order) has been flipped or re-ordered, and/or (sometimes both, sometimes one or the other) the coefficient notation has switched from engineering/decimal notation to scientific notation. I'll open an FRS ticket about this, but at this point we don't have a smoking gun as to who what where when or why this happens, we (Dave and I) just have seen it enough that it has become a "usual" problem in our parlance. Usually because it relies on Dave dilligently (but still only occasionally) browsing through the CDS overview screen before a pending computer change, and comes to me asking me to figure it out and resolve it. So it can be up to "many days" from when someone may have altered the filter file with some program, and when we notice it.
Created corresponding FRS Ticket 11481.