The seisBLRMS has been running on megatron via an open terminal ssh'd into there from allegra with matlab running. This

is because I couldn't get the compiled matlab functionality to work.

Even so, this running script has been dying lately because of some bogus 'NDS' error. So for today I

have set the NDS server for mDV on megatron to be fb40m:8088 instead of nodus.ligo.caltech.edu. If this seems to fix the problem

I will make this permanent by putting in a case statement to check whether or not the mDV'ing machine is a 40m-martian or not.

The green xterm on op540m which is running the seisBLRMS DMF got stuck somehow ~3 days ago and lost its NDS connection. I closed the matlab session and restarted it. Seismic trends are now back online.

I restarted the seisBLRMS DMF monitor by ssh'ing into mafalda and starting up a matlab session. I also have started a StripTool session on rossa by forwarding the process from op440m.

We need to get the modern EPICS installation onto these linux machines by copying what K. Thorne has done at LLO.

I've changed R2 resistor in the seism box for the VERT 1 channel from 464 Ohm to 1051 Ohm to reduce the gain of this channel by a factor of 2. This should help the GUR1Z signal not to be corrupted inside the AA box, so we can use it in the adaptive filtering.

A few weeks ago I found that GUR2_X signal is biased from 0 to 800 counts in average. I decided that the corresponding channel in the readout box is bad - adds DC voltage to the signal. I stopped using GUR2_XYZ channels of the seism readout box. Now the same thing happened with the GUR1_XYZ channels. I checked the signals coming out from the seism box with the oscilloscope and they were fine. So the problem is not in the readout box. Then I applied 1 V sine wave to the input of AA board to the GUR1_X and ACC_MC1_Z channels. GUR1_X channel still shows noise. Something is wrong with these channels inside the AA board or in the ADC.

Edited by Den: GUR1_XYZ_IN1 signals are empty though GUR1_XYZ are fine. So the problem is just that GUR1_XYZ_IN1 are not acquired for now though some of the ACC_IN1 channels contain the signal. I need to correct .ini files.

 So, none of our PEM BLRMS channels are recorded as of right now.  All we have for long-term record is the StripTool on the wall.  The 0.1-0.3Hz and 0.3-1 Hz traces both show these weirdo things, but the 1Hz and up BLRMS don't have any unusual noise.

 Seems like a problem to solve on Monday so that we don't end up without trends like this again.

 Tragically, this is more tricksy than I would have thought. The channels we need are "cdsEpicsOutput"s in the model.  They don't show up in Dataviewer (fast or slow channels) or the regular fast channel .ini file.  Jamie and I don't remember where these channels live and how to get them saved to frames.  I'm on top of it though.

I did notice however, that the striptool for seismic trends is showing the wrong channels for 3-10 and 10-30 Hz.  The other 3 channels are correctly the output after the sqrt is taken, but those two (orange and red on striptool) are before the sqrt, but after the bandpass and low pass.  I'll fix that now...

I reported the procedure to add slow channels to the FB. I guess you already have done Step.1

http://nodus.ligo.caltech.edu:8080/40m/5991

Our only seismometer is at the east end now.

Atm1, Ditch Day morning puzzle. The gardener came after the freshman did leave and cut the grass with the lawn mower.

Atm2, Yesterday afternoon the Aztecs containers moved out.

The earth quake shook ITMX free for a  short while.

Salton See is shaking again.

I tried to figure out where additional (to seismic) noise enters to MC_F, so the coherence below 1 Hz is low (~0.2-0.5). I've examined noise in the path

PD -> DEMOD -> MC BOARD -> FSS -> PZT Controller -> LASER

• I terminated ADC and measured its noise
• connected MC BOARD OUT to ADC, terminated INPUT1 of the MC BOARD and measured noise
• connected DEMOD Q OUT to MC BOARD INPUT1, terminated PD INPUT on the DEMODULATOR and measured noise
• connected PD to DEMOD, blocked the beam incident to the PD and measured noise

 MC BOARD noise shows up only below 0.1 Hz and at 10 Hz where the whitening filter starts to work. SNR is ~2 at 4 Hz, so we might want to slightly improve whitening filter. But other then that path PD->DEMOD->MC BOARD is not responsible for additional noises below 1 Hz.

Next I connected SR785 to the laser and measured the closed loop feedback signal while MC was locked.

Coherence between MC BOARD OUT1 and feedback signal is high enough to assume that FSS and PZT controller are also not responsible for additional noise.

