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.
idk - I'm recently worried about the 'thermal self locking' issue we discussed. I think you should try to measure the linewidth by scanning (with low input power) and also measure the TF directly by modulating the power via the AOM and taking the ratio of input/output with the PDA55s. I'm curious to see if the ringdown is different for low and high powers
I plan to model the PD+AOM as a lowpass filter with an RC time constant of 12us and undo its filtering action on the PMC trans ringdown measurement to get the actual ringdown time.
Is this acceptable?
This is an ole SURF report on thermal self-locking that may be of use (I haven't read it or checked it for errors, but Royal was pretty good analytically, so its worth looking at)
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
doesn't seem so anomolous to me; we're getting ~25 dB of gain range and the ideal range would be 40 dB. My guess is that even thought this is not perfect, the real problem is elsewhere.
I changed the office area thermostate near Steve's desk from 68F to 73F today. Please do not change it.
If anyone from facilities comes to adjust something, please put the details in the elog on the same day so that we can know to undo that change rather than chase down other drifts in the system.
Could you please put physical units on the Y-axis and also put labels in the legend which give a physical description of what each trace is?
It would also be good to a separate plot which has the IR locking signal and the green locking signal along with this out of loop noise, all in the same units so that w can see what the ratio is.
to make the comparisons meaningfully
one needs to correct for the feedback changes
when doing the AM sweeps of cavities
make sure to cross-calibrate the detectors
else you'll make of science much frivolities
much like the U.S. elections electors
Yesterday evening I took nearly all of the masks, gloves, gowns, alcohol wipes, hats, and shoe covers. These were the ones in the cleanroom cabinets at the east end of the Y-arm, as well as the many boxes under the yarm near those cabinets.
This photo album shows the stuff, plus some other random photos I took around the same time (6-7 PM) of the state of parts of the lab.
do you really mean awggui cannot make shaped noise injections via its foton text box ? That has always worked for me in the past.
If this is broken I'm suspicious there's been some package installs to the shared dirs by someone.
that's pretty great performance. maybe you can also upload some code so that we can do it later too - or maybe in the 40m GIT
I wonder how much noise is getting injected into PRC length at 10-100 Hz due to this. Any change the PRC ERR?
I just now modified the /etc/rsyncd.conf file as per Dan Kozak's instructions. The old conf file is still there with the file name appended with today's date.
I then enabled the rsync daemon to run on boot using 'enable'. I'll ask Dan to start the file transfers again and see if this works.
controls@nodus|etc> sudo systemctl start rsyncd.service
controls@nodus|etc> sudo systemctl enable rsyncd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/rsyncd.service to /usr/lib/systemd/system/rsyncd.service.
controls@nodus|etc> sudo systemctl status rsyncd.service
● rsyncd.service - fast remote file copy program daemon
Loaded: loaded (/usr/lib/systemd/system/rsyncd.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2020-04-13 16:49:12 PDT; 1min 28s ago
Main PID: 4950 (rsync)
└─4950 /usr/bin/rsync --daemon --no-detach
Apr 13 16:49:12 nodus.martian.113.168.192.in-addr.arpa systemd: Started fast remote file copy program daemon.
Apr 13 16:49:12 nodus.martian.113.168.192.in-addr.arpa systemd: Starting fast remote file copy program daemon...
There's this elog from Stephen about better 1064 sensitivity from Basler. We should consider getting one if he finds that its actual SNR is as good as we would expect from the QE improvement.
Might allow for better scatter measurements - not that we need more signal, but it could allow us to use shorter exposure times and reduce blurring due to the wobbly beams.
I had set up the 4395 to do this automatically a few years ago, but it looked at the FSS/IMC instead. When the PCDRIVE goes high there is this excess around ~500 kHz in a broad hump.
But the IMC loop gain changes sometimes with alignment, so I don't know if its a loop instability or if its laser noise. However, I think we have observed PCDRIVE to go up without IMC power dropping so my guess is that it was true laser noise.
This works since the IMC is much more sensitive than PMC. Perhaps one way to diagnose would be to lock IMC at a low UGF without any boosts. Then the UGF would be far away from that noise making frequency. However, the PCDRIVE also wouldn't have much activity.
This is the doc from Keita Kawabe on why the WFS heads should be rotated.
apt install source-highlight
then modified bashrc to point to /usr/share instead of /usr/bin
It would be good to have a corner plot with all the distances/ RoCs. Also perhaps a Jacobian like done in this breathtaking and seminal work.
was dead again this morning - JZ notified
current restart instructions (after ssh to megatron):
sudo su nds2mgr
make -f test_restart
so far it has run through the weekend with no problems (except that there are huge log files as usual).
I have started to set up monit to run on megatron to watch this process. In principle this would send us alerts when things break and also give a web interface to watch monit. I'm not sure how to do web port forwarding between megatron and nodus, so for now its just on the terminal. e.g.:
monit>sudo monit status
Monit 5.25.1 uptime: 4m
monitoring status Monitored
monitoring mode active
on reboot start
load average [0.15] [0.22] [0.25]
cpu 0.6%us 1.0%sy 0.2%wa
memory usage 1001.4 MB [25.0%]
swap usage 107.2 MB [1.9%]
uptime 40d 17h 55m
boot time Tue, 14 Apr 2020 17:47:49
data collected Mon, 25 May 2020 11:43:03
monitoring status Monitored
monitoring mode active
on reboot start
parent pid 1
effective uid 4666
uptime 3d 1h 22m
cpu total 0.0%
memory 19.4% [776.1 MB]
memory total 19.4% [776.1 MB]
security attribute unconfined
disk read 0 B/s [2.3 GB total]
disk write 0 B/s [17.9 MB total]
data collected Mon, 25 May 2020 11:43:03
how bout corner plot with power signals and oplevs? I think that would show not just linear couplings (like your coherence), but also quadratic couplings (chesire cat grin)
I propose we go for all CAPS for all channel names. The lower case names is just a holdover from Steve/Alan from the 90's. All other systems are all CAPS.
It avoids us having to force them all to UPPER in the scripts and channel lists.
does the FLIR have an option to export image with a colorbar?
How about just leave the lid open? or more open? I don't know what else can be done in the near term. Maybe swap with the SRM sat box to see if that helps?
maybe we should make a "dd" copy of pianosa in case rossa has issues and someone destroys pianosa by accidentally spilling coffee on it.
So, in summary, rossa is now all set up for use during lock acquisition. However, until this machine has undergone a few months of testing, we should freeze the pianosa config and not mess with it.
in the lab, checkin on the WFS
Sun Jul 5 18:25:50 2020
I redid Gautam's measurements to get a baseline before changing the head, and my results are very different: To me it looks like the WFS2 quadrants are all OK.
I've left the setup as is in case either me or Gautam want to double check. If we're agreed on this response, I'll remove the notches and disable the RF attenuators.
Sun Jul 5 21:42:45 2020
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
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
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.
3. I agree - this whitening will be handy to have for diagnostics.
4. I think in principle, we can ask a company to make the custom cables for us to save us some hand labor. Rich/Chub probably know the right companies to do small numbers of dirty cables.
5. Can't we just a single Noliac PZT in the same way that the OMC does? Or is the lead time too long?
6. Do we need active steering for this in-air test? I'm not even sure how we would get the alignment signal, so maybe that's a good reason to figure this out.
that's great. I think we would like to figure out how to present this so that its clear what the distribution of TFs is. Maybe we can plot the most likely curve as well as a shaded region indicating the 5% and 95% values?
I've pushed an MCMC simulation to the A+ BHD repo (filename MCMC_TFs.ipynb). The idea is to show how random offsets around ideal IFO change the noise couplings of different DOFs to readout.
and then we add the loops
No, there should be no unscheduled visits from any inspector, marshal, tech, or vendor. They all have to be escorted or they don't get in. If they have a problem with that, please give them my cell #.
For the ALS, in addition to the beat note spectrum, I think we need to know the loop gain use to feedback to the ETM to determine the true cavity length fluctuation. w/o ALS, the noise would be only due to the seismic noise, OSEM damping noise, and the IR-PDH residual. Those are all suppressed by the ALS loop, but then the ALS loop puts its sensing noise onto the cavity. So, if I'm thinking about this right, the ALS beat noise > 200 Hz doesn't matter so much to the CARM RMS. So the whitening seems to be doing good in the right spot, but we would like to have another boost in the green PDH to up the gain below ~300 Hz?
I lowered the (FAST) PZT gain on the IMC/FSS servo today.
I noticed that the MC locks looked unstable a lot of the day, and during lock the PCDRIVE channel is above 1 Vrms (which means the loop is oscillating, ttypically at the PZT/EOM crossover frequency).
I changed the default setting from 22 to 20 19 dB in the PSL Settings screen so the mcup script will use this for now. Feel free to revert if this turns out to be a Fluke (which you would think is a terrible name for a company, but...)
I set up to do the WFS head modifications today, but I was shot down in flames due to a missing AC/DC adapter.
The Prologix GPIB-ethernet dongle needs +8-13 V to run. Some riff raff has removed the adapter and I was thunderstruck to see that it had not been returned.
I did the usual hunt around the lab looking for something with the right specs and connector. I found one that could do +9V and had the right connector, but it didn't light up the adapter so I put it back in black SP table.
I'll order a couple of these (5 ordered for delivery on Wednesday) in case there's a hot demand for the jack / plug combo that this one has. The setup is in the walkway, but I returned the AS table to the usual state and made sure the IMC is locking well.
My power at home winked out for a second this morning, but it looks like either nothing happened in the 40m lab or else it rode it out.
MC is locked - lost lock around 11:25 AM and then relocked.
since the summary pages are working again, I was clicking through and noticed that there's a wandering peak in the whitened IMC spectrogram that goes from 10-30 Hz over the course of a day.
anyone know what this is ?
that's a very curious disconnection
the "Pentek" whitening board that carries the MC channels has jumpers to enable either 1 or 2 stages of 15:150 whitening. Looks lik MC_F has 2 and MC_L has 1.
I guess the MC_F signal is so low because of the high gain on the FSS board. We could lower the FSS common gain and increase the IMC board's VCO gain to make up for this. Maybe 6 dB would be enough. IF that is risky, we could also up the analog gain on the whitening board.
the seismometers obviously saturated during the EQ, but the accelerometers captured some of it. It looks like there's different saturation levels on different sensors.
Also, it seems the mounting of the MC2 accelerometers is not so good. There's some ~10-20 Hz resonance its mount that's showing up. Either its the MC2 chamber legs or the accelerometers are clamped poorly to the MC2 baseplate.
Sun Sep 20 00:02:36 2020 edit: fixed indexing error in plots
* also assuming that the sensors are correctly calibrated in the front end to 1 count = 1 um/s^2 (this is what's used in the summ pages)
the EQ was ~14 km south of Caltech and 17 km deep
I'm amazed at how much higher the noise is on the MC2 accelerometer. Is that really how much amplification of the ground motion we're getting? If so, its as if the MC has no vibration isolation from the ground in that band. We should put one set on the ground and make the more direct comparison of the spectra. Also, perhaps do some seismic FF using this sensor - I'm not sure how successful we've been in this band.
Attaching the coherence plot from ldvw.ligo.caltech.edu (apparently it has access to the 40m data, so we can use that as an alternative to dtt or python for remote analysis):
It would be interesting to see if we can use the ML based FF technology from this summer's SURF project by Nadia to increase the coherence by including some slow IMC alignment channels.
I think the digital loop in the ALS budget is too optimistic. You have to include all the digital delays and anti-aliasing filters to get the real response.
aslo, I recommend grabbing some of the actual spectra from the in-lock times with nds and using the calibrated spectra as inputs to this mode. Although we don't have good models of the stack, you can sort of infer it by using the calibrated seismometer data and the calibrated MC_F or MC_L channels (for IMC) or XARM/YARM signals for those.
This ALS loop is not stable. Its one of those traps that comes from using only the Bode plot to estimate the loop stability. You have to also look at the time domain response - you can look at my feedback lecture for the SURF students for some functions.
it would be a good idea for us to have an auto-reminder to have us check the flow of all the HEPAs in the lab and elog it once a year so that we can replace filters and pre-filters appropriately.