Pump  spool valves V5, V4, V3 sweating a lot. VM3 and VC2 not so much.

They are VAT valves F28-62887-03, 11, 14 and so on ~15-16 years old.

 I'm speculating that some plastic is aging-braking down at the atmospheric-pneumatic side of valves.
The vacuum side is not effected, according to vacuum pressure readings.

May be some condensation from the small turbos? No

I'm looking for an identical valve to examine, but I can not find one.

We are using industrial grade 99.96% Nitrogen to actuate these valves.

Valves are not effected are  dry: VA6, V6, V7 and all annuloses.

 I uninstalled gstreamer-devel and gst-plugins-base-devel on Rosalba.  Here is the command I ran:

$ sudo yum remove gstreamer-devel gstreamer-plugins-base-devel

Actually, I had installed these myself a few days earlier, before I knew that I should be recording such changes in the elog.  I'm sorry!

The way the filter's transfer function has been measured is by a swept sine between the "SERVO INPUT" and the "PIEZO DRIVE OUTPUT" connection on the box front panel. The spectrum analyzer used for the measurement is the SR785 and the source amplitude is set at 0.1V.

The two transfer functions are clearly different. In particular the old one looks like a simple integrator, whereas the new one already includes some sort of boost.

That probably explains why the new one is unable to lock the PLL. Indeed what the PLL needs, at least to acquire lock, is an 1/f filter.

I thought the two boxes were almost identical, at least in the filter shapes. Also the two schematics available in the DCC coincide.

 To me, they both look stable. I guess that the phase has to go to -180 deg to be unstable.

Why does the magnitude go flat at high frequencies? That doesn't seem like 1/f.

How about a diagram of what inputs and outputs are being measured and what the gain knob and boost switch settings are?

FYI: I stored the Universal PDH boxes in the RF cabiner in the Y arm.

 [Koji, Annalisa, Gautam]

Annalisa noticed that over the weekend the Y-arm green PDH was locked to a sideband, despite not having changed anything on the PDH box (the sign switch was left as it was). On friday, we tried turning on and off some of the filters on the slow servo (C1ALS_Y_SLOW) which may have changed something but this warranted further investigation. We initially thought that the demodulation phase was not at the optimal value, and decided to try introducing some capacitances in the path from the function generator to the LO input on the universal PDH box. We modelled the circuit and determined that significant phase change was introduced by capacitances between 1nF and 100nF, so we picked out some capacitors (WIMA FKP) and set up a breadboard on which to try these out.

After some trial and error, Koji dropped by and felt that the loop was optimized for the old laser, the various loop parameters had not been tweaked since the new laser was installed. The following parameters had to be optimized for the new laser;

• Servo gain
• LO frequency
• LO modulation depth
• Demodulation phase

The setup was as follows: 

• PDH box error signal to Oscilloscope CH1
• Green PD output to Oscilloscope CH2
• No capacitor between Function Generator and the PDH box
• 0.1Hz triangle wave (30 counts amplitude) applied to ETMY via awggui (so as to sweep the cavity and see stronger, more regular TEM00 flashes)

The PDH error signal did not have very well-defined features, so Koji tweaked the LO frequency and the modulation depth till we got a reasonably well-defined PDH signal. Then we turned the excitation off and locked the cavity to green. The servo gain was then optimized by reducing oscillations in the error signal. Eventually, we settled on values for the Servo Gain, LO frequency and modulation depth such that the UGF was ~20kHz (determined by looking at the frequency of oscillation of the error signal on an Oscilloscope), and the PDH signal had well-defined features (while the cavity was unlocked). The current parameters are

• LO frequency: 205.020 kHz
• modulation depth: 0.032 Vpp

We then proceeded to find the optimal demodulation phase by simulating the circuit with various capacitances between the function generator and the PDH box (circuit diagram and plots attached). The simulation seemed to suggest that there was no need to introduce any additional capacitance in this path (introducing a 1nF capacitance added a phase-lag of ~90 degrees-this was confirmed as the error-signal amplitude decreased drastically when we hooked up a 1nF capacitor on our makeshift breadboard). In the current configuration, the LO is connected directly to the PDH box.

Misc Points:

