40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 330 of 346 Not logged in
 New entries since: Wed Dec 31 16:00:00 1969
ID Date Author Type Category Subject
6871   Mon Jun 25 17:48:27 2012 yutaUpdateComputer Scripts / Programsscript for finding IR resonance using ALS

I made a python script for finding IR resonance using ALS. It currently lives in /opt/rtcds/caltech/c1/scripts/ALS/findIRresonance.py.

The basic algorism is as follows.

1. Scan the arm by putting an offset to the phase output of the phase tracker(Step C1:ALS-BEAT(X|Y)_FINE_OFFSET_OFFSET by 10 deg with 3 sec ramp time).

2. Fetch TR(X|Y) and OFFSET online data using pyNDS during the step.

3. If it finds a tall peak, sets OFFSET to the value where the tall peak was found.

4. If tall peak wasn't found, go back to 1 and step OFFSET again.

The time series data of how he did is plotted below.
I ran the script for Y arm, but it is compatible for both X and Y arm.

5074   Sun Jul 31 00:05:52 2011 kiwamuUpdateLSCscript for loss measurement : modified

I modified the script armloss so that the channel names in the script are properly adopted to the new CDS.

Additionally I disabled the ETMX(Y)_tickle command in the script.

The tickle command puts some offsets on the LSC signal to let the arms pass through a fringe until it gets locked, but apparently we don't need it because the arms are loud enough.

A brief check showed that the script ran fine.

I will measure the loss on the X and Y arm cavity tomorrow.

 Quote from #5067 Next : Health-check for the X arm ASS, the loss measurements.

6726   Thu May 31 02:27:24 2012 yutaUpdateIOOscript for reliefing MC WFS

I wrote a simple script for reliefing MC WFS servo. The script is located at /opt/rtcds/caltech/c1/scripts/MC/reliefMCWFS.
It simply uses ezcaservo to minimize the offset of the WFS feedback signal using MC alignment sliders.

    ezcaservo -r C1:SUS-MC${optic}_ASC${dof}_OUT16 -s 0 -g 0.0001 -t 10 C1:SUS-MC${optic}_${dof}_COMM


I put "MC WFS relief" button on the WFS medm screen (/opt/rtcds/caltech/c1/medm/c1ioo/master/C1IOO_WFS_MASTER.adl).

4221   Fri Jan 28 13:05:56 2011 KojiConfigurationComputersscript path fixed

We had some issues in terms of the script paths. I have fixed it by replacing /cvs/cds/caltech/scripts to /cvs/cds/rtcds/caltech/c1/scripts

Here is the output of diff

