I failed to start Rana's favorit anciant desktop computer at the vac rack. He has to baby this old beast just a little bit more.

Vacuum status: Vac Normal was reached through Farfalla: Rga was switched back to IFO and and Annuloses are beeing pumped now.

V1 was closed for about a day and the pressure reached  ~2.8 mTorr in the IFO.  This leakrate plus outgassing is normal

The ref cavity 5000V was turned on.

The only thing that has to be done is to restart the RGA. I forgat to turn it off on Friday.

POY11 PD was installed last night. The lock of the Y arm was confirmed with the POY11I signal.

- The DC transimpedance was modified to be 1010V/A as the incident power is tiny.

- The demodulation phase of the roughly adjusted (148deg) to have PDH signal at the I-phase.
 
The comparison with AS55I signal exhibits that POY11I have ~150 times weaker signal with 45dB whitening.
 
(In total 25000 times weaker.)

On the way to make POY11 functioning, there were many fixes at the LSC rack...

Details:

- The PD interface cards (power supply for the RFPDs) were checked:
So far the two card at the right hand side were checked. 

Desipite the previous entry reported the issues on those boards, they did not show any problem yesterday.

One hypothetical possibility is the enabling switches that is controlled from the old slow epics targets.

- POY55 was removed

This 55MHz PD is supposed to be installed at POP.
The PD, an RF cable, an RF amp, the power supply of the RF amp were removed.

- POY11 was installed

The PD was placed where the 55MHz was placed.

The beam was aligned on the diode using the IR viewer and the digital multimeter.

The power supply cable and the RF cable for POY on the ITMY table were used.

There were an ND filter on the POY beam path. It was removed.


- On the LSC rack
The PD RF was connected to the patch panel at the top of the rack.

There were loose connectors on the patch panel. Some connectors were tightened on the panel.

I found that POY11 and POX11 had I&Q signal reversely connected to the whitening board.
   ==> These were fixed but require the orthogonality test again for those channels.



The I phase output of the AS11 demod board had a broken connector. 

The onboard SMA has got disintegrated because of too much twist on the connector.
The board was once removed from the rack and the connector was fixed using a heat gun and soldering.

The DC signals were checked. POYDC was not correctly connected. POYDC were correctly connected to the POYDC channel.

- CDS
c1lsc was found with the RFM frozen.
The c1lsc machine was soft-rebooted after stopping all of the RT processes.

Once the RT processes came back, they were all burtrestored.

- PDH locking
Restored Y-arm. Locked it with AS55Q.
Ran ASS alignment for Y-arm.
100cnt 150Hz sinusoidal signal is applied to ETMY

Measured the PSD of AS55Q, POY11I, and POY11Q.
Adjusted the demod phase so that the excitation could be minimized in POY11Q.


 As it turns out Steve is not crazy in this particular instance: the vacuum computer, linux3 , has some issues. I can login just fine, but trying to open a terminal makes the CPU rail and the RAM max out and eventually the machine freezes.

Under KDE, I can open a terminal OK as root, but if I then try a 'su controls', the same issue happens. Let's wait for Jamie to fix this.

[Suresh / Koji / Rana / Kiwamu]

Last night we had a discussion about what we do for the RFAM issue. Here is the plan.

