back on new Rossa from Xi computing

1. switched to using Display Port for video; this works. The DVi, HDMI, VGA ports are connected to the motherboard rather than the video card, so they are not active.
2. runs super slow w/ SL 7.6; maybe some service is running after startup?
3. install repos and update according to LLO CDS wiki
4. add controls user and group according to LLO wiki
5. remove gstreamer ugly because it breaks yum update
6. run 'yum update --skip-broken' because GDS doesn't work
7. turn off old selinux stuff
8. modify fstab to get NFS

Next:

1. finish mounting
2. xfce
3. figure out why the LLO install instructions can't install any CDS software (e.g. root, DTT, etc)

Update: Sun Nov 3 18:08:48 2019

1. moved the SL7 fresh install repos back into etc/yum.repos.d/. The LLO instructions has me remove them, but the LLO supplied repos are no good for standard apps. After putting these back was able to install standard apps (terminator, root, diaggui)
2. copied over /etc/fstab lines from pianosa sothat the NFS mounts work correctly
3. added symlinks so that the NFS dirs mount in the right dirs
4. symlink libsasl2.so.3 -> libsasl2.so.2 and now DTT runs and can get data now and in the past
5. install XFCE
6. sitemap / MEDM works
7.  Did "sudo ln -s /usr/lib64/libXm.so.4 /usr/lib64/libXm.so.3" to enable StripTool.

Update: Fri Nov 15 00:00:26 2019:

1. random hanging of machine while doing various window moving or workspace switching
2. turned off power management in XFCE
3. turned off power management on monitor
4. disabled SELINUX
5. firewalld was already off
6. installed most, pdftk, htop, glances, qtgrace, lesstif
7. dataviewer now works and QTgrace is much nicer than XMGrace

wiped and install Debian 10 on rossa today

still to be done: config it as CDS workstation

please don't try to "fix" it in the meantime

Following instructions from LLO-CDS fo the rossa upgrade. Last time there were some issues with not being to access the LLO EPEL repos, but this time it seems to be working fine.

After adding font aliases, need to run 'sudo xset fp rehash' to get the new aliases to take hold. Afterwards, am able to use MEDM and sitemap just fine.

But diaggui won't run because of a lib-sasl error. Try 'sudo yum install gds-all'.

diaggui: error while loading shared libraries: libsasl2.so.2: cannot open shared object file: No such file or directory (have contacted LLO CDS admins)

X-windows keeps crashing with SL7 and this big monitor. Followed instructions on the internet to remove the generic 'Nouveau' driver and install the proprietary NVDIA drivers by dropping to run level 3 and runnning some command line hoodoo to modify the X-files. Now I can even put the mouse on the left side of the screen and it doesn't crash.

I used the following commands to get diaggui to run on rossa/SL7:

controls@rossa|lib64> ls -lrt libsasl*
-rwxr-xr-x. 1 root root 121296 Feb 16  2016 libsasl2.so.3.0.0
lrwxrwxrwx. 1 root root     17 Dec 18  2017 libsasl2.so -> libsasl2.so.3.0.0
lrwxrwxrwx. 1 root root     17 Dec 18  2017 libsasl2.so.3 -> libsasl2.so.3.0.0
controls@rossa|lib64> sudo ln -s libsasl2.so.3.0.0 libsasl2.so.2
controls@rossa|lib64> ls -lrt libsasl*
-rwxr-xr-x. 1 root root 121296 Feb 16  2016 libsasl2.so.3.0.0
lrwxrwxrwx. 1 root root     17 Dec 18  2017 libsasl2.so -> libsasl2.so.3.0.0
lrwxrwxrwx. 1 root root     17 Dec 18  2017 libsasl2.so.3 -> libsasl2.so.3.0.0
lrwxrwxrwx. 1 root root     17 Jun 26 22:02 libsasl2.so.2 -> libsasl2.so.3.0.0
 

Basically, I have set up a symbolic link to point sasl2.so.2 to sasl2.so.3.0.0. I've asked LLO again for some guidance on whether or not to find some backport in a non-standard SL7 repo. IF they reply, we may later replace this link with a regular file.

For the nonce, diaggui runs and is able to show us the spectra. We also got swept sine to work. But the FOTON launched from inside of AWGGUI doesn't inherit the sample frequency of the excitation channel so we can't filter noise injections from awggui yet.

UNELOGGED: someone has changed Pianosa from Ubuntu/Dumbian into SL7. Might be hackers.

