Is there a reason the framebuilder status light is red for all the front ends?
Also, I reenabled PRM watchdog.
Apparently there is a bug in the timing cards having to do with the new year roll-over that is causing front-end problems. From Rolf:
For systems using the Spectracom IRIG-B cards for timing information, the code did not properly roll over the time for
2012 (still thinks it is 2011 and get reports from DAQ of timing errors (0x4000)). I have made a temporary fix for this
in the controller.c code in branch-2.3, branch-2.4 and release 2.3.1.
I was going to check to see if the 40m is suffering from this. I'll be over to see if that's the problem.
It turned out that the power normalization need a modification.
I will work on it tomorrow and it will take approximately 2 hours to finish the modification.
Concept of Power Normalization
Now a power normalization is doable for the LSC error signals.
It is working fine, but at some point we may want to have some kind of a saturation filter or limiter to avoid dividing a signal by a small number.
(How to set the normalization)
The high frequency noise, which has been a dominant noise above 30 Hz in the Y arm ALS (#6133), decreased by a factor of 5.
This reduction was done by increasing the modulation depth at the Y end PDH locking. Now the noise floor at 100 Hz went to 0.2 pm/sqrtHz.
However the noise source is not yet identified and hence it needs a further investigation.
(Increasing the modulation depth)
I added an ALS feedback path on the MC2 suspension and this path will enable us to stabilise the MC length using the ALS scheme.
Leaving a note on the ALS feedback before I forget:
The MC2 suspension needs to have an input for the ALS feedback in the realtime model like ETMs.
I have realigned the steering mirrors for PMC because the transmitted light had been at ~ 0.741
After the alignment it went back to ~ 0.850.
Some new screens have been made for the new multiple-LOCKIN system running on the LSC realtime controller.
The medm screens are not so pretty because I didn't spend so long time for it, but it is fine for doing some actual measurements with those new screens.
So the basic works for installing the multiple-LOCKIN are done.
The attached figure is a screen shot of the LOCKIN overview window.
As usual most of the components shown in the screen are clickable and one can go to deeper levels by clicking them.
How to set the thresholds
The below is a screenshot of the trigger matrix screen. The thresholds column is pointed by a big white arrow.
Of course, DO NOT set the upper threshold value to be smaller than that of the lower threshold. Otherwise it won't correctly work.
Also if you want to have the usual trigger rather than the Schmitt trigger, simply put the upper and lower thresholds at the same values.
The picture below is a screen shot of the LSC real time model, zoomed in the new LOCKIN part.
The LOCKIN module consists of three big components:
I have edited c1scx.ini by hand in order to acquire some green locking related channels.
Somehow c1sus.ini, c1mcs.ini, c1scx.ini and c1scy.ini are not accessible via the daqconfig script.
As far as I remember it had been accessible via daqconfig a week ago when I edited c1scy.ini.
Anyway I had to edit it by hand. They need to be fixed at some point
Often people say "I don't use conlog because its real slow". Its a little like not driving because your car has no gas.
I looked into what's going on with conlog. No one has fixed its channel list in ~1 year so it didn't make much sense. Also since Oct 1 of this year, it expired the leap seconds epoch and has been waiting for someone to look at the log file and update the list of leap seconds.
There are a bunch of bad channels which are screwing up various tools (DV, DTT, etc.):
Examples: C1:LSC-Subsystem_NPRO_SW1, C1:-DOF2PD_MTRX_0_0_SW1, C1:BAD-BAR_CRAZY_2_RSET, C1:C1L-DOF2PD_MTRX_3_14_SW2, C1:DUB-SEIS_GUR2_Z_LIMIT, etc.
To fix up some of these issues, I have deleted several MEDM directories which I thought were old (there are several extras left from Aidan's Green time). I also have put a bunch of exclude variables into the conlog 'scan_adls' script to prevent it from adding some of the new worthless channels. Finally, I have started this command
../bin/strip_out_channels '.*STAT.*','.*_ALIVE.*','C1:PEM.*','.*_Name.*','C1:UCT.*','C1:MCP.*','C1:SP.*','C1:DU.*','C1:RF.*','C1:NIO.*','C1:TST.*','C1:SUP.*','C1:X.*','C1:FEC.*','.*_LFSERVO.*','.*FSS_SLOWDC.*','C1:LSC-LA_MTRX_21','C1:LSC-PD.*OFFSET','C1:LSC-ETM.*OFFSET' conlog*.log
which should strip lots of the excess conlog data out of the conlog directory. The only downside is that its setting all of the timestamps of the .log files to today instead of the historical times but I don't think we'll care about this too much. Hopefully it will speed things up to have less than 450 GB of conlog files...
update: 12 hours later, its still running and has removed ~100 GB so far. It will probably take the rest of the weekend to finish.
After I did a fine alignment of the X green beam path on the PSL table, the X arm beat-note was also obtained.
Here is a picture of the latest setup. The blue lines represent S-polarizing green beams.
During I was working on the PSL table HEPA was at 80 %, and after the work I brought it to 20 %.
I set the limitters of the MC WFS servos not to inject the feedback more than 2000.
The residual of the WFS shakes the MC SUSs at every lock loss.
Assumptions on the parameter estimations
I made the first trial of locking a Power-recycled single arm.
Here is the Gantt chart we discussed in the 40m meeting today.
Based on the discussions we had, I applied a little bit of corrections on the chart but the main stream remains the same.
While discussing the suspension hysteresis measurements, Koji, Kiwamu, and I realized that the suspension wire standoff is aluminum, whereas the standoff for the LIGO LOS are using quartz.
Using a soft aluminum standoff is bad. The movement of the suspension will slowly wear the groove and produce opportunities for mechanical upconversion and hysteresis.
In fact, the wire standoff as well as the clamping block on the top should be made of sapphire or ruby to prevent any such wearing issues. Steve is hot on the case.
This is NOT a work in the main stream,
but it gives us some prospects towards the full lock and perhaps some useful thoughts.
Lock Acquisition Steps
Actual Time Series
Below is a plot of the actual lock acquisition sequence in time series.
Scripting of the single arm automated lock script is 80% done.
The remaining 20 % is not something immediately needed and I start decreasing the priority on the Y arm ALS.
3/4 " thick colored acrylic material will be used in this air tight design. Surgical tubing for o-ring. We may have to put an o-ring into the bottom to have it really air tight.
The top drawing is not ready. It will have handle and industrial grade L-handle lock pin to hold cover down. There will be 2 one inch od post in the midle of the table to hold the cover and lock the ball pin.
I'm waiting for your inputs, so I can send this preliminary design out for quote.
I have been looking at the swings in the RAMmon channels since the heater was reengaged, to compare them to the data from beforehand (with and without the foam box). With the large grains of salt that I will list after, it appears that the EOM temperature controller does in fact reduce the amplitude of the swings by a measurable factor.
It seems impractical to try and rope off essentially 3 straight days where nothign major can be done to the IFO just to take RAM data. Instead, I think we should figure out a way to mimic the diurnal temperature swings on ~hour timescales. The EOM can temperature follows PSL-FSS_RMTEMP almost exactly and with a very short delay, so we can probably even accomplish this by stepping the lab A/C temperature. If this won't work, we can use an incandescent lamp or something similar to heat up the area around the EOM by a noticeable amount.
I'll try to come up with a good way to do this so that we can get some reliable data...
Online filter diverges. I did offline simulations with current c-code. Offline filter also diverges, even in the simplest case
witness = randn(1e6, 1); target = witness + 0.01*randn(1e6, 1);
I tried to create a new implementation of FXLMS algorithm as a c code. Then with this c code I did offline filtering with MCL and GUR signals and compared the error signals depending on the length of the filter.
One can see the code at the svn
adaptOnline - start here and choose algorithm
adaptive_filtering - Matlab implementation of AF
current_version.c - current version of the Filter (Matt's)
fxlms_filter.c - new version of the FXLMS filter
oaf.c - agent between Matlab and C (edited Matt's file)
Data samples can be found at nodus /users/den/wiener_filtering/data
Another hysteresis test has begun at 1:50 PT, Dec/19.
It will finish after 3 or 4 hours. During the measurement the PSL mechanical shutter will be kept closed.
I have recentered the oplev beams, including BS, ITMs and ETMs.
The measurement finished at ~ 21:50 PT.
A new test started from 16:05 PT, Dec 18th and takes a couple of hours to finish the measurement.
Do not touch the suspensions until further notice.
Here are the latest plots that I have obtained from the Friday night:
The residual motion in the arm displacements reached 70 pm in rms.
Koji has modified the script for the hysteresis measurement.
The hysteresis test has been aborted.
The test was from: 2011-12-17 09:48 to 11:49 (UTC).
This corresponds to the period from 2011-12-17 01:48 to 3:49 (PST).
Do you guys have timestamps for when you started/ended the test? I have been trying to take some long-term RAM data but keep getting foiled by stuff (this test, RTS upgrade, switching of RAMmon channels, etc.)
To test it, we are shaking all of the suspension biases +/-1.0 with a script.
All of the suspensions have accumulated unexpectedly big DC biases of about 5 from their nominal points.
All of the suspensions have accumulated unexpectedly big DC biases of about 5 from their nominal points.
We wonder if the flakiness of MC2 comes from the suspension or not.
The script is here:
For this test, we closed the mechanical shutter before the MC.
Also some amount of misalignment is anticipated.
Don't be surprised if you see nothing is working when you come to the lab in the weekend.
The 60 Hz line noise has gone away.
About Noise Budget
How to improve it ?
Unfortunately, after working on it all day, I had to abort the upgrade and revert the system back to yesterday's state.
I think I got most of the upgrade working, but for some reason I could never get the new models to talk to the framebuilder. Unfortunately, since the upgrade procedure isn't document anywhere, it was really a fly by the seat of my pants thing. I got some help from Joe, which got me through one road block, but I ultimately got stumped.
I'll try to post a longer log later about what exactly I went through.
In any event, the system is back to the state is was in yesterday, and everything seems to be working.
All RTS systems will be down until futher notice...
Actually, the LO inputs to the IQ boards have AP1053 (Cougar) amps on them. These are 10 dB amps and so putting 10 dBm in puts us on the very maximum of the LO range at 20 dBm.
I think the distribution box levels are fine.
I'm not sure I agree with your conversions, BUT:
The IQ boards use a PE4140, fancy MOSFET array as the mixer, and according to Peregrine (manufacturer), they can be operated with 0-20 dBm LO drive. I'm not recommending we drive them at 0 dBm, but perhaps the numbers you mentioned are OK.
The Rich demod box wants 10dBm for the local oscillator inputs, so I measured the values that we have coming out of the distribution box. I'm using the "Spare 55MHz" and the "POP11" outputs, both of which had terminators so were not in use.
The 55MHz had ~600mV peak, so between 5 and 6 dBm.
The 11MHz had ~800mV peak, so about 8 dBm.
This is not enough dBm for either. Going in search of RF amplifiers now...
Yeah, I looked and saw that it's a semiconductor mixer, so it doesn't have to be as perfect.
Everything is plugged in now to the new demod board. More details soonly...
The I & Q outs are plugged into whitening filter #3, channels 5-8. 11MHz I = chan 5, 11MHz Q = chan 6, 55MHz I = chan 7, 55MHz Q = chan 8. These channels are probably already recorded, but I haven't checked yet. Hopefully I'll have time tonight after I pack for my trip. But Zach, can you look into it tomorrow just to check?? Backup plan is to just go back to using the AS11 and POP55 boards and channels if the new board isn't doing what it's supposed to.
I disconnected the 3rd and 4th channels of the demod box since they were drawing unnecessary current, and making the box hot. Now the box is just warmish.
The existingly used used Pasternack Enterprices RG58 C/U cable lenght ~ 140 ft and the specs are here at Atm1
Atm2 The performance grade RG58-P coaxial cable specs.
To check if the MC alignment is OK or not, we tried to lock the Y-arm.
Once the alignment of Y-arm was restored, we saw the resonant peak of ~0.2 in TRY.
After a small tweak of PZT2, TRY has got improved up to 0.7.
Kiwamu made a small tweak on the problematic PZT1, then the full (1.0) TRY was recovered.
Thus we concluded the current MC alignment is good enough.
I made a test installation of ligo_viewer in /users/volodya/ligo_viewer-0.5.0c . It runs on pianosa (the Ubuntu machine) and needs Tcl/Tk 8.5.
To try it out run the following command on pianosa:
Press "CONNECT" to connect to the NDS server and explore. There are slides describing ligo_viewer at http://volodya-project.sourceforge.net/Ligo_viewer.pdf
Use /users/volodya/ligo_viewer-0.5.0c.tgz or later version - it has been updated to work with 64 bit machines.
Make sure Tcl and Tk development packages are installed. You can find required packages by running
apt-file search tclConfig.sh
apt-file search tkConfig.sh
If apt-file returns empty output run apt-file update
Unpack ligo_viewer-0.5.0c.tgz, change into the created directory.
Run the following command to configure:
./configure --with-tcl=/usr/lib/tcl8.5/ --with-tk=/usr/lib/tk8.5/
This works on Ubuntu machines. --with-tcl and --with-tk should point to the directories containing tclConfig.sh and tkConfig.sh correspondingly.
You can test the compilation with ./ligo_viewer.no_install
If everything works install with make install
If Tcl/Tk 8.5 is unavailable it should work with Tcl/Tk 8.3 or 8.4
I reengaged the heater this morning, to compare it with the free-wafting and passive box-covered data. In order to make the loop stable, I had to reduce the gain of the AD620 by 10. I have increased the TEMP_MON preamp gain by 10, so the calibration should still be ~3.5 V/K into the ADC (and in DV).
Below is a screenshot showing that the RAMmon signals are pushed to some (nonzero) value, and it appears that they stay there despite the changing PSL table temperature as measured by FSS_RMTEMP. My post from last week shows that without the heater servo the temperature of the EOM can follows RMTEMP almost exactly. So, it seems like the heater is working well at low frequencies, modulo sensor noise, which ought to be low for the thermistor. Since several things (MC, etc.) have changed since out baseline data, it migth be prudent to let this sit for a little while and then disconnect the heater to see what happens.
~11PM I came to the 40m and found the MC is repeating "LOCK->WFS ON->UNLOCK" sequence for ~2hours.
I checked the WFS spots on the QPDs and aligned them. No luck. I suspected the clipping of the beam in the chamber.
After I checked the trends of MC SUS OSEM values and IPPOS, I concluded that the input beam was aligned to somewhat misaligned MC.
The most noticable thing was that IPPOS (X, Y) indicated about (-0.5, 0) although the recent trend shows (-1, -0.5) is nominal.
In fact, the beam was about dropping from the diode. In addition, I found that the MC2 suspension showed a jump in the morning at around 8.30AM.|
This is consistent with what Jenne described.
This was a difficult situation as everything was moved.
I used the OSEM values to come back to the previous alignment of the suspensions, and started touching Zig-Zag before the MC.
After the alignment I ended up more clipping of the MC REFL. Also the spot on the IPPOS QPD was more dropping.
So, I have empirically used MC3 to misalign in Yaw to have better spot position on IPPOS. Then, the Zig Zag was aligned.
Then the spot on MC2 was adjusted while MCTRANS was kept maximized.
This helped the things back in the normal state.
Now the WFS servo is happily controlling the alignment.
MC REFL is 4.8 and 0.47 for unlocked and locked. (MCREFL_UNLOCK was 4.6 before my touch)
MCTRANS is 27000, which is close to the nominal.
IPPOS total, x, and y are 0.36, -0.97, and -0.47, respectively. They are about the nominal.
HOWEVER, we still don't know the position of the spot on MC1/MC3, and ITMY and ETMY.
I should consult with Kiwamu to check the spot positions tomorrow.
- If you find any reduction of MC transmission, check the suspensions to see if there is any slip.
- Before touching the input optics to recover the MC alignment, we should think what was moved.
- Before touching EOM alignment you must check the MC alignment WITHOUT WFS, so that you can recover the misalignment of EOM by the Zig-Zag steering.
- WFS is sensitive to clipping of the beam.
- We need a nifty indicator to tell how the MC transmitted beam is good.
Of course, looking at the MC transmission os the important thing, but I wonder if maybe we should also monitor the beam before it goes into the MC just to see if its the fault of the MC-WFS or not. In the bad old MZ days, I remember that the MC mirror alignment would drastically change the post-MC RAM.
It requires another PD/demod set, but may be illuminating in the end.
Also, can someone please add some channels to EPICS which calibrate the RAM channels into RAM units?
The MC coupling had become re-shittified. As we need transmitted MC light for the RAMmon, I realigned the input beam to the MC. (Jenne said that the MC mode itself should be well aligned, so I just used the zigzag on the PSL). MC_REFL is now ~0.5-0.6.
Dataviewer couldn't connect to the framebuilder, so I checked the CDS status screen, and all the fb-related things on each model went white, then red, then computer-by-computer they came back green. Now dataviewer works again. Is someone secretly doing shit while not in the lab??? Not cool man!
This happens on occasion, and I have reported it to the CDS guys. Something apparently causes the framebuilder to crash, but I haven't figured out what it is yet. I doubt this particular instance had anything to do with remote futzing.
Now we've got another day of data, with the foam box on for the last 24hrs.
First plot is a 5 day trend so you can see that the RAM has gotten a little bit smaller, as has the temperature drift, but not by a whole lot.
Second plot is the last 19 hours (so excluding much of the time while I was realigning beams on the PSL table yesterday), to zoom in on just the time when the foam box was installed.
After lunch Zach and I are going to engage the heater to temperature stabilize the system, to see how that affects things.
In other news, the MC looks like it was fine for a good long time, and ~3 hours ago it went bad. The mode that's flashing is really bad in both pitch and yaw. I don't know what happened, but something is not so awesome. Edit: Steve said that he opened the PSL table at some point this morning to look around but not touch, and also it's Janitor Day, and Kevin comes in around 8ish. That doesn't mean I know the actual cause, but those are the only things that happened in the IFO room this morning that anyone is aware of.
[Jenne, Mirko, with supervision from Jamie]
We are starting to create the new OAF model, so that it works with the new CDS system.
Why did you place Matt's code inside the simulink library and use the same library for all DOFs? I think this won't work out. Inside the .c code there are static variables. If all DOF use the same ADAPT_XFCODE() function, it means that they all mess there signals and coefficients with each other! Or the RCD during the compilation creates a copy of the function with the name of a library name in front? For example, ADAPT_MCL_ADAPT_XFCODE(). But then in the RCG manual it is claimed to name the .c file the same.
This problem can be fixed by creating .c files with proper names for each DOF. But here a memory question may arise. For 1 DOF we now have 28 witness channel. If we have a several minute filter, we use 28 * 104(filter length) * 3 (FIR coefficients, adapt input, corr input) * 8 (number of bytes in 1 double) = 6.7 Mb / DoF. For 8 DOF we'll allocate ~55 Mb of memory in the kernel. The c1lsc cache size is 6 Mb per cpu. So we are definitely out of cache and it will take some time for a processor to communicate with ram. I wonder if it is OKEY for us to allocate this amount of memory as static arrays inside the kernel.
Now we use 6.7 Mb of memory because it seems to be a mistake with placing the same function for all DOF and we actually allocate for 1.