From the other hand MC2 SUSPOS measured by OSEMS shows good coherence with GUR1_X

That means that MC2 is indeed driven by seismic motion. In order to figure out if this is the case for MC1 and MC3, I rotated GUR2 by 45 degrees. When it will calm down, I'll measure coherence between OSEMs and seismic motion.

I locked x,y arms and measured coherence between POS{X,Y}11_I_ERR, MC_F and seismometer signals.

Surprisingly, coherence between POSY and GUR1Y is low, but with GUR1X is relatively high. I wonder if this is due to MC that brings this x-axis noise to the arms.

The shaking has stopped at 9:32am  The AC was turned back on at 11:30am  We still do not have any explanation

 Kiwamu and Steve maybe don't know about how to trend seismic noise. If you just take the mean of the time series, you don't prove that the seismic noise got any higher. The STS has a nominally zero DC output, so the long period level shifts that you see tell you just that there was a DC offset.

This is NOT an increase in seismic noise. To see a seismic trend you should plot the trend of the BLRMS channels that we made especially for this purpose.

[Micro, Den]

Analyzing coherence of seismic noise and mode cleaner length we've figured out that at some days the coherence below 1 Hz is still present. For example, at Nov 13 we can see some coherence compared to most other dates when we are not able to see coherence as shown on the figure. On the top plot - psd of MC_L and GUR1_X at Nov 13 (red and blue) and Nov 15 (black and cyan). On the bottom plot is presented coherence between MC_L and GUR1_X on Nov 13 (red) and Nov 15 (black)

We can divide the psd plot for 2 parts - below 1 Hz and above 1 Hz. Above 1 Hz seismic noise on Nov 15 (cyan) was higher then on Nov 13 (blue) and correspondently MC_L at that region was higher on Nov 15. Below 1 Hz seismic noise was higher on Nov 13 but MC_L is still lower that on Nov 15. That is surprising. From the coherence plot we can say that once we have some more seismic noise than usually, we immediately see coherence.

Because of this we wanted to find out the level of the X noise that makes seismic noise invisible. We injected seismic noise by doing smooth physical exercises near MC_2 (1.5 m and 3 m apart). The MC_2 was in lock during the experiment.

In the coherence plot we can see that coherence between GUR1_X and MC_L increased with noise injection. The highest coherenced we obtained sittind down and standing up smoothly near MC_2 at distance 1.5 m. We did not want to come clother and break the lock. This measurement tells us that the X noise is approximately 3-4 times higher than seismic noise in the range 0.1 - 1 Hz. That means that it is approximately 1e-6 - 1e-8 m/sqrt(Hz) in this region. This noise goes down at frequencies from 2 Hz and not seen because of seismic noise. Actually, seismic noise can be filtered out with the Wiener filter and then we'll see the spectrum of X noise.

We now try to figure out the method to estimate the contribution of OSEM noise to the X noise.

There is still a problem why GUR, STS signals are poorly coherent to MC_L.  But at least we can see coherence at 2-5 Hz. It might be useful to do something with adaptive filtering because it does not work at all for a long time. We start with Wiener filtering. I still doubt that static filtering is useful. Adaptive filter output is linear to its coefficients, so why not to provide adaptive filter with a zero approximation equal to calculated Wiener filter coefficients. Then you automatically have Wiener filter ouput + adaptively control coefficients. But if Wiener filter is already present in the model, I tried to make it work. Then we can compare performance of the OAF with static filter and without it.

I started with GUR1_X and MC_F signals recorded 1 month ago to figure out how stable TF is. Will the same coefficients work now online? In the plot below offline Wiener filtering is presented.

This offline filtering was done with 7500 coefficients. This FIR filter was converted to IIR filter with the following procedure:

1. Calculate frequency responce of the filter. It is presented below.

2. Multiply this frequency response by a window function. This we need because we are interested in frequencies 0.1-20 Hz at this moment. We want this function to be > 1e-3 at ~0Hz, so that the DC component is filtered out from seismometer signal. From the other hand we also do not want huge signal at high frequenies. We know that this signal will be filtered with aggresive low-pass filterd before going to the actuator but still we want to make sure that this signal is not very big to be filtered out by the low-pass filter.

The window function is done in the way to be a differential function to be easier fitted by the vectfit3. Function is equal to 1 for 0.5 - 20 Hz and 1e-5 for other frequencies except neighbouring to the 0.5 and 20 where the function is cosine.