• The phase shifter in the PDH box is not connected: the IC in the box, JSPHS-26, is designed for operation in the range 18-26MHz. If necessary, an all-pass-filter could be introduced, with a tuneable rheostat to adjust the phase for our frequency range. Right now, turning the knob marked "LO phase angle" on the front panel doesn't do anything. The mixer on the PDH board is also not used for the same reason.
• PSL shutter was closed sometime earlier this evening, because we suspected some IR light was reaching the Green PD on the y-endtable, and was influencing the error signal. Its back open now.
• Useful information about the old y-end laser relevant to selecting the right LO frequency, modulation depth, and servo gain can be found here and in elog 2746 and subsequent replies, though the details of how the measurement were made aren't entirely clear. The idea is that the characteristics of the piezoelectric element in the laser has some characteristics which will determine the optimal LO frequency, modulation depth and servo gain.

To Do:

Now that we are reasonably confident that the loop parameters are optimal, we need to stabilise the C1ALS_Y_SLOW loop to stabilise the beat note itself. Appropriate filters need to be added to this servo.

Circuit Diagram: 50 ohm input impedance on the source, 50 ohm output impedance seen on the PDH box, capacitance varied between 1nF and 100nF in steps.

Plots for various capacitances: Gold-green trace (largest amplitude) direct from LO, other traces at input to PDH box.

Someone for some reason added full-rate DAQ specification to some ADC3 channels in the c1sus IOP model (c1x02):

#DAQ Channels

TP_CH15 65536
TP_CH16 65536
TP_CH17 65536
TP_CH18 65536
TP_CH19 65536
TP_CH20 65536
TP_CH21 65536

These appear to be associated with c1pem, so I'm guessing it was Den (particularly since he's the worst about making modifications to models and not telling anyone or logging or svn committing).

I'm removing them.

Does anyone know what the channels plugged in to the PEM ADCU, channels 5,6,7,8 are?  They aren't listed in the C1ADCU_PEM.ini file which tells the channel list/dataviewer/everything about all the rest of the signals which are plugged into that ADCU, so I'm not sure if they are used at all, or if they're holdovers from some previous time.  The cables are not labeled in a way that makes clear what they are.  Thanks!

Steve mentioned two unlabelled optics were found at EX, relics from the Endtable upgrade.

• One was a 1" 45 deg p-pol optic (Y1-1025-C-45P), it looks a bit scratched.
• The other was a Beam Sampler (BSF10-C).

These are now labelled and forked down on the SP table.

For the purpose of testing out the temperature sensors, I stole the PEM-SEIS_MC1X,Y,Z channels.

