40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 279 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  17086   Wed Aug 17 10:23:05 2022 TegaUpdateGeneralc1vac issues, pressure gauge replacement

- Disk full

I updated the configuration file '/etc/logrotate.d/rsyslog' to set a file sise limit of 50M on 'syslog' and 'daemon.log' since these are the two log files that capture caget & caput terminal outputs. I also reduce the number of backup files to 2.

controls@c1vac:~$ cat /etc/logrotate.d/rsyslog
/var/log/syslog
{
    rotate 2
    daily
    size 50M
    missingok
    notifempty
    delaycompress
    compress
    postrotate
        invoke-rc.d rsyslog rotate > /dev/null
    endscript
}

/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
{
    rotate 2
    missingok
    notifempty
    size 50M
    compress
    delaycompress
    postrotate
        invoke-rc.d rsyslog rotate > /dev/null
    endscript
}
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
    rotate 4
    weekly
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    postrotate
        invoke-rc.d rsyslog rotate > /dev/null
    endscript
}

- Vacuum gauge

The XGS-600 can handle 6 FRGs and we currently have 5 of them connected. Yes, having a spare would be good. I'll see about placing an order for these then.

Quote:

- Disk Full: Just use the usual /etc/logrotate thing

- Vacuum gauge

I rather feel not replacing P1a. We used to have Ps and CCs as they didn't cover the entire pressure range. However, this new FRG (=Full Range Gauge) does cover from 1atm to 4nTorr.

Why don't we have a couple of FRG spares, instead?

Questions to Tega: How many FRGs can our XGS-600 controller handle?

 

 

  14279   Tue Nov 6 23:19:06 2018 gautamUpdateVACc1vac1 FAIL lights on (briefly)