3. I've used vectfit3 software to approximate the product of the frequency response of the filter and window fucntion with the rational function. I've used 10 complex conjugate poles. The function was weighted in the way to make deviation as small as possible for interesting frequencies 0.5 - 10 Hz. The approximation error is big below 20 Hz where the window function is 1e-5 but at least obtained rational function does not increase as real function do at high frequencies.

I tried to make a foton filter out of this approximation but it turns out that this filter is too large for it. Probably there is other problem with this approximation but once I've split the filter into 2 separate filters foton saved it. Wiener21 and Wiener22 filters are in the C1OAF.txt STATIC_STATMTX_8_8 model.

I've tested how the function was approximated. For this purpose I've downloaded GUR and MC_F signals and filtered GUR singla with rational approximation of the Wiener filter frequency response. From power spectral density and coherence plots presented below we can say that approximation is reasonable.

Next, I've approximated the actuator TF and inverted it. If TF measured in p. 5900 is correct then below presented its  rational approximation. We can see deviation at high frequencies - that's because I used small weights there using approximation - anyway this will not pass through 28 Hz low-pass filter before the actuator.

I've inverted this TF p->z , z->p, k->1/k. I've also added "-" sign before 1/k because we subtract the signal, not add it. I placed this filter 0.5Actuator20 to the C1OAF.txt SUS-MC2_OUT filter bank.

The next plot compares online measured MC_L without static filtering and with it. Blue line - with online Wiener filtering, red line - without Wiener filtering.

We can see some subtraction in the MC_L due to the static Wiener filtering in the 2-5 Hz where we see coherence. It is not that good as offline but the effect is still present. Probably, we should measure the actuator TF more precisely. It seems that there some phase problems during the subtraction. Or may be digital noise is corrupting the signal. 

I made a model for our seismometer can using actual data so that we know approximately what the time constant should be when we test it out. I used the appendix in Megan Kelley's report to make a relation for the temperature in terms of time.

 so  and 

In our case, we will heat the can to a certain temerature and wait for it to cool on its own so 

We know that  where k is the k-factor of the insulation we are using, A is the area of the surface through which heat is flowing,  is the change in temperature, d is the thickness of the insulation.

Therefore,

We can take the derivative of this to get

, or  

We can guess the solution to be

 where tau is the time constant, which we would like to find.

The boundary conditions are  and . I assumed we would heat up the can to 40 celcius while the room temp is about 24. Plugging this into our equations,

, so 

We can plug everything back into the derivative T'(t)

Equating the exponential terms on both sides, we can solve for tau

Plugging in the values that we have, m = 12.2 kg, c = 500 J/kg*k (stainless steel), d = 0.1 m, k = 0.26 W/(m^2*K), A = 2 m^2, we get that the time constant is 0.326hr. I have attached the plot that I made using these values. I would expect to see something similar to this when I actually do the test.

