I tried SRMI. The glitch rate wasn't as high as that of PRMI but it happened once per 10 sec or so.

[Keiko / Kiwamu]

 Some updates on the locking activity:

• Started summarizing the data of the Michelson lock in a wiki page:
  • https://wiki-40m.ligo.caltech.edu/Interferometer_Characterization/Michelson_Noise_Budget
  • Some careful analysis of the OSA signals are missing
    • Besides the analysis we need to work on the mode matching to get a better resolution as Mirko achieved.
• Gradually moving on to the PRMI lock
  • The lock stays for reasonably a long time (~20 min or more)
  • POP22/110 demod signals seemed just ADC noise.
  • A first noise budget is in process
    • The glitches make the noise level worse above 40 Hz or so in both the MICH and PRCL budgets.
  • Sensing matrix will be measured tomorrow
  • The data will be also summarized in a wiki page

We tried to measure the sensing matrix for MICH and PRCL last night. They look too much mixed as we expect... the matrix may be posted later. We suspect the IX and IY of the MICH excitation is not balanced very well, although Kiwamu adjusted that about two weeks ago, and it is mixing the dof. We'll try to balance it again, ans see the matrix. 

Keiko, Kiwamu

ITMX and ITMY balance for the MICH excitation (lockin) is adjusted again. Now it's ITMx = -0.992, ITMy = 1 for MICH (lockin output matrix values).

RA: what were the old values? Does this change make any difference for the signal mixing noticed before?

The vent is still going on. At this moment the pressure inside of the chambers is about 630 Torr.

Koji and I have replaced the 2nd instrument grade compressed air cylinder by the 3rd cylinder around 9 pm.

So far the vent speed has been nicely kept at about 1 Torr / min.

I wanted to use locate to find some files today, but found that it doesn't index any of our NFS mounted files (i.e. the whole /cvs/cds/ and /opt/rtcds/ ).

So I went into /etc/updatedb.conf and edited it like so, so that it no longer ignores NFS type file systems:

controls@rossa:/etc 0$ diff updatedb.conf updatedb.conf~
4c4
< PRUNEFS="nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre_lite tmpfs usbfs udf fuse.glusterfs fuse.sshfs ecryptfs fusesmb devtmpfs"
---
> PRUNEFS="NFS nfs nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre_lite tmpfs usbfs udf fuse.glusterfs fuse.sshfs ecryptfs fusesmb devtmpfs"

The CRON.daily on ROSSA only should run each morning at 6:25 (under the ionice class 3 protocol as usual). If this seems OK after a week or so, we can do the same for the other CDS workstations (remembering to adjust their cron.daily times so that not every one hammers the NFS at the same time).

I modified /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini to include the C1:LSC-DegreeOfFreedom_TRIG_MON channels.  These are the same channel that cause the LSC screen trigger indicators to light up. 

I vaguely followed Koji's directions in elog 5991, although I didn't add new grecords, since these channels are already included in the .db file as a result of EpicsOut blocks in the simulink model.  So really, I only did Step 2.  I still need to restart the framebuilder, but locking (attempt at locking) is happening.

The idea here is that we should be able to search through this channel, and when we get a trigger, we can go back and plot useful signals (PDs, error signals, cotrol signals,....), and try to figure out why we're losing lock. 

Rana tells me that this is similar to an old LockAcq script that would run DTT and get data.

EDIT:  I restarted the daqd on the fb, and I now see the channel in dataviewer, but I can only get live data, no past data, even though it says that it is (16,float).  Here's what Dataviewer is telling me:

Connecting to NDS Server fb (TCP port 8088)
Connecting.... done
read(); errno=0
LONG: DataRead = -1
No data found

read(); errno=9
read(); errno=9
T0=13-03-29-08-59-43; Length=432010 (s)
No data output.


I seem to be able to retrieve these channels ok from the past:

