Greg had noted that some of the DAQ Frames meta-data is incorrect. I made the corrections in the h1fw0 and h1fw1 configuration files (daqdrc). These changes went in as part of the DAQ restarts during this morning's work.

Running framecpp_dump_objects on h1fw0's science frame shows the corrected settings:

nameDetector: LHO_4k

latitude: 0.810795

Rolf, Jim, Dave

Short story, we installed RCG2.8, we found problems which could not be fixed quickly, we backed out to 2.7.2

The following systems were not changed during the 2.8 testing: h1psl front end, the DAQ code, mx_stream, mbuf.

All front end models were recompiled against 2.8. Local changes were found in h1hpibs, h1hpiitmx, h1isiham6, h1susitmy (the HEPI models showed major changes compared to SVN).

All front end models except the PSL were restarted with the new 2.8 versions. The DAQ was reconfigured to remove all the EDCU INI files relating to front end channels (only non-FE EDCU channels were being acquired, e.g. Vacuum and FMCS).

We found that running the h1iopsush2a model caused corruption of the DAQ data stream from the front ends to the DAQ Data Concentrator. Rolf tried various tests but no quick solution was found. With time running out we decided to back out the 2.8 models and reinstall the tag2.7.2 models.

I ran an "install world" make in the rtbuild-2.7.2 area, so models were not recompiled against 2.7.2, existing binary code was re-installed in the target area.

We ran into safe.snap restoration for the following models: h1hpietmy, h1isibs, h1isietmx, h1isietmy, h1isiitmy, h1pemey, h1peml0. In these cases they were manually restored to this morning's settings before the models were stopped.

To test RCG2.8 we recompiled dataviewer, the new version is still installed as it is backwardly compatible.

EDCU for Beckhoff C1PLC2 was edited to remove two channels (H1:LSC-REFL_SUM_A,B_OUTSW) which appear to have disappeared.

Since we have access and I was in-chamber anyways, in:

• BSC1, I swapped the witness plate directly that was under the ITMy with a fresh one - see T1300874 for eventual analysis of the removed wafer

(2 more plus 2 1" optic samples were left alone for posterity)

• BSC2, I swapped the witness plate that was directly under the BS with a fresh one - see T1300875 for eventual analysis of the removed wafer

(1 more plus 1 1" optic sample were left alone for posterity)

• BSC3, we added a fresh witness plate (none previously in this newly populated chamber).

(Corey G, Jim W)

With a window of opportunity to work in BSC9, I hopped in chamber and Jim worked from up top.  Following the Cabling document (D1300007), Flange layout (D1003081), and using my BSC 9 Cable Table (alog), I went about checking & connectiong some cables to the chamber.  While doing this found a few issues:

1)  TMS SUS cables needed to be "turned around".  The end with "ears" was originally on flange side, and the cables could not be connected with these large ears on.  Luckily, fixing this required just flipping the cables around.  Confirmed that we now have real signals on the TMS medm.

2)  While connecting the Beam Diverter cable (D1000223 s/n S1202656) to the flange, I appear to have galled one of its set screws.  The cable is well seated and the other set screw is fine, but one of the set screws feels pretty bad. 