----------------------------------------------

 rossa:caltech>diff cshrc.40m cshrc.40m.20110128 44,47c44,45 < # OBSOLETE set path = ($path /cvs/cds/caltech/scripts/general) < # OBSOLETE set path = ($path /cvs/cds/caltech/scripts/general/netgpibdata) < set path = ($path /cvs/cds/rtcds/caltech/c1/scripts/general) < set path = ($path /cvs/cds/rtcds/caltech/c1/scripts/general/netgpibdata) --- > set path = ($path /cvs/cds/caltech/scripts/general) > set path = ($path /cvs/cds/caltech/scripts/general/netgpibdata) 50,51c48 < # OBSOLETE setenv PERL5LIB /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/perlmodules:/cvs/cds/caltech/libs/solaris9/usr_local_lib/perl5/5.8.0/:/cvs/cds/rtcds/caltech/c1/scripts/general:/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules < setenv PERL5LIB /cvs/cds/caltech/libs/solaris9/usr_local_lib/perl5/5.8.0/:/cvs/cds/rtcds/caltech/c1/scripts/general:/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules --- > setenv PERL5LIB /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/perlmodules:/cvs/cds/caltech/libs/solaris9/usr_local_lib/perl5/5.8.0/:/cvs/cds/rtcds/caltech/c1/scripts/general:/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules 61,64c58,59 < #OBSOLETE setenv PATH ${SOLARISPATH}/bin:$GDSPATH/bin:$ROOTSYS/bin:$TDSPATH/bin:/cvs/cds/caltech/scripts/general/netgpibdata:$PATH < setenv PATH${SOLARISPATH}/bin:$GDSPATH/bin:$ROOTSYS/bin:$TDSPATH/bin:/cvs/cds/rtcds/caltech/c1/scripts/general/netgpibdata:$PATH < #OBSOLETE setenv SCRIPTS /cvs/cds/caltech/scripts < setenv SCRIPTS /cvs/cds/rtcds/caltech/c1/scripts --- > setenv PATH ${SOLARISPATH}/bin:$GDSPATH/bin:$ROOTSYS/bin:$TDSPATH/bin:/cvs/cds/caltech/scripts/general/netgpibdata:PATH > setenv SCRIPTS /cvs/cds/caltech/scripts 87,88c82 < #OBSOLETE setenv PERL5LIB /cvs/cds/caltech/scripts/general:/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules < setenv PERL5LIB /cvs/cds/rtcds/caltech/c1/scripts/general:/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules --- > setenv PERL5LIB /cvs/cds/caltech/scripts/general:/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules 99,100c93 < #OBSOLETE setenv SCRIPTPATH /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/netgpibdata < setenv SCRIPTPATH /cvs/cds/rtcds/caltech/c1/scripts/general:/cvs/cds/rtcds/caltech/scripts/general/netgpibdata --- > setenv SCRIPTPATH /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/netgpibdata 103,104c96 < #OBSOLETE setenv SCRIPTS /cvs/cds/caltech/scripts < setenv SCRIPTS /cvs/cds/rtcds/caltech/c1/scripts --- > setenv SCRIPTS /cvs/cds/caltech/scripts 135,137c127 < #OBSOLETE alias listenDARM '/cvs/cds/caltech/scripts/c1/listenDARM' < alias listenDARM '/cvs/cds/rtcds/caltech/c1/scripts/c1/listenDARM' < --- > alias listenDARM '/cvs/cds/caltech/scripts/c1/listenDARM' 156,157c146 < #OBSOLETE setenv PERL5LIB /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/perlmodules < setenv PERL5LIB /cvs/cds/rtcds/caltech/c1/scripts/general:/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules --- > setenv PERL5LIB /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/perlmodules 167,168c156 < #OBSOLETE setenv SCRIPTPATH /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/netgpibdata < setenv SCRIPTPATH /cvs/cds/rtcds/caltech/c1/scripts/general:/cvs/cds/rtcds/caltech/scripts/general/netgpibdata --- > setenv SCRIPTPATH /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/netgpibdata 172,173c160 < #OBSOLETE setenv SCRIPTS /cvs/cds/caltech/scripts < setenv SCRIPTS /cvs/cds/rtcds/caltech/c1/scripts --- > setenv SCRIPTS /cvs/cds/caltech/scripts 198,199c185 < #OBSOLETE alias listenDARM '/cvs/cds/caltech/scripts/c1/listenDARM' < alias listenDARM '/cvs/cds/rtcds/caltech/c1/scripts/c1/listenDARM' --- > alias listenDARM '/cvs/cds/caltech/scripts/c1/listenDARM' 288,295c274,277 < #OBSOLETE alias makefiltscreen '/cvs/cds/caltech/scripts/Admin/makeFilterScreen.pl' < #OBSOLETE alias makelockinscreen '/cvs/cds/caltech/scripts/Admin/makeLockInScreen.pl' < #OBSOLETE alias f_and_r '/cvs/cds/caltech/scripts/Admin/find_and_replace.pl' < #OBSOLETE alias plotrgascan '/cvs/cds/caltech/scripts/RGA/plotrgascan' < alias makefiltscreen '/cvs/cds/rtcds/caltech/c1/scripts/Admin/makeFilterScreen.pl' < alias makelockinscreen '/cvs/cds/rtcds/caltech/c1/scripts/Admin/makeLockInScreen.pl' < alias f_and_r '/cvs/cds/rtcds/caltech/c1/scripts/Admin/find_and_replace.pl' < alias plotrgascan '/cvs/cds/rtcds/caltech/c1/scripts/RGA/plotrgascan' --- > alias makefiltscreen '/cvs/cds/caltech/scripts/Admin/makeFilterScreen.pl' > alias makelockinscreen '/cvs/cds/caltech/scripts/Admin/makeLockInScreen.pl' > alias f_and_r '/cvs/cds/caltech/scripts/Admin/find_and_replace.pl' > alias plotrgascan '/cvs/cds/caltech/scripts/RGA/plotrgascan' 10816 Thu Dec 18 16:21:08 2014 ericqUpdateComputer Scripts / Programsscripts not being backed up! I just stumbled upon this while poking around: Since the great crash of June 2014, the scripts backup script has not been workingon op340m. For some reason, it's only grabbing the PRFPMI folder, and nothing else. Megatron seems to be able to run it. I've moved the job to megatron's crontab for now. 2344 Sun Nov 29 16:56:56 2009 robAoGall down cond.sea of red Came in, found all front-ends down. Keyed a bunch of crates, no luck: Requesting coeff update at 0x40f220 w/size of 0x1e44 No response from EPICS  Powered off/restarted c1dcuepics. Still no luck. Powered off megatron. Success! Ok, maybe it wasn't megatron. I also did c1susvme1 and c1susvme2 at this time. BURT restored to Nov 26, 8:00am But everything is still red on the C0_DAQ_RFMNETWORK.adl screen, even though the front-ends are running and synced with the LSC. I think this means the framebuilder or the DAQ controller is the one in trouble--I keyed the crates with DAQCTRL and DAQAWG a couple of times, with no luck, so it's probably fb40m. I'm leaving it this way--we can deal with it tomorrow. 2345 Mon Nov 30 10:28:47 2009 AlbertoAoGall down cond.sea of red  Quote: Came in, found all front-ends down. Keyed a bunch of crates, no luck: Requesting coeff update at 0x40f220 w/size of 0x1e44 No response from EPICS  Powered off/restarted c1dcuepics. Still no luck. Powered off megatron. Success! Ok, maybe it wasn't megatron. I also did c1susvme1 and c1susvme2 at this time. BURT restored to Nov 26, 8:00am But everything is still red on the C0_DAQ_RFMNETWORK.adl screen, even though the front-ends are running and synced with the LSC. I think this means the framebuilder or the DAQ controller is the one in trouble--I keyed the crates with DAQCTRL and DAQAWG a couple of times, with no luck, so it's probably fb40m. I'm leaving it this way--we can deal with it tomorrow. I found the red sea when I came in this morning. I tried several things. 1. ssh into fb40m: connection refused 2. telnet fb40m 8087: didn't respond 3. shutdown fb40m by physically pushing the power button: it worked and the FB came back to life but still with a red light on the MEDM DAQ_DETAIL screen; 4. powercycled fb40m AND C0DAQCTRL: no improvement 5. shutdown fb40m, C0DAQCTRL, C1DCUEPICS and pushed the reset button on the RF network crate; then I restarted the computers in this order: fb40m, C1DCUEPICS, C0DAQCTRL: it worked: they came back to life and the lights eventually turned green on the MEDM montior screen I'm now going to restart the single front -ends and burtgooey them if necessary. 2346 Mon Nov 30 11:29:40 2009 AlbertoAoGall down cond.sea of red Quote:  Quote: Came in, found all front-ends down. Keyed a bunch of crates, no luck: Requesting coeff update at 0x40f220 w/size of 0x1e44 No response from EPICS  Powered off/restarted c1dcuepics. Still no luck. Powered off megatron. Success! Ok, maybe it wasn't megatron. I also did c1susvme1 and c1susvme2 at this time. BURT restored to Nov 26, 8:00am But everything is still red on the C0_DAQ_RFMNETWORK.adl screen, even though the front-ends are running and synced with the LSC. I think this means the framebuilder or the DAQ controller is the one in trouble--I keyed the crates with DAQCTRL and DAQAWG a couple of times, with no luck, so it's probably fb40m. I'm leaving it this way--we can deal with it tomorrow. I found the red sea when I came in this morning. I tried several things. 1. ssh into fb40m: connection refused 2. telnet fb40m 8087: didn't respond 3. shutdown fb40m by physically pushing the power button: it worked and the FB came back to life but still with a red light on the MEDM DAQ_DETAIL screen; 4. powercycled fb40m AND C0DAQCTRL: no improvement 5. shutdown fb40m, C0DAQCTRL, C1DCUEPICS and pushed the reset button on the RF network crate; then I restarted the computers in this order: fb40m, C1DCUEPICS, C0DAQCTRL: it worked: they came back to life and the lights eventually turned green on the MEDM montior screen I'm now going to restart the single front -ends and burtgooey them if necessary. Everything is back on. Restarted all the front ends. As usual c1susvme2 was stubborn but eventually it came up. I burt-restored all the front-ends to Nov 26 at 8am. The mode cleaner is locked. 2355 Sat Dec 5 14:41:07 2009 robAoGall down cond.sea of red, again Taking a cue from entry 2346, I immediately went for the nuclear option and powered off fb40m. Someone will probably need to restart the backup script. 2356 Sat Dec 5 15:20:10 2009 JenneAoGall down cond.sea of red, again  Quote: Taking a cue from entry 2346, I immediately went for the nuclear option and powered off fb40m. Someone will probably need to restart the backup script. Backup script restarted. 3970 Mon Nov 22 20:31:58 2010 kiwamuUpdateGreen Lockingsearching for unknown loss in green PD path As I said in the past entry (see this entry), there was unknown loss of about 20dB in the beat detection path. So I started fully characterizing the beat detection path. Today I measured the frequency response of the wideband RFPD using the Jenne Laser. Since all the data were taken by using a 1064nm laser, the absolute magnitudes [V/W] for 532nm are not calibrated yet. I will calibrate the absolute values with a green laser which has a known power. The data were taken by changing the bias voltage from -150V to 0V. The shape of the transfer function looks quite similar to that Hartmut measured before (see the entry). It has 100MHz bandwidth when the bias voltage is -150V, which is our normal operation point. Theoretically the transfer function must keep flat at lower frequency down to DC. Therefore for the calibration of this data, we can use the DC signal when a green beam with a known power is illuminating the PD. 6328 Mon Feb 27 21:26:22 2012 DenUpdatePEMseis box I did liso simulation of the circuit in the seis box. I think that AD620 (first amplifier in the circuit) noise might be much less with the signal from guralps from 0.01 Hz. Here is the TF of AD620 output / circuit input. The noise spectrum is at this node is The psd of the seismic noise below 1 Hz ~ 1u m/s => circuit input signal is ~1mv. The TF of the whole circuit is This result differs from the graph on the circuit sheet, but may be it was done before the resistor parameteres changed. Back of the envelop calculations also show that it is not possible to acheive DC gain 200 while 50-800 Hz gain = 5000. I'll check with the spectrum analyzer. AD620 might be a weak point in the simulation since this is not a "classical" operational amplifier, it contains a resistor that adjusts the gain. During the liso simulation I assumed that we have an ordinary opamp (with noise, gain and gbw parameters taken from the real ad620 datasheet) with a resistor parallel to the opamp = 50k and a resistor before the inverted input that corrsponds to R2. In this case the gain of the simulated opamp is the same as of the real one given by the formula 1 + 49.9k / R2, though noise parameters may change. This should be also checked with the spectrum analyzer. 6349 Fri Mar 2 18:55:06 2012 DenUpdatePEMseis box I've put the seismometer box back to the 1x1, Guralp is back under MC2. When the seismometer is not plugged in, the noise is Now, I'm going to collect some data from GUR 1 and MC_F and see if the problem with adaptive filter (increasing errror while decreasing mu) will be gone. 6346 Fri Mar 2 11:05:28 2012 DenUpdatePEMseis box gain I've replaced R2 resistor that adjusts the gain of the AD620 amplifier. Previous value 5491Ohm, new value 464Ohm, so the gain should increase up to ~200-250. Only at the N/S 1 circuit! LISO simulation of the circuit transfer function and noise are LISO predicts gain ~45-46 dB = 200 and noise at the level of 10uV at 1Hz. The transfer function and noise measured are The noise measured is 5 times higher then predicted by LISO. Though I described AD620 as an ordinary amplifier with 49.9kOhm resistor connecting output and inverted input. I specified the noise spectrum 10 nV and 1/f corner frequency 30 Hz. In the AD620 datasheet noise spectrum is 10 - 100 nV depending on the gain. However, the gain is 200 and noise spectrum should be 10 nV. May be in reality it is not the case. It also possible that the noise model used by LISO is not valid for AD620 as it is not an ordinary operational amplifier. 6338 Wed Feb 29 01:02:06 2012 DenUpdatePEMseis box measured I've measured the input signal to the seismic box from seismometer Guralp 1. The spectrum of the signal in the "input +" (TP 1) is The spectrum below 1 Hz is ~250 uV/sqrt(Hz). As the input is differential, then the input voltage is 0.5 mV/sqrt(Hz). The spectrum of the "output +" signal (TP 2) is So the gain at ~ 1Hz is ~20. I've measured the transfer function between the "input +" and "output +" (TP1 and TP2) for all 9 circuits The channels 1-6 are of new modification and have gain ~20 at the frequencies 0.2 - 100 Hz. Below 0.2 Hz the gain is reduced. 100 Hz - cut off frequency of the low-pass filters. Meanwhile channels 7-9 (old configuration) have much more gain and 10_50 Hz filters work here. The coherence between "input +" and "output +" (TP1 and TP2) for 9 circuits is We can see that channel VERT 3 is very bad. For others coherence is lost below 0.2 Hz. The spectrum analyzer noise measured is ~1000 times less then the signal at these frequencies. I'll pay more attention to this loss of coherence at low frequencies. Something is noisy. 6343 Thu Mar 1 00:05:23 2012 DenUpdatePEMseis box noise I've moved GUR1 seismometer from MC2 to the working tables in order not to disturb the MC while working with the seismometer box. The new place for the GUR1 for a few days is near the printer, cables and blue boxes. I've cleaned all mess and wires from the floor, so that seismometer now looks like that I've connected 2 inputs of the N/S 1 circuit of the seismometer box with a 50 Ohm resistor and measured the noise at the output. The comparison with the seismic signal is The noise increased at 0.5 Hz and is pretty big. This might explain the loose of coherence at low frequencies. 6345 Thu Mar 1 21:48:34 2012 DenUpdatePEMseis box noise  Quote: The noise increased at 0.5 Hz and is pretty big. This might explain the loose of coherence at low frequencies. This is because spectrum analyzer did not plot the real noise spectrum at the first few points at low frequencies. I've remeasured the noise at 1mHz - 3Hz at "output -" (TP9) and compared it to the seismometer signal The noise seems to be much less then the signal. I've measured the noise several times and once I got a huge amount of noise I made another measurement in some time and got the low noise again. A circuit might have a bad contact somewhere. The plan is to change AD620 adjustable resistor (R2) from 5.49kOhm to 500Ohm to increase the gain from 20 up to 200. 287 Wed Jan 30 20:39:31 2008 robUpdateDMFseisBLRMS In order to reduce the probability of seisBLRMS crashing due to unavailability of data, I edited seisBLRMS.m so that it displays data from 6 minutes in the past, rather than 3. After compiling, this version ran for ~8 hours without crashing. I've killed the process now because it seems to interfere with alignment scripts that use ezcademod, causing "DATA RECEIVING ERROR 4608" messages. These don't cause ezcademod to crash, but so many of them are spit out that the scripts don't work very well. I guess running DMF constantly is just making the framebuilder work too hard with disk access. In the near term, we can maybe work around this by having DMF programs check the AutoDithering bit of the IFO state vector, and just not try to get data when we're running these sorts of scripts. 2387 Thu Dec 10 15:18:55 2009 JenneUpdateVACseisBLRMS last 20 days - including the pounding from next door Attachment 1: Untitled.png 1730 Fri Jul 10 17:32:08 2009 ranaUpdateEnvironmentseisBLRMS & mafalda restarted Rana, Alberto Mafalda's ethernet cable had fallen out of the connector on the hub-side. We reconnected it and rebooted mafalda and restarted seisBLRMS. Mafalda didn't mount /cvs/cds on start up for some reason. I mounted it using 'sudo mount linux1:/home/cds /cvs/cds' and it took at least 30 seconds, so maybe there's a timeout issue. Seems OK now. 282 Mon Jan 28 18:56:47 2008 ranaUpdateDMFseisBLRMS 1.0 I made all of the updates I aludded to before: • Expanded the dmf.db file on c1aux to include all accelerometers and the seismometer. • Added the channels to the C0EDCU.ini file and restarted the framebuilder daqd. • Modified seisBLRMS.m to use .conf files for the channels. The .conf files are now residing in the compiled matlab directory that Rob made. I still have yet to compile and test the new version. Its running on linux3 right now, but feel free to kill it and compile it to run on Mafalda. It should be making trends overnight and so we can finally see what the undergrads are really up to. 284 Tue Jan 29 14:56:39 2008 robUpdateDMFseisBLRMS 1.0 The seisBLRMS 1.0 program crashed at ~7:20 pm last night, so we didn't get data from overnight. It crashed when framecaching failed. I added a try-catch-end statement around the call to dttfft2 to let the program survive this, then compiled it and started it on mafalda. After ~45 minutes, the compiled version encountered the same error, and while it didn't crash per se, after 20 minutes it still wasn't able to read data. We may have to dig deeper into the guts of mDV to make this stuff run more robustly. 312 Tue Feb 12 16:34:07 2008 robDAQDMFseisBLRMS 1.1 The compiled version of seisBLRMS had been running ~2 weeks without crashing as of last night, when I killed it so it wouldn't interfere with alignment scripts. I added an EPICS channel C1:DMF-ENABLE, and updated the DMF executables to check this channel while running. So far it seems to work. When you're running alignment acripts, simply click the DISABLE button on the C1DMF_MASTER.adl screen, and then re-ENABLE when the scripts finish. It's not clear why this is necessary though. Theories include the constant disk access is keeping the framebuilder busy, reducing its ability to deal with ezcademod commands and DMF programs just flooding the network with so much traffic that ezcademod-related packets run late and get ignored. Also, for reasons of aesthetics, I changed the data delay from 6 minutes to 5 minutes. We'll see if that's enough. 317 Thu Feb 14 15:05:18 2008 robDAQDMFseisBLRMS 1.1 > > Also, for reasons of aesthetics, I changed the data delay from 6 minutes to 5 minutes. We'll see if that's enough. 5 minutes didn't work.  1559 Thu May 7 23:34:59 2009 robUpdateSEIseisBLRMS already lost Can't find hostname 'fb40m' it only lasted a few hours 1400 Fri Mar 13 19:26:09 2009 YoichiUpdateDMFseisBLRMS compiled I compiled seisBLRMS. The tricks were the following: (1) Don't add path in a deployed command. It does not make sense to add paths in a compiled command because it may be moved to anywhere. Moreover, it can cause some weird side effects. Therefore, I enclosed the addpath part of mdv_config.m in a "if ~isdeployed ... end" clause to avoid adding paths when deployed. Instead of adding paths in the code, we have to add paths to necessary files with -I options at the compilation time. This way, mcc will add all the necessary files into the CTF archive. (2) Add mex files to the CTF archive by -a options. For some reason, mcc does not add necessary mex files into the CTF archive even though those files are called in the m-file which is being compiled. We have to add those files by -a options. (3) NDS_GetData() is slow for nodus when compiled. NDS_GetData(), which is called by get_data() stops for a few minutes when using nodus as an NDS server. This problem does not happen when not compiled. I don't know the reason. To avoid this, I modified seisBLRMS.m so that when an environmental variableNDS is defined, it will use an NDS server defined in this variable.