(PLAN)

  1. Build and install an RFAM monitor (a.k.a StochMon ) with a combination of a power splitter, band-pass-filters and Wenzel RMS detectors.

       => Some ordering has started (#5682). The Wenzel RMS detectors are already in hands.

  2. Install a temperature sensor on the EOM. And if possible install it with a new EOM resonant box.

      => make a wheatstone bridge circuit, whose voltage is modulated with a local oscillator at 100 Hz or so.

  3. Install a broadband RFPD to monitor the RFAMs and connect it to the StochMon network.

      => Koji's broadband PD or a commercial RFPD (e.g. Newfocus 1811 or similar)

  4. Measure the response of the amount of the RFAM versus the temperature of the EO crystal.

      => to see whether if stabilizing the temperature stabilizes the RFAM or not.

  5.  Measure the long-term behavior of the RFAM.

      => to estimate the worst amount of the RFAM and the time scale of its variation

  6. Decide which physical quantity we will stabilize, the temperature or the amount of the RFAM.

  7. Implement a digital servo to stabilize the RFAMs by feeding signals back to a heater

     => we need to install a heater on the EOM.

  8. In parallel to those actions, figure out how much offsets each LSC error signal will have due to the current amount of the RFAMs.

    => Optickle simulations.

  9. Set some criteria on the allowed amount of the RFAMs

    => With some given offsets in the LSC error signal, we investigate what kind of (bad) effects we will have.

I have modified all of the three RFPD interface cards to be enabled permanently.
This prevents an accidental disabling caused by a stray voltage of the logic input (or whatever),
which was reported in multiple occasions by Anamaria and me.

The logic ICs (74LS04) for buffering of the EPICS switches were removed by 14pin sockets with additional wires soldered.
The modification shorts the inputs to the second logic chips, resulting in the permanent enabling of the PD circuit.

There looks some activity at around MC2 on Wednesday afternoon.
It caused the misalignment of MC2. Misalignment was not found in MC1/3.

It seems that the incident beam on the MC was aligned in the evening.
This increased the MC transmission but it is vibible that the spot on MC2 is shifted from the center.

We need an action on this issue tomorrow in the daytime.

I am working on fixing this.  You might some strange stuff going on in the control room screens.  Pls ignore it till I am done.

  I have realigned the MC by recentering the spots on all the MC optics.  The current spot positions (in mm) are:

MC1P     MC2P     MC3P      MC1Y      MC2Y     MC3Y

0.2245    0.3364   -0.2801   -1.8891    0.1631   -1.744

Initially the lockins 2 and 5 showed very small outputs.  This was traced to the fact that we have recently switched on a 28Hz ELP filter module in the MC2 ASC filter bank which introduces an extra phase of about 75deg..  See this elog.

When the MC ASS lockins were initially setup, the phase was set with this filter module switched off.  Since quite some time has passed since the last calibration of these phases, I readjusted the phases to minimise the  Q_OUTPUT and I also adjusted the GAINs in the SIG filter banks  of all the six lockins so that their I_OUT's drop by the calibration value of -2.65 when an offset of 0.1 is introduced into the MC suspension output matrices.  Two short scripts in the $scripts$/ASS/ directory help in setting and removing these offsets.  They are called MCxoffsetOn and MCxoffsetOff.   They have to be edited appropriately to address each DoF of the MC.

The $scripts$/ASS/mcassUp script., which sets up everything to make the MC spot decentering measurement, has been edited to set these new phases and gains.  The old settings have been commented out.

I then centered the spots on the WFS sensors and the MC_TRANS QPD.  We are now ready to make the MC WFS output matrix transfer coef measurement again, but this time with the WFS loops closed.

While chatting with Jenne I learnt that some substantial amount of work had taken place yesterday around the MC2 chamber.  This was associated with the relocating of seismometers.  ref elog. 

I reiterate what is well known for quite sometime:  MC2 table is not well isolated from the ground.  And we should not approach this chamber unless absolutely necessary. I have blocked off the area around it which we should avoid.  It is a serious waste of time and effort to realign the MC each time the MC2 table decides to settle into a new position.

Steve tells me that the mild-steel frame supporting the chamber+MC2_table sits with two legs on one concrete slab while the other two legs sit on another one.   The frame is also quite weak without sufficient gussets or cross connects.  The next time we have a major shutdown we must replace this frame with a more sturdy one which sits on one slab (preferably the one on which the rest of the MC sits).

Till we improve this mounting, I suggest that we avoid that area as much as possible.

[Suresh, Mirko, Koji]

A cable from the stochmon box to the cross connect for the EPICS ADCs is installed.

The power supply and the signal outputs are concentrated in a single DSub 9pin connector
that is newly attached on the box.

The connection from the stochmon side of the cable and the EPICS value was confirmed.
The calibration of them looks fine.

To do:
- Once the stochmon box is completed we can immediately test it.
- The EPICS channel names are still as they were. We need to update the database file of c1iool0, the chans file for the slow channel.

The pinout is as following

-------------
| 1 2 3 4 5 |   Female / Inside View
\  6 7 8 9  /
 \---------/

1 - 11MHz Signal
2 - 30MHz Signal
3 - 55MHz Signal
4 - NC
5 - +5V supply
6 - 11MHz Return
7 - 30MHz Return
8 - 55MHz Return
9 - Supply ground

The amount of offsets in the LSC signals due to the RFAMs have been estimated by an Optickle simulation.

The next step is to think about what kind of effects we get from the RFAMs and estimate how much they will degrade the performance.

(Motivation)

(Results : Offsets in LSC error signals)

(Simulation setup)

For clarity, I also note the definition of PM/AM ratio as well as how the first order upper sideband looks like.

EDIT by KI:

  The definition of the recycling gain is wrong here.

See the latest entry (#5875)

Here is a summary about the Power Recycled Michelson (PRMI).

It seems the mode matching is also one of the greatest contributor on the low recycling gain.

 (Estimated parameters)

     +  Loss = 5.3% (or effective reflectivity of  93.28% in Michleson) => Under coupling !!

     +  Mode matching efficiency = 47.4 %  => Really bad !!

   With these values we end up with a recycling gain of 7 and a normalized REFLDC of  0.5 as observed (#5773).

Also according the incident beam scan measurement (#5773) the loss is NOT a local effect like a clipping, it is more like uniformly distributed thing.

As for the mode matching, the number indicates that approximately the half of the incident light is coming back to the REFL port without interacting with PRMI.

This is bad because the non-mode-matched light, which is just a junk light, is entering into the photo detectors unnecessarily.

In the worst scenario, those junk light may create a funny signal, for example a signal sensitive to the alignment of PRM.

(Estimation method)

The method to estimate the loss and the MM (Mode-Matching efficiency) is essentially the same as before (#5541).

One difference from the previous estimation is that the I used more realistic parameters on the transmissivity of ITMs and PRM :

     PRM : T = 5.637 %  (see the 40m wiki)

     ITM : T = 1.384 %  (see the 40m wiki)

 In addition to the basic calculations I also made plots which are handy for figuring out where we are.

Quantities we can measure are the reflected light from PRMI and the recycling gain using the REFL PD and the POY PD respectively.

So I wanted to see how the loss and MM can be estimated from the measured REFL DC and recycling gain.

The plots below are the ones.

[Loss map]

 The first figure shows a contour map of the loss as a function of the measured REFL DC and recycling gain.

The white area is a place where no proper solutions can be found (for example MM can get to more than 100 or loss becomes negative).

The star mark in the plot corresponds to the place where we are now. Obviously the loss is about 5%.

If we somehow decrease the amount of the loss the star mark will mostly go up in the plot.

[MM map]
 The second figure shows a contour map of the MM as a function of the measured REFL DC and recycling gain. 

The X and Y axis are exactly the same as that of the first plot. Again the star mark represents the place where we are.

We are currently at MM=47%

(Solutions)

Here are some solutions to bring the recycling gain higher.

We don't work on these things immediately since it requires opening of the chambers again and it will take some times.

But we should think about those options and prepare some stuff for a coming vent.

  + Refinement of the position of the mode matching telescopes.  => The Recycling gain can go up to 15.

     => Assuming the loss in the cavity doesn't change, the star mark in the first plot will go to the left hand side along the "0.05" black solid line.

     => However PRMI will be still under coupled.

     => Needs an estimation about which way we move the telescopes.

 + Locate the place of the dominant loss source and reduce it somehow.

    => The recycling gain will be more than 18 if the loss reduces by a factor of more than 5.

    => Needs a clever way to find it otherwise we have to do it in the classical way (i.e. white light and trying to find dirty surfaces)

Goal of this week :  ALS on the Y arm

Minimum success : Detection of the green beatnote between the freq-doubled PSL and the Y arm transmitted light

Difficult to understand.

The mode matching does not change the recycling gain. It changes the coupling of the incident light into the cavity.
It changes the reflected and accumulated power, but the recycling gain is not affected.

The recycling gain is determined by the optical configuration and the optical loss in the cavity.

In the actual measurement, of course, we should take both of the loss and the mode matching into account.
But this is the issue of the measurement method.

The essential questions are:
How much is the actual recycling gain? And how does it affect the signal extraction?

 As Koji pointed out I made a wrong definition on the recycling gain of PRMI (Power-Recycled Michelson Interferomter).

    Recycling gain :       

   Reflectivity of PRMI (measured by REFLDC):

    Power build up (measured by POY DC) :

    Mode Matching (MM) efficiency : 

    Loss in the PRMI cavity :

 (Results of Measurement and Estimation)

     Estimated recycling gain = 15

     Estimated MM efficiency = 47.4%

     Estimated Loss = 5.3%

     Measured power build Up = 7

     Measured reflectivity of PRMI = 0.5

Goal of this week : Noise budgeting on the Y arm ALS

Minimum success : bring the Y arm to the resonance by using ALS  NOISE BUDGETING!!!

 => as a preparation the incident beam pointing needs to be fixed by steering the MC suspensions.

[Rana / Kiwamu]

 As a part of the ALS noise budgeting we took a look at the Y end PDH setup to see if we are limited by an effect from the Amplitude Modulation (AM).

(AM transfer function)

(Y table setup needs more improvements)

• Use washers
• Beam clipping in Green Faraday and the very last mirror
• Use two screws and wide base plate
• Tune PPKTP PID parameters
• Remove flipper mirror
• Move the mechanical shutter to where the beam size is smaller
• Put a beam damp for the reflected light from the PD
• Cable rack
• Improve the incident angle on the last two launching mirrors

What is meant by the "average response of 50 dB"? Is this dB[ RIN / Hz ] or something? Also, do you mean the average over a broad band or the average response at the chosen modulation frequency over several trials? I don't really understand what measurement was done.

GPIB<->WIFI on Agilent Network Analyzer 4395A was broken.
The connection was fixed by replacing and configuring the LINKSYS bridge.

=======

Kiwamu and I have identified that the LINKSYS bridge was guilty.

I knew that we had another one in the bathroom, I configured it.

HOW TO CONFIGURE IT

• You need a host with 192.168.1.*.
• Connect the host and the LINKSYS directly
• Open http://192.168.1.226/
• Select 40MARS and infrastructure mode
• Register it in the MAC filter of the 40MARS (see wiki and use your head)

The new unit works fine.

I checked the malfunctioning unit and the configuration was the same as the others.

The bad one detected the existence of 40MARS during the configuration, but it does not establish
the connection in the actual use. I am afraid that something is broken or some setting is lost
during the power supply shutdown.

Now stochmon for 11MHz and 55MHz is running. The calibration / noise measurement are going to be post later...

We are now trying to understand why the coherence between SUS-X_SUSPOS_IN1 and SUS-X_SUSPOS_OUT is lost below 1 Hz for X = MC1, MC2, MC3, BS, ITMX, ITMY, ETMX, ETMY, SRM. It is OKEY only for PRM but the different filteres are used there. For PRM - 30:0.0 and Bounce Roll, for all others - 30:0.0 and Cheby. The transfer functions between these two signals plotted in foton and fft tools are also not the same.

If we switch off all the filters between these 2 signals, than the coherence is one. If one of the filters is switched on, everything is also fine. But if there are several present, than they filter the signal in unexpected way.

Moreover it seems that the coherence is dependent on the input signal. The coherence is better with local dumping than without.

 We have done the following on the c1sus and c1lsc computers : provided excitation, let the signal pass through filters 30:0.0 and Cheby and plotted the coherence between in and out signals.

c1sus computer - coherence is corrupted

c1lsc computer - coherence is not corrupted

The AM transfer function of the Y end laser has been measured again, but using the frequency-doubled laser this time.

Here is the latest plot of the AM transfer function. The Y-axis is calibrated to RIN (Relative Intensity Noise) / V.

IFBW (which corresponds to a frequency resolution) was set to 100 Hz and the data was averaged about 40 times in a frequency range of 100 kHz - 400 kHz.

Also the zipped data is attached.

It is obvious that out current modulation frequency of 179 kHz (178850 Hz) is not at any of the notches.

It could potentially introduce some amount of the offset to the PDH signal, which allows the audio frequency AM noise to couple into the PDH signal.

Currently I am measuring how much offset we have had because of the mismatched modulation frequency and how much the offset can be reduced by tuning the modulation frequency.

There is still a problem why GUR, STS signals are poorly coherent to MC_L.  But at least we can see coherence at 2-5 Hz. It might be useful to do something with adaptive filtering because it does not work at all for a long time. We start with Wiener filtering. I still doubt that static filtering is useful. Adaptive filter output is linear to its coefficients, so why not to provide adaptive filter with a zero approximation equal to calculated Wiener filter coefficients. Then you automatically have Wiener filter ouput + adaptively control coefficients. But if Wiener filter is already present in the model, I tried to make it work. Then we can compare performance of the OAF with static filter and without it.

I started with GUR1_X and MC_F signals recorded 1 month ago to figure out how stable TF is. Will the same coefficients work now online? In the plot below offline Wiener filtering is presented.

This offline filtering was done with 7500 coefficients. This FIR filter was converted to IIR filter with the following procedure:

1. Calculate frequency responce of the filter. It is presented below.

2. Multiply this frequency response by a window function. This we need because we are interested in frequencies 0.1-20 Hz at this moment. We want this function to be > 1e-3 at ~0Hz, so that the DC component is filtered out from seismometer signal. From the other hand we also do not want huge signal at high frequenies. We know that this signal will be filtered with aggresive low-pass filterd before going to the actuator but still we want to make sure that this signal is not very big to be filtered out by the low-pass filter.

The window function is done in the way to be a differential function to be easier fitted by the vectfit3. Function is equal to 1 for 0.5 - 20 Hz and 1e-5 for other frequencies except neighbouring to the 0.5 and 20 where the function is cosine.

3. I've used vectfit3 software to approximate the product of the frequency response of the filter and window fucntion with the rational function. I've used 10 complex conjugate poles. The function was weighted in the way to make deviation as small as possible for interesting frequencies 0.5 - 10 Hz. The approximation error is big below 20 Hz where the window function is 1e-5 but at least obtained rational function does not increase as real function do at high frequencies.

I tried to make a foton filter out of this approximation but it turns out that this filter is too large for it. Probably there is other problem with this approximation but once I've split the filter into 2 separate filters foton saved it. Wiener21 and Wiener22 filters are in the C1OAF.txt STATIC_STATMTX_8_8 model.

I've tested how the function was approximated. For this purpose I've downloaded GUR and MC_F signals and filtered GUR singla with rational approximation of the Wiener filter frequency response. From power spectral density and coherence plots presented below we can say that approximation is reasonable.

Next, I've approximated the actuator TF and inverted it. If TF measured in p. 5900 is correct then below presented its  rational approximation. We can see deviation at high frequencies - that's because I used small weights there using approximation - anyway this will not pass through 28 Hz low-pass filter before the actuator.

I've inverted this TF p->z , z->p, k->1/k. I've also added "-" sign before 1/k because we subtract the signal, not add it. I placed this filter 0.5Actuator20 to the C1OAF.txt SUS-MC2_OUT filter bank.

The next plot compares online measured MC_L without static filtering and with it. Blue line - with online Wiener filtering, red line - without Wiener filtering.

We can see some subtraction in the MC_L due to the static Wiener filtering in the 2-5 Hz where we see coherence. It is not that good as offline but the effect is still present. Probably, we should measure the actuator TF more precisely. It seems that there some phase problems during the subtraction. Or may be digital noise is corrupting the signal. 

 As part of the initiative to get a good daily summary page for aLIGO commissioning, Josh is spearheading his Detector Characterization group to produce such web pages for the 40m.

They're starting out with this launching point and then we can add all kinds of other information and plots as we want (e.g. Vac, PEM, Weather, coffee status). If you have suggestions/ideas, just edit this entry and add them, or email Josh directly.

I tried to run the seismic StripTool tonight, which seems liek a simple task. But instead I fell through the rabbit hole again...

The seismic.stp couldn't be run from zita/op340m because zita doesn't have EPICS or MEDM and because the op340m version of StripTool cannot load the new file format in which rossa/pianosa save their files.

Once I got it running by sshing in to rossa, I noticed that the BLRMS trends didn't make any sense. Correctly guessed that this was because all of the BP and LP filters were off. Why? Because of bad BURT, that's why.

As it turns out (if you look through the autoburt logs), several of our FE machines haven't been correctly saving snapshots because of some channel count mismatch between old and new SNAP files. So we are not getting the settings restored correctly for these systems when they get booted. Probably, someone has got to suss out the source of the BURT snap messages; it may be that we have to rehash the snap process after any substantial model rebuild.

For c1pemepics, I did a manual restore from the time when Mirko last ELOG'd that BLRMS was trending OK (Nov 23 @ 3 AM).

Seems like we should also get some kind of auto email warning if the BURTs fail in this way. Otherwise, we'll lose a lot of work if it goes on for weeks.

Bottom line: fix the autoburt so that it doesn't fail after model rebuilds.

At the suggestion of Rana and Koji, I have worked out some design parameters for a Stewart platform to be used as a vibration isolation device or as a platform for characterization of suspensions.  I have made some initial guesses about the following design requirements:

• linear travel: 40 microns peak to peak (based on SOS design requirements in LIGO-T950011)
• angular travel: 3 mrad peak to peak (based on SOS design requirements in LIGO-T950011)
• payload mass: 5 kg (wild guess of mass of loaded SOS)
• payload moment of inertia: 0.01 kg m^2 (wild guess)
• bandwidth: 500 Hz (suggestion of Rana and Koji: ~kHz)

From these assumptions, I have worked out:

• peak actuator force: 0.88 kN
• minimum radius of top platform: 15 cm
• minimum radius of bottom platform: 30 cm
• minimum height: 26 cm

The combination of high force, high speed, and ~micron travel limits seems to point to piezoelectric actuators.  PI's model P-225.80 would meet the peak push-pull force requirement, but I have not yet determined if it would meet the bandwidth requirement.  Apparently, typical piezoelectric actuators can exert a greater push force than pull force; wonder if one could use an actuator with a smaller force range than the P-225.80 if the actuator is biased by compression.  (Is this what is meant by a "preloaded" actuator?) 

I have attached a PDF explaining how I worked out the actuator force and platform dimensions.  (I'll try to dice up this PDF and put the contents in the Wiki.)  I also have a plant model in MATLAB with which I have been playing around with control schemes, but I don't think that this is ready to show yet.

Here are some tasks that still remain to be done for this preliminary case study:

• select sensing technologies: integrated linear encoders and/or strain meters, inertial sensing, optical levers, etc.
• study joints: Koji and Rana suggest flexures; I need to propose the joint geometry and material
• study internal modes of the platforms and actuators themselves
• build noise budget

I'd like to ask for input principally on:

• appropriateness of my design assumptions
• piezo actuators currently in use in the lab

 Edit: I also added a Mathematica notebook with the inverse kinematics (mapping from platform state to leg lengths) of the platform. 

[Koji Kiwamu]

We wonder if the flakiness of MC2 comes from the suspension or not.

To test it, we are shaking all of the suspension biases +/-1.0 with a script.

The script is here:
/users/koji/111216/SUS_hysteresis.sh

For this test, we closed the mechanical shutter before the MC.

Also some amount of misalignment is anticipated.
Don't be surprised if you see nothing is working when you come to the lab in the weekend.

Here is the Gantt chart we discussed in the 40m meeting today.

Based on the discussions we had, I applied a little bit of corrections on the chart but the main stream remains the same.

Often people say "I don't use conlog because its real slow". Its a little like not driving because your car has no gas.

I looked into what's going on with conlog. No one has fixed its channel list in ~1 year so it didn't make much sense. Also since Oct 1 of this year, it expired the leap seconds epoch and has been waiting for someone to look at the log file and update the list of leap seconds.

Some issues:

• Don't use the phrases like OUTPUT, OUTMON, OUT16, or INMON as the usual part of a channel name. These are filter modules words which use to exclude channels from conlog. Please fix ALL of the LOCKIN screens to get rid of the OUTPUT filter banks.
• If you use an EPICS channel in a servo so that its getting changed 16 times a second, make sure to add it to the conlog exclude list.

There are a bunch of bad channels which are screwing up various tools (DV, DTT, etc.):

Examples: C1:LSC-Subsystem_NPRO_SW1, C1:-DOF2PD_MTRX_0_0_SW1, C1:BAD-BAR_CRAZY_2_RSET, C1:C1L-DOF2PD_MTRX_3_14_SW2, C1:DUB-SEIS_GUR2_Z_LIMIT, etc.

• There are a bunch of old, unused directories in c1/medm/. EVERYONE take a look in there and delete the OLD dead ones so that we don't keep recording those channels.

 To fix up some of these issues, I have deleted several MEDM directories which I thought were old (there are several extras left from Aidan's Green time). I also have put a bunch of exclude variables into the conlog 'scan_adls' script to prevent it from adding some of the new worthless channels. Finally, I have started this command

../bin/strip_out_channels '.*STAT.*','.*_ALIVE.*','C1:PEM.*','.*_Name.*','C1:UCT.*','C1:MCP.*','C1:SP.*','C1:DU.*','C1:RF.*','C1:NIO.*','C1:TST.*','C1:SUP.*','C1:X.*','C1:FEC.*','.*_LFSERVO.*','.*FSS_SLOWDC.*','C1:LSC-LA_MTRX_21','C1:LSC-PD.*OFFSET','C1:LSC-ETM.*OFFSET' conlog*.log

which should strip lots of the excess conlog data out of the conlog directory. The only downside is that its setting all of the timestamps of the .log files to today instead of the historical times but I don't think we'll care about this too much. Hopefully it will speed things up to have less than 450 GB of conlog files...

update: 12 hours later, its still running and has removed ~100 GB so far. It will probably take the rest of the weekend to finish.

 I moved the following old and obsolete MEDM directories to an archive /cvs/cds/rtcds/caltech/c1/medm

• c1vga
• c1vgl
• c1gpt
• c1gpv
• c1nio
• c1spy
• c1spx

None of these models were present in /cvs/cds/rtcds/caltech/c1/target

Remember that we don't use /cvs/cds/rtcds anymore.  Everything should be in /opt/rtcds now.

There has been no lock of input MC for more than 5days. WTF???

I have fixed a loose mirror of the PMC input and the alignment of the MC2 Yaw.

- The PSL mech-shutter was closed. It has been opened.

- Then, I checked the MC suspensions. Mainly MC2 Yaw has kept drifting. (Fig.1)
In fact, there was no WFS actions during this drift.

Anyway, now MC2 Yaw was aligned and the lock was restored.

- It was very unsatisfactory for me that the PMC alignment kept drifting.
The trend of the PMC REFL and PMC TRANS for a year suggests that:

• Occasional drifts exist since a year ago (or probably since we built this new PMC setup in 2010 Sep)
• The drift has got frequent for the recent four months, and got more for the recent one month.

I went into the PMC setup and tapped several optics in order to find any loose optic.
Immediately I found that the mirror before the AOM was loose. Basically any mild tapping was enough
to misalign the mirror such that the caivty loose the TEM00 mode.

I tightened the retainer set screw of the optic and aligned the PMC again. It looks OK now as I can not
misalign this optic by the tapping anymore. But if it still remains drifting, we need to replace the mount.

 WE currently use long cables to give us the dispersion that we want for the MFD. A cable gives a long delay - both the phase delay and the group delay.

But we only need the dispersion (group delay). We can get this by just using a very sharp low pass filter and having the corner be above the frequency that we have the beat signal.

For example, the MiniCircuits SLP-200+ has got a corner frequency of 200 MHz and a group delay of ~10 ns (like a 3 m vacuum delay). So we would have to use 10 of these to get the delay we now get. The passband attenuation is only 0.5 dB, so we would lose 5 dB. The cost is $35 ea. We have a few on the shelf.

OTOH, if we tune the beat frequency down to 30 MHz, we can use the SLP-30 which has a group delay of 30 ns around 30 MHz. That's like 9m at light speed. We could easily get a nice result by just using 4 or 5 SLP in series.

So why is Kiwamu using cables?? And how should we really choose the beat note frequency??

[Suresh, Jamie]

Suresh and I opened up and checked out the eLIGO tip-tilts assemblies we received from LLO. There are two, TT1 and TT2, which were used for aligning AS beam into the OMC on HAM6. The mirror assemblies hang from steel wires suspended from little, damped, vertical blade springs. The magnets are press fit into the edge of the mirror assemblies. The pointy flags magnetically attach to the magnets. BOSEMS are attached to the frame. The DCC numbers on the parts seem to all be entirely lies, but this document seems to be close to what we have, sans the vertical blade springs: T0900566

We noticed a couple of issues related to the magnets and flags. One of the magnets on each mirror assembly is chipped (see attached photos). Some of the magnets are also a bit loose in their press fits in the mirror assemblies. Some of the flags don't seat very well on the magnets. Some of the flag bases are made of some sort of crappy steel that has rusted (also see pictures). Overall some flags/magnets are too wobbly and mechanically unsound. I wouldn't want to use them without overhauling the magnets and flags on the mirror assemblies.

There are what appear to be DCC/SN numbers etched on some of the parts.  They seem to correspond to what's in the document above, but they appear to be lies since I can't find any DCC documents that correspond to these numbers:

TT1: D070176-00 SN001
  mirror assembly: D070183-00 SN003
TT2: D070176-00 SN002
  mirror assembly: D070183-00 SN006

Plans:

•  DRMI (PRMI) + one arm test before the LVC meeting
•  Study of the funny sensing matrix and the RAM offset effects before the LVC meeting
•  Glitch hunting

Action items:

• MC beam pointing 
  
  • to make the PZT1 pitch relax
• OSA setup
  •    a long BNC cable for monitoring the signal in the control room
• Power budget on the AP table
  • in order to ensure the laser power on each photo diode

•  POP22/110 sideband monitor
  • installation of an RF amp
  • building a diplexer
  • connect the signals to the demod boards 
•  Calibration of the demod boards
  • calibrate the conversion loss of the mixers to calibrate all the LSC signals to watts / meter
•  (1+G) correction for the glitch time series data
• Simulation study for the RAM offset
  • How much offset do we get due to the RAM ? and how do the offsets screw up the sensing matrix ?
•  A complete set of the MICH characterization
  •   DC power
  •   Sensing matrix
  •   Noise budget
  •   OSA
  •   Estimation of the RAM offset 
  •  Summarize the results in the wiki
•  A complete set of the PRMI/DRMI characterization
  •  The same stuff as the MICH characterization
•  DRMI + one arm test
  •   Monitor the evolution of the sensing matrix during the arm is brought to the resonance

In order to install the necessary extensions to epics to make the aLIGO conlog work, I have edited one file in the base epics install that affects makefiles:

/cvs/cds/caltech/apps/linux64/epics/base/configure/CONFIG_COMMON

Jamie said he prefers diffs, so I regenerated the original file and did a diff against the current file:

megatron:configure>diff CONFIG_COMMON.orig.reconstructedMar72012 CONFIG_COMMON.bck.Mar72012
206,207c206,210
< USR_CPPFLAGS =
< USR_DBDFLAGS =
---
> USR_CPPFLAGS = -I $(EPICS_BASE)/include
> USR_CPPFLAGS += -I $(EPICS_BASE)/include/os/Linux/
> USR_CPPFLAGS += -I $(EPICS_BASE)/../modules/archive/lib/linux-x86_64/
> USR_DBDFLAGS = -I $(EPICS_BASE)/dbd
> USR_DBDFLAGS += -I $(EPICS_BASE)/../modules/archive/dbd

This is saved in CONFIG_COMMON.diff.Mar72012_1

 After following up with Patrick Thomas for a while trying to make the extensions to epics work within the currently installed epics, he decided that we should just start over with a fresh install of epics 3.14.10.

I am installing this in /ligo/apps/linux-x86_64/epics/base-3.14.10/

Prior to all of this, I had done a lot of installation and configuration of the packages needed to make LAMP work:

sudo apt-get install lamp-server^

sudo apt-get install phpmyadmin

I then continued to follow the instructions on Patrick's wiki:

https://awiki.ligo-wa.caltech.edu/aLIGO/Conlog#EDCU_library

I installed the c_string library into /ligo/apps/linux-x86_64/ according to his instructions.  (prior to my installs, there was no /ligo/ on this machine at all, so I made the needed parent directories with the correct permissions).

That should be everything up to installing epics (working on that now).

Successful? Installation of Fresh EPICS and Extensions

Fresh Copy of EPICS 3.14.10

/ligo/apps/linux-x86_64/epics

/ligo/apps/linux-x86_64/epics/iocs/conlog/iocBoot/iocc1_conlog

Rest of Install

New Install Instructions:

You want to create the EPICS IOC boot directory by doing the following:

In the top level of the IOC (.../epics/iocs/conlog) with the appropriate
paths:

/epics/base/bin/linux-x86_64/makeBaseApp.pl -i -t ioc c1_conlog
What application should the IOC(s) boot?
The default uses the IOC's name, even if not listed above.
Application name? conlog

Then you will have to update the st.cmd it creates. You can compare the
st.cmd and st.cmd.backup files in the other directories to see what needs
to be changed.

I don't know if just copying the directory will work, it might.

You will also probably want to change the following line in
/epics/modules/archive/archiveApp/src/drvArchive.c:

queue = epicsMessageQueueCreate(100000000, sizeof(struct message_type));

and reduce 100000000 to something smaller depending on the amount of ram
available to the computer. I think sizeof(struct message_type) is
something like 112 bytes. Then recompile.

You basically put a file with the list of channels to use in the directory
path for "use channel list filepath" in the following command in st.cmd:
drvArchive_read_channel_list_filepaths <add channel list filepath>,<remove
channel list filepath>,<use channel list filepath>
I can send you the script that I currently use to generate that channel
list if you want, but it may need to be changed for your setup.

Once you start the ioc, open the medm which can be checked out from
subversion here: cds_user_apps/trunk/cds/common/medm/CONLOG.adl
with macro substitution for IFO: medm -x -macro "IFO=C1"
and click on the button for "Use channel list".
The number of monitored channels should increase to the number of channels
in the file.

-Patrick

...

The perl script and example file are attached, just redirect the output of
the perl script to a file. It scans autoBurt.req files in a particular
directory and its subdirectories for channel names that meet certain
criteria. All the file contains is a list of channel names, one on each
line. To start the IOC, go to the target directory and run
./startup.c1conlog.

My Notes Regarding These Instructions:

dbLoadRecords("db/conlog.db","IFO=C1")
drvArchive_mysql "C1_conlog","/data/mysql/C1_conlog_epics_user"
drvArchive_read_channel_list_filepaths "/ligo/caltech/data/conlog/c1/add_channel_names","/ligo/caltech/data/conlog/c1/remove_channel_names","/ligo/caltech/data/conlog/c1/use_channel_names"
drvArchive_write_channel_list_filepaths "/ligo/caltech/data/conlog/c1/channel_names","/ligo/caltech/data/conlog/c1/monitored_channel_names","/ligo/caltech/data/conlog/c1/unmonitored_channel_names"

controls: cd /opt/rtcds/<site>/<ifo>/target/conlog/conlogepics
controls: cp -r /ligo/apps/linux-x86_64/epics/iocs/conlog/db ./
controls: cp -r /ligo/apps/linux-x86_64/epics/iocs/conlog/dbd ./
controls: cp /ligo/apps/linux-x86_64/epics/iocs/conlog/iocBoot/ioc<ifo>_conlog/envPaths ./
controls: cp /ligo/apps/linux-x86_64/epics/iocs/conlog/iocBoot/ioc<ifo>_conlog/st.cmd ./
controls: echo ./bin/linux-x86_64/conlog st.cmd > startup.<ifo>conlog
controls: chmod a+x startup.<ifo>conlog

megatron:~/ryan>diff -u /var/www/conlog/conlog.php /var/www/conlog/conlog.php.bck.Mar82012_1
--- /var/www/conlog/conlog.php  2012-03-08 15:31:53.152547771 -0800
+++ /var/www/conlog/conlog.php.bck.Mar82012_1   2012-03-08 15:28:23.062704171 -0800
@@ -19,7 +19,7 @@
        <form action="query.php" method="post">
                <h3><label for="database">Database:</label></h3>
                <select id="database" name="database">
-                       <option value="C1_conlog">C1</option>
+                       <option value="h2_conlog">h2</option>
                </select>
 
                <h3><label for="included_channels">Included channels:</label></h3>

megatron:~/ryan>diff -u /var/www/conlog/query.php /var/www/conlog/query.php.bck.Mar82012_1
--- /var/www/conlog/query.php   2012-03-08 15:33:45.122550303 -0800
+++ /var/www/conlog/query.php.bck.Mar82012_1    2012-03-08 15:32:31.772554679 -0800
@@ -168,8 +168,8 @@
        }
 
        $database_name = $_POST["database"];
-       if ($database_name == 'C1_conlog') {
-               $server = '192.168.113.209';
+       if ($database_name == 'h2_conlog') {
+               $server = 'cdsconlog';
        }
        else {
                die('Unknown database.');

megatron:~/ryan>diff -u /etc/mysql/my.cnf /etc/mysql/my.cnf.bck.Mar82012_1
--- /etc/mysql/my.cnf   2012-03-08 15:35:57.122548370 -0800
+++ /etc/mysql/my.cnf.bck.Mar82012_1    2012-03-08 15:35:10.652559315 -0800
@@ -49,7 +49,7 @@
 #
 # Instead of skip-networking the default is now to listen only on
 # localhost which is more compatible and is not less secure.
-#bind-address          = 127.0.0.1
+bind-address           = 127.0.0.1
 #
 # * Fine Tuning
 #
megatron:~/ryan>

Conlog Environment

Too Many Fast Changing EPICS in New Conlog

 Hi Rana,

It looks like the channe list file has a few blank lines that the channel list reader is choking on. I removed the lines and it is working now.. I have made the error message a bit more obvious (gave the file name  and line number) and allowed it to ignore empty lines so this won't cause problems with future versions (when installed). The bottom line is nds2 is now running on mafalda.
Best regards,

John   

JIMS Channels in PEM Model

The PEM model has been modified now to include the JIMS(Joint Information Management System) channel processing. Additionally Jim added test points at the outputs of the BLRMS.

For each seismometer channel, five bands are compared to threshold values to produce boolean results.  Bands with RMS below threshold produce bits with value 1, above threshold results in 0.  These bits are combined to produce one output channel that contains all of the results.

A persistent version of the channel is generated by a new library block that called persist which holds the value at 0 for a number of time steps equal to an EPICS variable setting from the time the boolean first drops to zero. The persist allows excursions shorter than the timestep of a downsampled timeseries to be seen reliably.

The JIMS Channels are being recorded and written to frames:

The two JIMS channels at 2048:
[C1:PEM-JIMS_CH1_DQ] Persistent version of JIMS channel. When bit drops to zero indicating something bad (BLRMS threshold exceeded) happens the bit stays at zero  for >= the value of the persist EPICS variable.
[C1:PEM-JIMS_CH2_DQ] Non-persistent version of JIMS channel.

And all of the BLRMS channels at 256:
Names are of the form:
[C1:PEM-RMS_ACC1_F0p1_0p3_DQ]
[C1:PEM-RMS_ACC1_F0p3_1_DQ]

For additional details about the JIMS Channels and the implementation, please see the previous elog entries by Jim.

Conlog

I have a working aLIGO Conlog/EPICS Log installed and running on megatron.

Please see this wiki page for the details of use:
https://wiki-40m.ligo.caltech.edu/aLIGO%20EPICs%20log%20%28conlog%29

I also edited this page with restart instructions for megatron:
https://wiki-40m.ligo.caltech.edu/Computer_Restart_Procedures#megatron

Please see Ryan's previous elog entries for installation details.

Future Work

• Determine useful thresholds for each band
• Generate MEDM Screens for JIMS Channels
• Add a decimation option to channels
• Add EPICS Strings in PEM model to describe bits in JIMS Channels
• Add additional JIMS Channels: Testing additional characterization methods
• Implement a State Log on Megatron: Will Provide a 1Hz index into JIMS Channels
• Generate a single web page that allows access to aLIGO Conlog/EPICS Log and State Log

I accidently shut off the laser at 19:34 with the emergency shutoff button while trying to tap into a video line for the Sensoray device.

We reset the interlock and restarted the PSL.  The end AUX lasers seem to have come back online fine.  PMC and mode cleaner locked back up quickly.

This morning I installed Ubuntu 10.04 on rosalba.  This is the same version that is running on pianosa.  The two machines should be identically configured, although rosalba may be missing some apt-getable packages.

[Jenne/Den/Koji]

We locked Xarm/Yarm and manually alignmed ITMX/ITMY/BS/ETMX/ETMY/PZT1/PZT2.

ITMY OPLEV was largely misaligned ==> The beam was centered on the QPD.

----

Then we aligned PRM using SB locking PRMI.

We noticed that OPLEV servo does not work. It made the PRM just noiser.

We went into the PRM table and found that the OPLEV beam was clipped in the vacuum chamber.
We tried to maximize the reflected beam from the window by touching the steering mirrors at the injection side.

Then the reflected beam was introduced to the center of the QPD.

After the alignment, the OPLEV QPD SUM increased to 4000ish from 200ish.
According to the OPLEV trend data, this is a nominal value of the QPD SUM.

Now the OPLEV servo does not go crazy.

 --

BS OPLEV beam was centered on the QPD.

Top tab categolies:

• Summary
• CDS
  • CDS Status
• PEM
  • Seismic 24h trend
  • Accoustic 24h trend
  • Weather/Temp/Barometer/etc 24h trend
• PSL/IOO
  • PSL summary trend / duty ratio
  • IOO summary (MC Health Check/IOO QPD trends / IFO QPD trends / Transmon QPD trends) duty ratio
• SUS
  • Summary
  • OSEM PSD/trend
  • OPLEV PSD/trend
• IFO
  • DC Mon
  • RF ports
  • OMC
• Steve
  • Vacuum
• Misc.

IFO

• DC Monitors
  • Incident beam power trend (24h)
  • AS/REFL/POP/TRX/TRY bean power trend (24h)
  • AS/POP RF beam power trend (24h)
• RF port
  • DARM sensitivity PSD (mean/min/max/reference) for an hour
  • DARM/CARM/PRCL/MICH/SRCL PSD
  • DARM/CARM/PRCL/MICH/SRCL (freq vs Gaussianity)
  • DARM/CARM/PRCL/MICH/SRCL calibration trend
• OMC
  • TBD

   Here is the suggested layout of the MC health check web page layout. I will update the Omnigraffle file as people comment and suggest changes.  If you want the file let me know.