To set up the experiment, I removed the can (with Steve's help) and will place a few heating pads on the outside and wrap the whole thing in a few layers of insulation to make the total thickness 0.1m. Then, we will attach the heaters to a DC source and heat the can up to 40 celcius. We will wait for it to cool on its own and monitor the temperature to create a plot and find the experimental time constant. Later, we can use the heatng circuit we used for the PSL lab and modify the parts as needed to drive a few amps through the circuit. I calculated that we'd need about 6A to get the can to 50 celcius using the setup we used previously, but we could drive a smaller current by using a higher heater resistance.

I performed a test with the can last week with one layer of insulation to see how well it worked. First, I soldered two heaters together in series so that the total resistance was 48.6 ohms. I placed the heaters on the sides of the can and secured them. Then I wrapped the sides and top of the can in insulation and sealed the edges with tape, only leavng the handles open. I didn't insulate the bottom. I connected the two ends of the heater directly into the DC source and drove the current as high as possible (around 0.6A). I let the can heat up to a final value of 37.5C, turned off the current and manually measured the temperature, recoding the time every half degree. I then plotted the results, along with a fit. The intersection of the red line with the data marks the time constant and the temperature at which we get the time constant. This came out to be about 1.6 hours, much longer than expected considering that onle one layer instead of four was used. With only one layer, we would expect the time constant to be about 13 min, while for 4 layers it should be 53 min (the area A is 0.74 m^2 and not 2 m^2).

Updated some values, most importantly, the k-factor. I had assumed that it was in the correct units already, but when converting it to 0.046 W/(m^2*K) from 0.26 BTU/(h*ft^2*F), I got the following plot. The time constant is still a bit larger than what we'd expect, but it's much better with these adjustments.

For our next steps, I will measure the time constant of the heater without any insulation and then decide how many layers of it we will need. I'll need to construct and calibrate a temperature sensor like the ones I've made before and use it to record the values more accurately.

For the insulation, I have decided to use this one (Buna-N/PVC Foam Insulation Sheets). We will need 3 of the 1 inch plain backing ones (9349K4) to wrap a few layers around it. I'll try two layers for now, since the insulation seems to be doing quite well according to initial testing.

I've ordered 4 of these from McMaster. Should be delivered to the 40m by noon tomorrow.

Kira and I also discussed the issiue. It would be good if someone can hunt aroun on the web and get some free samples of non-shedding foam with R~4.

Steve, the pictures you posted are not the AA board I was referring to. The attached pictures show the board which is sitting beneath the GPS time server.

 We got granite bases today from the manufacturer. We plan to set them up on Wednesday, 8 am. Please note, there will be an installation mess at Xend, Yend and corner during ~4 hours. Let us know if you have any objections to do this at this particular time.

Installation locations are specified in elog 8270, scheme attached is valid except for Xend. Instrument will be installed on the place of nitrogen containers.

(  next to the wall at corner sout-east of the south end )

 The carpenter shop finished the installation of the 3 granite bases.Rapid Set Cement All high strength non-shrink grout was used.

 Compressive strength  3000 PSI at 1 hour and 9000 PSI at day 28 The janitor is still cleaning up after them at the south end.

The  soft silicon gas kits are working well with the SS can.  Den is making  the adaptor plate drawing for the feedthrough.

 To put everything in one place I add a final drawing of the base to this elog.

 Next time we continue with wiring and putting temperature and pressure sensors inside the box. Connector support plate drawing is attached. We'll have sensors inside the kit with STS-2 or Trillium as their connector is small enough (19 pin vs 26 pin for Guralps) that we can put an additional 4 pin lemo connecor (2 pins for each sensor). I think EGG.0B.304.CLL is good for this application. Temperature and pressure sensor we can by from omega.

STS-2 - end of X arm

GUR 2 - isolation box

TRILLIUM - 1Y3 (DC power supply uses 1Y3 AC power, please do not close the door completely)

GUR 1 - end of Y arm

Now we have several "triangular seismic antennas". Different configurations can be chosen to compare the results.

 Looking at the PEM BLRMS, I noticed that the GUR1Z channel had a much reduced microseism compared to the GUR1X. Looking at the BLRMS screens everything seems ON, although its a mess (too many filters in the banks, etc. - clean this up, PEM people).

 Looking at the Z channel in DTT, I see that the Z spectra looks double high pass filtered below ~1 Hz.     Needs some attention in the daytime.

From Den and Ayaka's elog entry from Nov 29, its clear that this problem is there at that time. It seems that the seismometer was not even hooked up before then. Perhaps Tara returned the seismometer around Thanksgiving and then someone here hooked it up but neglected to log this work? If so, please make an elog now describing the installation of this sensor at the 40m and log any future work which takes place at the 40m lab even if you think it is inconsequential.

 Yesterday I wanted to recenter Guralps. I turned them off, understood that would be able to center them because we do not have power cable to Guralp box from Tara yet and turned them back on.

I've switched Guralp cables and spectrums are fine now.

Steve for Nancy,

Seismometer interface box ac power was turned off, Guralps disconnected and moved. Ranger locked, moved and released. Nancy will describe the rest soon.

The flattened lead balls were checked for their heights by the calliper, and were all in the range of 9.50 to 9.70 mm.

The rechecking was done by using these balls between two aluminium plates and checking their levelling. When confirmed this, we proceeded to install the balls(no more balls :P ) in their place.

The Guralps were switched off by switching off the power supply to them. The ranger mass was clamped in order to be able to move it. This can be undone by rotating the transport screw counter-clockwise.

We installed the flattened lead ballsin the space made for them. The granite was then placed on it with the help of many other people in the lab.  It was lowered by hanging it on two straps held by people , and then placed in the space marked for it.

Did we then turn on the seismometers? Did we release the locking screw on the Ranger? What happened to Bat-Boy??? Since they make a good mystery I will choose to leave them out of my elog entry.

 At ~2350 UTC on June 2, the seismometers were turned off. After the granite slab was repositioned with the new lead, the Ranger was turned on, but not the Guralps.

Now, after ~24 hours, I have put the Guralps onto the granite and turned them on. During this off time, the input channels should be ADC noise limited (or perhaps limited by the INA134 differential receiver chips inside of the Sander Liu AA chassis). The following plot shows that this noise level is ~0.8 uV/rHz and then rising like ~1/sqrt(f) below 5 Hz:

I checked the slab again by whacking it. It still rings with a Q of several, so I think we need to make the lead flatter. There should barely be any room between the granite and the linoleum.

UPDATE:

I guessed that it should be possible to make the slab-to-floor coupling better with flatter lead (Brian Lantz suggested to use lead sheets). So I removed my booties and jumped up and down on the granite several times. Because of my soft sole shoes, I was able to make an impulsive impact without shattering the granite. The effect of the stomping was pretty dramatic - the horizontal resonance frequency has gone up by a factor of 2. The red trace shows the new TF after the stomping:

 And the resulting spectrum is here too. As you can see, there is no excess between the Ranger and the Guralps until ~50 Hz where the mechanical resonance in the short direction (non-MC dir) takes over.

 So, the lesson for next time is to flatten the balls a little more. I leave it to Nancy to calculate the horizontal resonant frequencies of this lead/granite combo to see if it matches with our measurements.

For the huddle test, I have updated the code to divide the residual by sqrt(2) because of the assumption of equal noise from the 2 Guralps. We would have to multiply this trace by sqrt(2) to compare with the previous results.

Now the question is, how do I add a low noise ~50 mV offset to the front of the Guralp breakout box to test for the noise of the box?

Atm1,  I'm not sure about the seismic data.   Baja earthquake magnitude 3.0 at  yesterday morning.Seismometers do not see them !

Atm2,  No posted seismic activity.  Someone is jump walking in the lab? Why are there time delays between the suspensions?

Pizza mail didn't go out last weekend - looking at logfile, it seems like the "sendmail" service was missing. I installed sendmail following the instructions here: https://tecadmin.net/install-sendmail-server-on-centos-rhel-server/

Except that to start the sendmail service, I used systemctl and not init.d. i.e. I ran systemctl start sendmail.service (as root). Test email to myself works. Let's see if it works this weekend. Of course this isn't so critical, more important are the maintenance emails that may need to go out (e.g. disk usage alert on chiara / N2 pressure check, which looks like nodus' responsibilities). 

An email has come at 5PM on Dec 3rd.

Since the recent filesystem fracas, the new accounts could not be created on nodus / dokuwiki (for the controls workshop, for example).

I started sendmail on nodus using the command:   sudo /etc/init.d/sendmail start

and the SwiftMail plugin on there is now sending out the confirmation emails again. This will happen each time we reboot nodus, so let's replace it.

I'm having trouble getting the sendmail service going on nodus since the Christmas day power failure - for some reason, it seems like the mail server that sendmail uses to send out emails on nodus (mx1.caltech.iphmx.com, IP=68.232.148.132) is on a blacklist! Not sure how exactly to go about remedying this.

Running sudo systemctl status sendmail.service -l also shows a bunch of suspicious lines:

Why is nodus attempting to email umakant.rapol@iiserpune.ac.in?

I personally don't like the idea of having sendmail (or something similar like postfix) on a personal server as it requires a lot of maintenance cost (like security update, configuration, etc). If we can use external mail service (like gmail) via gmail API on python, that would easy our worry, I thought.

Okay I will port awade's python mailer stuff for this purpose.

gautam 14Jan2018 1730: Python mailer has been implemented: see here for the files. On shared drive, the files are at /opt/rtcds/caltech/c1/scripts/general/pizza/pythonMailer/

gautam 11Feb2018 1730: The python mailer had never once worked successfully in automatically sending the message. I realized this may be because I had put the script on the root user's crontab, but had setup the authentication keyring with the password for the mailer on the controls user. So I have now setup a controls user crontab, which for now just runs the pizza mailing. let's see if this works next Sunday...

I think sendmail is required on nodus since that's how the dokuwiki works. That's why the dokuwiki was trying to send an email to Umakant.

I know it, and I don't like it. DokuWiki seems to allow us to use an external server for notification emails. That would be the way to go.

I am now measuring the sensing matrix in the DRMI configuration.

A goal of tonight is to measure the sensing matrix as a test of the script.

The result will be updated later.