I wrote a Makefile to compile seisBLRMS. You can read the file to see the details of the tricks.
I also wrote a script start_seisBLRMS, which can be found in /cvs/cds/caltech/apps/DMF/compiled_matlab/seisblrms/. To start seisBLRMS, you can just call this script.
At this moment, seisBLRMS is running on megatron. Let's see if it continues to run without crashing.

 Quote: 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.

1416   Sun Mar 22 22:47:58 2009 ranaUpdateDMFseisBLRMS compiled but still dying
Looks like seisBLRMS was restarted ~1 AM Friday morning but only lasted for 5 hours. I just restarted it on megatron;
let's see how it does. I'm not optimistic.
1596   Sun May 17 23:22:19 2009 ranaUpdateEnvironmentseisBLRMS for the past 3 weeks
Looks like Chris Wipf's fix of using fclose worked for the NDS client.
The attached plot shows the minute trend RMS - we should put the calibration for these into the .m file
so that the EPICS values are in something useful like microns or microns/sec.

I also now see why Nodus seems really slow with the elog sometimes. When we load a page with an attached
PDF, it runs 'gs' to try to generate the PNG preview. Because its on Solaris it often fails because it
can't find some font. We should probably disable the preview or fix the font issue.
Attachment 1: Untitled.png
1706   Fri Jun 26 19:14:04 2009 ranaUpdateEnvironmentseisBLRMS for the past 3 weeks
Restarted the seisBLRMS.m on mafalda (running a term on op540m). Don't know why it stopped - the
terminal had a 'disabled by EPICS' message even though the EPICS enable button was enabled.

