The acromags are on the UPS. I suspect the transient came in on one of the signal lines. Chub tells me he unplugged one of the signal cables from the chassis around the time things died on Monday, although we couldn't reproduce the problem doing that again today.
In this situation it wasn't the software that died, but the acromag units themselves. I have an idea to detect future occurrences using a "blinker" signal. One acromag outputs a periodic signal which is directly sensed by another acromag. The can be implemented as another polling condition enforced by the interlock code.
If the acromags lock up whenever there is an electrical spike, shouldn't we have them on UPS to smooth out these ripples? And wasn't the idea to have some handshake/watchdog system to avoid silently dying computers?
The problem encountered with the vac controls was indeed resolved via the recommendation I posted yesterday. The Acromags had gone into a protective state (likely caused by an electrical transient in one of the signals)
The old IBM laptop (Asia) has died from a fan error after 7 years. WE have a new Lenovo 330 IdeaPad to replace it:
Install done. Touchpad not recognized by linux - lots of forum posts about kernel patching...Arrgh!
I have swapped our martian router's WiFi security over to WPA2 (AES) from the previous, less-secure, system. Creds are in the secrets-40-red.
agreed - we need all pumps on UPS for their safety and also so that we can spin them down safely. Can you and Chub please find a suitable UPS?
However, I discovered that TP1---the pump that might be most damaged by a sudden power failure---is not on the UPS. It's plugged directly into a 240V outlet along the wall. This is because the current UPS doesn't have any 240V sockets. I'd recommend we get one that can handle all the turbo pumps.
G=10 or G=100?
Can we get some panel mount FC/APC connectors and put them on a box? Then we could have the whole setup inside of a box that is filled with foam and sits outside the PSL hut.
if this gonna be general for everybody, maybe it oughta be called IFOtest (like the last incarnation that was tried in Livingston) ?
then the SUS tests could just be some smaller set of measurements. Using the same code base, but different params.
had trouble using YUM to update. This turned out to be a config problem with our Martian router, not the new laptop. Since I've changed the WiFi pwd awhile ago for the martian access for the CDS laptops, you'll have to enter that in order to use the laptops.
turned out to be some Access Control nonsense inside of the router. Even loggin in as admin with a cable gave some of the fields the greyed out color (had to hover over the link and then type the URL directly in the browser window). ASIA is now able to connect and use YUM + usual connections. Gautam and I have also moved the router a little to get easier view of its LED lights and not blockk its WiFi signal with the cable tray. We'll get a little shelf so that we can mount it ~1 foot off of the wall.
still, this seems like a bad laptop choice: the Lenovo Ideapad 330 will not have its touchpad supported by SL7 without compiling a new version of the kernel
let us have 3 by 4, nevermore
so that the number of columns is no less
and no more
than the number of rows
so that forevermore we live as 4 by 4
I'm struggling to think
If thy left hand troubles thee
then let the mirror show the right
for if it troubles enough to cut it off
it would not offend thy sight
My hunch is that the TECs are working too hard and can't offload the heat onto the heat sinks. As the diode's degrade, more of the electrical power is converted to heat in the diodes rather than 808 nm photons. So hopefully the increased airflow will help.
I tried to increase the DTEC setpoints, but that seems to detune them too far from the laser absorption band, so that's not very efficient for us. IN any case, if we end up changin the laser temperature, we'll have to adjust the ALS lasers to match, and that will be annoying.
The office area was very cold and the HVAC air flow stronger than usual. I changed the setpoint on the thermostat near Steve's desk from 71 to 73F at 1830 today.
no BMP files
don't need to lock - make sure the 4 OSEMs are centered on the camera field just as we have for the arm cavity mirrors
I'm attaching a picture of the screen. I just positioned the enclosure by turning it a bit and I suppose we can see the mirror inside the vacuum now (the MC2 is still not locked).
a useful piece of code that we should ask one of this summer's SURFs to write:
this will solve the sticky slider problem and do it in a systematic way. We can run it from the command line: e.g. 'unsticky.py c1psl c1ioo c1lsc'
Aaron complained to me earlier that the PMC could not be locked. Turned out to be a classic sticky slider problem,
we are thinking of doing a sprucing up of the input mode cleaner WFS (sensors + electronics + feedback loops)
you have to use a BS with a larger wedge angle (5 arcmin ~ 1 mrad) so that the beams don't overlap on the camera
I found the MC2 face camera disabled(?) and the MC servo board input turned off. I turned the MC locking back on but I don't see any camera image yet.
"bricked" is to mean that it has the functionality of a brick and can be tossed. But rossa seems to have just gotten some software config corruption. I spent a couple hours reinstalling SL7 today as per my previous elog notes and the X display seems to work as before.
i.e. it was fine with the default setup, except for the ole "X chrashes if the mouse goes to left side of screen". As before, I
left side of screen is safe again
This time I installed SL7.6 and followed the K Thorne wiki. But its having trouble installing cds-root because it can't find root.
One of the biggest challenges in LIGO is reducing the alignment control noise. If you haven't worked on it for at least a few years, it probably seems like a trivial problem. But all versions of LIGO since 2001 have been limited by ASC noise below ~50 Hz.
I think the 40m IMC is a good testbed for us to try a few approaches towards mitigating this noise in LIGO. The following is a list of steps to take to get there:
I think that steps 1-6 are well within our existing experience, but we should do it anyway so as to reduce the IMC beam motion at low frequencies, and also to reduce the 10-100 Hz frequency noise as seen by the rest of the interferometer.
Steps 7-8 are medium hard, but we can get some help from the CSWG in tackling it.
Step is pretty tough, but I would like to try it and also get some help from MLWG and CSWG to address it.
What about just use high gain feedback to MC2 below 20 Hz for the IMC lock? That would reduce the excess if this theory is correct.
via Polish chat, GV tells us to RTFE
please no one touch the UPS: last time it destroyed ROSSA. Please ask Chub to order the replacement batteries so we can do this in a controlled way (fully shutting down ALL workstations first). Last time we wasted 8 hours on ROSSA rebuilding.
There was an alarm sound from the Smart-UPS 2200 sitting under the workstation. I see that the 'replace battery' light is red, and this elog tells me that these batteries are replaced every ~1-4 years; the last replacement was march 2016. Holding down the 'test' button for 2-3 seconds results in the alarm sound and does not clear the replace battery indicator.
not need to use DTT. I'm attaching some half-finished notebooks that give the gist.
That's it! Now you have the complex, single frequency TFs. Next you invert the matrix.
"# Get some ASC data - Calculate Sensing Matrix \n",
"### also make the radar plots"
Formatted and re-installing OS on rossa for the 3rd or 4th time this year. I suggest that whoever is installing software and adjusting video settings please stop.
If you feel you need to tinker deeply, use ottavia or zita and then be prepared to show up and fix it.
While I was moving the UPS around, the network lights went out for Rossa, so I may have damaged the network interface or cable. Debugging continues.
wonder if its possible to do variable finesse locking
Gabriele mentioned that Virgo used arm trans PDH for this, but I guess we could possibly use POX/POY to start and bring in the PRM with 50% MICH trans
I'm curious to see if we really need the 1611, or if we can calibrate the diode laser vs. the 1611 one time and then just use that calibration to get the absolute cal for the DUT.
Got the network to work again just by unplugging the power cord and letting it sit for awhile. But corrupted OS by trying to install Nvidia drivers.
I think this offset setting thing is not so good. People do this every few years, but putting offsets in servos means that you cannot maintain a stable alignment when there are changes in the laser power, PMC trans, etc. The better thing is to do the centering of the WFS spots with the unlcoked beam after the control offsets have been offloaded to the suspensions.
It would be good if you and Shruti can look at how to change the parameters in Zero so as to do a fit to the measured data. Usually, in scipy.optimize we give it a function with some changeable params, so maybe there's a way to pass params to a zero object in that way. I think Ian and Anchal are doing something similar to their FSS Pockel's cell simulator.
During our EX AM/PM setups, I don't think we bumped the PDH gain knob (and I hope that the knob was locked). Possible drift in the PZT response? Good thing Shruti is on the case.
Is there a loop model of green PDH that agrees with the measurement? I'm wondering if something can be done with a compensation network to up the bandwidth or if the phase lag is more like a non-invertible kind.
back on new Rossa from Xi computing
Update: Sun Nov 3 18:08:48 2019
Update: Fri Nov 15 00:00:26 2019:
this is due to the Equivalence Principle: local accelerations are indistinguishable from spacetime curvature. On a spherical Earth, the local gradient of the metric points in the direction towards the center of the Earth, which is colloquially known as "down".
I don't understand why the z-axis motion reported by the T240 is ~10x lower at 10 mHz compared to the X and Y motions. Is this some electronics noise artefact?
at 1 Hz' this effect is not large so that's real translation. at lower frequencies a ground tilt couples to the horizontal sensors at first order and so the apparent signal is amplified by the double integral. drawing a free body diagram u can c that
x_apparent = (g / s^2) * theta
but for vortical this not tru because it already measures the full free fall and the tilt only shows up at 2nd order
We turned off many excessive violin mode bandstop filters in the LSC.
Due to some feedforward work by Jenne or EQ some years ago, we have had ~10 violin notches on in the LSC between the output matrix and the outputs to the SUS.
They were eating phase, computation time, and making ~3 dB gain peaking in places where we can't afford it. I have turned them off and Gautam SDF safed it.
Offensive BS shown in brown and cooler BS shown in blue.
To rotate the DTT landscape plot to not be sideways, use this command (note that the string is 1east, not least):
pdftk in.pdf cat 1east output out.pdf
The large ground motion at 1 Hz started up again tonight at around 23:30. I walked around the lab and nearby buildings with a flashlight and couldn't find anything whumping. The noise is very sinusoidal and seems like it must be a 1 Hz motor rather than any natural disturbance or traffic, etc. Suspect that it is a pump in the nearby CES building which is waking up and running to fill up some liquid level. Will check out in the morning.
Estimate of displacement noise based on the observed MC_F channel showing a 25 MHz peak-peak excursion for the laser:
dL = 25e6 * (13 m / (c / lambda)
= 1 micron
So this is a lot. Probably our pendulum is amplifying the ground motion by 10x, so I suspect a ground noise of ~0.1 micron peak-peak.
(this is a native PDF export using qtgrace rather than XMgrace. uninstall xmgrace and symlink to qtgrace.)
and so it begins...until this is finished I have turned off the projector and moved the striptools to the big TV (time to look for Black Friday deals to replace the projector with a 120 inch LED TV)
...maybe the opto-mechanical CARM plant is changing as a function of the CARM offset...
Even assuming 50% error in the calibration factors, it's hard to explain the swing of TRX/TRY when the CARM offset is brought to zero.
if the RP don't fit
u must acquit
sweep the laser amplitude
to divine the couplin w certitude
filter Q seems too high,
but what precisely is the proper way to design the IF filter?
seems like we should be able to do it using math instead of feelins
Izumi made this one so maybe he has an algorythym
Recently, accordian to Gautam, the NDS2 server has been dying on Megatron ~daily or weekly. The prescription is to restart the server.
Also, megatron is running Ubuntu 12 !! Let's decide on a day to upgrade it to a Debian 18ish....word from Rolf is that Scientific Linux is fading out everywhere, so Debian is the new operating system for all conformists.
# this function gets some data (from the 40m) and saves it as
# a .mat file for the matlabs
# Ex. python -O getData.py
from scipy.io import savemat,loadmat
import scipy.signal as sig
from astropy.time import Time
Yehonathan, please center the EX seismometer.
The attached PDF shows the seismometer signals (I'm assuming that they're already calibrated into microns/s) during the lab tour for the art students on 11/1. The big spike which I've zoomed in on shows the time when we were in the control room and we all jumped up at the same time. There were approximately 15 students each with a mass of ~50-70 kg. I estimate that out landing times were all sync'd to within ~0.1 s.
I have re-centered the EX (and EY) seismometers. They are Guralp CMG40-T, and have no special centering procedure except cycling the power a few times. I turned off the power on their interface box, then waited 10s before turning it back on.
The fist atm shows the comparison using data from 8-9 PM Saturday night:
The IBM laptop at EX was running Ubuntu 14, so I allowed it to start upgrading itself to Ubuntu16 as it desired. After it is done, I will upgrade it to 18.04 LTS. We should have them all run LTS.
I noticed recently that Megatron was running Ubuntu 12, so I've started its OS upgrade.
Megatron and IMC autolocking will be down for awhile, so we should use a different 'script' computer this week.
Mon Dec 9 14:52:58 2019
upgrade to Ubuntu 14 complete; now upgrading to 16
Megatron is now running Ubuntu 18.04 LTS.
We should probably be able to load all the LSC software on there by adding the appropriate Debian repos.
I have re-enabled the cron jobs in the crontab.
The MC Autolocker and the PSL NPRO Slow/Temperature control are run using 'initctl', so I'll leave that up to Shruti to run/test.