controls@pianosa:/opt/rtcds/caltech/c1/scripts 0$ tconvert 1049050000
Apr 03 2013 18:46:24 UTC
controls@pianosa:/opt/rtcds/caltech/c1/scripts 0$ ./general/getdata -s 1049050000 -d 10 --noplot C1:LSC-PRCL_TRIG_MON
Connecting to server fb:8088 ...
nds_logging_init: Entrynds_logging_init: Exit
fetching... 1049050000.0
Hit any key to exit: 
controls@pianosa:/opt/rtcds/caltech/c1/scripts 0$ 

Maybe DTT just needed to be reloaded/restarted?

apt install source-highlight

then modified bashrc to point to /usr/share instead of /usr/bin

Below are new alamode calculations of the PRC and SRC g-factors and arm mode matchings.  These include fixes to the ABCD matrices for the flipped folding mirrors that properly (hopefully) take into account the focusing effect of passing through the optic substrates.

I've used nominal curvatures of -600 m for the G&H PR2/SR2 optics, and -700 m for the Laseroptik PR3/SR3 dichroics.

An interesting and slightly disappointing note is that it looks like it actually would have been better to flip PR3 instead of PR2, although the difference isn't too big.  We should considering flipping SR3 instead or SR2 when dealing with the SRC.  I'll take responsibility for messing up the calculation for the flipped TTs.

PRC

SRC

RXA: maybe nominal, but we don't actually have measurements of the installed optics' curvatures, so there could be ~10-15% errors in the RoC. Which translates into a 1-2% error in the g-factor.

I think we like the idea of flipping SR2 better than SR3 for the same ghost beam reasons as PR2 is better than PR3.  There isn't very much free space in the BS chamber, and if we flip PR/SR3, we have to deal with green ghosts as well as IR.

The flipping SR2 case seems okay to me - flipping either one of the SR folding mirrors gives us a slightly better g-factor than the design with infinite curvatures, and flipping SR2 gives us slightly better mode matching to the arm than the flipped SR3 case, but more importantly, there are fewer ghosts to deal with.  I vote we flip SR2, not SR3.

 Updated laser inventory and operator list. They are posted in the 40m wiki and entry doors of the 40m IFO room.

Let me know if this list needs correction.

Lightwave  M126N-1064-700 NPRO sn 337 in the PSL enclosure got connected to local emergency shut off switch. This is a LIGO operational safety requirement.

In an attempt to clean up the medm situation, I did a bunch of further rearrangement and cleanup.  Instead of having c1ifo, I moved a bunch of stuff into a MISC directory, including all of the CDS, IFO, and VIDEO screens:

controls@rossa:~ 0$ ls -1 /opt/rtcds/caltech/c1/medm/MISC | grep -v _BAK
CDS_BIO_STATUS.adl
CDS_FE_STATUS.adl
CDS_IPC_ERR.adl
help
ifoalign
IFO_ALIGN.adl
ifoalign.orig
IFO_CONFIGURE.adl
IFO_CONFIGURE.txt
IFO_OVERVIEW.adl
IFO_OVERVIEW_AIDAN.adl
IFO_STATE.adl
snap
VIDEO.adl
controls@rossa:~ 0$

I updated the sitemap and the relevant screens accordingly.

I also updated the IFO_ALIGN script infrastructure a bit.  The new IFO ALIGN location is /opt/rtcds/caltech/c1/medm/MISC/ifoalign.  The scripts are now called simply:

/opt/rtcds/caltech/c1/medm/MISC/ifoalign/misalign_soft.csh
/opt/rtcds/caltech/c1/medm/MISC/ifoalign/restore_soft.csh
/opt/rtcds/caltech/c1/medm/MISC/ifoalign/save_soft.csh

These run Jenne's new soft restore stuff, and store burt snapshots for optic alignment in /opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt.

This has all been checked into the svn.

I updated the getdata script so that it can now handle downloading long stretches of data.

  /opt/rtcds/caltech/c1/scripts/general/getdata