I also changed the delay from 4 to 2 minutes. So now it is calculating a 64 s PSD starting from 2 minutes ago. We had
put it back to 4 minutes long ago since the framebuilder was acting slow, but maybe it will work now since its using
the NDS1 protocol instead of direct frame reading. If it starts not finding data, please kill the seisBLRMS and restart
it with a 3 minute delay.
1379   Mon Mar 9 19:33:10 2009 ranaUpdateDMFseisBLRMS in temp condition

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.

Attachment 1: Untitled.png
392   Fri Mar 21 23:17:47 2008 ranaConfigurationDMFseisBLRMS restarted
I updated the seisBLRMS par file with the new channel names of the accelerometers and the seismometer and then
recompiled the code and restarted it according to Rob's elog entry. It went fine and the seisBLRMS is now back in
action
.
3385   Sat Aug 7 21:57:56 2010 ranaSummaryDMFseisBLRMS restarted

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.

Attachment 1: Untitled.png
3563   Mon Sep 13 02:45:59 2010 ranaConfigurationDMFseisBLRMS restarts

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.

291   Fri Feb 1 12:37:39 2008 robUpdateDMFseisBLRMS trends

Here are DV trends of the output of seisBLRMS over the last ~36 hours (which is how long it's been running), and another of the last 2 hours (which show the construction crew taking what appears to be a lunch break).
Attachment 1: seis36hours.png
Attachment 2: seis2hours.png
6497   Fri Apr 6 16:22:15 2012 DenUpdateEnvironmentseism box

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.

6581   Fri Apr 27 13:32:06 2012 DenUpdatePEMseism channels

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.

6272   Fri Feb 10 15:52:35 2012 JenneUpdatePEMseismic BLRMS loud too

 Quote: 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.

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.

6275   Fri Feb 10 23:58:30 2012 ranaUpdatePEMseismic BLRMS loud too

 Quote: 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.

6276   Mon Feb 13 11:30:51 2012 JenneUpdatePEMseismic BLRMS loud too

Quote:

 Quote: 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...

6277   Mon Feb 13 12:02:17 2012 KojiUpdatePEMseismic BLRMS loud too

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

 Quote: 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.

9958   Thu May 15 15:10:02 2014 SteveUpdatePEMseismic activities

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.

Attachment 1: DichDay.png
Attachment 2: Ditchday8am.jpg
Attachment 3: AztecsGone.jpg
12519   Tue Sep 27 08:49:47 2016 SteveUpdateSUSseismic activity is up

The earth quake shook ITMX free for a  short while.

Attachment 1: 4.3mSaltonSee.png
Attachment 2: ITMXstuck.png
12590   Tue Nov 1 09:03:08 2016 SteveUpdateSUSseismic activity is up

Salton See is shaking again.

Attachment 1: seismicActivity.png
6611   Mon May 7 01:07:58 2012 DenUpdateIOOseismic in mcf

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.

6610   Sun May 6 01:41:55 2012 DenUpdatePEMseismic in x,y arms

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.

6269   Fri Feb 10 11:46:44 2012 steveUpdateIOOseismic noise back to normal

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

Attachment 1: seism4h.png
Attachment 2: seis60s.png
Attachment 3: oneday.png
6271   Fri Feb 10 15:47:38 2012 ranaUpdatePEMseismic noise back to normal

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.

5919   Wed Nov 16 23:50:40 2011 DenUpdateAdaptive Filteringseismic noise injection

[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.

6029   Mon Nov 28 18:53:35 2011 DenSummaryWienerFilteringseismic noise substraction

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.

Attachment 4: filter_fitting.jpg
13427   Tue Nov 14 16:02:43 2017 KiraSummaryPEMseismometer can testing

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.

$\frac{dQ}{dt}=mc\frac{dT(t)}{dt}$ so $T(t)=\frac{1}{mc}\int \frac{dQ}{dt}dt=\frac{1}{mc}\int P_{net}dt$ and $P_{net}=P_{in}-P_{out}$

In our case, we will heat the can to a certain temerature and wait for it to cool on its own so $\inline P_{in}=0$

We know that $\inline P_{out}=\frac{kA\Delta T}{d}$ where k is the k-factor of the insulation we are using, A is the area of the surface through which heat is flowing, $\inline \Delta T$ is the change in temperature, d is the thickness of the insulation.

Therefore,

$T(t)=\frac{1}{mc}\int_{0}^{t}\frac{kA}{d}[T_{lab}-T(t')]dt'=\frac{kA}{mcd}(T_{lab}t-\int_{0}^{t}T(t')dt')$

We can take the derivative of this to get

$T'(t)=\frac{kAT_{lab}}{mcd}-\frac{kA}{mcd}T(t)$, or $T'(t)=B-CT(t)$

We can guess the solution to be

$T(t)=C_{1}e^{-t/\tau}+C_{2}$ where tau is the time constant, which we would like to find.

The boundary conditions are $\inline T(0)=40$ and $\inline T(\infty)=T_{lab}=24$. I assumed we would heat up the can to 40 celcius while the room temp is about 24. Plugging this into our equations,

$\inline C_{1}+C_{2}=40, C_{2}=24$, so $\inline C_{1}=16$

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

$T'(t)=-\frac{16}{\tau}e^{-t/\tau}=B-C[16e^{-t/\tau}+24]$

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

$\frac{16}{\tau}e^{-t/\tau}=16Be^{-t/\tau}, \frac{1}{\tau}=B, \tau=\frac{1}{B}=\frac{mcd}{kA}$

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.

Attachment 1: time_const.png
ELOG V3.1.3-