Jon and I stuck a extender card into the eurocrate at 1X8 earlier today (~5pm PT), to see if the box was getting +24V DC from the Sorensen or not. Upon sticking the card in, the FAIL LEDs on all the VME cards came on. We immediately removed the extender card. Without any intervention from us, after ~1 minute, the FAIL LEDs went off again. Judging by the main volume pressure (Attachment #1) and the Vacuum MEDM screen (Attachment #2), this did not create any issues and the c1vac1 computer is still responsive.

But Steve can perhaps run a check in the AM to confirm that this activity didn't break anything.

Is there a reason why extender cards shouldn't be stuck into eurocrates?

Attachment 1: Screenshot_from_2018-11-06_23-18-23.png
Screenshot_from_2018-11-06_23-18-23.png
Attachment 2: Screenshot_from_2018-11-06_23-19-26.png
Screenshot_from_2018-11-06_23-19-26.png
  14281   Wed Nov 7 08:32:32 2018 SteveUpdateVACc1vac1 FAIL lights on (briefly)...checked

The vacuum and MC are OK

Quote:

Jon and I stuck a extender card into the eurocrate at 1X8 earlier today (~5pm PT), to see if the box was getting +24V DC from the Sorensen or not. Upon sticking the card in, the FAIL LEDs on all the VME cards came on. We immediately removed the extender card. Without any intervention from us, after ~1 minute, the FAIL LEDs went off again. Judging by the main volume pressure (Attachment #1) and the Vacuum MEDM screen (Attachment #2), this did not create any issues and the c1vac1 computer is still responsive.

But Steve can perhaps run a check in the AM to confirm that this activity didn't break anything.

Is there a reason why extender cards shouldn't be stuck into eurocrates?

 

Attachment 1: Vac_MC_OK.png
Vac_MC_OK.png
  14207   Fri Sep 21 16:51:43 2018 gautamUpdateVACc1vac1 is unresponsive

Steve pointed out that some of the vacuum MEDM screen fields were reporting "NO COMM". Koji confirmed that this is a c1vac1 problem, likely the same as reported here and can be fixed using the same procedure.

However, Steve is worried that the interlock won't kick in in case of a vacuum emergency, so we are leaving the PSL shutter closed over the weekend. The problem will be revisited on Monday.

  14215   Mon Sep 24 15:06:10 2018 gautamUpdateVACc1vac1 reboot + TP1 controller replacement

[steve, gautam]

Following the procedure in this elog, we effected a reset of the vacuum slow machines. Usually, I just turn the key on these crates to do a power cycle, but Steve pointed out that for the vacuum machines, we should only push the "reset" button.

While TP1 was spun down, we took the opportunity to replace the TP1 controller with a spare unit the company has sent us for use while our unit is sent to them for maintenance. The procedure was in principle simple (I only list the additional ones, for the various valve closures, see the slow machine reset procedure elog):

  • Turn power off using switch on rear.
  • Remove 4 connecting cables on the back.
  • Switch controllers.
  • Reconnect 4 cables on the back panel.
  • Turn power back on using switch on rear.

However, we were foiled by a Philips screw on the DB37 connector labelled "MAG BRG", which had all its head worn out. We had to make a cut in this screw using a saw blade, and use a "-" screwdriver to get this troublesome screw out. Steve suspects this is a metric gauge screw, and will request the company to send us a new one, we will replace it when re-installing the maintaiend controller. 

Attachments #1 and #2 show the Vacuum MEDM screen before and after the reboot respectively - evidently, the fields that were reading "NO COMM" now read numbers. Attachment #3 shows the main volume pressure during this work.

Quote:

The problem will be revisited on Monday.

Attachment 1: beforeReboot.png
beforeReboot.png
Attachment 2: afterReboot.png
afterReboot.png
Attachment 3: CC1.png
CC1.png
  14278   Tue Nov 6 19:41:46 2018 JonOmnistructure c1vac1/2 replacement

This afternoon I started setting up the Supermicro 5017A-EP that will replace c1vac1/2. Following Johannes's procedure in 13681 I installed Debian 8.11 (jessie). There is a more recent stable release, 9.5, now available since the first acromag machine was assembled, but I stuck to version 8 for consistency. We already know that version to work. The setup is sitting on the left side of the electronics bench for now.

  1505   Mon Apr 20 23:27:59 2009 ranaSummaryVACc1vac2 rebooted: non-functional for several months
We found several problems with the framebuilder tonight. The first symptom was that it was totally out of
disk space. The latest daqd log file had gone up to 500 MB and filled the space. The log file was full of
a lot of requests from my seisBLRMS.m code, but what was really making it so big was that it couldn't
connect to c1vac2 (aka scipe4) to make connections for some channels.

We looked into the daqd log files and this has been going on since at least December. There were several
'whited out' records for TP2 and TP3 in the Vacuum overview as well as the Checklist screen! Why did no
one notice this and fix it??
WE cannot function if we just ignore any non-functioning displays and say
"Oh, that never worked."

For sure, we know that it was working in 2005. Jay and Steve and Alan looked at it.

Today it was responding to ping and telnet, but not allowing any new connections. I hit the RESET button
on it. Several lights went RED and then it came back up. The readbacks on the EPICS screens are OK too.

I went into fb0 and deleted many of the GB size log files from the past several months. There is now
19GB free out of its local 33GB disk.
  5989   Wed Nov 23 16:48:39 2011 SureshUpdateGeneralcable cleanup

[Koji Suresh]

As part of the general lab clean up we removed many unused BNC cables (long and short) from around the SP table.  We removed one very long BNC cable which was connected on one side to an PEM input and not connected on the other side near the 1X2 rack..   There were several cables from an old SURF phase camera project which were still attached to a couple of RF amps on the SP tables and running towards the 1X6 rack. 

We also removed some unused power cables  plugged into a power distribution strip near Megatron.

 

  875   Mon Aug 25 10:23:53 2008 steveHowToGeneralcable killer
Rack 1Y7 double violation:

BNC cables left to be jammed by door

and see destroyed BNCs

RED fibers should be rerouted.
I placed protective obstacle in position
so the door can not be closed.

Please do not do this!

DNA analysis is in progress on your finger prints.
Attachment 1: cablkill.png
cablkill.png
Attachment 2: cablkll2.png
cablkll2.png
  7873   Thu Jan 3 19:19:59 2013 ranaHowToElectronicscable racks

Today I found 3 power cables in the orange Pomona cable tray, put in so that the cables were damaged and therefore dangerous.

Please think about what you are doing before doing it. Damaging these things because your are in a hurry or frustrated will just waste our time and damage our interferometer.

For reference, we only use the thick blue Pomona racks for power cables. We use the orange and black ones for thinner cables. Pay attention and keep the cables organized.

Cable Rack Selection

 

  4390   Wed Mar 9 16:07:42 2011 kiwamuUpdateVIDEOcable session

[Koji, Steve, Suresh, Kiwamu]

The following video cables have been newly laid down :

  - MC1F/MC3F (65 ft.)

  - PMCR (100 ft.)

  - PSL spare (100 ft.)

  - PSL1  (100 ft.)

  - PSL2  (100 ft.)

 

  11659   Fri Oct 2 15:11:08 2015 SteveUpdatePEMcable squashed

Cable numbered #53 from Accelerometer 4 to 1X7 / DAQ input c26 was squased while removing network card from Sun Fire x4600 today.

This cable has to be tested.

  7807   Tue Dec 11 08:53:52 2012 SteveHowToPEMcables needs care

How NOT to:

The janitor can not clean in areas like this. He may only steps on these cables accidentally as he dust wiping our chambers.

Attachment 1: IMG_1839.JPG
IMG_1839.JPG
  7809   Tue Dec 11 10:09:04 2012 AyakaHowToPEMcables needs care

Quote:

How NOT to:

The janitor can not clean in areas like this. He may only steps on these cables accidentally as he dust wiping our chambers.

 Sorry for the mess. I fixed it.

  3996   Tue Nov 30 12:33:27 2010 kiwamuSummaryIOOcabling of in-vac PZT mirrors

  10066   Wed Jun 18 22:34:44 2014 ericqUpdateIOOcaget frusrtation

Quote:

 Somehow the caget/caput commands are really slow. I'm not sure if this is new behavior or not, but after changing values, it takes ~1-2 seconds to move on to the next command.

This is still happening. Specifically: on all of the control room computers, calls to caget display the result immediately, but then hang for five seconds (consistently five). We had also seen a situation where calls hang indefinitely on ottavia/pianosa, but a reboot "fixes" this.

Some observations:

  • Front end machines and the FB have proper caget/caput response times.
  • Control room machines have some odd ping behavior when targeting frontends/FB; namely the ping times themselves are ok, but each ping line takes quite some time to show up, which made us think that there is odd network routing issue happening with some network switch. 
  • Front ends and FB get epics from /opt/rtapps, whereas control room machines get epics from /ligo/apps, which has different contents. (Is this for Gentoo vs. Ubuntu? I don't really get why this is the case...). This means different environment setting scripts to be called, so maybe the control room machines are misconfigured in some way for the new name server?

I poked around the network settings on all of these machines, but everything seemed reasonable. Nothing was changed. Rossa and Pianosa have their network settings done through some Ubuntu GUI, but I don't know where the settings are written. I had expected their settings to be in /etc/network/interfaces; maybe we should change this to be consistent with other machines, and easier to administrate via the terminal. 

Despite all this, ezcaread is fine.

  10077   Thu Jun 19 22:04:23 2014 ericqUpdateComputer Scripts / Programscaget/caput now return in reasonable time

I think I've fixed the caget/caput issue. Rana's observation that pinging the IP directly was faster than pinging the hostname set me on a path of googling which informed making the following changes to the DNS setup on chiara (specifically, informed by this thread: http://www.dslreports.com/forum/r11836974-BIND-slow-to-reply-over-LAN-Solved)

/etc/bind/named.conf.local has these lines:

zone "martian" IN {
 type master;
 file "/etc/bind/zones/martian.db";
 };
zone "113.168.192.in-addr.arpa" {
 type master;
 file "/etc/bind/zones/rev.113.168.192.in-addr.arpa";
};

The first zone command links hostnames like c1lsc to an IP like 192.168.113.62, but apparently in the second, we need to do the inverse. So, for each line in martian.db like

c1lsc           A       192.168.113.62

I added a line in rev.113.168.192.in-addr.arpa like so:

62 IN PTR c1lsc.martian

This seems kind of silly, but now if you do the host command from a workstation, it can find the hostname associated with an IP. 

controls@pianosa|~ > host 192.168.113.62
62.113.168.192.in-addr.arpa domain name pointer scipe12.martian.113.168.192.in-addr.arpa.
62.113.168.192.in-addr.arpa domain name pointer c1lsc.martian.113.168.192.in-addr.arpa.

[At this point, note that we have a bunch of duplicate entries in https://wiki-40m.ligo.caltech.edu/Martian_Host_Table  with these scipe## hostnames. What are these for?]


 
Now (edited for brevity):
 
controls@ottavia|~ > ping -c 5 -D c1sus
PING c1sus.martian (192.168.113.85) 56(84) bytes of data.
<SNIP>
--- c1sus.martian ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3997ms
rtt min/avg/max/mdev = 0.051/0.075/0.114/0.028 ms
controls@ottavia|~ > ping -c 5 -D 192.168.113.85
PING 192.168.113.85 (192.168.113.85) 56(84) bytes of data.
<SNIP>
--- 192.168.113.85 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3998ms
rtt min/avg/max/mdev = 0.052/0.130/0.380/0.127 ms
 
controls@pianosa|~ > time caget C1:LSC-XARM_GAIN
C1:LSC-XARM_GAIN               0.015
real    0m0.039s
 
controls@pianosa|~ > time caput C1:LSC-XARM_GAIN 0.0151
Old : C1:LSC-XARM_GAIN               0.015
New : C1:LSC-XARM_GAIN               0.0151
real    0m0.054s
 
 
 

 

  6931   Fri Jul 6 14:10:31 2012 yutaSummaryLSCcalculation of FPMI using ALS

From calculation, phase fluctuation of reflected beam from length stabilized arm is not disturbing MI lock.

Easy calculation:
  The phase PD at AS port sense is

phi = phi_x - phi_y = 2*l_MICH*omega/c + (phi_X - phi_Y)

  where l_MICH is the Michelson differential length change, omega is laser frequency, phi_X and phi_Y are phase of arm reflected beam. From very complicated calculation,

phi_X ~ F/2 * Phi_X

  at near resonance. Where F is arm finesse, Phi_X is the round trip phase change in X arm. So,

phi = 2*l_MICH*omega/c + F/2 * 2*L_DARM*omega/c

  Our ALS stabilizes arm length in ~ 70 pm(see elogs #6835#6858). Finesse for IR is ~450. Considering l_MICH is ~ 1 um, MICH signal at AS port should be larger than stabilized DARM signal by an order of magnitude.

Length sensing matrix of FPMI:
  Calculated length sensing matrix of 40m FPMI is below. Here, I'm just considering 11 MHz modulation. I assumed input power to be 1 W, modulation index 0.1i, Schnupp asymmetry 26.6 mm. PRM/SRM transmissivity is not taken into account.

[W/m]     DARM      CARM      MICH
REFL_I    0         1.69e8    0
REFL_Q    7.09e1    0        -3.61e3
AS_I      0         0         0
AS_Q      1.04e6    0         3.61e3


  Maybe we should use REFL_Q as MICH signal, but since IQ separation is not perfect, we see too much CARM. I tried to lock MI with REFL11_Q yesterday, but failed.

  4402   Thu Mar 10 17:03:48 2011 Larisa ThorneConfigurationElectronicscalculations for passive low pass filter on X arm

[Kiwamu, Larisa] 

 

We want to increase gain in the lower frequencies, so a circuit must be designed (a passive low pass filter). 

 

First, measurements were taken at the X arm for impedance and capacitance, which were 104.5kOhms and 84.7pF respectively. Kiwamu decided to make the circuit resemble a voltage divider for ease of calculation, such that Vout/Vin would be a ratio of some values of the equivalent circuit reactance values. After a few algebra mistakes, this Vout/Vin value was simplified in terms of the R, C measured and the R', C' that would be needed to complete the circuit. 

Since the measured C was very small and the measure R was fairly high, the simplified form allowed us to pick values of R' and C' that would make the critical frequency occur at 0.1Hz: set the R' resistance to 1MOhm and C' capacitance to 10uF, which would yield a gain ~1.

With these values a circuit we can start actually making the circuit.

  8248   Thu Mar 7 01:43:35 2013 yutaUpdateLSCcalibrated MI differential length spectra

Free swing MI differential length is 86 nm RMS and residual length when locked is 0.045 nm RMS(in-loop).
Looks very quiet. Comparison with PRMI is the next step.

Openloop transfer function:
  OLTF of simple MI lock using AS55_Q_ERR as error signal and ITMs as actuators is below.
  UGF ~ 90 Hz, phase margin ~ 40deg
  I added 16 Hz resonant gain to suppress bounce mode.
LSCMICHOLTF_MI.png

MI differential length spectra:
  Below. Calibration was done using calibrated AS55_Q_ERR and actuator response(elog #8242)
MImotion.png


  Expected free swing is calculated using

x_free = (1+G)/G * A * fb

where G is openloop transfer function, A is actuator response, fb is feedback signal(C1:LSC_ITMX/Y_IN1) spectrum. I used A as simple pendulum with resonant frequency at 1 Hz, Q = 5. Since free swing RMS is dominated by this resonance, RMS depends on this Q assumption.

  6841   Wed Jun 20 18:43:57 2012 yutaUpdateLSCcalibrated POX error signal

[Jenne, Yuta]

We did the same calibration for POX. It was 3.8e12 counts/m. See elog #6834 for the details of calibration we did.

According to Kiwamu's calibration, actuator response of ITMX is;

A_ITMX  = 4.913e-09 Hz^2*counts/m / freq^2

Plots below are results from our calibration measurement.

LSCxarmTF_usingITMX.pngLSCxarm_HAover1plusG.pngPOXerrorcalibration.png

  6834   Tue Jun 19 23:36:19 2012 yutaUpdateLSCcalibrated POY error signal

[Jenne, Yuta]

We calibrated POY error signal(C1:LSC-POY11_I_ERR). It was 1.4e12 counts/m.

Modeling of Y arm lock:
  Let's say H is transfer function from Y arm length displacement to POY error signal. This is what we want to measure.
  F is the servo filter (filter module C1:LSC-YARM).
  A is the actuator TF using ITMY. According to Kiwamu's calibration using MICH (see elog #5583),

  A_ITMY  = 4.832e-09 Hz^2*counts/m / freq^2

  We used ITMY to lock Y arm because ITMY is already calibrated.

What we did:
  1. Measured openloop transfer function of Y arm lock using POY error signal using ITMY (G=HFA). We noticed some discrepancy in phase with our model. If we include 1800 usec delay, phase fits well with the measurement. I think this is too big.
LSCyarmTF_usingITMY.png


  2. Measured a transfer function between actuator to POY error signal during lock. This should give us HA/(1+G).
LSCyarm_HAover1plusG.png

  4. Calculated H using measurements above. Assuming there's no frequency dependance in H, we got

  H = 1.4e12 counts/m

POYerrorcalibration.png

 For sanity check; Peak to peak of the POY error signal when crossing the IR resonance is about 800 counts. FWHM is about 1 nm, so our measurement is not so crazy.

  6835   Wed Jun 20 00:01:04 2012 JenneUpdateLSCcalibrated POY error signal

[Yuta, Jenne]

We have measured the out of loop residual motion of the Yarm while locked with the ALS.  We see ~70pm RMS, as compared to Kiwamu's best of ~24pm RMS.  So we're not yet meeting Kiwamu's best measurement, but we're certainly not in crazy-land.

The Yarm ALS was locked, I took a spectrum of POY11_I_ERR, and used the calibration that we determined earlier this evening.  For reference, I attach a screenshot of our ALS loop filters - we had on all the boosts, and both resonant gain filters (~3Hz and ~16Hz).

A large part of the RMS is coming from the 60Hz power line and the 180Hz harmonic....if we could get rid of these (how were they eliminated from the measurement that Kiwamu used in the paper?? - plotted elog 6780) we would be closer. 

Also, it looks like the hump (in our measurementf ~100Hz, in Kiwamu's ~200Hz) is not quite an order of magnitude higher in amplitude in our measurement vs. Kiwamu's.  We have ~5e-11 m/rtHz, Kiwamu had ~7e-12 m/rtHz.  This increase in noise could be coming from the fact that Yuta and Koji decreased the gain in the Ygreen PDH loop to prevent the PDH box from oscillating. 

While we should still think about why we can't use the same gain that Kiwamu was able to ~6 months ago, we think that we're good enough that we can move on to doing mode scans and residual motion measurements of the Xarm.

 

Attachment 1: LSC_POY_11_I_ERR_calib_19June2012.pdf
LSC_POY_11_I_ERR_calib_19June2012.pdf
Attachment 2: POY_calib_19June2012_FiltBankSettings.png
POY_calib_19June2012_FiltBankSettings.png
  8256   Fri Mar 8 03:07:19 2013 yutaUpdateLSCcalibrated PRM-ITMY length spectra

Measured free swing PRM-ITMY length was 230 nm RMS.
MI differential length was 85 nm RMS(elog #8248). This tells you that PR2, PR3 are not so noisy compared with usual suspensions.

Openloop transfer function:
  OLTF of PRM-ITMY cavity lock using REFL55_Q_ERR as error signal and PRM as actuator is below.
  UGF ~ 120 Hz, phase margin ~ 50 deg.
  Somehow, phase delay was 460 usec, which is smaller than the empirical value 550 usec.
LSCPRCLOLTF_PRITMY.png


PRM-ITMY length spectra:
  Below. Calibration was done using calibrated REFL55_Q_ERR and actuator response(elog #8255).
PRITMYmotion.png

  9606   Wed Feb 5 20:41:57 2014 DenUpdateLSCcalibrated spetra from OAF test

We did online adaptive filtering test with IMC and arms 1 year ago (log 7771). In the 40m presentations I can still see the plot with uncalibrated control spectra that was attached to that log. Now it the time to attach the calibrated one.

Template is in the /users/den/oaf

Attachment 1: oaf_cal.pdf
oaf_cal.pdf
  6938   Sun Jul 8 00:27:54 2012 yutaSummaryLockingcalibrating phase tracking mode scan data

FSR for X/Y arm are 3.97 +/- 0.03 MHz and 3.96 +/- 0.02 MHz respectively. This means X/Y arm lengths are 37.6 +/- 0.3 m and 37.9 +/- 0.2 m respectively.
I calibrated the mode scan results using 11MHz sideband as frequency reference.
Calibration factor between the phase of the phase tracker and IR frequency is 9.81 +/- 0.05 kHz/deg for X arm, 9.65 +/- 0.02 kHz/deg for Y arm.

Calculation:
  For the mode scan measurements, we swept the phase of the phase tracker linearly with time. Previous calculation was done without calibrating seconds into actual IR frequency. The first order calibration can be done using modulation frequency as reference. Note that I'm still assuming our sweep was linear here.

  Relation between FSR and modulation frequency can be written in

f_mod = n * nu_FSR + nu_f

  where f_mod is the modulation frequency, n is an integer, nu_f = mod(nu_FSR,f_mod).
  nu_FSR and nu_f are measurable values (in seconds) from the mode scan. We know that f_mod = 11065910 Hz (elog #6027). We also know that nu_FSR is designed to be ~3.7 MHz(=c/2L). So, n = 2.
  We can calculate f_mod in seconds, so we can calibrate seconds into IR frequency.


Calibrating X arm mode scan:
  From the 8FSR mode-scan data (see elog #6859), positions of TEM00 and upper/lower 11 MHz sidebands in seconds are;

TEM00    242.00     214.76     187.22     159.27     131.33     102.96     74.61     46.00     17.51
upper    236.70     209.05     181.36     153.42     125.06      96.86     68.43     40.20
lower    220.35     192.96     165.03     136.98     108.92      80.65     52.25     23.90


  So, FSR and nu_f in seconds are;

FSR    27.24     27.54     27.95     27.94     28.37     28.35     28.61     28.49
nu_f   21.80     21.82     22.14     22.19     22.26     22.28     22.40     22.40


  By using formula above, modulation frequency in seconds are;

f_mod    76.28    76.90    78.04    78.07    79.00    78.98    79.62    79.38

  By taking average, FSR and f_mod in seconds are

FSR    28.1 +/- 0.2
f_mod    78.3 +/- 0.4

  We know that f_mod = 11065910 Hz, so conversion constant from seconds to frequency is

k1 = 0.1413 +/- 0.0007 MHz/sec

  We swept the phase by 3600 deg in 250 sec, so conversion constant from degree to frequency is

k2 = 9.81 +/- 0.05 kHz/deg

  Also, using k1, FSR for X arm is

FSR = 3.97 +/- 0.03 MHz

  This means, X arm length is

L = c/(2*FSR) = 37.6 +/- 0.3 m


Calibrating Y arm mode scan:
  From the 8FSR mode-scan data (see elog #6832), positions of TEM00 and upper/lower 11 MHz sidebands in seconds are;

TEM00    246.70     218.15     190.06     161.87     133.26     104.75     76.01     47.19     18.60
upper    240.86     212.78     184.32     155.73     127.23      98.48     69.78     41.26
lower    224.53     195.73     167.31     139.13     110.81      82.27     53.60     24.50


  So, FSR and nu_f in seconds are;

FSR    28.55     28.09     28.19     28.61     28.51     28.74     28.82     28.59
nu_f   22.44     22.57     22.60     22.61     22.47     22.48     22.50     22.68


  By using formula above, modulation frequency in seconds are;

f_mod    79.54    78.75    78.98    79.825    79.485    79.955    80.14    79.855


  By taking average, FSR and f_mod in seconds are

FSR    28.5 +/- 0.1
f_mod    79.6 +/- 0.2

  We know that f_mod = 11065910 Hz, so conversion constant from seconds to frequency is

k1 = 0.1390 +/- 0.0003 MHz/sec

  We swept the phase by 3600 deg in 250 sec, so conversion constant from degree to frequency is

k2 = 9.65 +/- 0.02 kHz/deg

  (k2 of X arm and Y arm is different because delay-line lengths are different)
  Using k1, FSR for X arm is

FSR = 3.96 +/- 0.02 MHz

  This means, X arm length is

L = c/(2*FSR) = 37.9 +/- 0.2 m


Summary of mode scan results:
X arm
  Mode matching    MMR = 91.2 +/- 0.3 % (elog #6859) Note that we had ~2% of 01/10 mode.
  FSR         FSR = 3.97 +/- 0.03 MHz (this elog)
  finesse    F = 416 +/- 6 (elog #6859)
  g-factor    g1*g2 = 0.3737 +/- 0.002 (elog #6922)

  length        L = 37.6 +/- 0.3 m (this elog)
  ETM RoC  R2 = 60.0 +/- 0.5 m (this elog and #6922; assuming ITM is flat)

Y arm
  Mode matching    MMR = 86.7 +/- 0.3 % (elog #6828) Note that we had ~5% of 01/10 mode.
  FSR         FSR = 3.96 +/- 0.02 MHz (this elog)
  finesse    F = 421 +/- 6 (elog #6832)
  g-factor    g1*g2 = 0.3765 +/- 0.003 (elog #6922)

  length       L = 37.9 +/- 0.2 m (this elog)
  ETM RoC R2 = 60.7 +/- 0.3 m (this elog and #6922; assuming ITM is flat)

  I think these are all the important arm parameters we can derive just from mode scan measurement.

  Every errors shown above are statistical error in 1 sigma. We need linearity check to put systematic error. Also, we need more precise calibration after that, too, if the sweep has considerably large non-linearity. To do the linearity check, I think the most straight forward way is to install frequency divider to monitor actual beat frequency during the sweep.

  6939   Sun Jul 8 00:58:08 2012 KojiSummaryLockingcalibrating phase tracking mode scan data

Quote:

FSR for X/Y arm are 3.97 +/- 0.03 MHz and 3.96 +/- 0.02 MHz respectively. This means X/Y arm lengths are 37.6 +/- 0.3 m and 37.9 +/- 0.2 m respectively.

These aren't so bad. (Look at this entry)

And interestingly the ETM curvatures are closer to ATF measurements than Coastline's measurement. (Look at wiki)

  6815   Wed Jun 13 17:39:13 2012 yutaUpdateGreen Lockingcalibrating the beatbox

[Jenne, Yuta]

We put 0 dBm sine wave to the RF input of the beatbox and linear-sweeped frequency of the sine wave from 0 to 200 MHz using network analyzer (Aligent 4395A).
(We first tried to use 11 MHz EOM marconi)

Whlile the sweep, we recorded the output of the beatbox, C1:ALS-BEATY_(FINE|COARSE)_(I|Q)_IN1_DQ. We made them DQ channels today. Also, we put gain 10 after the beatbox before ADC for temporal whitening filter using SR560s.

We fitted the signals with sine wave using least squares fit(scipy.optimize.leastsq).
Transision time of the frequency from 200 MHz to 0 Hz can be seen from the discontinuity in the time series. We can convert time to frequency using this and supposing linear sweep of the network analyzer is perfect.

Plots below are time series data of each signal(top) and expansion of the fitted region with x axis calibrated in frequency (bottom).

ALS-BEATY_COARSE_I_IN1_DQ.pngALS-BEATY_COARSE_Q_IN1_DQ.png
ALS-BEATY_FINE_I_IN1_DQ.pngALS-BEATY_FINE_Q_IN1_DQ.png


We got

C1:ALS-BEATY_COARSE_I_IN1_DQ = -1400 sin(0.048 freq + 1.17pi) - 410
C1:ALS-BEATY_COARSE_Q_IN1_DQ = 1900 sin(0.045 freq + 0.80pi) - 95

C1:ALS-BEATY_FINE_I_IN1_DQ = 1400 sin(0.89 freq + 0.74pi) + 15
C1:ALS-BEATY_FINE_Q_IN1_DQ = 1400 sin(0.89 freq + 1.24pi) - 3.4

(freq in MHz)

The delay line length calculated from this fitted value (supposing speed of signal in cable is 0.7c) is;

  D_coarse = 0.7c * 0.048/(2*pi*1MHz) =  1.6 m
  D_fine = 0.7c * 0.89/(2*pi*1MHz) = 30 m

So, the measurement look quite reasonable.

FINE signals looks nice because we have similar response with 0.5pi phase difference.
For COARSE, maybe we need to do the measurement again because the frequency discontinuity may affected the shape of the signal.

  1185   Mon Dec 8 00:10:42 2008 carynSummaryGeneralcalibrating the jenne laser
I apologize in advance for the long list of numbers in the attachment. I can't seem to make them hide for some reason.

So, since Jenne's laser will probably be used for the Stoch mon calibration, Alberto and I took some measurements to calibrate Jenne's laser.
We focused the beam onto the New Focus RF 1GHz photodetector that we stole from rana's lab (powered with NewFocus power 0901). Measured the DC output of the photodetector with scope. Aligned the beam so DC went up (also tried modulating laser at 33MHz and aligning so 33MHz peak went up). Hooked up the 4395a Spectrum/Network Analyzer to the laser and to the AC out of the photodetector (after calibrating Network analyzer with the cables) so that the frequency response of the laser*photodetector could be measured.
(Note: for a while, we were using a splitter, but for the measurements here, I got rid of the splitter and just sent the RFout through the cables to channel A for the calibration, sent RFout to the laser and photodetector to channel A for the measurement)

Measured the frequency response. At first, we got this weird thing with a dip around 290MHz (see jcal_dip_2_norm.png below).
After much fiddling, it appeared that the dip was from the laser itself. And if you pull up just right on the corner of this little metal flap on the laser (see picture), then the dip in the frequency response seems to go away and the frequency response is pretty flat(see jcal_flat_3_norm below). If you press down on the flap, the dip returns. This at least happened a couple of times.
Note that despite dividing the magnitude by the DC, the frequency responses don't all line up. I'm not sure why. In some cases the DC was drifting a bit(I presume the laser was coming out of alignment or decided to align itself better) and maybe with avgfactor=16, and measuring mean DC on the scope, it made the DC meas not match up the the frequ resp meas...
I've attached the data for the measurements made (I'm so sorry for all the #'s. I can't figure out how to hide them)
name/lasercurrent/DC/analyzer SourcePower/analyzer avgfactor
jcal7_1/I=31.7mA/DC=-4.41/SourcePower=0dBm/avgfactor=16
jcal7_2/I=31.7mA/DC=-1.56/SourcePower=0dBm/avgfactor=none
jcal8_1/I=31.7mA/DC=-4.58/SourcePower=0dBm/avgfactor=16
jcal8_2/I=31.7mA/DC=-2.02/SourcePower=0dBm/avgfactor=16
jcal8_3/I=31.7mA/DC=-3.37/SourcePower=0dBm/avgfactor=16
Note also that the data from the 4395a seems to have column1-frequency, column2-real part, column3-imaginary part...I think. So, to calculate the magnitude, I just took (column2)^2+(column3)^2.


To get sort of an upper-bound on the DC, I measured how DCmax varied with laser current, where DCmax is the DC for the best alignment I could get. After setting the current, the laser was modulated at 33MHz and the beam was aligned such that the 33MHz peak in the photodetector output was as tall as I could manage. Then DC was measured. See IvsDCmax.png. Note the DC is negative. I don't know why.

Also, the TV's don't look normal, the alarm's going off and I don't think the mode cleaner's locked.
Attachment 1: IvsDCmax.png
IvsDCmax.png
Attachment 2: data.tar.gz
Attachment 3: jcal_dip_2_norm_log.png
jcal_dip_2_norm_log.png
Attachment 4: jcal_flat_3_norm_log.png
jcal_flat_3_norm_log.png
  1189   Tue Dec 9 10:48:17 2008 CarynSummaryGeneralcalibrating the jenne laser: impedance mismatch?

We sent RFout of network analyzer to a splitter, with one side going back to the network analyzer and the other to the laser modulation input. We observed a rippled transfer function through the splitter. The ripple is probably due to reflection due to an impedance mismatch in the laser.
Attachment 1: reflection.png
reflection.png
  8255   Fri Mar 8 02:17:04 2013 yutaUpdateLSCcalibration of PRM actuator

[Manasa, Yuta]

We measured AC response of PRM actuator using PRM-ITMY cavity.
Result is

PRM:  (19.6 +/- 0.3) x 10^{-9} (Hz/f)^2 m/counts

It is almost the same as in 2011 (elog #5583). We took the same procedure as what Kiwamu did.

What we did:
  1. Aligned PRMI in usual procedure, mis-aligned ITMX and locked PRM-ITMY cavity using REFL55_Q_ERR. POP DC was about 18 when locked.

  2. Made UGF of PRM-ITMY cavity lock at 10 Hz and introduced elliptic LPF at 50 Hz(OLTF below).
OLTF_PRCL.png


  3. Measured transfer function from C1:LSC_ITMY_EXC to C1:LSC_REFL55_Q_ERR. Dividing this by ITMY actuator response(measured in elog #8242) gives calibration of REFL55_Q.

  4. Measured transfer function from C1:LSC_PRM_EXC to C1:LSC_REFL55_Q_ERR to calibrate PRM actuator.

Result:
  Calibration factor for REFL55_Q for PRM-ITMY cavity was (1.37 +/- 0.02) x 10^9 counts/m (plot below). Error is mainly from statistical error of the average.
calibREFL55Q.png


  Measured AC response (50-200 Hz) of PRM is below.
actcalibPRM.png


Next:
  - Measure free-run length spectrum of PRM-ITMY cavity and compare with MICH free-run.

  5637   Sat Oct 8 00:44:42 2011 kiwamuUpdateLSCcalibration of SRM actuator

The AC response of the SRM actuator has been calibrated.

 actuators.png
(Summary of the calibration results)
     BS = 2.190e-08 / f2     [m/counts]
     ITMX  = 4.913e-09 / f2   [m/counts]
     ITMY  = 4.832e-09 / f2   [m/counts]
     PRM   = 2.022e-08 / f2  [m/counts]
     SRM   = 2.477e-08 / f2  [m/counts]    ( NEW ! ) 
 
(Measurement)
The same technique as I reported some times ago (#4721) were used.
The Signal-Recycled ITMY was locked for measuring the actuator response.
Since the ITMY actuator had been already calibrated, first the sensor was calibrated into [counts/m] by exciting the ITMY actuator and then calibrated the SRM actuator with swept sine measurement.
 
 - - notes to myself
   SRCL GAIN = 2.2
   Sensor = REFL11_I
   Demod. phase = 40 deg
   Resonant condition = Carrier resonant
   Gain in WF = 0 dB

Quote from #5583
The AC responses of the BS, ITMs and PRM actuators have been calibrated.

 

  7738   Wed Nov 21 21:06:13 2012 AyakaUpdateLSCcalibration of arms

Motivation

In order to estimate whether we can see acoustic coupling in arms or not, we have to calibrate signals to phase noise.

Method

I used the same method as Yuta and Jenne did (6834).
I switched from ETM locking to ITM locking since only ITM actuators are calibrated (5583), and measured the open loop transfer function and the transfer function from ITM excitation to POX/POY error signal. Then I can estimate the calibration value H [counts/m] from POY/POX error signal to displacement.

Results

Yarm; H = 9.51 x 1011 counts/m
  OL_y.pngerr_exc_y.pngPOY_disp_y.png

Xarm; H = 6.68 x 1011 counts/m
OL_x.pngerr_exc_x.pngPOX_disp_x.png

Phase noise in arms:
XY_phase.png
blue; Xarm, green; Yarm

 

Next Step

I will calibrate the acoustic signal and see if it is reasonable that we can see the acoustic coupling signal in the arms.
But I guess it is difficult. Actually I have not seen coherence between ETM feedback signals and acoustic sounds yet. (I measured acoustic noise near POX and in PSL table.)

If I find that it is hopeless, I will create some sounds and try to measure transfer function from acoustic sound to arm cavity signals.
I am interested in how the transfer function calculated by wiener filtering is different from the measured transfer function.

 

Note

I found that we do not have enough phase margin. This is why the arm locking is not so stable.

  7739   Sat Nov 24 13:58:07 2012 ranaUpdateLSCcalibration of arms

For the loop diagnosis, its best to use the method of "IN1/IN2", rather than manipulate the close loop gain. In this way, you can directly plot the swept sine measurement from DTT as the open loop gain.

Also, for reporting calibration, we should all try to record the current settings better. Anything that may change the loop gain should be recorded along with the Bode plot and the DATA must be posted to the elog - no more of just posting plots.

We need to know, e.g.

  1. what is the power in the arms?
  2. are the LSC whitening filters on?
  3. are the SUS dewhitening filters on?
  4. What normalization is being used in the LSC?
  5. What digital filters are on in the X/YARM loop filter bank?

Resistance is feudal.

  7743   Mon Nov 26 10:42:06 2012 AyakaUpdateLSCcalibration of arms

I uploaded a zip file that contains data files used for the calibration.

OLTF_x/y.txt: the open loop transfer function (measured by IN1/IN2 in arm servo filter bank).
coh_x/y.txt: coherence of OLTF. I used the data where coherence > 0.98.
ext_err_x/y.txt: the transfer function from ITM excitation signal to POX/POY error signal.
coh_x2/y2.txt: coherence of ext_err. I used the data where coherence > 0.98.

The LSC whitening filter was off because the xarm was unlocked when the POX Q whitening filter was turned on. (We have to study what was wrong.)
The SUS whitening filters were on.
The all digital filters except +6dB filter were on.

Attachment 1: armcalib.zip
  8009   Wed Feb 6 15:05:18 2013 SteveUpdateSAFETYcameras must be anchord

Cameras must be immediately anchord to avoid a possible collusion with the view port !

Attachment 1: IMG_0070_1.JPG
IMG_0070_1.JPG
Attachment 2: IMG_0069_1.JPG
IMG_0069_1.JPG
  7178   Tue Aug 14 14:26:40 2012 SteveUpdateCamerascameras touched up

 I optimized the TM views with illuminator light on quad1  It actually looks better there.

I'll post a dark-  OSEM light only in jpg tomorrow.  ETMY camera is malfunctioning in dark condition now.

 

Attachment 1: cameras.png
cameras.png
  2453   Sun Dec 27 20:05:28 2009 kiwamuUpdateComputerscan not communicate with front-ends

In this evening I found that fb40m has been down, then I restarted fm40m successfully.

However there still is a problem, the reflective memory can not communicate with some front-end CPUs ( such as c1iscey, c1susvme, ...etc.)

Right now I don't have any ideas about this, I am leaving them as they are now .... we can deal with them tomorrow. 


The followers are what I did.

(1) ssh to fb40m then "pkill tpman"

(2) telnet to fb40m then typed "shutdown". ( These procedure are on the 40m wiki)

(3) make sure fb40m gets recovered while watching the medm screen C0DAQ_DETAIL.adl

(4) run the backup script in fb40m

(5) in order to fix the communication problem, physically turn off c1dcuepics and c0daqctrl

(6) keying some front-end CPUs. ---> still some of front ends indicate RED on the medm screen C0DAQ_DETAIL.adl ( figure attached )

 

 

Attachment 1: C0DAQ_DETAIL.png
C0DAQ_DETAIL.png
  8714   Mon Jun 17 23:12:19 2013 ManasaUpdateGreen Lockingcan't get IR to resonate

What I did: 

1. Followed the same procedure to enable ALS (http://nodus.ligo.caltech.edu:8080/40m/8703)
2. Enabling ALS servo stabilized the arm fluctuation and the beat frequency.
3. Beat frequency sweep was done (with ALS servo enabled) by changing offset C1:ALS-BEATX_FINE_OFFSET_OFFSET in steps.

Discussion:

I swept the beat frequency through ~10MHz and could not find IR resonance. But TRY TRX varied from 0 - 0.9 counts as the beat frequency sweep was done. I suspected that the offset steps might have been too big and I had jumped over the IR resonance. So, I repeated the offset sweep again in smaller steps (offset steps 0.1) and it did not help. 
I also played with the gain of the ALS servo to stabilize the loop and set the gain to the maximum (smallest error signal oscillating around '0') and did the frequency sweep. The arm cavity would still not resonate through the sweep but only evolve from no flashes to strong flashes for IR (0 - 0.9 counts).
  1836   Wed Aug 5 15:33:05 2009 rob, albertoDAQGeneralcan't get trends

We can't read minute trends from either Dataviewer or loadLIGOData from before 11am this morning. 

 

fb:/frames>du -skh minute-trend-frames/
 106G   minute-trend-frames

So the frames are still on the disk.  We just can't get them with our usual tools (NDS).

 

 Trying to read 60 days of minute trends from C1:PSL-PMC_TRANSPD yields:

Connecting to NDS Server fb40m (TCP port 8088)
Connecting.... done
258.0 minutes of trend displayed
read(); errno=9
read(); errno=9
T0=09-06-06-22-34-02; Length=5184000 (s)
No data output.

 

Trying to read 3 seconds of full data works.

Second trends are readable after about 4am UTC this morning, which is about 9 pm last night.

 


  1841   Thu Aug 6 09:22:17 2009 AlbertoDAQGeneralcan't get trends

Quote:

We can't read minute trends from either Dataviewer or loadLIGOData from before 11am this morning. 

 

fb:/frames>du -skh minute-trend-frames/
 106G   minute-trend-frames

So the frames are still on the disk.  We just can't get them with our usual tools (NDS).

 

 Trying to read 60 days of minute trends from C1:PSL-PMC_TRANSPD yields:

Connecting to NDS Server fb40m (TCP port 8088)
Connecting.... done
258.0 minutes of trend displayed
read(); errno=9
read(); errno=9
T0=09-06-06-22-34-02; Length=5184000 (s)
No data output.

 

Trying to read 3 seconds of full data works.

Second trends are readable after about 4am UTC this morning, which is about 9 pm last night.

 


 Yesterday Alex started transferring the data records to the new storage unit. That prevented us from accessing the trends for a fe hours.

The process had been completed and now we can read the trends again.

  8143   Sat Feb 23 07:14:58 2013 yutaUpdateLSCcan't lock Y arm

I tried to align and lock Y arm for the first time after pumping.
But I couldn't lock Y arm for more than ~1 sec. Why?


What I did:
  1. Centered IPANG/IPPOS using input TT1/TT2.

  2. Restored ITMY/ETMY slider values when it was aligned before pumping. I saw tiny flashes in TRY PD at this point.

  3. Replaced Ygreen REFL camera with ETMYT camera to see transmitted beam mode.

  4. Used TT1/TT2 and ITMY/ETMY to get ~ 0.4 peak in normalized TRY PD output (C1:LSC_TRY_OUT).

  5. Centered POY beam on POY11 PD.

  6. Changed I/Q mixing angle (C1:LSC-POY11_PHASE_R) from -61 deg to -16 deg to get good PDH signal in I_ERR (attached).

  7. Ran LSCoffsets script (now on LSC_OVERVIEW screen) to adjust PD offsets.

  8. Tried to lock Yarm with different gains, but failed. When lock is acquired, TRY fluctuates ~50 % and unlocks suddenly.


What I found:
  1. There was some OFFSETs left turned on in suspension screens. Don't leave them on!! They change alignment of the optics. I will leave it on until we complete Yarm alignment.

  2. C1:SUS-(ITMY|ETMY)_ASC(PIT|YAW) was kept oscillating the optic since Dec 17, 2013. I think this is from interrupted ASS script. Your script should restore everything when interrupted!


Next:
  - Beamspot on ITMY looks off-centered. Maybe A2L is causing unstable lock?
  - Maybe F2A is causing unstable lock?
  - More alignment?
  - FSS related? crontab related?

Attachment 1: TRYPOY.png
TRYPOY.png
  8149   Sat Feb 23 16:54:24 2013 JenneUpdateLSCcan't lock Y arm

I'm not sure that Yuta had found the real Yarm flashes last night.  When I came in today, the Yarm would flash.  However I found that the SRM was aligned, and if I misaligned it, the Yarm flashes would disappear.  So somehow the beam getting into the cavity was related to the reflection off of the SRM.

Later, I moved the TTs, leaving ITMY and ETMY alone, after having misaligned SRM (and ITMX) and I found flashes.  This wasn't ideal though, since the beam was much, much too high on IPANG (beam was half falling off the top of the lens, although yaw was pretty good).  That was also when I changed out the ETMYT camera the first time around.  The flashes on the new camera were visible, but much dimmer than with the Watec.

I tried locking the Yarm in this state, but I could never achieve a lock, even momentarily.  It almost seemed like I wasn't sending actuation signal out to the coils, although signal appeared all the way through the chain until the LSC signal summed with the local damping signal.  I also switched the LSC output matrix to try actuating on the ITM, but I was also not able to lock then.  I have switched it back to have Yarm actuate on ETMY.  I could see a nice PDH signal on POY, and nice flashes on TRY, but no lock at all.  The trigger was triggering, but still no catching of the lock.  I'm not really sure what's up.

After playing with a non-locking, poorly aligned Yarm, I started over by recentering the beam on IPPOS and IPANG using the TTs, but have not been able to get flashing in the cavity again.  After much fitzing around, I put the Watec back at ETMYT, in hopes that we can see flashes again at some point, since it's more sensitive than the old Sony.  Still no flashes though.

I have to leave, but Yuta and Manasa are here, and so I'm leaving the IFO in their custody.

  8150   Sat Feb 23 17:14:59 2013 yutaUpdateLSCcan't lock Y arm

Jenne found that;
  0. If all mirrors are "aligned," Yarm flashes.
  1. If SRM is misaligned, Yarm doesn't flash.
  2. If BS is misaligned, Yarm doesn't flash.
  3. If ITMX is misaligned, Yarm still flashes.

So, my hypothesis from this is that I was playing with " TT1 -> TT2 -> ITMY -> BS -> SRM -> BS -> Yarm "  configuration last night.
This hypothesis can explain;
  1. Why I could not get TRY peak more than 0.5 (additional BS reflection makes incident power to Yarm less).
  2. Why I had to change POY11 I/Q mixing angle by ~ 45 deg (because EOM to Yarm length changed).
  3. Why I couldn't lock Yarm stably (additional reflection by BS and SRM made too much beam jitter?).

We are now trying to get "real" Yarm flash.

  6816   Thu Jun 14 01:36:34 2012 yutaUpdateGreen Lockingcan't scan Y arm for 1FSR

[Jenne, Koji, Yuta]

We tried to scan of the Y arm but we couldn't scan for more than 1FSR.
In principle, we can do that because the error signal we are using, C1:ALS-BEATY_COARSE_I_IN1, has the range of ~ 40 MHz, which is about 10FSR (see elog http://nodus.ligo.caltech.edu:8080/40m/6815).

ALS stays for more than 10 min when we don't do the scan. If we put some offset gradually from C1ALS-OFFSETTER2, the lock breaks.
We monitored PZT output of the Y end laser, C1:GCY-SLOW_SERVO1_IN1, but it stayed in the range when scanning. So, there must be something wrong in the ALS loop.

Current in-loop arm length fluctuation is about 0.1 nm RMS (0.5 counts RMS).
Below is the spectrum of the error signal when the ALS is off(green) and on (pink,red). Below ~ 50 Hz, the measurement of the Y arm length is limited by ADC noise (~ 2uV/rtHz).
BEATY_COARSE_LoopOnOff.png

  14336   Fri Dec 7 19:42:47 2018 ranaFrogselogcan't upgrade DokuWiki because of PHP / SL7

All of our wikis (except the 40m one which unfortunately got turned into ligo.org mess) use DokuWiki. This now has an auto-upgrade feature through the Admin web interface.

I tried this recently and it fails with this message:

DokuWiki 2018-04-22a "Greebo" is available for download.
 You're currently running DokuWiki Release 2017-02-19e "Frusterick Manners".
! New DokuWiki releases need at least PHP 5.6, but you're running 5.4.16. You should upgrade your PHP version before upgrading!

So we'll have to wait until SL7 (which is what NODUS is running).

I DID do a 'yum upgrade' which updated all the packages. I also installed yum-cron so that the RPM listings get updated daily. But sadly, SL7 only has PHP 5.4.16 (which is a June 2013 release):

> Package php-5.4.16-43.el7_4.1.x86_64 already installed and latest version

  4667   Mon May 9 16:12:49 2011 JamieConfigurationCDScanonicalize paths to core and userapps

I have updated the /opt/rtcds paths to reflect the new specification of the CDS aLIGO code release procedures document.


Path to RTS/opt/rtcds/caltech/c1/core/release

This is where the advLigoRTS front-end code generator is checked out.  The "release" directory is a link to the svn branch from which we are currently running ("trunk" by default).

This used to be at /opt/rtcds/caltech/c1/core/advLigoRTS


Path to userapps: /opt/rtcds/caltech/c1/userapps/release

This is where the cds_user_apps code is checked out.  cds_user_apps is where all of the front-end models, medm screen, scripts, etc. will live.  The "release" directory is a link to the svn branch from which we are currently running ("trunk" by default).

This was most recently at /opt/rtcds/cds_user_apps

 

  10938   Fri Jan 23 19:38:02 2015 JenneUpdateLSCcarm_cm_up supports both signs of CARM offset

A small change, but now the carm_up script supports both sides of the CARM offset.  After the arms are locked with ALS it asks for a "+" or a "-", which indicates which sign of digital CARM offset will be added.  In the past, we have been primarily using the "+" sign.
 

  12965   Wed May 3 16:12:36 2017 johannesConfigurationComputerscatastrophic multiple monitor failures

It seems we lost three monitors basically overnight.

The main (landscape, left) displays of Pianosa, Rossa and Allegra are all broken with the same failure mode:

their backlights failed. Gautam and I confirmed that there is still an image displayed on all three, just incredibly faint. While Allegra hasn't been used much, we can narrow down that Pianosa's and Rossa's monitors must have failed within 5 or 6 hours of each other, last night.

One could say ... they turned to the dark side cool

Quick edit; There was a functioning Dell 24" monitor next to the iMac that we used as a replacement for Pianosa's primary display. Once the new curved display is paired with Rossa we can use its old display for Donatella or Allegra.

  12966   Wed May 3 16:46:18 2017 KojiConfigurationComputerscatastrophic multiple monitor failures

- Is there any machine that can handle 4K? I have one 4K LCD for no use.
- I also can donate one 24" Dell

ELOG V3.1.3-