Attached are plots are dust counts > .3 microns and > .5 microns in particles per cubic foot for Monday Novemeber 5, 2012. The data was taken from approximately 6 AM to 6 PM.
[Giacomo, Paul]
Yesterday we made some preliminary tests of the HAM AUX suspensions in the HAM2 chamber. We released the earthquake stops and checked that we could read sensible data from the OSEMs, and actuate the mirrors too - all of them looked fine, so the questionable cable connection mentioned in entry 4593 doesn't appear to be a problem. We then put the earthquake stops back in place and moved the HAM AUXs into the middle of the table to keep them out of the way for the moment (since we don't have dog-clamps to hold them down). We pulled the OSEMs out to make open light measurements (see comment from Giacomo in the near future). At first glance these look fine.
These are the measured open light values for the HAUX AOSEMs (10 seconds average):
| IM1 | IM2 | IM3 | IM4 | |
| UL | 23592 | 27614 | 25743 | 24264 |
| LL | 27862 | 25716 | 27778 | 24565 |
| UR | 25194 | 20038 | 26476 | 25148 |
| LR | 25681 | 28232 | 25051 | 19580 |
These are to be compared with the (approximate) ones recorded at the end of August (see post 4004). It appears that most of them have gon down in magnitude, with a few going below the 25000 threshold and one even below 20000. Not sure what the reason for and impact of this is...
Also, we measured the open light noise to look for excess noise of other strange thing, but we found none (good!). See attached image (input filters have for this measurements have offsets and gains based on the above open light values, as well as de-withening filters and nominal counts->um conversion factor).
It turns out that all the out of vacuum cables were swapped during this measurements, so these values cannot be directly compared to the ones measured in August, as different channels were reading different physical OSEMs (see entry 4697)
I ran my spectra with the purge air off. I don't need quiet time anymore.
Turning off the purge air of HAM3-ISI did not affect the peak observed at ~4.3Hz. Spectra are attached.
After the initial install of h1oaf0 we noticed that the RFM Y arm IPC error was lit and would not reset. At 17:28 I restarted h1iopoaf0 with the pciRfm=1 to see if this made any difference, it didn't the IPC error is still stuck on. The model h1peml0 was restarted in the course of this work at 17:28 local time.
WP#3535
modified IOP model h1iopsush2a to move the DACKILL trigger from MC1 to MC3. Prompted by disconnecting the top OSEM cables from MC1 and attaching to MC3 as it undergoes chamber side testing.
This is a transitory WP, so it has been closed.
Removed 4.5" ISC-REFL TIP/TILT 1-2 flange from D5-3 and preserved Class-A for re-installation at TBD location
Mark B. Starting Matlab TFs of MC3 at 14:12.
Mark B. Finished TFs at 11:10 next morning 11/6: Damped: 2012-11-05_1600* Undamped: 2012-11-06_0930*
Mark B. Data looks good except for slight V peak in R TF at 0.85 Hz - see attachment.
We observed peaks around 4Hz on spectra taken last week on HAM3-ISI. LLO folks suggested it may come from the purge air.
After talking with John and Kyle, we agreed on me turning it all the way down for about an hour. I will now take spectra in this configuration and put the butterfly valve back to the position I found it in (fully open) once I am done.
I just put the purge air back into its initial position: fully open.
Cheryl, Paul, Rodica
On Friday we installed the 3.5 mm thick DKDP and finished the characterization of the H1 Faraday isolator.
Its performance is:
Isolation: >30 dB for powers below 80 W, ~28 dB for powers as high as 140 W
Forward Extinction: >30 dB over the entire power range
Transmission: ~98%
Thermal lensing: Average f = -67 m, determining >99% mode matching
Beam Quality: - small deviation from gaussian for x and y profiles at 140 W, but notably elliptical. Profiles and intensity maps attached.
Surface quality of DKDP was good. Cheryl took IR pictures under exposure to 140 W laser power.
[Giacomo, Paul]
We moved all 4 HAM AUX assemblies into HAM 2, and cabled them up. One of the cable connections was a bit questionable, so we'll look out for that on Monday when we release the stoppers on the HAM AUXs. We attached all the other cable ends to their designated cable brackets in HAM 2. We also put together the in-vacuum periscope assembly, which is currently residing in the clean area next to HAM 2.
[Paul, Giacomo, Rodica, Cheryl]
This simulation work is related to the measurements described in entry 4571, in which beam distortion was observed when using the FI with 4mm DKDP at high-power.
Rodica found a paper by Khazanov in which the phasefront distortion due to a TGG / DKDP crystal combination at high laser power was measured (see http://www.intechopen.com/books/advances-in-solid-state-lasers-development-and-applications/faraday-isolators-for-high-average-power-lasers). To see if this kind of distortion could be responsible for the measure beam shape distortion observed by Rodica and Cheryl in the above report, I ran an FFT simulation where the distortion measured by Khazanov was applied at the FI position, and the beam was them propagated through the focusing lens setup used by Rodica and Cheryl. The result showed that such a distortion was capable of producing the 'double-beam' like intensity pattern, shortly after the beam waist position.
To understand the effect better, Giacomo created a semi-empirical functional form for the distortion that could roughly reproduce the phase distortion shape measured by Khazanov. We then used this functional form in FFT simulations, manually tweaking the parameters so as to match the intensity pattern measured by Rodica and Cheryl. This process was quite succesful; as shown in the attached plots we could reproduce Rodica and Cheryl's observations pretty well (to the eye).
The simulation study remains very much qualitative at this stage, but we hope that with a more complete set of beam profile measurements we can fit the phase distortion to the observed beam profiles, and pull out an estimate for the overall mode purity.
I noticed that it did not look like the alarm levels had been set on the FMCS EPICS channels. These are set by a burtrestore. I have set them.
WP#3533
We moved all fast PEM channels from H2 to H1 this afternoon.
The h2tcsl0 front end was shut down. It was disconnected from the PEM IO Chassis. The h1oaf0 one-stop cable was extendeded into the LVEA and connected to the LVEA PEM chassis. We powered h1oaf0 up for the first time, and Dolphin crashed all corner station SUS and SEI systems (see today's alog).
The h2ioptcsl0 model was copied for h1iopoaf0, and the h2peml0 model converted to h1peml0. We checked the SEIS channels looked ok.
I added PEM to H1 DAQ and removed it from H2 DAQ.
We have completed the transition of the EY CDS systems from H2 to H1. In the past two days we have been cleaning up MEDM screens, converting the filter module files and reconfiguring the H1 and H2 DAQs.
The only task left is to convert the HWS EPICS system to H1, we are working with the TCS group on this.
I am closing out WP #3518.
Late report from Wed/Thursday.
We have been noticing that when the 2-RFM systems h1lscl0 and h1oaf0 were powered up they crash all systems on the Dolphin network. On wed h1lsc0 was powered up for the very first time all SUS and HPI models crashed. The IOP models and ISI models time gliched. I diag reset runing models and restarted crashed models. Later Hugo noticed that the DAC drives for h1isiham3 were randomized and we could only recover by power cycling the h1seih23 IO Chassis (unplugging the DC power cord).
Today we got the same initial problem by powering up h1oat0. This time all user models crashed including ISI. We were careful to restart all models this time, including IOP models.
We correctly powered down h1oaf0 by first removing it from the Dolphin network, yet when we powered it up we once again crashed all Dolphin connected models. We are seeing a pattern here. Again we restarted all models (IOP and User). Hugo reported that the DAC channels for h1isiham3, h1susmc2 and h1suspr2 seem to be working (i.e. we cannot reproduce the DAC channels randomized problem).
[Patrick / Kiwamu]
We made some changes in the EPICS server script and database file for a slow digital process (PLC2 on H2ECATC1) to broadcast the EPICS values associated with the IMC control.
Yesterday we took a look at the OPC and EPICS servers on H1ECATC1 because the EPICS values had not been available. H1ECATC1 contains two PLCs (called PCL1 and PLC2) and the database file of both of them should be passed to the EPICS server. It turned out that the lines for PLC2, which takes care of the IMC servo and some others, were commented out in the EPICS startup script called st.cmd. We released the commented lines so that both PLC1.db and PLC2.db are loaded. However running the startup script then gave endless warning messages.
To make the situation simpler, we temporarily split the startup script into two pieces - one for PLC1 and the other for the IMC servo (which is a part of PLC2). They are called PLC1_st.cmd and PLC2_st.cmd respectively and each has a dedicated bat file. Also we made a database file which contains only IMC servo parts by copying the corresponding lines from the existing PLC2.db. This file is currenlty named as PLC2_IMC_REFL_SERVO.db
We ran both scripts to activeate two EPICS servers and they seemed running fine so far. So we are now able to see the EPICS values associated with the IMC servo board from an MEDM screen, which is good.
We need to further investigate why we got the numerous warning messages and how we solve it at some point.
Two viewports were fully installed on the south door of HAM01, BF1 (ISC beam) and BF2 (PSL input). The viewports are currently covered with viewport protectors.
Viewport covers now have safety covers' yellow type.