I unplugged Guralp NS1b, Guralp Vert1b, Guralp EW1b cables from the PEM ADCU(#10,#11,#12) near 1Y7 and put temp sensors in their place (temporarily).

I unplugged Guralp EW1b and Guralp Vert1b and plugged in temp sensors temporarily. Guralp NS1b is still plugged in.

[Masayuki, Manasa]

Looking into control signals and error signals of the Y arm green PDH servo,

1. The saturation of feedback signal (PZT_OUT) at +/-4000 counts (less than 5V) comes from only the readout saturating. The signals looked fine on the oscilloscope.
2. We did a sine sweep at the PZT_OUT and optimized the LO frequency. The LO frequency did not need any change.
3. The error signal has some offset to it. We are not sure where this comes from.

We have been seeing that whenever green loses lock, the spot position moves down in pitch on the ETMYF camera and the GTRY camera. This led us to think about if the lock loss originated from the PDH or from the cavity.

We looked into dataviewer channels of green, IR, oplev and suspension for the following cases:
1. Green and IR PDH locked
2. Green locked and arms flashing for IR
3. Green shutter closed and IR PDH locked
4. Green shutter closed and arms flashing for IR
5. Arms flashing for IR and ETMY oplev servo turned off.

Dataviewer snapshots of glitch in all the above cases are saved in masayuki's folder users/masayuki/ALS/kicked_mirror/

In all the above cases, we could still see the glitch. We could conclude that the problem lied with the ETMY SUS.
Shown below is the dataviewer snapshot of ETMY sus and shadow sensor channels. The glitch exists even when the oplev servo is turned off pointing to problems associated with the ETMY suspension.

Does anyone know what the purpose of the indicated optic in Attachment #1 is? Can we remove it? It will allow a little more space around the elliptical reflector...

I don't think it was used. It is not on the diagram too. You can remove it.

I was receiving missing path error when I was trying to measure the MC spot positions. Jenne pointed out that Koji had moved all the unused scripts in scripts/ASS to /scripts/ASS/OBSOLETE yesterday and in the process one of the scripts that the MC spot position measurement script calls for (MeasureSpotPositions.py) must have also been moved to the OBSOLETE directory. I moved the script to /scripts/ASS/MC so that we know the script is being used and also changed its path in the main script.

I reproduced Gautam's sketch of the 1x1 and 1x2 Eurocrates into a pdf image that contains links to the appropriate DCCs in the legend (see attachement).

Thanks. Please update this wiki page too.

https://wiki-40m.ligo.caltech.edu/Electronics/ElectronicsRacks#A1X1

Done.

As of RCG version 2.1, recorded channels use the suffix "_DQ", instead of "_DAQ".  I just rebuilt and installed the c1lsc model, which changed the channel names, therefore hosing the old daq channel ini file.  Here's what I did, and how I fixed it:

$ ssh c1lsc
$ cd /opt/rtcds/caltech/c1/core/trunk
$ make c1lsc
$ make install-c1lsc
$ cd /opt/rtcds/caltech/c1/scripts
$ ./startc1lsc
$ cd /opt/rtcds/caltech/c1/chans/daq
$ cat archive/C1LSC_110517_152411.ini | sed "s/_DAQ/_DQ/g" >C1LSC.ini
$ telnet fb 8087
daqd> shutdown

Aim: To develop a neural network that resolves mirror motion from video.

I had created a python code to find the combination of hyperparameters that trains the neural network. The code (nn_hyperparam_opt.py) is present in the github repo. It's running in cluster since a few days. In the meanwhile I had just tried some combination of hyperparameters.

These give a low loss value of approximately 1e-5 but there is a large error bar for loss value since it fluctuates a lot even after 1500 epochs. This is unclear.

Input: 64*64 image frames of simulated video by applying beam motion sine wave of frequency 0.2Hz and at 10 frames per sec. This input data is given as an hdf5 file.

Train : 100 cycles,  Test: 300 cycles, Optimizer = Nadam (learning rate = 0.001)

Model topology:

                    256       ->      128    ->       1

Activation :        selu     selu           linear

Case 1: batch size = 48, epochs = 1000, loss function = mean squared error

Plots of output predicted by neural network (NN) & input signal has been shown in 1st graph & variation in loss value with epochs in 2nd graph.

Case 2: batch size = 32, epochs = 1500, loss function = mean squared logarithmic error

Plots of output predicted by neural network (NN) & input signal has been shown in 3rd graph & variation in loss value with epochs in 4th graph.

Aim: To develop a neural network that resolves mirror motion from video.

I tried to reduce the overfitting problem in previous neural network by reducing the number of nodes and layers and by varying the learning rate, beta factors (exponential decay rates of moving first and second moments) of Nadam optimizer assuming error of 5% is reasonable.

Input:

32 * 32 image frames (converted to 1d array & pixel values of 0 to 255 normalized) of simulated video by applying sine signal to move beam spot in pitch with frequency 0.2Hz and at 10 frames per second.

Total: 300 cycles ,           Train: 60 cycles,    Validation: 90 cycles,    Test: 150 cycles

Model topology:

                                          Input               -->                  Hidden layer               -->                    Output layer                                  

                                                                                          4 nodes                                              1 node

Activation function:                                  selu                                             linear

Batch size = 32, Number of epochs = 128, loss function = mean squared error

Optimizer: Nadam

Case 1:

Learning rate = 0.00001,    beta_1 = 0.8 (default value in Keras = 0.9),  beta_2 = 0.85 (default value in Keras = 0.999)

Plot of predicted output by neural network, applied input signal & residual error given in 1st attachment.

Case 2:

Changed number of nodes in hidden layer from 4 to 8. All other parameters same.

These plots show that when residual error increases basically the output of neural network has a smaller amplitude compared to the applied signal. This kind of training error is unclear to me.

When beta parameters of optimizer is changed farther from 1, error increases.

Aim: To develop a neural network that resolves mirror motion from video.

Case 1:

Input : Simulated video of beam spot motion in pitch by applying 4 sine  waves of frquencies 0.2, 0.4, 0.1, 0.3 Hz  and amplitude ratios to frame size to be 0.1, 0.04, 0.05, 0.08

The data has been split into train, validation and test datasets and I tried training on neural network with the same model topology & parameters as in my previous elog (https://nodus.ligo.caltech.edu:8081/40m/14070)

The output of NN and residual error have been shown in Attachment 1. This NN model gives a large error for this. So I think we have to increase the number of nodes and learning rate so that we get a lower error value with a single sine wave simulated video ( but not overfitting) and then try training on linear combination of sine waves.

Case 2 :

Normalized the target sine signal of NN so that it ranges from -1 to 1 and then trained on the same neural network as in my previous elog with simulated video created using single sine wave. This gave comparatively lower error (shown in Attachment 2). But if we train using this network, we can get only the frequency of test mass motion but we can't resolve the amount by which test mass moves. So I'm unclear about whether we can use this.

Completed:

Wrote and tested a code for AGC using cavity transmission signal and length error signal.

Wrote and tested a code for frequency shifting (downconversion) using mixing and LPF

Wrote a code for whitening using FFT.

Altium working on cit40m iMac

Plans:

Writing codes for Frequency warping and whitening in time domain.

Implement AGC and frequency shifting on the real time control system.

Calculate requirements for Anti-aliasing filter.

I spent a day trying to modify Joe B.'s LLO camera client-server code without ultimate success. His codes now runs without throwing any errors, but something inside the black-box handoff of his camera source code to gstreamer appears to be SILENTLY FAILING. Gautam suggested a call with Joe B., which I think is worth a try.

In the meantime, I've impemented a simple Python video feed streamer which does work, and which students can use as a base framework to implement more complicated things (e.g., stream multiple feeds in one window, save a video stream movie or animation).

It uses the same PyPylon API to interface with the GigE cameras as does Joe's code. However, it uses matplotlib instead of gstreamer to render the imaging. The matplotlib code is optimized for maximum refresh rate and I observed it to achieve ~5 Hz for a single video feed. However, this demo code does not set any custom cameras settings (it just initializes a camera with its defaults), so it's quite possible that the refresh rate is actually limited by, e.g., the camera exposure time.

Location of the code (on the shared network drive):

/opt/rtcds/caltech/c1/scripts/GigE/demo_with_mpl/stream_camera_to_mpl.py

This demo initializes a single GigE camera with its default settings and continuously streams its video feed in a pop-up window. It runs continuously until the window is closed. I installed PyPylon from source on the SL7 machine (rossa) and have only tested it on that machine. I believe it should work on all our versions of Linux, but if not, run the camera software on rossa for now.

Usage:

From within the above directory, the code is executed as 

$python stream_camera_to_mpl.py [Camera IP address]

with a single argument specifying the IP address of the desired camera. At the time I tested, there was only one GigE camera on our network, at 192.168.113.152.

Aha! Video is back!

I think it would be good to add a flag whereby the video can be saved to disk in some uncompressed video format (ogg, avi, ?) instead of displayed to a matplotlib window. We could then use the default to just display video, but use the save-to-disk flag to grab a few minutes of video for image processing.

To include the plots that I've been working on in some form other than on my computer, here they are:

First is the big surface plot of all the amplitude spectra, taken in 10min intervals on one month of S5 data. The times when the IFO is unlocked are represented by vertical black stripes (white was way too distracting).  For the paper, I need to recreate this plot, with traces only at selected times (once or twice a week) so that it's not so overwhelmingly large.  But it's pretty cool to look at as-is.

Second is the same information, encoded in a pseudo-BLRMS.  (Pseudo on the RMS part - I don't ever actually take the RMS of the spectra, although perhaps I should).  I've split the data from the surface plot into bands (The same set of bands that we use for the DMF stuff, since those seem like reasonable seismic bands), and integrated under the spectra for each band, at each time.  i.e. one power spectra gives me 5 data points for the BLRMS - one in each band.  This lets us see how good the filter is doing at different times.

At the lower frequencies, after ~25 days, the floor starts to pick up.  So perhaps that's about the end of how long we can use a given Wiener filter for.  Maybe we have to recalculate them about every 3 weeks.  That wouldn't be tragic. 

I don't really know what the crazy big peak in the 0.1-0.3Hz plot is (it's the big yellow blob in the surface plot).  It is there for ~2 days, and it seems awfully symmetric about it's local peak.  I have not yet correlated my peaks to high-seismic times in the H1 elog.  Clearly that's on the immediate todo list. 

Also perhaps on the todo list is to indicate in some way (analagous to the black stripes in the surface plot) times when the data in the band-limited plot is just extrapolated, connecting the dots between 2 valid data points.

A few other thoughts:  The time chosen for the training of the filter for these plots is 6:40pm-7:40pm PDT on Sept 9, 2007 (which was a Sunday night).  I need to try training the filter on a more seismically-active time, to see if that helps reduce the diurnal oscillations at high frequency.  If that doesn't do it, then perhaps having a "weekday filter" and an "offpeak" filter would be a good idea.  I'll have to investigate.

The current update on the Chameleon video switch is: no progress.

I connected the old laptop that Rob/Steve acquired via RS-232 serial to the back of the video switch.  I'm using P2, the same serial port that the C1AUX computer was connected to just in case there's something good about P2 vs. P1. 

I used HyperTerminal to (try to) talk to the switch.  Settings were:  COM1, bits per second = 9600, data bits = 8, parity = none, stop bits = 1, flow control = none.  I can successfully send/get back responses to the basic commands, I (inquiry as to the type of equipment), and H (help - spits out the list of acceptable commands).  But when I try to do an actual command to do some video switching, everything hangs.  The front panel's rolling display (which just echos the company name) stops, then starts up again after ~20sec.  The hyperterminal display doesn't change.  I get neither the "DONE" answerback, which would indicate that the command executed successfully, nor do I get the "ERROR" answerback, which would indicate that something is wrong.  It just hangs.  If I disconnect, and restart the connection, and instead of trying a real command, but instead just send 'blahblahblah', then it will answerback 'ERROR' the first time, and then if I try to send another garbage message, everything hangs again.  So, I can sort of talk to the video switch, but I can't make it do anything yet.

I'm leaving the laptop connected instead of C1AUX, since the video EPICS screen doesn't work anyway for now.  If you want to start up the connection, either input the settings quoted above, or open "40m Video", which should have these connection settings saved in HyperTerminal.

 [Steve, Suresh, Larisa]

The following cables were laid today: ETMYT, ETMY, IFOPO, MC1, OMCR, AS Spare, and MC2T.

Though the paper suggested 135' for the MC2T, we used a 110'. This is too short: need at least another 15' for the MC2T.

The RCR cable wasn't crossed off on the list, but a cable exists at the RCR cable which is black and is labeled (old label, 75 ohms)

There was no indication of which length was needed for MC1, so a 95' cable was used.

After the catastrophic fb disk failure last week we lost essentially the entire front end system (not any of the userapp code, but the front end boot server, operating system, and DAQ).  The fb disk was entirely unrecoverable, so we've been trying to rebuild everything from the bits and pieces lying around, and some disks that Keith Thorne sent from LLO.  We're trying to get the front ends working first, and will work on recovering daqd after.

Luckily, fb1, which was being configured as an fb replacement, is mostly fully configured, including having a copy of the front end diskless root image.  We setup fb1 as the new boot server, and were able to get front ends booting again.  Unfortunately, we've been having trouble running and building models, so something is still amis.  We've been taking a three-pronged approach to getting the front ends running:

• /diskless/root.fb: This involves booting the front ends from the backup of the diskless root from fb.  Runs gentoo kernel 2.6.34.1.  This should correspond to the environment that all models were built and running against.  But something is missing in the configuration.  The front ends were also mounting /opt from fb, which included the dolphin drivers, and we don't have a copy of that, so models aren't loading or recompiling.
• /diskless/root.x1boot: Keith sent a disk image of the entire x1boot server from LLO.  It uses gentoo kernel 3.0.8.  This ostensibly includes everything we should need to run the front ends, but it's unfortunately configured with newer versions of some of the software and also isn't loading our existing models or building new ones.  This also seems to be having issues with the dolphin drivers.
• /diskless/root.jessie: This is an entirely new boot image build from scratch with Debian jessie, using an RTS-patched 3.2 kernel.  This would use the latest versions of everything.  It's mostly working, we just need to rebuild the dolphin driver and source.

It seems that in all cases we need to rebuild the dolphin drivers from source.

To clarify, we're able to boot the x1boot image with the existing 2.6.25 kernel that we have from fb.  The issue with the root.x1boot image is not the kernel version but some of the other support libraries, such as dolphin.

Update:

• front ends booting with the new Debian jessie diskless root image and a linux 3.2 version of the RTS-patched kernel
• dolphin is configured correctly and running on c1lsc and c1sus
• models building and running with RCG 3.0.3

Up next:

• add c1ioo to the dolphin network
• recompile/restart all front end models
• daqd

I'll try to get the first two of those done tomorrow, although it's unclear what model updates we'll have to do to get things working with the newer RCG.

1. Jordan (new Engineer) and Chub neatened out the cabling at 1Y2/1Y3 today. After their work, I plugged in all the Dsubs to the rear Eurocrate DB37->DIN96 adaptors. Jordan nicely fixed up the labels on the cable with some extra sellotape for a more durable label.
2. As part of the war on cross-connects, Chub removed some cables that were piping BIO signals from the fast CDS system to the whitening boards.
   • There is a SCSI to DB37 custom ribbon cable going from the BIO card in the expansion chassis to a 1U chassis box at the very bottom of 1Y2.
   • This 1U box, with DCC number D080478 (but no schematic exists on the DCC or any of the usual secret hidey-holes) breaks out the 32 BIO channels to 16+16.
   • Each set of 16 channels was supposed to get broken out to 8+8 via some cross connects and then goto the whitening boards. This is the part that got distrubed.
   • Koji and I discussed options - if Chub cannot resotre this easily, we will make a D37--> 4*D15 breakout board, and pipe the signals via the backplane P2 connectors. This will mean ~10 more days before the LSC system can be tested.
   • Some cabling to the TT DACs and an ADC were also disturbed, but these are easily restored.
3. From the hardware standpoint, some cross-struts for strain relief on the back of 1Y2 need to be installed --> Chub.

The top-level subsystem subdirectories in the cds_user_apps source repository were renamed today to be all lower case.  This required checking out the new directory and updating all of the model links in /opt/rtcds/caltech/c1.  Here is how I updated the cds_user_apps working tree:

cd /opt/rtcds/caltech/c1/userapps
mv trunk{,.bak}
svn update --depth=files trunk
svn update --depth=empty trunk/{cds,isi,isc,psl,sus}

I then fixed the links in the /opt/rtcds/caltech/c1/core/release/src/epics/simLink directory:

for link in $(find . -maxdepth 1 -type l); do ln -sf $(readlink $link | tr [:upper:] [:lower:]) ; done

A couple of things had to be cleaned up:

• /opt/rtcds/caltech/c1/userapps/trunk/cds/c1/models/c1uct.mdl was linked in, but that model doesn't seem to exist anymore, so I removed the link.
• a couple of things were linked from /opt/rtcds/caltech/c1/userapps/trunk instead of /opt/rtcds/caltech/c1/userapps/release, so I fixed those links.
• /opt/rtcds/caltech/c1/userapps/release/cds/test/models/llo/l1isctest.mdl was not checked out, so I checked it out and fixed the link (this model should really be named something different if it is of common use, or we plan on using it at the 40m).

I have updated the wiper.pl script (/opt/rtcds/caltech/c1/target/fb/wiper.pl) that runs on the framebuilder (in crontab) to delete old frames in case of file system overloading.  The point of this script is to keep the file system from overloading by deleting the oldest frames.  As it was, it was not properly sorting numbers which would have caused it to delete post-GPS 1000000000 frames first.  This issue was identified at LHO, and below is the patch that I applied to the script.

--- wiper.pl.orig  2011-04-11 13:54:40.000000000 -0700
+++ wiper.pl       2011-09-14 19:48:36.000000000 -0700
@@ -1,5 +1,7 @@
 #!/usr/bin/perl
 
+use File::Basename;
+
 print "\n" .  `date` . "\n";
 # Dry run, do not delete anything
 $dry_run = 1;
@@ -126,14 +128,23 @@
 
 if ($du{$minute_trend_frames_dir} > $minute_frames_keep) { $do_min = 1; };
 
+# sort files by GPS time split into prefixL-T-GPS-sec.gwf
+# numerically sort on 3rd field
+sub byGPSTime {
+    my $c = basename $a;
+    $c =~ s/\D+(\d+)\D+(\d+)\D+/$1/g;
+    my $d = basename $b;
+    $d =~ s/\D+(\d+)\D+(\d+)\D+/$1/g;
+    $c <=> $d;
+}
+
 # Delete frame files in $dir to free $ktofree Kbytes of space
 # This one reads file names in $dir/*/*.gwf sorts them by file names
 # and progressively deletes them up to $ktofree limit
 sub delete_frames {
        ($dir, $ktofree) = @_;
        # Read file names; Could this be inefficient?
-       @a= <$dir/*/*.gwf>;
-       sort @a;
+       @a = sort byGPSTime <$dir/*/*.gwf>;
        $dacc = 0; # How many kilobytes we deleted
        $fnum = @a;
        $dnum = 0;
@@ -145,6 +156,7 @@
          if ($dacc >= $ktofree)  { last; }
          $dnum ++;
          # Delete $file here
+         print "- " . $file . "\n";
          if (!$dry_run) {     
            unlink($file);
          }

I have pushed changes made to the toggleWFSoffsets.py script to the git.

This file may be found in: "/opt/rtcds/caltech/c1/Git/40m/scripts/MC/WFS/"

The changes made are:

Updated the script to allow for toggling step responses on either optics or sensors (default = optics), chosen by user

The script orignally asked user to make any last changes to the offsets before hitting enter to run without displaying the new changes.

Now the script checks for changes made by the user to the offsets and displays them if detected. If no changes are made, the code starts running the steps.

All SURFs (and all others as always) are supposed to post the update of your status on the elog.

In fact, I already heard that Sharmila had been working on the serial connection to TC-200 and made some results. All of us like to hear the story.

I have been working on configuration of the Daily Summary webpages and have been attempting to create a "PSL health" page.  This page will display the PMC power, the temperature on the PSL table and the PSL table microphone levels.  Thus far, I have managed to make the extra PSL tab and configure the graph of the interior temperature, using channel C1:PSL-FSS_RMTEMP.

I have been attempting to make a spectrogram for one of the PMC channels, but there is an issue with the spectrogram setup, as Duncan Macleod noted in ELOG 6686:

"At the moment a package version issue means the spectrogram doesn't work, but the spectrum should. At the time of writing, to use the spectrum simple add 'plot-dataplot2'."

Because of this issue, I have also been trying to make the spectrogram plots work.  Thus far, I have fixed the issue with one of the spectrogram plots, but there are several problems with the other four that I need to address.  I have also been looking at the microphone channels and trying to make the plot for them work.  I checked which microphone was on the PSL table and plotted it in matplotlib to make sure it was working.  However, when I tried to incorporate it into the daily summary pages, the script stops at that point!  It might simply be taking an excessively long time, but I have to figure out why this is the case.

                                                 (I am using channel C1:PEM-MIC_6_IN1_DQ, if this is blatantly wrong, please let me know!!)

The main point of this ELOG is that I have working test-daily summary pages online!  They can be found here:

https://nodus.ligo.caltech.edu:30889/40m-summary-test/archive_daily/20120710/

Also, if anyone has more requests for what they would like to see on the finalized summary pages site, please respond to this post or email me at: endavison@umail.ucsb.edu

I have updated the 'videoswitch' program that controls the video MUX.  It now includes the ability to query the video mux for the channel mapping:

controls@pianosa:~ 0$ /opt/rtcds/caltech/c1/scripts/general/videoswitch -h
Usage:
videoswitch [options] [OUT]      List current output/input mapping [for OUT]
videoswitch [options] OUT IN     Set output OUT to be input IN

Options:
  -h, --help            show this help message and exit
  -i, --inputs          List input channels and exit
  -o, --outputs         List output channels and exit
  -l, --list            List all input and output channels and exit
  -H HOST, --host=HOST  IP address/Host name
controls@pianosa:~ 0$

Last report on model change / screen work from yesterday.

The ALSwatch script has always been just looking at the EPICS output of the CARM and DARM filter banks, and if it saw a single saturation, it would run the down script.  This was non-ideal because (a) the EPICS channels aren't the real signals, and (b) sometimes we'll hit the rails briefly and that's okay - we want to shut things down only when we're constantly saturating.

It turns out that there was a pre-existing saturation monitor part in CDS_PARTS, which I have used.  There is one each looking at the output of the CARM and DARM filter banks.  The threshold for what saturation means is set as an epics input.  The part outputs a running count (number of saturations since the last time it was not saturated, resets each time it goes non-saturating) and a total number since the last reset (also an epics input). 

(To be continued... still writing)

Attached is the layout for the "intermediate" CDS upgrade option, as was discussed on Wednesday. Under this plan:

• Existing FEs stay where they are (they are not moved to a single rack)

• Dolphin IPC remains PCIe Gen 1

• RFM network is entirely replaced with Dolphin IPC

Please send me any omissions or corrections to the layout.

I just want to point out that if you move all the FEs to the same rack they can all be connected to the Dolphin switch via copper, and you would only have to string a single fiber to every IO rack, rather than the multiple now (for network, dolphin, timing, etc.).

1. The diagram should clearly show the host machines and the expansion chassis and the interconnects between them.
2. We no longer have any Gentoo bootserver or diskless FEs.
3. The "c1lsc" host is in 1X4 not 1Y3.
4. The connection between c1lsc and Dolphin switch is copper not fiber. I don't know how many Gbps it is. But if the switch is 10 Gbps, are they really selling interface cables that have lower speed? The datasheet says 10 Gbps.
5. The control room workstations - Debian10 (rossa) is the way forward I believe. it is true pianosa remains SL7 (and we should continue to keep it so until all other machines have been upgraded and tested on Debian 10).
6. There is no "IOO/OAF". The host is called "c1ioo".
7. The interconnect between Dolphin switch and c1ioo host is via fiber not copper.
8. It'd be good to have an accurate diagram of the current situation as well (with the RFM network).
9. I'm not sure if the 1Y1 rack can accommodate 2 FEs and 2 expansion chassis. Maybe if we clear everything else there out...
10. There are 2 "2GB/s" Copper traces. I think the legend should make clear what's going on - i.e. which cables are ethernet (Cat 6? Cat 5? What's the speed limitation? The cable? Or the switch?), which are PCIe cables etc etc. 

I don't have omnigraffle - what about uploading the source doc in a format that the excellent (and free) draw.io can handle? I think we can do a much better job of making this diagram reflect reality. There should also be a corresponding diagram for the Acromag system (but that doesn't have to be tied to this task). Megatron (scripts machine) and nodus should be added to that diagram as well.

I've produced updated diagrams of the CDS layout, taking the comments in 15476 into account. I've also converted the 40m's diagrams from Omnigraffle ($150/license) to the free, cloud-based platform draw.io. I had never heard of draw.io, but I found that it has most all the same functionality. It also integrates nicely with Google Drive.

Attachment 1: The planned CDS upgrade (2 new FEs, fully replace RFM network with Gen 1 Dolphin IPC)
Attachment 2: The current 40m CDS topology

The most up-to-date diagrams are hosted at the following links:

• Planned 40m CDS topology
• Current 40m CDS topology

Please send me any further corrections or omissions. Anyone logged in with LIGO.ORG credentials can also directly edit the diagrams.

Not sure if 1Y1 can accommodate both c1sus2 and c1bhd as well as the various electronics chassis that will have to be installed. There may need to be some distribution between 1Y1 and 1Y3. Does Koji's new wiring also specify which racks hold which chassis?

Some minor improvements to the diagram:

1. The GPS receiver in 1X7 should be added. All the timing in the lab is synced to the 1pps from this.
2. We should add hyperlinks to the various parts datasheets (e.g. Dolphin switch, RFM switch, etc etc) so that the diagram will be truly informative and self-contained.
3. Megatron and nodus, but especially chiara (NFS server), should be added to the diagram. 

I've updated the  Computer Restart Procedures  page in the wiki with the latest fb restart procedure.

To just restart just the daqd (frame builder) process, do:

1) telnet fb 8088

2) shutdown

The init process will take care of the rest and restart daqd automatically.