It now writes the data to disk incrementally while it's downloading from the server, so it doesn't fill up memory.

I also added a couple new options:

* --append allows for appending to existing data files

* --noplot suppresses plotting during download

I updated the peakFit routines to make them a bit more user friendly:

• modified so that any subset of optics can be processed at a time, instead of just all
• broke out tweakable fit parameters into a separate parameters.m file
• added a README that describes use

These changes were committed to the 40m svn.

I was working with the git repo in the SnapPy_pypylon folder (/cvs/cds/rtcds/caltech/c1/scripts/GigE/SnapPy_pypylon) and needed to create a branch. To avoid any confusion, I modified the PS1 variable and that alone in the bashrc file to reflect the git branch so that the prompt now displays the git branch if you enter a repository. This is just an update.

After poking at the new configuration more, it also started to show instability.  I couldn't figure out how to make test points or excitations available in this configuration, and adding in the full set of test point channels, and trying to do simple things like plotting channels with dtt, the frame writer (fw) would fall over, apparetnly unable to keep up with the broadcast from the dc.

I've revered everything back to the old semi-working fb configuration, and will be kicking this to the CDS group to deal with.

[Paco]

Upgraded zita's ubuntu and restarted the striptool script.

Use LISO - see what it tells you. I would think that you should make a differential RC filter to get the right behavior. (e.g. 1K on each leg and 1 uF between them)

Each leg of the diff input of the board has a 4k input impedance.

But surely the AO input to the MC servo should also make sense independently.

I used APTITUDE to install texlive-full on rosalba so that I could work on a paper. pdflatex was not found on pianosa, rosalba, megatron, etc. I used this command:

sudo aptitude install texlive-full