3)  The ISC QPDs are extremely important, and one thing I DID NOT want to do is fry these guys buy connecting them to the wrong flange.  So, I did not plug the QPDs (I later found out that the dirty-side cable aren't connected, so I could have connected them).  One other issue came up here.  Each QPD cable shares flange with either a Beam Diverter or Picomotor.  We are pondering the idea of whether we can put BOTH QPDs on one flange and the Beam Diverter/Picomotor on the other one.  This could help prevent us from accidentally frying a QPD.  We're still waiting on this per an email Keita sent out to all interested parties. 

was upgraded to V3 including software.

The three slow controls computers (Beckhoff) have been setup to automatically restart. They will continue at the point where they were turned off. This includes the TwinCAT system manager, all active PLCs and the TwinCAT ioc. (The TwinCAT ioc exports the TwinCAT channels into EPICS.) For configuration details look at section 4 in T1300175. After a power failure the system should now come back fully without manual intervention.

The DTS iMac workstations (running OS X) now run Matlab 2012b by default.

Today's major activity was the installation of the Cartridge into BSC3.  This started roughly late morning and was completed by 2:30-ish. 

Other Activities Of The Day:

Doug tried taking measurements to look at BSC3 in the morning (but wasn't able to due to interferences)

Work on X1:  Ed Watt removing insulation & inspection (not sure if this started today...they had mask-fittings in the morning and then they need to set up lighting to begin work)

Waiting to hear back from ISC regarding EX work (mentioned in morning meeting).

Dust Monitor continue to exhibit "noisy" behavior and alarm quite a bit due to a "step up" in counts (noted by Patrick & Jeff B.) coinciding with software change last Tues.  Unless something is changed, may be worth it to change alarm levels on these guys (I'll be on shift again on Thurs, and change levels if situation doesn't improve).

HAM2/3 ISI going up & down (Arnaud & kissel)

Contractor here to service tanks at 9:21am

Purge Air check at EX & LVEA (Gerardo)

Working with FSS (Stefan after talking with Rick)

Testing Oplev/Pcal templates (Rick/Craig)

  (Jeff B & Andres R)  

 We took the first set of undamped transfer functions for H1-OMC this afternoon. I’ve posted the results in the attached files. Comparison to the results from LLO testing looks positive. We will wait for Stuart A and Jeff K to comment before proceeding.    

Apollo (Bubba, Randy, Scott, Tyler), MitchR, JimW

BSC3 cartridge is in the chamber. No issues. We even learned from last time and put the covers on tighter this time. The quad is uncovered (just the sock is removed, I wasn't brave enough to touch anything else), so SUSsers can inspect at their leisure.

[Cheryl, Stefan, Sheila, Kiwamu, Joe, Paul]

The isolation ratio was calculated using both references for the rejected beam power (see Stefan's aLOG entry 7934), giving results different by 3dB.
Both are above the requirement of 30dB though.

The pick off beam splitter on the PSL table was characterized using power-meter measurements as follows:
Power in = 109.8mW
Power reflected = 38mW
Power transmitted = 67.8mW
R=0.3461
T=0.6175
L=0.0364

The first FI ratio calculation is made using the FI rejected beam power measurement on ISCT1 and the non-rejected beam power measurement on the PSL table.

In this case both measured beams pass forward through the IMC, through the FI, reflect off the PRM, and pass through the FI again before taking different paths (see attached drawing for measurement locations).

From this point, the rejected beam passes a R=90% BS and two 50% beam splitters before being measured on ISCT1. The power of the rejected beam just after the FI is therefore calculated as 6.94mW / 0.1 / 0.5 / 0.5 = 277.6mW. This is actually rather low considering that the power into the IMC should be around 555mW (1000mW*0.9*0.6175). Perhaps there was another 50% beamsplitter unaccounted for in the path somewhere? It's possible that some power is lost in the power control stage on the PSL just before the periscope, but I didn't think it shouldn't be as much as 50%. In this calculation, however, the isolation ratio inferred is unaffected by any loss at the power control stage because that stage is common to both the non-rejected and the rejected beams.

After returning through the FI, the non-rejected beam passes backwards through the IMC. The forward throughput efficiency of the IMC is taken as 94.25%, obtained from observing trends in the IMC REFL PD power (though this does not account for losses inside the IMC). The return efficiency is taken as the forward efficiency multiplied by the average x/y overlap of 94% between the measured mode in HAM1 (see entry 9750 and comments).
The beam then passes back through to the PSL and is reflected off the 34.6% reflective pick off BS. The beam does pass back through the power control stage, however it should have optimal polarization to pass this stage with high-efficiency, so this is not taken into account here.
The non-rejected beam power just after the FI is therefore calculated as 37uW / 0.9425 / 0.94 / 0.3461 = 123uW.

FI isolation ratio = -10*log10( non-rejected power / rejected power) = -10*log10( 123e-6 / 277.6e-3 ) = 33.5 dB

The second calculation is made using the other measurement of the input beam power on the PSL along with the non-rejected beam power measurement on the PSL table.

The non-rejected beam just after the FI is the same as before: 37uW / 0.9425 / 0.94 / 0.3461 = 123uW

From the PSL pick off beam splitter direct reflection point to just after the FI on the return path from the PRM, the rejected beam passes the pick-off BS (picking up a factor T/R = 1.7842 in power from the measurement point), the IMC in forward transmission (94.25% throughput), the FI (97.8%), reflects off the PRM (96.9%), and passes the FI again (97.8%).
The rejected beam power just after the FI is therefore calculated as 339mW / 0.3461 * 0.6175 * 0.9425 * 0.978 * 0.969 * 0.978 = 528mW

Calculating the isolation ratio with these numbers gives us:
FI isolation ratio = -10*log10( non-rejected power / rejected power) = -10*log10( 123e-6 / 528e-3 ) = 36.4 dB

This is quite a significant discrepancy between the two values for the isolation ratio. I am more confident in the 33.5 dB number though, because the measured beam paths have more in common in that case (especially the final power control stage). The 36.4 dB number is susceptible to any other losses in the IMC input beam path, such as the final power control stage before the periscope.

 

H1:PSL-FSS_MIXER_OFS set to zero.

H1:PSL-FSS_MIXER_OFS, which is a mixer offset adjust. was set to -1.634V. That seems high. I couldn't find any alog about setting it. And the ODC bit was set at 0.8V and was alarming. After discussing it with Rick, I set it to zero and verified that the FSS is still locking fine. We should verify (by blocking the light on the diode) that zero is a reasonable setting.

The default matlab version for the DTS linux-x86_64 is now matlab2012b.

J. Kissel, S. Ballmer, R. Mittleman

Executive summary: The seismic's HAM 2&3 front end was unable to drive output signals this weekend -- unclear whether it was related to the CDS maintenance. I have now restored its functionality with a soft-reboot of all front-end processes on the computer. The HAM-ISIs have been restored to level 3 isolation, HEPIs have been left with no drive requested but watchdogs are happy and master switch is on. Details below.


---- Details ----

Stefan informed me that Rich was having trouble getting signals out of the h1seih23 front end (both HAM2 / HAM3 ISIs and HPIs), and after a few unsuccessful trouble shooting attempts gave up. The symptoms were strange -- all levels of watchdogs were untripped (including the IOP model) and master switches were on, but no signals were getting out to the DAC (as reported by, e.g. H1:FEC-53_DAC_OUTPUT_1_7 type channels). The only metric of the failure mode was on the CDS overview screen the "WD" bit in the CDS State Word (the eighth bit [the 128 bit] of H1:FEC-53_STATE_WORD) for the H1IOPSEIH23 was red (and only the IOP, none of the user models' WD bits were red), and the GDS_TP screen for the IOP model showed the timing (H1:FEC-53_TIME_ERR) was red and claimed NO SYNC. 

After trying a few iterations of soft-rebooting things without success, the gave up. They knew that there was a proper song-and-dance, correct order, to soft-booting but they admitted to not remembering what it was and not being able to find any documentation describing it.

I came in this morning, and did the proper procedure, and all is now functioning properly.

---- The proper front end soft-reboot procedure ----
I'm sure it's documented some where, but being able to find it... 

[in words]
(1) log into the front end,
(2) kill all the user models (order doesn't matter),
(3) restart the IOP model, and
(4) restart the user models (order doesn't matter).

[what the terminal looks like]
controls@opsws3:~ 0$ ssh h1seih23  # Step (1)
controls@h1seih23 ~ 0$ killh1isiham2   # Step (2)
controls@h1seih23 ~ 0$ killh1isiham3   #       |
controls@h1seih23 ~ 0$ killh1hpiham3   #       |
controls@h1seih23 ~ 0$ killh1hpiham2   #       v
controls@h1seih23 ~ 0$ starth1iopseih23   # Step (3)
h1iopseih23epics H1 IOC Server started
Burt restored /opt/rtcds/lho/h1/target/h1iopseih23/h1iopseih23epics/burt/safe.snap
Old : H1:FEC-53_BURT_RESTORE         1
New : H1:FEC-53_BURT_RESTORE         1
 * WARNING:  awgtpman_iop has already been started.
controls@h1seih23 ~ 0$ starth1hpiham2   # Start of Step (4)
h1hpiham2epics: no process found
h1hpiham2epics H1 IOC Server started
Burt restored /opt/rtcds/lho/h1/target/h1hpiham2/h1hpiham2epics/burt/safe.snap
Old : H1:FEC-54_BURT_RESTORE         1
New : H1:FEC-54_BURT_RESTORE         1
 * Starting h1hpiham2 awgtpman ...                                        [ !! ]
controls@h1seih23 ~ 0$ starth1hpiham3
h1hpiham3epics: no process found
h1hpiham3epics H1 IOC Server started
Burt restored /opt/rtcds/lho/h1/target/h1hpiham3/h1hpiham3epics/burt/safe.snap
Old : H1:FEC-55_BURT_RESTORE         1
New : H1:FEC-55_BURT_RESTORE         1
 * Starting h1hpiham3 awgtpman ...                                        [ !! ]
controls@h1seih23 ~ 0$ starth1isiham2
h1isiham2epics: no process found
h1isiham2epics H1 IOC Server started
Burt restored /opt/rtcds/lho/h1/target/h1isiham2/h1isiham2epics/burt/safe.snap
Old : H1:FEC-56_BURT_RESTORE         1
New : H1:FEC-56_BURT_RESTORE         1
 * Starting h1isiham2 awgtpman ...                                        [ !! ]
controls@h1seih23 ~ 0$ starth1isiham3
h1isiham3epics: no process found
h1isiham3epics H1 IOC Server started
Burt restored /opt/rtcds/lho/h1/target/h1isiham3/h1isiham3epics/burt/safe.snap
Old : H1:FEC-57_BURT_RESTORE         1
New : H1:FEC-57_BURT_RESTORE         1
 * Starting h1isiham3 awgtpman ...                                        [ !! ]
controls@h1seih23 ~ 0$    # End of Step (4)


After the turning on the front end processes, I
- was delighted to see the safe.snaps were reasonably up to date 
- Turned on the HAM2-ISI and HAM3-ISIs damping loops and restored to Level 3 isolation 
- left HAM2 and HAM3 HEPIs as untripped and master switches on, but no requested drive since I figured Rich was just going to immediately play with it once he got in. 

The final measurement obtained from the sideband sweep data taken last Thursday was of the IMC g-factor (or alternatively the MC2 radius of curvature).

For this measurement, we wanted to measure the resonant frequencies of higher-order modes in the IMC. To do this we need to observe beats between higher-order mode sidebands transmitted through the cavity with the HG00 mode carrier also transmitted through the cavity.

Due to the spatial orthogonality of higher-order modes, a single element photodiode would would usually be insensitive to this signal (hence using wavefront sensors to detect misalignment). In the absence of a broadband wavefront sensor in transmission of the IMC, we can instead break the spatial symmetry at the REFL AIR photodiode using any physical obstruction to recover the signal. In this case, we used an iris offset with respect to the beam centre to partially block the beam. In addition to this, the IMC input beam was misaligned by disengaging the WFS loops and applying offsets to the periscope PZT in order to better ring up higher-order modes.

The first attached plot shows a sweep of one whole FSR around the 45.5MHz FSR peak. Overlaid on the measured data is the output from a Finesse model of the IMC, with the IMC geometry as designed expect for the MC2 radius of curvature which was taken as 27.275m from the nebula optics page. The Finesse model allows us to quickly identify each peak in the measured transfer function.

The higher-order mode content in the model was hand-tuned to match the data, as the effects of the iris are effectively un-quantifiable.  Since for this measurement we are only interested in the higher-order mode resonance freuqencies, correct y-axis values scaling is not necessary.

Higher resolution scans were then made of 6 individual higher-order mode peaks. The second attached plot shows the results of fitting a Lorentzian function to these higher-order mode peaks. The cavity g-factors corresponding to the fitted higher-order mode difference frequency (using the mean FSR reported in 8087) were then calculated. From there, the MC2 Rc could be calculated.

The results are shown in the following table:

The "Rc_eff" column shows the effective MC2 radius of curvature experienced in either the tangential or sagittal planes. The IMC beam probes MC2 under a small angle (0.82^o - see T0900386), and as a result the Rc experienced in the tangential (xz) plane is shorter than the normal incidence Rc by a factor of cos(0.82^o), and the sagittal plane (yz) Rc is longer than the normal incidence Rc by a factor of cos(0.82^o). The difference frequency between the HG00 mode and the HG10 mode is determined by the effective Rc in the tangential plane, and the difference frequency between the HG00 mode and the HG01 mode is determined by the effective Rc in the sagittal plane. The Rc_eff, g-factor and HOM diff. freq. entries for the Nebula/design rows were calculated from the quoted Rc of 27275mm and the incident angle 0.82^o.

The Rc column shows the equivalent normal incidence Rc values. For the fitted peaks these values were calculated from the Rc_eff values and the incident angle 0.82^o. For the Nebula/design values these are just the quoted Rc from the vendor measurement.

The mean value of MC2 Rc from all 6 peak measurements is 27277mm, with standard deviation 11mm*. This can be compared with the polisher's reported value of 27275mm (from the nebula page), the manufacturing requirement of 27240±140mm (see E070079-A-D), and the manufacturing goal of 27240±30mm (see also E070079-A-D). The value of Rc from this measurement agreed with the vendor value within the error bars, and is well within the manufacturing requirements (although it is slightly outside the manufacturing goal).

* The fits for HG11 and HG20/02 are a little suspect due to the influence of other nearby resonances. In both cases this influence can be expected to lower the measured peak frequency. For the HG11 mode this has the effect of increasing the HOM diff freq. and therefore lowering the calculated Rc. For the HG20/02 mode this has the effect of lowering the HOM diff freq. and therefore increasing the calculated Rc. The mean value for the Rc when these two measurements are discounted is 27278mm, and the standard deviation is 10.5mm. It appears therefore that the nearby resonances have a roughly equal and opposite effect on the HG11 and HG20/02 Rc values, and thus don't strongly affect the final result.

I put together an ODC site overview screen that contains the bits of all ODC channels implemented so far.
It also contains links to per-chamber summary screens, which in turn have links to the ODC screens with bit labels.

For now I added a link to the sitemap ASC menu.

More stuff will be added as it becomes available.

The screens all are in sys/common/medm, and should work for both sites. They are in svn as version 5850.

The pictures below show the site overview, and example chamber overviews for end-x and ham2.

The scheduled mainenance for the LHO CDS fileserver is complete.  The workstations, web services, and remote login are once again available for use.  Workstations in the LVEA were remotely shut down on Friday; these can be powered back on at any time they are needed.  The control room workstations, opsws0-7 are powered off to conserve electricity but may also be powered on if needed over the weekend.

The RAID card has been replaced in cdsfs0.  The new controller is now in the process of verifying the blocks on disk, which is a lengthy process and will take in the neighborhood of ~20 hours.  I will be back on site tomorrow early afternoon to run some additional checks on the filesystem before booting the CDS workstations and starting the RAID cache battery test.  There should be no issues with any of the CDS web pages at this point, it looks like everything is running normally there.  The external login server will be turned back on at the same time the workstations are ready.

RichM, HughR
Check for valid HEPI signals at BSC3 showed problems.  Found Cable going from HEPI AA chassis going to incorrect card on I/O comp.  HEPI I/O adc had an ISI cable attached.  We made BSC3 look like BSC 1/2 to correct; this matched the drawings.  The cable running from HEPI AA chassis was unlabeled.  The labeled cable was unattached at both ends.  I suspect the EEguys know something about this--maybe the labeled cable was deemed bad.  It should be removed is so and the cabling being used should be labeled.