Donatella is now the only Ubuntu machine in the control room. I propose we keep it this way for another month and then go fully SL7 if we find no bugs with Pianosa/Rossa.

I noticed these streaky lines again today (but they were not a problem last night). It is annoying if we have to reboot this machine all the time. I wonder if this has something to do with missing drivers. When I ran sudo apt update && sudo apt upgrade, I got several lines like (this isn't the whole stack trace)

Is this indicative of the graphics drivers being installed incorrectly? I am hesitant to mess with this because I think in the past, it was always trying to update some graphics driver that crashed the whole machine into some weird state where we have to wipe the drive and do a fresh re-install of the OS.

Should we just follow these instructions? The graphics card is apparently Quadro P400, which is one of the supported ones according to the list of supported devices.

Or just swap donatella and rossa monitors and defer the problem for later?

This is strange - I was definitely able to launch medm when I was working on this machine remotely on Friday. But now, there does seem to be a problem with this shared library being missing.

First of all, I installed mlocate to find where the shared library files are installed. Then I made the symlink, and now sitemap seems to work again.

Weirdly, my changes to /etc/resolv.conf got overwritten somehow. Was this machine rebooted? Uptime suggests it's only been running for ~6 hours at the time of writing of this elog.

yes, I rebooted yesterday to fix the 'steaking white lines' problem in the video/display

maybe we're supposed to edit something besides resolv.conf since that gets over-written on boot for some linux OS

After some consultation with Erik von Reis at LHO, this workstation is progressing towards being usable for most commissioning tasks. DTT, awggui, foton, and MEDM are all now working well. The main limitation now comes from the fact that many of our python scripts are written for python2, and rossa doesn't have many dependencies installed for python2. I see no reason to build these dependencies on rossa for python2, we should not have to work with an unsupported language. But at the same time, I don't want to completely wipe all our python2 scripts, and make them python3, because this would involve a lot of tedious testing that I'm not prepared to undertake at the moment (the problem is compounded by the fact that pianosa does not have many dependencies installed for python3).

So what I have done in the interim is make python3 versions of the most important scripts I need to get the PRFPMI locking working - they are in the scripts directory and have the same names as their python2 counterparts, but have a 3 appended to their names. So when working on rossa, these are the scripts that are called. Eventually, after a lot more testing, we can depracate the old scripts. Currently, where applicable, the MEDM screens allow for either the python2 or python3 version of the script to be called.

Please, for the time being, do not try and install any new packages on rossa unless you are prepared to debug any problems caused and return the machine to a workable state. If you find some issue with a missing package on rossa, (i) make a note of it on the elog, and (ii) if possible, set up your own conda environment for testing and install dependencies to that environment only.

I too, would prefer py3 for everything, but aren't all the cdsutils / gaurdian things still python2?

Is it possible to just make a python2 conda environment on rossa? I would guess that its simple and won't interfere with the regular operation of that machine.

In fact, all these utilities are now available in python3. There may be some bugs (e.g. this), but I've checked basic functionality and things look usable enough for development to proceed. While we can have a python2 env on rossa, I think it's unnecessary.

I wanted to try using rossa as my locking workstation today. However, a few problems became quickly evident. Basically, any of our scripts that rely on the cdsutils package (there are MANY) will not work on rossa, because of some library error. This machine is running Debian 10, while the cdsutils package is being loaded from a pre-compiled install on the shared drive, so perhaps this isn't surprising?

Digging a little more, I found that actually, a version of cdsutils that actually works with python3 is actually shipped with the standard cds-workstation meta-package. This is great news, and we should try and use this where possible I guess. Deferring further debugging for daytime work.

Anyway, I added a symlink: sudo ln -s /usr/lib/x86_64-linux-gnu/libncurses.so.6 /usr/lib/x86_64-linux-gnu/libncurses.so.5, and installed wmctrl using sudo apt install wmctrl. 

I did

sudo usermod -a -G lpadmin controls

and then was able to add Grazia to the list of printers for Rossa by following the instructions on the 40m Wiki.

I installed color syntax highlighting on Rossa using the internet (https://superuser.com/questions/71588/how-to-syntax-highlight-via-less). Now if you do 'less genius_code.py', it will be highlighting the python syntax.

when I try 'sitemap' on rossa I get:

medm: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory
 

Indeed, this is now fixed by following instructions from here. I rebooted rossa at ~1250 PDT and confirmed that resolv.conf didn't get overwritten. The resolv.conf file also now has the following useful lines at the head:

With the network config, mounting, and symlinks setup, rossa is able to be used as a workstation for dataviewer and MEDM. For DTT, no luck since there is so far no lscsoft support past the Ubuntu14 stage.

I have slightly rotated the lambda/2 plate, which is used for attenuating the REFL beam's power on the AS table

because the plate had been at an unusual angle for investigation of the glitches since last Thursday.

It means the laser power going to the coating thermal noise setup has also changed. Just keep it in mind.

Here's a sort of rough analysis of the aligned PRM-PR2 cavity mode scan.

On Friday we took some mode scan measurements of the PRM-PR2 cavity by pushing PRM (C1:SUS-PRM_LSC_EXT) with a 0.01 Hz, 300 count sine wave.  We looked at the transmitted power on the POP DC PD and the error signal on REFL11_I.

Below is a detail of the scan, chosen because the actuation was in its linear region and there were three relatively ok looking transmission peaks with nice PDH response curves:

The vertical green lines on the bottom plot indicate the rough averaged separation of the 11 MHz side-band resonances from the carrier, at +- 0.0275 s.  If we take this for our calibration, we get roughly 400 MHz / second.

The three peaks in top plot have an average FWHM of 0.00381 s.  Given the calibration above, the average FWHM = ~1.52 MHz.

If we assume a cavity length of 1.91 m, FSR = 78.5 MHz.

Putting this together we get a finesse = ~51.6.

Analysis of misaligned mode scans to follow.

The expected finesse is 100ish. How much can we beleive the measured number of 50?
From the number we need to assume PR2 has ~93% reflectivity.
This does not agree with my feeling that the cavity is overcoupled.
Another way is to reduce the reflectivity of the PRM but that is also unlikely from the data sheet.

The scan passed the peak in 4ms according to the fitting.
How do the analog and digital antialiasing filters affect this number?

[Jenne, Yuta]

We redid PRM-PR2 cavity scan because last one (elog #7990) was taken with the sampling frequency of 2 KHz. We have also done TMS measurement.

Method:
 1. Align input TTs and PRM to align PRM-PR2 cavity.
 2. Sweep cavity length using C1:SUS-PRM_LSC_EXC.
 3. Get data using Jamie's getdata and fitted peaks using /users/jrollins/modescan/prc-pr2_aligned/run.py
 4. Calculated cavity parameters

Results:
 Below is the figure containing peaks used to do the calculation.



 From 11 MHz sidebands, calibration factor is 462 +/- 22 MHz/sec (supposing linear scan around peaks)
 FWHM is 1.45 +/- 0.03 MHz.
 TMS is 2.64 +/- 0.05 MHz.
 Error bars are statistical errors of the average over 3 TEM00 peaks.

 If we believe cavity length L to be 1.91 m, FSR is 78.5 MHz.
 So, Finesse will be 54 +/- 1 and cavity g-factor will be 0.9944 +/- 0.0002. 0.9889 +/- 0.0004   (Edited by YM; see elog #8056)
 If we believe RoC of PRM is exactly +122.1 m, measured g-factor insists RoC of PR2 to be -187 +/- 4.
 If we believe RoC of PR2 is exactly -600 m, measured g-factor insists RoC of PRM to be 218 +/- 6.

Discussion:
 1. Finesse is too small (expected to be ~100). This time, data was taken 16 KHz. Cut-off frequency of the digital antialiasing filter is ~ 5 kHz (see /opt/rtcds/rtscore/release/src/fe/controller.c). FWHM is about 0.003 sec, so it should not effect much according to my simulation.

 2. I don't know why FWHM measurement from the last one is similar to this one. The last one was taken 2 KHz, this means anti-aliasing filter of 600 Hz. This should double FWHM.

 3. Oscilloscope measurement may clear anti-aliasing suspicion.

I redid PRM-PR2 cavity scan using oscilloscope to avoid anti-aliasing effect.
Measured Finesse was 104 +/- 1.

Method:
 1. Splitted POP DC output into three and plugged two into oscilloscope TDS 3034B. Ch1 and Ch2 was set to 1 V/div and 20 mV/div respectively to take the whole signal and higer resolution one at the same time (Koji's suggestion). Sampling frequency was 50 kHz. Sweeping time through FWHM was about 0.001 sec, which is slow enough.
 2. Took mode scan data from the oscilloscope via network.

Preliminary results:
 Below is the plot of the data for one TEM00 peak.


 The data was taken twice.
 Measured FWHM was 0.764 MHz and 0.751 MHz. By taking the average, FWHM = 0.757 +/- 0.005 MHz.
 This gives you Finesse = 104 +/- 1, which is OK compared with the expectation.

What I need:
 I need better oscilloscope so that we can take longer data (~1 sec) with higher resolution (~0.004 V/count, ~50kHz).
 TDS 3034B can take data only for 10 ksamples, one channel by one!  I prefer Yokogawa DL750 or later.

0.764 and 0.751 do not give us the stdev of 0.005.

I have never seen any Yokogawa in vicinity.

stdev of [0.764, 0.751] is 0.007, but what we need is the error of the averaged number. Statistical error of the averaged number is stdev/sqrt(n).

Makes sense. I mixed up n and n-1

Probability function: X = (x1 + x2 + ... + xn)/n, where xi = xavg +/- dx

Xavg = xavg*n/n = xavg

dXavg^2 = n*dx^2/n^2
=> dXavg = dx/sqrt(n)

Xavg +/- dXavg = xavg +/- dx/sqrt(n)

Koji was correct.

When you estimate the variance of the population, you have to use unbiased variance (not sample variance). So, the estimate to dx in the equations Koji wrote is

dx = sqrt(sum(xi-xavg)/(n-1))
   = stdev*sqrt(n/(n-1))

It is interesting because when n=2, statistical error of the averaged value will be the same as the standard deviation.

dXavg = dx/sqrt(n) = stdev/sqrt(n-1)

In most cases, I think you don't need 10 % precision for statistical error estimation (you should better do correlation analysis if you want to go further). You can simply use dx = stdev if n is sufficiently large (n > 6 from plot below).

On the day before yesterday and in this morning, I measured loss map of ETMX. I reported the method I used to change the beam spot on ETMX below.

Round trip loss was measured for 5 x 5 points. The result is below.

(unit: ppm)

455.4 +/- 21.1       437.1 +/- 21.8       482.3 +/- 21.8       461.6 +/- 22.5       507.9 +/- 20.1      
448.4 +/- 20.7       457.3 +/- 21.2       495.6 +/- 20.2       483.1 +/- 20.8       472.2 +/- 19.8      
436.9 +/- 19.3       444.6 +/- 19.7       483.0 +/- 19.5       474.9 +/- 20.9       498.3 +/- 18.7      
454.4 +/- 18.7       474.4 +/- 20.6       487.7 +/- 21.4       482.6 +/- 20.7       487.0 +/- 19.9      
443.7 +/- 18.6       469.9 +/- 20.2       482.8 +/- 18.7       480.9 +/- 19.5       486.1 +/- 19.2 

The correspondence between the loss shown above and the beam spot on ETMX is shown in the attached figure. In the figure, "up" and "right" indicate direction of shift of the beam spot when you watch it via the camera (ex. 455.4 ppm corresponds to the highest and rightest point in the view via the camera). 

This result is consistent withe previous result of 561.19 +/- 14.57 ppm ericq got with ASDC and reported in elog 10248 if the discussion I reported in 11819 is taken into account. Elog 11819 says in short that the strange behavior of ASDC could give us 60-70 ppm error.

The reason why the error is larger than that of the measurement for ETMY is that the noise of POX is larger than that of POY. But I am not sure to what extent the statistical error needs to be reduced.

How I shifted the beam spot on ETMX:   

Basically, the method was same as one used for Y arm. Different point is: for Y arm we have two steering mirrors TT1&2, but for X arm we have only one steering mirror BS. Then in order to shift incident beam so that the beam spot on ITMX does not change, I ran the dithering of X arm as well as that of Y arm and added offsets to both dither loops that caused same amount of shift on ETMX and ETMX. Thanks to the symmetry between X arm and Y arm, the dithering of Y arm ensured that the beam spot on ITMX was unchanged as well as that of ITMY. The idea of this method is schematically shown in Attachment 2. 

The calibration of how much the beam spot shifted is based on the results of elog 11846 . The offset was [-15,-7.5,0,7.5,15]x[-5,-2.5,0,2.5,5] for pitch and yaw, respectively.  

I measured round trip loss of Y arm. The alignment of relevant mirrors was set ideal with dithering (no offset).

Summary:

 round trip loss of Y arm: 166.2 +/- 9.3 ppm

(In the error, only statistic error is included.)

How I measured it: 

I compared the power of light reflected by Y arm (measured at AS) when the arm was locked (P_L) and when ETMY was misaligned (P_M). P_L and P_M can be described as 

.

The reason why P_L takes this form is: (1-alpha)*4T_ITM/(T_tot)^2 is intracavity power and then product of intracavity power and loss describes the power of light that is not reflected back. Here, alpha is power ratio of light that does not resonate in the arm (power of mismatched mode and modulated sideband), and T_tot is T_ITM+T_loss. Transmissivity of ETM is included in T_loss. I assumed alpha = 7%(mode mismatch) + 2 % (modulation) (elog 11745)

After some calculation we get

.

Here, higher order terms of T_ITM and (T_loss/T_ITM) are ignored. Then we get

.

Using this formula, I calculated T_loss. P_L and P_M were measured 100 times (each measurement consisted of 1.5 sec ave.) each and I took average of them. T_ETM =13.7 ppm is used.

Discussion: 

-- This value is not so different from the value ericq reported in July (elog 10248).

-- This method of measuring arm loss is NOT sensitive to T_ITM.  In contrast, the method in which loss is obtained from finesse (for example, elog 11740) is sensitive to T_ITM.

In the method I'm now reporting, 

,

but in the method with finesse,

.

In the latter case, if relative error of T_ITM is 10%, error of T_loss would be 1000 ppm.

So it would be better to use power of reflected light when you want to measure arm loss.  

[yutaro, Koji]

Due to the strange behavior (elog 11815) of ASDC level, we checked if it is possible to use POYDC instead of ASDC to measure the power of reflected light of YARM. Attached below is the spectrum of them when the arm is locked. This spectrum shows that it is not bad to use POYDC, in terms of noise. The spectrum of them when ETMY is misaligned looked similar.

So I am going to use POYDC instead of ASDC to measure arm loss of YARM. 

Ed by KA:
The spectra of POYDC and ASDC were measured. We foudn that they have coherence at around 1Hz (good).
It told us that POYDC is about 1/50 smaller than ASDC. Therefore in the attached plot, POYDC x50 is shown.
That's the meaning of the vertical axis unit "ASDC".

Tonight I measured "loss map" of ETMY. The method to calculate round trip loss is same as written in elog 11810, except that I used POYDC instead of ASDC this time.

How I changed beam spot on ETMY is: elog 11779.

I measured round trip loss for 5 x 5 points. The result is below.

(unit: ppm)

494.9 +/- 7.6       356.8 +/- 6.0       253.9 +/- 7.9       250.3 +/- 8.2       290.6 +/- 5.1      
215.7 +/- 4.8       225.6 +/- 5.7       235.1 +/- 7.0       284.4 +/- 5.4       294.7 +/- 4.5      
205.2 +/- 6.0       227.9 +/- 5.8       229.4 +/- 7.2       280.5 +/- 6.3       320.9 +/- 4.3      
227.9 +/- 5.7       230.5 +/- 5.5       262.1 +/- 5.9       315.3 +/- 4.7       346.8 +/- 4.2      
239.7 +/- 4.5       260.7 +/- 5.3       281.2 +/- 5.8       333.7 +/- 5.0       373.8 +/- 4.9 

The correspondence between the loss shown above and the beam spot on ETMY is shown in the following figure. In the figure, "downward" and "left" indicate direction of shift of the beam spot when you watch it via the camera (ex. 494.9 ppm corresponds to the lowest and rightest point). 

Edited below on 28th Nov. 

To shift the beam spot on ETMY, I added offset in YARM dither loop. The offset was [-30,-15,0,15,30]x[-10,-5,0,5,10] for pitch and yaw, respectively.  How I calibrated the beam spot is basically based on elog 11779, but I multiplied 5.3922 for vertical direction and 4.6205 for horizontal direction which I had obtained by caliblation of oplev (elog 11785).

Edited above on 28 th Nov.    

I will report the detail later. 

Here, I upload data I took last night, including the power of reflected power (locked/misaligned) and transmitted power for each point (attachement 1).

And I would like to write about possible reason why the loss I measured with POYDC and the loss I measured with ASDC are different by about 60 - 70 ppm (elog 11810 and 11818). The conclusion I have reached is: 

It could be due to the strange bahavior of ASDC level. 

This difference corresponds to the error of ~2% in the value of P_L/P_M. As reported in elog 11815, ASDC level changes when angle of the light reflected by ITMY changes, and 2% change of ASDC level corresponds to 10 urad change of the angle of the light according to my rough estimation with the figure shown in elog 11815 and attachment 2. This means that 2% error in P_L/P_M could occur if the angle of the light incident to YARM and that of resonant light in YARM differ by 10 urad. Since the waist width  of the beam is ~3 mm, with the 10 urad difference, the ratio of the power of TEM10 mode is , where . This value is reasonable; in elog 11743 Gautam reported that the ratio of the power of TEM10 was ~ 0.03, from the result of cavity scan. Therefore it is possible that the angle of the light incident to YARM and that of resonant light in YARM differ by 10 urad and this difference causes the error of ~2% in P_L/P_M, which could exlain the 60 - 70 ppm difference. 

The rsync job to sync our frames over to the cluster has been on a 20 MB/s BW limit for awhile now.

Dan Kozak has now set up a cronjob to do this at 10 min after the hour, every hour. Let's see how this goes.

You can find the script and its logfile name by doing 'crontab -l' on nodus.

Still seems to be running without causing FB issues. One thought is that we could look through the FB status channel trends and see if there is some excess of FB problems at 10 min after the hour to see if its causing problems.

I also looked into our minute trend situation. Looks like the files are comrpessed and have checksum enabled. The size changes sometimes, but its roughly 35 MB per hour. So 840 MB per day.

According to the wiper.pl script, its trying to keep the minute-trend directory to below some fixed fraction of the total /frames disk. The comment in the scripts says 0.005%,

but I'm dubious since that's only 13TB*5e-5 = 600 MB, and that would only keep us for a day. Maybe the comment should read 0.5% instead...

I'm not so sure. I just was experiencing some severe network latency / EPICS channel freezes that was alleviated by killing the rsync job on nodus. It started a few minutes after ten past the hour, when the rysnc job started. 

Unrelated to this, for some odd reason, there is some weirdness going on with ssh'ing to martian machines from the control room computers. I.e. on pianosa, ssh nodus fails with a failure to resolve hostaname message, but ssh nodus.martian succeeds. 

So today, after an "rm" error while working with the autoburt.pl script and burt restores in general, I asked Dan Kozak how to actually look at the backup data.  He said there's no way to actually look at it at the moment.  You can reverse the rsync command or ask him to grab the data/file if you know what you want.  However, in the course of this, we realized there was no /cvs/cds data backup.

Turns out, the rsync command line in the script had a "-n" option.  This means do a dry run.  Everything *but* the actual final copying.

I have removed the -n from the script and started it on nodus, so we're backing up as of 5:22pm today.

I'm thinking we should have a better way of viewing the backup data, so I may ask Dan and Stewart about a better setup where we can login and actually look at the backed up files.

In addition, tomorrow I'm planning to add cron jobs which will put changes to files in the /chans and /scripts directories into the SVN on a daily basis, since the backup procedure doesn't really provide a history for those, just a 1 day back backup.

 Added TRX and TRY and POY11_I_ERR and POX11_I_ERR to the c1lsc.mdl using a new-style DAQ Channels block, recompiled, installed, started the model, all good.  Restarted the daqd on the framebuilder, and everything is green.  I can go back and get recorded data using dataviewer (for the last few minutes since I started fb), so it all looks good.

Note on the new DAQ Channels block:  Put the text block (from CDS_PARTS) at the same level as the channel you want to save, and name it exactly as it is in the model.  The code-generator will add the _DQ for you.  i.e. if you define a channel "TRY_OUT_DQ" in the lsc model, you'll end up with a channel "C1:LSC-TRY_OUT_DQ_DQ".

We can't compile any changes to the LSC or the GCV models since Jamie's new script / program isn't found.  I don't know where it is (I can't find it either), so I can't do the compiling by hand, or point explicitly to the script.  The old way of compiling models in the wiki is obsolete, and didn't work :(

This means we can't (a) record TRY or (b) add the Q quadrature of the beat PD to the real time system tonight.

We're going to try just using Yuta's pynds script to capture data in real time, so we can keep working for tonight.

Sorry about that.  I had modified the path environment that pointed to the rtcds util.  The rtcds util is now in /opt/rtcds/caltech/c1/scripts/rtcds, which is in the path.  Starting a new shell should make it available again.

Finally I found a company who can do Koji's improved  -hard to make-  specification on ruby or sapphire wire standoff.

NOT POLISHED excimer laser cut, wire groove radius R 0.0005" + - 0.0002"

$250 ea at 50 pieces of order

Atm 1 & 5, showing the ruby R ~10 mm as it is seated on Al SOS test mass

Atm. 2, 3 & 4  chipped long edges with SOS sus wire OD 43 micron as  calibration

Bluebean Optical Tech Limited of Shanghai delivered 50 pieces red ruby prisms with radius.  The first prism pictures were taken at June 5

and it was retaken again as BB#1 later

More samples were selected randomly as one from each bag of 5 and labeled as BB#2.......6    

 The R10 mm radius can be seen agains the  ruler edge.  The v-groove edge was labeled with blue marker and pictures were taken

from both side of this ridge. The top view is shown as the wire laying across on it.

SOS sus wire of 43 micron OD used as calibration as it was placed close to the side that it was focused on.

The V-groove ridge surface quality was evaluated based on as scale of 1 – 10 with 10 being the most positive.

Remaining thing to examin, take picture of the contacting ridge to SOS from the side.

3-4 hrs ago we run out of nitrogen. We are back to Vacuum Normal

I have attached the result of running the PID script on the seismometer with the can on. The daily fluctuations are no more than 0.07 degrees off from the setpoint of 39 degrees. Not really sure what happened in the past day to cause the strange behavior. It seems to have returned back to normal today.

I'm running a comsol job on optimus in a tmux session named cryocavs. Should be done in less than 24 hours, judging by past durations.

I'm running a test with daqd right now, so please do not disturb for the moment.

I'm temporarily writing frames into a tempfs, which is a filesystem that exists purely in memory.  There should be ZERO IO contention for this filesystem, so if the daqd failures are due to IO then all problems should disappear.  If they don't, then we're dealing with some other problem.

There will be no data saved during this period.

I have reverted daqd to the previous configuration, so that it's writing frames to disk.  It's still showing instability.

 In order to figure out what downsampling ratio we can take, we need to determine the running time of the fxlms_filter() function. If the filter length is equal to 5000, downsampling ratio is equal to 1, number of witness channels is 1 then with ordinary compilation without speed optimization one call runs for 0.054 ms (milli seconds). The test was done on the 3 GHz Intel processor. With speed optimization flags the situation is better

-O1 0.014 ms, -O3 0.012 ms

However, Alex said that speed optimization is not supported at RCG because it produce unstable execution time for some reason. However, by default the kernel should optimize for size -Os. With this flag the running time is also 0.012 ms. We should check if the front-end machine compilers indeed use -Os flag during the compilation and also play with speed optimization flags. Flags -O3 and -Os together might also give some speed improvement.

But for now we have time value = 0.012 ms as running time for 5000 coefficient filter, 1 witness channel and downsample ratio = 1. Now, we need to check how this time is scaled if we change the parameters.

5000 cofficients - 0.012 ms

10000 coefficients - 0.024 ms

15000 coefficients - 0.036 ms

20000 coefficients - 0.048 ms

We can see that filter length scaling is linear. Now we check downsampling ratio

ratio=1 - 0.048 ms

ratio=2 - 0.024 ms

ratio=4 - 0.012 ms

Running time on the dependance of downsample ratio is also linear as well as on the dependence of the number of witness channels and degrees of freedom. 

If we want to filter 8 DOF with approximately 10 witness channels for each DOF, then 5000 length filter will make 1 cycle for ~1 ms, that is good enough to make the downsample ratio equal to 4.

Things get a little bit complicated when the code is called for the first time. Some time is taken to initialize variables and check input data. As a result the running time of the first cycle is ~0.1 ms for 1 DOF that is ~10 times more then running time of an ordinary cycle. This effect takes place at this moment when one presses reset button in the c1oaf model - the filter becomes suspended for a while. To solve this problem the initialization should be divided by several (~10) parts.

This is long overdue, but our burt files for SDF now live in the LIGO userapps SVN, as they should.

The canonical files live in places like /opt/rtcds/userapps/release/cds/c1/burtfiles/c1x01_safe.snap and are symlinked to files like /opt/rtcds/caltech/c1/target/c1x01/c1x01epics/burt/safe.snap

The 40m safety audit will be at Wednesday afternoon, March 3

Please participate getting our lab to inspection grade safety level.