While this was installing, I read a bunch of forums which claim that its better to bypass the apt-get and use the 
TexLive installer instead so that we can use its own package updater 'tlmgr'. Otherwise, the standard Ubuntu distributions
are years out of date (e.g. doesn't have RevTex 4.1).

LISO confirms that I did my algebra right in picking the component values, and shows no extra zeros. 

I also took some TFs with the SR785 and confirmed that both CM board inputs behave the same, and that including the LPF on the input gives the expected 1/f shape at the slow and fast outputs.

 The brand new OSEM LED and PD can be picked up with a weak magnet. These ferrous metals of LEDs and PDs will be magnetized by sitting in the sus next to the

magnets for years. I hanged optics with new OSEMs and never saw this effect before.

We have to demagnetize them.

The OSEM LEDs and PDs from Honeywell have always had some ferromagnetic material in them. These are the same OSEMs we had since 2000.

You must be thinking of the really old 20th century plastic OSEMs.

[Mengyao, Yuta]

Last night, I used 1.5 m delay line COARSE and got 5FSR mode scan. The range 5FSR was limited by the range of SR560.
So, this time, we used 6.4 m(21 feet) cable as a delay line for FINE servo. This should increase the sensitivity by factor of 4. But the range will be 4 tmes smaller, ~ 1.3FSR.

Below is the plot of the mode scan.
You can see the peak height difference between TEM00s, but it's just from the resolution of pixels.

You still can see noisiness goes up when blue plot goes down. But this time, 2000 stands for 27 MHz and -2000 stands for 15 MHz in the beat frequency because we flipped the filter gain this time.
Last night, the top of the triangle was about 40 MHz and bottom was about 60 MHz.




We are going to derive mode-matching and some cavity parameters using this plot.

JoeB and JamieR are working somewhat coherently on a set of python libraries to fulfill all of our command line CDS wants. This is being done mostly to satisfy The Guardian and the SkunkTools project.

I did an 'svn up' in /opt/rtcds/userapps (it might finish in ~1000 years) to get the things that they have so far (in particular, Joe's 'pyavg'). There's going to be some issues since the pylib stuff written by Yuta/Kiwamu has never been integrated with anything and is imported as 'epics' in many python scripts. As we move over to the new stuff there will be a lot of broken script functions since the new libraries are also used in that way.

Rana suggested using OSEM sensing voltages as guide lines to look seismic activity.

As you see todays drilling and tumping activity was nothing compared to the EQ of mag 5 and 4

Optic level servos are turned back on.

What Steve means is that there is some drilling going on in the CES shop to accomodate the new water flume group. We want to

make sure that the mirrors don't move enough to break the magnets. On the dataviewer we should look to make sure that the

sensor channels stay between 0-2 V.     -Rana

 The second loop of the bungee cord should be on the top of the acrylic  and still on the supporting aluminum tube as shown.

We tried not to open chambers above 10,000 particles of 0.5 micron cf/min

New items going in:                       2 rasor beam traps, 5 badly oxidized old silver plated  setscrew with spring loaded tips......to be replaced in the future, viton tips for eq screws....some are lose, gold plated allen wrench installed at ITMX bottom, reglued magnet on ITMX

Bad hardware things found:          nylon ball "locking elements" on OSEM locking set screws with screwdriver  slot, lose  1064 nm filter on OSEM pd

 This seal is good for daily use- operation only. The IFO has to be sealed  with light metal doors every night so ants and other bugs can not find their way in.

Our janitor Kevin is mopping the hole IFO room floor area with 5%  ant killing solution in water in order to discourage bugs getting close to our openings of the vented chamber.

You may be sensitive to this chemical too.  Do not open chamber till after lunch.

Roger.

Matt and Koji:

We closed the light doors of the chambers.

Cold cathode gauge CC4  is reading normal.

CC1 is glitching, it is probably dirty.

CC2 is fluctuating too much and it is cutting out for 6-7 minutes. It must be insulated by deposits and there is no emission current.

I think the same goes for P1

They will have to be replaced at the next vent

The COVAC_MONITOR.adl was changed. Ion pump labeled as disconnected means: ion pump controller power turned off and ion pump gate valve control connection disconnected.

RP2 roughing pump labeled disconnected means:  hardware  disconnected.

The actual operational, valve control screen has not been changed yet.

We run out of N2 for the vacuum system 6 hrs ago. The pressure rose to 1.2 mTorr with V1 closed. The interlock worked! See Nirogen presure reading fixed at http://nodus.ligo.caltech.edu:8080/40m/10968

The vacuum interlock: Nitrogen pressure transducer is reading the pneumatic pressure continously at the pump spool and c1vac1 processing it. When it drops below 60 PSI it closes V1 gate valve and V4 & V5.  Gate valve V1 needs minimum 60 PSI to close. It is critical that V1 is closed before you run out of Nitrogen so the IFO pressure is contained.

IFO vacuum is back to Vac Normal. The MC is locked.

cc4 = 2E-6 Torr with VM1 open.

Daily N2 consumption measured to be 530PSI as 3 days on 3-27-2015 but note: it does vary !

I have seen it as high as 900 psi  The long term average ~750 psi

We run out of N2 for the vacuum system. The pressure peaked at 1.3 mTorr with MC locked. V1 did not closed because the N2 pressure sensor failed.

We are back to vac normal. I will be here tomorrow to check on things.

Amstron batteries replaced after 11 months with SP-12-5.5HR,  2 years warranty from replaceUPSbattery.com

Note: the replace battery LED did not go out ( well pasted 24 hrs ) till the self test bottom was hold down for 2-3 sec

APC Smart -UPS 2200   model: SUA2200RM2U   batteries were replaced by compatible RBC43, 8x  12V5A

Batteries replaced after 3.5 years with Amstron AP-1250F2,  8x 12V 6Ah

Ben and I found this vacuum valve relay box intermittently shorthing yesterday.

It effects V4, V5, VA6 and VM1........   Please do not touch this box under the beam pipe next to the vac rack!

The function of this box to send 120VAC to the vacuum valve to move.

Steve and I managed to access the fuse in the vacuum VME crate, but replacing it did not bring it back up.  We decided to replace the entire crate.

We manually checked that the most important valves, VC1, VM1 and V1, were all closed.  We disconnected their power so that they would automatically close, and we wouldn't have to worry about them accidentally opening when we rebooted the system.

We noted where all the cables were, disconnected everything, and removed the crate.  We noted that one of the values switched when we disconnected one of the IPC cables from a VME card.  We'll note which one it was in a followup post.  We thought that was a little strange, since the VME crate was completely unpowered.

Anyway, we removed the crate, swapped in a spare, replaced all the cards and connections, double checked everything, then powered up the crate.  That's when minor chaos ensued.

When the system came back online after about 20 seconds, we heard a whole bunch of valves switching.  Luckily we were able to get the medm screens back up so that we could see what was going on.

Apparently all of the ION pump valves (VIPEE, VIPEV, VIPSV, VIPSE) opened, which vented the main volume up to 62 mTorr.  All of the annulus valves (VAVSE, VAVSV, VAVBS, VAVEV, VAVEE) also appeared to be open.  One of the roughing pumps was also turned on.  Other stuff we didn't notice?  Bad.

We ran around and manually unplugged all of the ION pump valves, since I couldn't immediately pull up the vacuum control screen.  Once that was done and we could see that the main volume was closed off we went back to figure out what was going on.

We got the medm vacuum control screen back (/cvs/cds/caltech/medm/c0/ve/VacControl_BAK.adl.  really??)  There was a lot of inconsistency between the readback states of the valves and the switch settings.  Toggling the switches seemed to bring things back in line.  At this point it seemed that we had control of the system again.  The epics readings were consistent with what we were seeing in the vacuum rack.

We went through and closed everything that should have been closed.  The line pressure between the big turbo pump TP1 and the rest of the pumps was up at atmosphere, 700 Torr.  We connected the roughing pumps and pumped down the lines so that we could turn the turbos back on.  Once TP2 and TP3 were up to speed, we turned on TP1 and opened V1 to start pumping the main volume back town.   The main volume is at 7e-4 Torr right now.

So there are a couple of problems with the vacuum system.

• Why the hell did valves open when we rebooted the VME crate?  That's very bad.  That should never happen.  If the system is set to come up to an unsafe state that needs to be fixed ASAP.  The ION pump valves should never have opened.  Nor the annulus valves.
• Why were the switches and the readbacks showing different states?
• Apparently there is no control of the turbo pumps through MEDM.  This should be fixed.

I connect belledona, the laptop at the vacuum station to the wired network, so that it's connection would be less flaky.

[ericq, Gautam, Steve]

Following roughly the same procedure as ELOG 11354, c1vac1 and c1vac2 were rebooted. The symptoms were identical to the situation in that ELOG; c1vac1 could be pinged and telneted to, but c1vac2 was totally unresponsive. 

The only change in the linked procedure was that we did not shut down the maglev. Since I unwittingly had it running for days without V4 open while Steve was away, we now know that it can handle shorter periods of time than that...

Upon reboot, many channels were readable again, unfortunately the channels for TP2 and TP3 are still blank. We were able to return to "Vacuum normal state," but because of unknowned communication problems with VM1's interlock, we can't open VM1 for the RGA. Instead we opened VM2 to expose the RGA to the main IFO volumn, but this isn't part of the "Normal" state definite, so things currently read "Undefined state".

[ Gautam and Steve ]

c1vac1 and c1vac2 were rebooted and the gauges are communicating now. V1, VA6, V5 and V4 were closed and disconnected to avoid unexpected valve switching. All went smoothly.

The new ITcc gauge is at 1e-5 Torr as CC1   This is the gauge that should be logged in slow channel.

TP2 fore line dry pump was replaced this morning after 382 day of operation.

TP3 dry pump is very noisy, but it's pressure still 47 mTorr