40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 95 of 341 Not logged in
ID Date Author Type Category Subject
1716   Thu Jul 2 17:37:36 2009 steveUpdateVACV1 interlock test

Joe, Alberto and Steve

We tested gate valve V1 interlock by :

1, decelerated rotation by brake from maglev controller unit.

2, turned maglev  controller off from controller unit.

3, unpluged 220VAC plug from wall socket

None of the above action triggered V1 to close. This needs to be corrected in the future.

The MEDM monitor screen of maglev indicated the correct condition changes.

8988   Thu Aug 8 18:47:41 2013 SujanSummaryPEMUsing weiner filters for subtracting signals MC_L and GUR2_X

I used MC_L signal from the Mode Cleaner as the desired signal with GUR2_X as witness signals. I observed good subtraction where coherence is high. But there was noise added in other frequency bands. I am not sure how to avoid that.

Please find attached documents that contains relevant plots.

640   Mon Jul 7 13:58:37 2008 Eric, josephbDAQPEMUsing unused PEM channels to test camera code
Joe and I have taken control of the EPICS channels C1:PEM-Stacis_EEEX_geo and C1:PEM-Stacis_EEEY_geo since we heard that they are no longer in use.  We are currently
using them to test the ability for the Snap camera code to read and write from EPICS channels.  Thus, the information being written to these channels is completely unrelated
to their names or previous use.  This is only temporary; we'll create our own channels for the camera code shortly (probably within the next couple of days).

- Eric
16926   Thu Jun 16 19:49:48 2022 CiciUpdateGeneralUsing the SR785

[Deeksha, Cici]

We used a python script to collect data from the SR785 remotely. The SR785 is now connected to the wifi network via Ethernet port 7.

17031   Mon Jul 25 09:37:39 2022 DeekshaUpdateElectronicsUsing the DFD to measure PZT TF

The DFD was setup to measure the change in beatnote when excited. A long long (128in) cable goes from the SR785 near the DFD all the way to the Xend AUX which it accordingly excites and the DFD is monitored by the oscilloscope at the other end. This was completed on Friday. The wires and stand have been moved to the side but the setup is still a bit chaotic. As of writing this post, there is still atleast some minor issue with the setup as we aren't getting the expected output.

[I will shortly update this elog with more pictures]

Edit: the SR785 was replaced by the AG 4395, and pictures added

1598   Mon May 18 02:18:17 2009 ranaSummarySEIUsing STACIS w/ a good position sensor
WE turned off STACIS a few years ago because we noticed that it was causing noise below a few Hz and making
the overall velocity between the ends higher than with them off. I'm pretty sure they were causing noise
because they use little geophones which are noisy. Below ~0.2 Hz the horizontal geophones are also probably
limited by tilt-horizontal coupling.

Another concept (based on discussion with Brian Lantz and Matt Evans) is to instead put a good position sensor
between the ground and then blue support beam. Since the the STACIS rubber acts like a Q~2 passive resonance at
20 Hz, the whole seismic system (including the blue beams, in-vac tubes, and internal stack) act like a proof
mass of a seismometer.

So, in principle, if we use a very good position sensor and feedback to the STACIS piezo actuators, we can cancel
the ground motion before it enters the stacks. The initial LIGO OSEMs have a noise of 10^-10 m/rHz above 10 Hz
and going up like 1/f below 10 Hz. The AdvLIGO BOSEMs have a noise of ~2x better. Even better, however, are the
UK's EUCLID interferometric OSEMs (developed by Stuart Aston and Clive Speake).

In the attached plot, I show what we can get if we use these EUCLIDs make a ~60 Hz BW feedback loop w/ STACIS.

BLACK   - raw ground motion measured by the Guralp
MAGENTA - motion after passive STACIS (20 Hz harmonic oscillator with a Q~2)
GREEN   - difference between ground and top of STACIS
YELLOW  - EUCLID noise in air
BLUE    - STACIS top motion with loop on (60 Hz UGF, 1/f^2 below 30 Hz)
CYAN    - same as BLUE, w/ 10x lower noise sensor

One of the SURF projects this summer is to put together a couple different sensors like EUCLID to understand the noise.
6265   Thu Feb 9 20:01:02 2012 ranaSummaryElectronicsUsing RF LP filters as dispersion units for the MFD

WE currently use long cables to give us the dispersion that we want for the MFD. A cable gives a long delay - both the phase delay and the group delay.

But we only need the dispersion (group delay). We can get this by just using a very sharp low pass filter and having the corner be above the frequency that we have the beat signal.

For example, the MiniCircuits SLP-200+ has got a corner frequency of 200 MHz and a group delay of ~10 ns (like a 3 m vacuum delay). So we would have to use 10 of these to get the delay we now get. The passband attenuation is only 0.5 dB, so we would lose 5 dB. The cost is \$35 ea. We have a few on the shelf.

OTOH, if we tune the beat frequency down to 30 MHz, we can use the SLP-30 which has a group delay of 30 ns around 30 MHz. That's like 9m at light speed. We could easily get a nice result by just using 4 or 5 SLP in series.

So why is Kiwamu using cables?? And how should we really choose the beat note frequency??

13131   Fri Jul 21 19:44:58 2017 NaomiSummaryComputer Scripts / ProgramsUsing PyKat to run Finesse

I have been working on using PyKat to run Finesse. There appear to be several ways to run an equivalent simulation using Finesse:

1: .kat only

Run a .kat file directly from the terminal. For example, if in the directory containing the Finesse kat.ini file, run the command ‘./kat file.kat’. This method does not use PyKat.

To edit the simulation using this method, one must directly edit the .kat file. This is not ideal, as all parameters must be hard-coded, and there is no looping method for duplicate commands.

Both of the following methods use PyKat in some manner. To run Finesse using PyKat from a .py file, the command ‘from pykat import finesse’ should be included. In addition, two environment variables must be defined:

• FINESSE_DIR': directory containing ‘kat’ executable
• KATINI’: location and name of kat.ini file

Within a .py file running PyKat, the kat object contains all of the optical components and their states. To create a kat object, we use the command:

kat = finesse.kat()

2: .kat + .py

To load Finesse commands from a .kat file, we can use the command loadKatFile(). For example, using the kat object as defined above:

kat.loadKatFile(‘file.kat’)

The kat object now contains any components defined in the .kat file. The states of these components can be altered using PyKat. For example, if in the .kat file, we defined a mirror named ‘ITM’, with R = 0.9, T = 0.1, phi = 0, and with nodes 1 and 2 to its left and right, respectively, using the Finesse command

m ITM 0.9 0.1 0 n1 n2

we can now alter the state of the mirror using a PyKat command such as

kat.ITM.phi = 30

which changes the ‘phi’ property of the mirror to 30 degrees. Once all alterations to objects are made, we can run Finesse using the command

out = kat.run()

which stores the output of the Finesse simulation in the variable out.

3: .py only

We can also run a Finesse simulation without any .kat file. There are two ways to define Finesse objects within a .py file.

- Parse a string containing Finesse commands, as would be found in a .kat file, using the command parseCommands(). For example,

 kat.parseCommands(‘m ITM 0.9 0.1 0 n1 n2’)

defines the same mirror as above. This object can now be altered using pyKat in the same manner as above.

- Define an object using the classes defined in PyKat. For example, to define the same ITM mirror, we can use:

ITM = mirror(‘ITM’, ‘n1’, ‘n2’, 0.9, 0.1, 0)

kat.add(ITM)

The syntax for these classes can be found in the files included in the PyKat package named ‘commands.py’, ‘detectors.py’, and ‘components.py’.

We can also run Finesse commands (rather than just defining components) using their respective classes. These must also be added to the kat object. For example:

x = xaxis(‘lin’, [‘-4M’, ‘4M’], ‘f’, 1000, ‘laser’)

kat.add(x)

This runs the command ‘xaxis’, which sets the x-axis of the output data to run from freq = -4 MHz to 4 MHz, in 1000 steps. This is equivalent to the following Finesse command:

xaxis laser f lin -4M 4M 1000

In theory, we should be able to use PyKat to run any Finesse command. However, not all Finesse commands appear to be defined in PyKat; one example is the Finesse command ‘yaxis’, which I cannot locate in PyKat. In addition, I have had difficulty running some commands such as ‘cav’ and ‘pd’, despite following their class definitions in the PyKat files. However, these commands can still be easily run in PyKat using parseCommands().

16551   Thu Jan 6 17:16:51 2022 YehonathanUpdateBHDUsing Peek screws/nuts

There were several cases where the long EQ stops didn't perform as expected.

In one type of case, we used a counterweight at the front of the adapter but not in the back leaving a recess where the lower back EQ stop should touch.

In the other type, a recess in the thick optics adapter prevented the upper EQ stop from touching the adapter. In the first thick optic, the screw was screw barely scratched the recess' corner. In the second case, it didn't touch it at all.

In the last group meeting, we discussed using Peek screws (made out of plastic) to prevent metal on metal bumping when the EQ can touch the adapter and Peek nuts when it doesn't to increase its impact area.

Mcmaster has 1.5" long 1/4-20 screws (part number 98885A131) that will fit well in the OSEM plates. We can order 20 of those.

The biggest Peek nuts on Mcmaster however are not big enough (7/16" wide) to cover the entire bottom recess area which is 0.5" wide (they are good enough for the top recess area in the thick adapter optic design). Koji suggested that we can use a big Peek washer for that purpose that can be held between nuts. We should then order 10 Peek nuts (98886A813) and 1 package of 10 Peek washers (0.63" OD) (93785A600).

12129   Tue May 24 17:55:17 2016 VarunUpdateElectronicsUsing Altium

Contacted Charles regarding use of Altium. Got to know that Altium is installed on cit40m iMac in Win7 on VirtualBox. Had to update Virtualbox to get it working. Altium now works for sometime, but then fails, saying that it is unlicensed.

16128   Mon May 10 10:57:54 2021 Anchal, PacoSummaryCalibrationUsing ALS beatnote for calibration, test

### Test details:

• We locked both arms and opened the shutter for Yend green laser.
• After toggling the shutter on.off, we got a TEM00 mode of green laser locked to YARM.
• We then cleared the phase Y history by clicking "CLEAR PHASE Y HISTROY" on C1LSC_ALS.adl (opened from sitemap > ALS > ALS).
• We sent excitation signal at ITMY_LSC_EXC using awggui at 43Hz, 77Hz and 57Hz.
• We measured the power spectrum and coherence of C1:ALS-BEATY_FINE_PHASE_OUT_HZ_DQ and C1:SUS-ITMY_LSC_OUT_DQ.
• The BEATY_FINE_PHASE_OUT_HZ is already calibrated in Hz. This we assume is done by multip[lying the VCO slope in Hz/cts to the error signal of the digital PLL loop that tracks the phase of beatnote.
• We calibrated C1:SUS-ITMY_LSC_OUT_DQ by multiplying with
$\dpi{150} \large 3 \times \frac{2.44 \, nm/cts}{f^2} \times \frac{c}{1064\,nm \times 37.79\, m} = \frac{54.77}{f^2} kHz/cts$ where f is in Hz.
The 2.44/f2 nm/cts is taken from 13984.
• We added the calibration as Poles/zeros option in diaggui using gain=54.577e3 and poles as "0, 0".
• We found that ITMY_LSC_OUT_DQ calibration matches well at 57Hz but overshoots (80 vs 40) at 43 Hz and undershoots (50 vs 80) at 77Hz.

### Conclusions:

• If we had DRFPMI locked, we could have used the beatnote spectrum as independent measurement of arm lengths to calibrate the interferometer output.
• We can also use the beatnote to confirm or correct the ITM actuator calibrations. Maybe shape is not exactly 1/f2 unless we did something wrong here or the PLL bandwidth is too short.
441   Thu Apr 24 11:50:10 2008 josephbSummaryComputer Scripts / ProgramsUseful tidbits learned while tracking the network setup
In process of understanding the network setup I've learned several things:

1) The status lights on C0DAQ_RFMNETWORK.adl are controlled by the fiber network, as opposed to the ethernet network. However, even if everything is working properly on the VME end, you may still need to reboot it in order to be able to contact it via the ethernet (ssh or telnet).

2) After disconnecting the hub out by 1Y9, I was able to telnet into c1vac1, but not c1vac2. I was told that the Turbo pump and Ion pump readbacks on C0VACMONITOR.adl had not been working for awhile (years?). So I went out and rebooted the c1vac2 card. This seemed to restore the epic channels and we now have correct readbacks on the turbo pumps. The ion pumps all are reading no voltage, which is good because they're turned off. However C1:Vac-IPSE_mon is reading "On", although Steve assures me the actual unit is currently off, so there may be a minor channel issue there.
16976   Wed Jul 6 22:40:03 2022 TegaSummaryCDSUse osem variance to turn off SUS damping instead of coil outputs

I updated the database files for the 7 BHD optics to separate the OSEM variance trigger and the LATCH_OFF trigger operations so that an OSEM variance value exceeding the max of say 200 cnts turns off the damping loop whereas pressing the LATCH_OFF button cuts power to the coil. I restarted the modbusIOC service on c1susaux2 and checked that the new functionality is behaving as expected. So far so good.

TODO

Figure out the next layer of watchdogging needed for the BHD optics.

 Quote: [Anchal, JC, Ian, Paco] We have now fixed all issues with the PD mons of c1susaux2 chassis. The slow channels are now reading same values as the fast channels and there is no arbitrary offset. The binary channels are all working now except for LO2 UL which keeps showing ENABLE OFF. This was an issue earlier on LO1 UR and it magically disappeared and now is on LO2. I think the optical isolators aren't very robust. But anyways, now our watchdog system is fully functional for all BHD suspended optics.

16979   Thu Jul 7 21:25:48 2022 TegaSummaryCDSUse osem variance to turn off SUS damping instead of coil outputs

[Anchal, Tega]

Implemented ramp down of coil bias voltage when the BHD optics watchdog is tripped. Also added a watchdog reset button to the SUS medm screen that turns on damping and ramps up the coil PIT/YAW bias voltages to their nominal values. I believe this concludes the watchdog work.

 Quote: TODO Figure out the next layer of watchdogging needed for the BHD optics.

13823   Mon May 7 20:01:14 2018 RorpheusUpdateGeneralUse anti-dewhitening + show CARMA/DARMA

example of plots illustrating DAC range / saturation

11383   Tue Jun 30 05:47:38 2015 ranaUpdateLSCUse BALUNs
 Quote: The RMS in both channels mostly comes from a whole mess of 60Hz harmonics. I'll see what I can do by taking better care of the delay line cables, but it is kind of weird that this would be worse now, given that there was little care given to them before either.

BALUNs

4177   Thu Jan 20 15:39:59 2011 AidanUpdateLockingUpper limit on frequency noise of ADC

[Aidan, Kiwamu]

Kiwamu and I plugged the output from a DS3456 function generator into the ADC and started recording the data. The func. generator output a 237.8Hz, 1Vpp sine wave. We chose this value because it corresponds to the FSR of a 38.5m cavity (=3.896MHz) divided by 2^14, the frequency divider amount we intend to use.

Since 1 FSR divided down is 237.8Hz and corresponds to a length change of the cavity of 532nm/2 = 266nm, then we can, roughly, say that a frequency change of 1Hz corresponds to a length change in the cavity of approximately 1nm. The width of the 237.8Hz peak in the spectra corresponds to an upper limit on the noise floor due to digitizing the signal (this could be limited by the ADC, or the function generator, or the windowing on the FFT).

The FWHM of the peak in the spectrum was approximately 5mHz, corresponding to an uncertainty in the length of the cavity of about 6pm (we used a Hanning Window, 50% overlap and a BW of 2.92mHz, 7 averages). Regardless of what is the dominant contribution to the width of the peak, this implies that the frequency noise associated with digitizing a signal in the ADC is much smaller than we require and will not limit our performance if we choose to use a frequency divider and digital PLL with the Green Locking.

1687   Fri Jun 19 13:39:29 2009 AidanUpdateGeneralUpper limit measurement of the scatter from the eLIGO beam dumps.

I measured the scatter from the eLIGO beam dumps as best I could. The experiment setup is shown in the attached diagram.

After familiarizing myself with the equipment in the morning I noticed three issues with the setup

1 - around the minimum scatter the back scatter from the beam dump is very susceptible to the incident angle (makes sense since the Si plate inside the beam dump at Brewster's angle when there is minimum scatter).

2 - The mirrored plug (Part 20 in D0900095) which is suppose to be used for alignment is not very effective. It moves around too much in its hole in the front face of the beam dump. Just by touching it I could make the reflected beam jump around by about 0.1 radians.

- I think to align these properly we'll have to partly assemble the dumps. If we leave off the front plate of the horn then we can measure the reflection off the Si. If we measure this with a power meter then alignment becomes a simple matter of rotating until this reflection is minimized.

3. - For this measurement the incident beam was a small (~ 1mm diameter) central beam with a small amount of spray of laser light beyond that central region. This spray was hitting the aluminium front face of the beam dump and was scattering back to the photodiode. This was clearly the limiting factor in the measurement. Most of this light was spread horizontally so I placed a couple of pieces of black glass on either side of the aperture, just blocking the edges a little. This reduce the background reading at the minimum scatter from 17.0uV to around 4.5uV with still a little bit of light hitting the top and bottom of beam dump face.

The incident power on the beam dump fluctuated a little but was in the range 20.5 to 22mW. The response of the PD is approximately 0.2 A/W and the transimpedance is 7.5E4 V/A.

The SR830 Sensitivity was set to 1x1 mV.

It was difficult to measure the actual angle of incidence. The dump pivoted about a point directly under the input aperture at the front. By measuring the displacement of a point on the back of the dump as I rotated it and knowing the distance between this point and the pivot point I was able to make a reasonably accurate measurement of a range of angles about the minimum.

The measured scatter (in V measured directly by the PD and as a fraction of the incident power) is shown in the attached plots.

I think I can do a better job cleaning up the incident beam - so these numbers only represent an upper limit on the scatter.

attachment 1: beam dump assembly

attachment 2: experimental layout

attachment 3: scatter measurement

attachment 4: BRDF - (scatter divided by the solid angle = 1.1 m steradians)

attachment 5: (slightly blurred )photo of dump - overhead view

17062   Thu Aug 4 22:32:31 2022 KojiUpdateIOOUpon leaving the lab (WFS investigation)

Upon leaving the lab:

- HEPA is ON at the original speed (i.e. same speed at 5PM today)

- WFS servo is ON, partly because we want to see how stable it is. It is not handled with the autolocker right now.
So there is a possibility that the WFS servo goes wild and make the IMC totally misaligned (and does not come back)
In such a case, go to the WFS servo screen and push "CH" (clear history) of each servo filters.

14806   Wed Jul 24 16:45:32 2019 JonUpdateCamerasUpgraded Pylon from 5.0.12 to 5.2.0

I upgraded Pylon, the C/C++ API for the GigE cameras, to the latest release, 5.2.0. It is installed in the same location as before, /opt/rtcds/caltech/c1/scripts/GigE/pylon5, so environment variables do not change. The old version, 5.0.12, still exists at opt/rtcds/caltech/c1/scripts/GigE/backup_pylon5.

The package contains a GUI application (/bin/PylonViewerApp) for streaming video. The old version supports saving still images, but Milind discovered that the new version supports saving video as well. This required installing a supplementary package supporting MPEG-4 output.

Basler's GUI application is launched from the terminal using the alias pylon. I've tested it and confirm it can save both videos and still-image formats. I recommend to also try grabbing images using this program and check the bit resolution. It would be a useful diagnostic to know whether it's a bug in Joe B.'s code or something deeper in the camera settings.

14808   Wed Jul 24 20:23:52 2019 gautamUpdateCamerasUpgraded Pylon from 5.0.12 to 5.2.0

Since there are multiple SURF projects that rely on the cameras:

1. I moved the new installs Jon made to "new_pylon5" and "new_pypylon". The old installs were moved back to be the default directories.
2. The bashrc alias for pylon was updated to allow the recording of videos (i.e. it calls the PylonViewerApp from new_pypylon).
3. There is a script that can grab images at multiple exposures and save 12-bit data as uint16 numpy arrays to an HDF5 file. Right now, it is located at /users/kruthi/scripts/grabHDR.py. We can move this to a better place later, and also improve the script for auto adjusting the exposure time to avoid saturations.

My changes were necessary because the grabHDR.py script was throwing python exceptions, whereas it was running just fine before Jon's changes. We can move the "new_*" dirs to the default once the SURFs are gone.

Let's freeze the camera software config in this state until next week.

14810   Thu Jul 25 09:19:32 2019 JonUpdateCamerasUpgraded Pylon from 5.0.12 to 5.2.0

I'll keep developing the camera server on a parallel track using the "new_..." directory naming convention. One thing I forgot to note is that the new pylon/pypylon packages require Python 3, so will not work with any of the 2.7 scripts. All of the environment I need to set up is exclusively Python 3. I won't change anything in the Python 2.7 environment in current use.

Also, I found the source of the bit resolution issue: Joe B's code loads a set of initialization parameters from a config file. One of them is "Frame Type = Mono8" which sets the dynamic range of the stream. I'll look into how this should be changed.

 Quote: Since there are multiple SURF projects that rely on the cameras: I moved the new installs Jon made to "new_pylon5" and "new_pypylon". The old installs were moved back to be the default directories. The bashrc alias for pylon was updated to allow the recording of videos (i.e. it calls the PylonViewerApp from new_pypylon). There is a script that can grab images at multiple exposures and save 12-bit data as uint16 numpy arrays to an HDF5 file. Right now, it is located at /users/kruthi/scripts/grabHDR.py. We can move this to a better place later, and also improve the script for auto adjusting the exposure time to avoid saturations.
10427   Fri Aug 22 18:05:02 2014 AndresUpdateIMCUpgrade of the IMC WFSs for the reflection

# Upgrade of IMC Reflection Optical Setup

Nick and I upgrade the IMC. We move both WFSs and placed them facing west. When aligning the beam into the WFS, we make sure that the beam were hitting the center of the mirrors and then we placed the lenses in their corresponding position. We used the beam scanner to measure the waist and the waist in the second WFS was bigger than 1mm, and the second WFS was a little bit below than 1mm. We center the beam in the WFSs and in the PD. We did haven't measure whether we have a good Gouy Phase. Below I attached the picture of how the new setup look like.

1934   Fri Aug 21 17:49:47 2009 YoichiSummaryComputersUpgrade FE conceptual plan
I started to draw a conceptual diagram of the upgraded FE system.
http://nodus.ligo.caltech.edu:30888/FE/FE-Layout.html
(It takes some time to load the page for the first time)

Some places, tips will pop up when you stop the cursor over an object.
You can also click on the LSC block to see inside.

This is just a start point, so we should add more details.
The source of the diagrams are in the svn:

I used yEd (http://www.yworks.com/en/products_yed_about.html) to make
the drawings. It is Java, so works on many platforms.
3553   Thu Sep 9 14:42:40 2010 josephbUpdateCDSUpdating suspensions model

I've been working on updating the suspensions model, incorporating Koji's refinements as well as trying to simplify the model and making it less cluttered.

This had the side benefit of making an incorrect connection obvious.  I had incorrectly wired the ASCPIT input to be summed into the yaw path, and the ASCYAW input into the pitch path.  This has been corrected.

I've finished a single optic, and now I am in the process of propagating the changes to all the optics, as well as cleaning up the overall diagram using Rolf's new tags, which make things much less cluttered.  I've attached a screenshot of the PRM optic control model, and will be updating the Matlab web export once I've updated the full model.

8003   Tue Feb 5 12:08:43 2013 Max HortonUpdateSummary PagesUpdating summary pages

Getting started:  Worked on understanding the functionality of summary_page.py.  The problem with the code is that it was written in one 8000 line python script, with sparse documentation.  This makes it difficult to understand and tedious to edit, because it's hard to tell what the precise order of execution is without tracing through the code line by line.  In other words, it's difficult to get an overview of what the code generally does, without literally reading all of it.  I commented several functions / added docstrings to improve clarity and start fixing this problem.

Crontab:  I believe I may have discovered the cause of the 6PM stop on data processing.  I am told that the script that runs the summary_pages.py is called every 6 hours.  I believe that at midnight, the script is processing the next day's data (which is essentially empty) and thus not updating the data from 6PM to midnight for any of the days.

Git:  Finally, created git repository called public_html/__max_40m-summary_testing to use for testing the functionality of my changes to the code (without risking crashing the summary_pages).

4270   Thu Feb 10 14:07:18 2011 josephbUpdateCDSUpdating dolphin drivers to eliminate timeouts when one dolphin card is shutdown

[Joe,Alex]

Alex came over and we installed the new Dolphin drivers so that the front ends using the Dolphin PCIe RFM network don't pause for a long time when one of the other nodes in the network go down.  Generally this pause would cause the code to time out and quit.  Now you can take c1lsc or c1sus down without having the other have problems.

We did note on reboot however, that the Dolphin_wait script sometimes (not always) seems to hang.  Since this is run at boot up, to ensure the dolphin card has had enough to allocate memory space for data to be written/read from by the IOP process, it means nothing else in the startup script gets run if it does happen.  In this case, running "pkill dolphin_wait" may be necessary.

Note that you may still have problems if you hit the power button to force a shutdown (i.e. holding it for 4 seconds for immediate power off), but as long as you do a "reboot" or "shutdown -r now" type command, it should come down gracefully.

What was done:

Alex grabbed the code from his server, and put it /home/controls/DIS/ on fb.

He ran the following commands in that directory to build the code.

./configure  '--with-adapter=DX' '--prefix=/opt/DIS'

make

sudo make install

He proceeded to modify the /diskless/root/etc/rc.local to have the line:

insmod /lib/modules/2.6.34.1/kernel/drivers/dis/dis_kosf.ko

In that same file he commented out

cd /root

and

exec /bin/bash/

He then modified the run levels in /diskless/root/etc/inittab. Level 0, level 3, and level 6 were changed:

l0:0:wait/etc/rc.halt

l3:3:wait:etc/rc.level3

l6:6:wait:/etc/rc.reboot

Then he created the scripts he was refering to:

rc.level3 is just:

exec /bin/bash

rc.halt is:

/opt/DIS/sbin/dxtool prepare-shutdown 0 sleep 3 halt -p

rc.reboot is:

reboot

Basically rc.halt calls a special code which prepares the Dolphin RFM card to shutdown nicely.  This is why just hitting the power button for 4 seconds will cause problems for the rest of the dolphin network.

We then checked out of svn the latest dolphin.c in  /opt/rtcds/caltech/c1/core/advLigoRTS/src/fe

The Dolphin RFM cards have a new numbering scheme.  4 is reserved for special  broadcasts to everyone, so the Dolphin node IDs now start at 8.  So we needed to change the c1lsc and c1sus Dolphin node IDs.

To change them we went to /etc/dis/dishosts.conf on the fb machine, and changed the following lines:

HOSTNAME: c1sus ADAPTER:  c1sus_a0 4 0 4 HOSTNAME: c1lsc ADAPTER:  c1lsc_a0 8 0 4

to

HOSTNAME: c1sus ADAPTER:  c1sus_a0 8 0 4 HOSTNAME: c1lsc ADAPTER:  c1lsc_a0 12 0 4

The FE models for the c1lsc and c1sus machines were recompiled and then the computers were rebooted.  After having them come back up, we tested that there was no time out by shutting down c1lsc and watching c1sus. We then reveresed and shutdown c1sus while watching c1lsc.  No problems occured.  Currently they are up and communicating fine.

4220   Fri Jan 28 12:15:58 2011 josephbUpdateCDSUpdating conlog channel list/ working on "HealthCheck" script

I've updated the scan_adls script (currently located in /cvs/cds/caltech/conlog/bin) to look at new location of our medm screens.  I made a backup of the old conlog channel list as /cvs/cds/caltech/conlog/data/conlog_channels.old-2011-01-28.

I then ran the update_chanlist script in the same directory, which calls the scan_adl script.  After about 5 minutes it finished updating the channel list.  I restarted the conlogger just to be sure, and checked that our new model channels showed up in the conlog (which they do).

I have added a cron job to the op340m cron tab to once a day run the update_conlog script at 7am.

Next, I'm working on a HealthCheck script which looks at the conlog channel list and checks to see if channels are actually changing over short time scales, and then spit back a report on possibly non-functioning channels to the user.

6518   Wed Apr 11 12:25:11 2012 RyanUpdateComputersUpdating aLIGO Conlog

Over the next few days, I will be working on upgrading the aLIGO Conlog install to include new bugfixes distributed by Patrick T.  The currently running conlog *should* not be affected, but please let me know if it is (ryan.fisher@ligo.org).

6539   Tue Apr 17 10:55:50 2012 RyanUpdateComputersUpdating aLIGO Conlog

 Quote: Over the next few days, I will be working on upgrading the aLIGO Conlog install to include new bugfixes distributed by Patrick T.  The currently running conlog *should* not be affected, but please let me know if it is (ryan.fisher@ligo.org).

The upgrade to the aLIGO Conlog is completed.  The conlog is once again running on megatron in a screen session. (see http://nodus.ligo.caltech.edu:8080/40m/6396)

As mentioned in last post, we earlier made an error in making sure that all time series arrays go in with same sampling rate in CSD calculation. When we fixed that, our recursive method just blew out in all the efforts since then.

We suspect a major issue is how our measured sensing matrix (the cross-coupling matrix between different degrees of freedom on excitation) has significant imaginary parts in it. We discard the imaginary vaues and only use real parts for iterative method, but we think this is not the solution.

Here we present cross-spectral density of different channels representing the three sensed DOFs (normalized by ASD of no excitation data for each involved component) and the sensing matrix (TF estimate) calculated by normalizing the first cross spectral density plots column wise by the diagonal values. These are measured with existing ideal output matrix but with the new input matrix. This is to get an idea of how these elements look when we use them.

Note, that we used only 10 seconds of data in this run and used binwidth of 0.25Hz. When we used binwidth of 0.1 Hz, we found that the peaks were broad and highest at 13.1 Hz instead of 13 Hz which is the excitation frequency used in these measurements.

### How should we proceed?

• We feel that we should figure out a way to use the imaginary value of the sensing matrix, either directly or as weights representing noise in that particular data point.
• Should we increase the excitation amplitude? We are currently using 500 counts of excitation on coil output.
• Are there any other iterative methods for finding the inverse of the matrix that we should be aware of? Our current method is rudimentary and converges linearly.
• Should we use the absolute value of the sensing matrix instead? In our experience, that is equivalent to simply taking ratios of the PSD of each channel and does not work as well as the TF estimate method.
2267   Fri Nov 13 14:04:27 2009 josephb, kojiUpdateComputersUpdated wiki with RCG instructions/tips

I've placed some notes pertaining to what Koji and I have learned today about getting the RCG code working on the 40m wiki at:

http://lhocds.ligo-wa.caltech.edu:8000/40m/Notes_on_getting_the_CDS_Realtime_Code_Generator_working

We're still trying to fix the tst system, as the moment its reporting an invalid number of daq channels and during daq initialization it fails.  (This from the /cvs/cds/caltech/target/c1tst/log.txt file). Note: This problem is only on megatron and separated from the conventional DAQ system of the 40m.

cpu clock 2800014
Warning, could open /rtl_mem_tst' read/write (errno=0)
configured to use 2 cards
Initializing PCI Modules
2 PCI cards found
***************************************************************************
ADC 0 is a GSC_16AI64SSA module
Channels = 64
Firmware Rev = 512

***************************************************************************
1 DAC cards found
DAC 0 is a GSC_16AO16 module
Channels = 16
Filters = None
Output Type = Differential
Firmware Rev = 3

***************************************************************************
0 DIO cards found
***************************************************************************
0 IIRO-8 Isolated DIO cards found
***************************************************************************
0 IIRO-16 Isolated DIO cards found
***************************************************************************
0 Contec 32ch PCIe DO cards found
0 DO cards found
***************************************************************************
0 RFM cards found
***************************************************************************
Initializing space for daqLib buffers
Initializing Network
Found 1 frameBuilders on network
Waiting for EPICS BURT at 0.000000 and 0 ns 0x3c40c004
BURT Restore = 1
Waiting for Network connect to FB - 10
Reconn status = 0 1
Reconn Check = 0 1
Initialized servo control parameters.
DAQ Ex Min/Max = 1 32
DAQ Tp Min/Max = 10001 10094
DAQ XTp Min/Max = 10094 10144
DAQ buffer 0 is at 0x8819a020
DAQ buffer 1 is at 0x8839a020
daqLib DCU_ID = 10
DAQ DATA INFO is at 0x3e40f0a0
Invalid num daq chans = 0
DAQ init failed -- exiting

2268   Fri Nov 13 15:01:07 2009 JenneUpdateComputersUpdated wiki with RCG instructions/tips

 Quote: I've placed some notes pertaining to what Koji and I have learned today about getting the RCG code working on the 40m wiki at: http://lhocds.ligo-wa.caltech.edu:8000/40m/Notes_on_getting_the_CDS_Realtime_Code_Generator_working We're still trying to fix the tst system, as the moment its reporting an invalid number of daq channels and during daq initialization it fails.  (This from the /cvs/cds/caltech/target/c1tst/log.txt file).

Dmass tells me that you have to record at least one channel.  ie at least one channel in your .ini file must be set to acquire, otherwise the DAQ will flip out.  It seems to be unhappy when you're not asking it to do things.

2269   Fri Nov 13 22:01:54 2009 KojiUpdateComputersUpdated wiki with RCG instructions/tips

I continued on the STAND ALONE debugging of the megatron codes.

- I succeeded to run c1aaa with ADC/DAC. (c1aaa is a play ground for debugging.)

The trick was "copy DAC block from sam.mdl to aaa.mdl".
I don't understand why this works. But it worked.
I still have the problem of the matrices. Their medm screens are always blank. Needs more works.

- Also I don't understand why I can not run the build of c1tst when I copy the working aaa.mdl to tst.mdl.

- The problem Joe reported: "# of channels to be daqed" was solved by

make uninstall-daq-aaa make install-daq-aaa 

This command is also useful.

daqconfig

- Now I am in the stable development loop with those commands

killaaa make uninstall-daq-aaa make aaa make install-aaa make install-daq-aaa make install-screens-aaa startaaa 

usage: ./go_build aaa

- Note for myself: frequently visited directories

/home/controls/cds/advLigo/src/epics/simLink (for model) /home/controls/cds/advLigo (to build) /cvs/cds/caltech/target/c1aaa (realtime code log)
/cvs/cds/caltech/target/c1aaaepics (ioc log) /cvs/cds/caltech/medm/c1/aaa (medm screens) /cvs/cds/caltech/chans (filter coeffs)  /cvs/cds/caltech/chans/daq (daq settings)

2270   Sat Nov 14 06:46:48 2009 KojiUpdateComputersUpdated wiki with RCG instructions/tips

I am still working on the c1aaa code. Now it seems that C1AAA is working reasonably (...so far).

1) At a certain point I wanted clean up the system status. I have visited /etc/rc.local to add c1aaa for realtime to non-realtime task

before: /usr/bin/setup_shmem.rtl mdp mdc tst& after: /usr/bin/setup_shmem.rtl mdp mdc tst aaa& 

I rebooted the system several times.

sudo /sbin/reboot

2) I found that gabage medm screens accumulated in ~/cds/advLigo/build/aaaepics/medm after many trials with several simulink models.
This directory is always copied to /cvs/cds/caltech/medm/c1/aaa at every make install-screens-aaa
This caused very confusing MEDM screens in the medm dir like C1AAA_ETMX_IN_MATRX.adl (NOT ETMY!)

I did

cd ~/cds/advLigo
make clean-aaa 

to refresh aaaepics dir. The current development procedure is

killaaa  make clean-aaa  make uninstall-daq-aaa make aaa make install-aaa make install-daq-aaa make install-screens-aaa startaaa

3) Sometimes startaaa does not start the task properly. If the task does not work, don't abandon.
Try restart the task. This may help.

  killaaa
(deep breathing several times)
startaaa

What to do next:

- MEDM works

* make more convenient custom MEDM screens so that we can easily access to the filters and switches
* retrofit the conventional SUS MEDM to the new system

- once again put/confirm the filter coeffs and the matrix elements

- configure DAQ setting so that we can observe suspension motion by dataviewer / dtt

- connect the suspension to megatron again

- test the control loop

2278   Tue Nov 17 00:42:12 2009 KojiUpdateComputersUpdated wiki with RCG instructions/tips

Dmass, Joe, Koji

### "The RGC code does not work unless the name of the mdl file (simulink model) matches to the model name "

The model name is written in the second line. This is automatically modified if the mdl file is saved from simulink.
But we copied the model by using "cp" command. This prevent from the TST model working!

megatron:simLink>head tst.mdl Model {   Name                    "tst"   Version                 7.3   MdlSubVersion           0 ... ... ...

This explained why the AAA model worked when the DAC block has been copied from the other model.
This was not because of the ADC block but the saving model fixed the model name mismatch!

### Now our current working model is "C1TST". Most of the functionalities have been implemented now:

• The simulink model has been modified so that some of the functionalities can be accomodated, such as LSC/ASC PIT/ASC YAW.
• Some filter names are fixed so as to inherit the previous naming conventions.
• The SUS-ETMY epics screen was modified to fit to the new channel names, the filter topologies, and the matrices.
• The chans file was constructed so that the conventional filter coefficients are inherited.
• All of the gains, filter SWs, matrix elements have been set accordingly to the current ETMY settings.
• burt snapshot has been taken: /cvs/cds/caltech/target/c1tstepics/controls_1091117_024223_0.snap burtrb -f /cvs/cds/caltech/target/c1tstepics/autoBurt.req -o controls_1091117_024223_0.snap -l /tmp/controls_1091117_024215_0.read.log -v

### What to do next:

• Revisit Oplev model so that it accomodates a power normalization functionality.
• ETMY QPD model is also missing!
• Clean up mdl file using subsystem grouping
• Check consistency of the whitening/dewhitening switches.
• Test of the controllability
• BTW, what is happened to BIO?
• Implementation of the RFM card

### Directories and the files:

• The .mdl file is backed up as  /home/controls/cds/advLigo/src/epics/simLink/tst.mdl.20091116_2100 
• The default screens built by "make" is installed in
/cvs/cds/caltech/medm/c1/tst/ They are continuously overridden by the further building of the models. 
• The custom-built medm screens are stored in  /cvs/cds/caltech/medm/c1/tst/CustomAdls/

The backup is
/cvs/cds/caltech/medm/c1/tst/CustomAdls/CustomAdls.111609_2300/ 
• The custom-built chans file is  /cvs/cds/caltech/chans/C1TST.txt 
The backup is
/cvs/cds/caltech/chans/C1TST.111609 
• burt snap shot file
/cvs/cds/caltech/target/c1tstepics/controls_1091117_024223_0.snap 
14461   Fri Feb 15 20:07:02 2019 JonUpdateVACUpdated vacuum punch list

While working on the vac controls today, I also took care of some of the remaining to-do items. Below is a summary of what was done, and what still remains.

## Completed today

• TP2/3 overcurrent interlock raised from 1 to 1.2 A. This was tripping during normal operation as the pump accelerates from low-speed (standby) to normal-speed mode.
• Interlock conditions on VABSSCO/VABSSCI removed. Per discussion with Steve, these are not vent valves, but rather isolation valves between the BS/IOO/OMC annuli. The interlocks were preventing the valves from opening, and hence the IOO and OMC annuli from being pumped.
• Channel exposed for interlocking in-vacuum high-voltage drivers. The channel name is C1:Vac-interlock_high_voltage. The vac interlock service sets this channel's value to 0 when the main volume pressure is in the range 3 mtorr-500 torr, and to 1 otherwise.
• Annuli pumping integrated into the set of recognized states. "Vacuum normal" now refers to TP1 and TP2 pumping on the main volume AND TP3 pumping on all the annuli. The system is currently running in this state.
• TP1 lowered to the nominal speed setting recommended by Steve: 33.6 krpm (560 Hz).

## Still remaining

• Implement a "blinker" input-output signal loop between two Acromags to detect hardware failures like the one today.
• Add an AC power monitor to sense extended power losses and automatically put the system into safe shutdown.
• Migrate the RGA to c1vac. Still some issues getting the serial comm working.
• Troubleshoot the SuperBee (backup) main volume Parani gauge. It has not communicated with c1vac since a serial adapter was replaced two weeks ago. Chub thinks the gauge was possibly damaged by arcing during the replacement.
• Scripting for more automated pumpdowns.
• Generate a bootable backup hard drive for c1vac, which could be swapped in on a short time scale after a failure.
10957   Thu Jan 29 16:14:10 2015 manasaUpdateGeneralUpdated to do list for FOL

Since there will be some work that supposedly will involve moving stuff on the table and racks; here is the updated to-do list for FOL.

4134   Tue Jan 11 13:32:52 2011 josephb, kiwamuUpdateCDSUpdated some DAQ channel names

[Joe, Kiwamu]

We modified the activateDAQ.py script which lives in /opt/rtcds/caltech/c1/chans/daq/ and updates the C1SUS.ini, C1MCS.ini, C1RMS.ini, C1SCX.ini and C1SCY.ini files.  These files contain the DAQ channels for all the optics.

It has been modified so that channels like C1:SUS-ITMX_ULSEN_OUT_DAQ become C1:SUS-ITMX_SENSOR_UL.  Similarly the oplev signals go from C1:SUS-ITMX_OLPIT_OUT to C1:SUS-ITMX_OPLEV_PERROR.

After some debugging, we ran the script successfully and checked the output was correct.  We then restarted the frame builder (telnet fb 8088 and then shutdown) and also hit the DAQ reload button for all the front ends.

I tested in dataviewer that I could go back several years as well as going back just 1 hour in the history and see data for C1:SUS-ITMX_SENSOR_LL as well as C1:SUS-ITMX_OPLEV_YERROR.  I also tested realtime is also working for these channels.

The contents of the script are below.

inputfiles=["C1SUS.ini","C1RMS.ini","C1MCS.ini","C1SCX.ini","C1SCY.ini"] prefix="[C1:SUS-" optics=["BS_","ITMX_","ITMY_","PRM_","SRM_","MC1_","MC1_","MC2_","MC3_","ETMX_"] #channels=["SUSPOS_IN1","SUSPIT_IN1","SUSYAW_IN1","SUSSIDE_IN1","ULSEN_OUT","URSEN_OUT","LRSEN_OUT","LLSEN_OUT","SDSEN_OUT","OL_SUM_IN1","OLPIT_IN1","OLYAW_IN1"] channels_dict = {'SUSPOS_IN1':'SUSPOS_IN1_DAQ', 'SUSPIT_IN1':'SUSPIT_IN1_DAQ', 'SUSYAW_IN1':'SUSYAW_IN1_DAQ', 'SUSSIDE_IN1':'SUSSIDE_IN1_DAQ', 'ULSEN_OUT':'SENSOR_UL', 'URSEN_OUT':'SENSOR_UR', 'LRSEN_OUT':'SENSOR_LR', 'LLSEN_OUT':'SENSOR_LL', 'SDSEN_OUT':'SENSOR_SIDE', 'OLPIT_OUT':'OPLEV_PERROR', 'OLYAW_OUT':'OPLEV_YERROR', 'OL_SUM_OUT':'OPLEV_SUM'} suffix="_DAQ]\n" ## set datarate datarate=2048 ## read the ini files for inputfile in inputfiles:     print inputfile     outputfile=inputfile     ifile = open(inputfile,'r')     lines = ifile.readlines()     ifile.close()     for k in range(len(lines)):         for op in optics:             for ch in channels_dict:                 if (prefix+op+ch+suffix) in lines[k]:                     lines[k]=prefix + op + channels_dict[ch] + "]\n"                     lines[k+1]=lines[k+1].lstrip("#").rstrip(lines[k+1].split("=")[1])+"1\n"                     lines[k+2]=lines[k+2].lstrip("#")                     lines[k+3]=lines[k+3].lstrip("#").rstrip(lines[k+3].split("=")[1])+str(datarate)+"\n"                     lines[k+4]=lines[k+4].lstrip("#")     ofile = open(outputfile,'w')     for k in range(len(lines)):         ofile.write(lines[k])         #print lines[k]     ofile.close() `

4160   Fri Jan 14 20:39:20 2011 ranaUpdateCDSUpdated some DAQ channel names

I like this activateDAQ script, but someone (Jenne with Joe's help) still needs to add the PEM channels - we still cannot see any seismic trends.

4292   Mon Feb 14 21:59:35 2011 ranaUpdateCDSUpdated some DAQ channel names

Although Joe and Kiwamu claim that they have inserted the correct DAQ names for the OPLEVs (e.g. PERROR and YERROR) back in Jan. 11, when I look today, I see that these channels are missing!

## I want my PERROR/YERRORs back!

4300   Tue Feb 15 11:56:17 2011 josephbUpdateCDSUpdated some DAQ channel names
That is my fault for not running the activateDAQ.py script after a round of rebuilds. I have run the script this morning, and confirmed that the oplev channels are showing up in dataviewer.

Quote:

Although Joe and Kiwamu claim that they have inserted the correct DAQ names for the OPLEVs (e.g. PERROR and YERROR) back in Jan. 11, when I look today, I see that these channels are missing!

## I want my PERROR/YERRORs back!

10108   Fri Jun 27 18:07:38 2014 NichinUpdateComputer Scripts / ProgramsUpdated script for acquiring data from Agilent 4395A network analyzer

The updated script for remotely getting data from Agilent 4395A network analyzer is located at /users/nichin

This network analyzer device is located at crocetta.martian (192.168.113.108)

### How to run the script:

> python NWAG4395A_modified.py [filename.yml]

1. The script accepts sweep parameters and output options via a .yml file that is written following a template that can be found at /users/nichin/NWAG4395template.yml
2. The data obtained is stored as a .dat file and the corresponding details regarding the acquired data is in a .par parameter file
3. You can choose to get a plot of the data obtained by specifying it in the .yml file. The plots are automatically stored as PDF.
4. Plots, data and parameter files are all stored in a new folder that is created with a timestamp in its name.
5. NOTE: Plotting options are only available in computers running numpy versions of 1.6.0 or above. The plotting sections of the code worked on Chiara, which has a 1.6.1 numpy, but did not work on Rossa which only had 1.3.0 numpy. Anyway, I have added an extra function that checks the version and skips the plotting part if needed.

### Test Run:

I connected a simple 2MHz Low pass filter between the modulation output and signal input of the NA and ran a scan from 0Hz to 20MHz. The script was run from Chiara.

The expected plot was obtained and is attached here.

### Further work:

I now have to work on setting up the RF switch in rack 1Y1 to select between required PDs and also on the code that chooses which channel is being selected.

There is also a problem of 2 8x1 RF switches being present, instead of one 16x1. Alex's code for RF switching does not take this into account.

### RXA: I've deleted your plot because it didn't meet the minimal Bode plot standards. Please look up "Bode Plot" using Google/Wikipedia and try to follow some good example. Bode plot should contain Phase as well as magnitude. Also, the axes must be labeled with some physical units.

10111   Mon Jun 30 00:18:15 2014 NichinUpdateComputer Scripts / ProgramsUpdated script for acquiring data from Agilent 4395A network analyzer

Quote:

### RXA: I've deleted your plot because it didn't meet the minimal Bode plot standards. Please look up "Bode Plot" using Google/Wikipedia and try to follow some good example. Bode plot should contain Phase as well as magnitude. Also, the axes must be labeled with some physical units.

Sorry Rana for not giving much attention to the plot. I will definitely change the way they are being plotted.

I was more focused on getting the data acquisition to work. Also, the current script gets only the magnitude and not the phase... I still have to work on that.

15429   Wed Jun 24 22:47:21 2020 YehonathanUpdateWikiUpdated phase maps webpage
I uploaded the new phase maps measurements made by GariLynn to nodus and updated the optics phase maps page.
I also added MetroPro and Matlab analysis for these phase maps.
3546   Wed Sep 8 14:44:37 2010 josephbUpdateCDSUpdated parse_mdl_to_ipc.py and feCodeGen.pl

I updated parse_mdl_to_ipc.py to correctly work with the 3 new cdsIPCx parts, namely cdsIPCx_PCIE (for dolphin connections), cdsIPCx_RFM (for our traditional reflected memory connections), and cdsIPCx_SHMEM (local shared memory on the computer).  These parts replaced cdsIPCx awhile back (see here ).

The code now correctly counts each type independantly with regards to ipcNum (I.e. you can have ipcNum = 0 for RFM and ipcNum = 0 for SHMEM for example).

I also went in and modified a few sections of the feCodeGen.pl (in /opt/rtcds/caltech/c1/core/advLigoRTS/src/epics/util/) so as to properly assign names to matrix adl files, matrix of filter bank adl files, and filter bank adl files.

4344   Wed Feb 23 11:53:30 2011 josephbUpdateCDSUpdated mx drivers

Alex and I updated the open mx drivers from 1.3.3 to 1.3.901 (1.4 release candidate).  We downloaded the drivers from: http://open-mx.gforge.inria.fr/

We put them in /root/open-mx-1.3.901 on the fb machine (and thus get mounted by all the front ends.).  We did configure and make and make install.

We did a quick check with /opt/mx/bin/mx_info on the fb machine at this point and realized the MAC addresses and host names were all messed up, including two listings for c1iscex with different mac addresses (neither of which was c1iscex).

We then brought all the front ends mx_streams down, brought the fb down, then cleared all the peer names with mx_hostname.  We then brought the fb up, and the front end mx_stream processes.

/opt/mx/mx_info now shows a clean and correct set of hostnames and mac addresses.  Testpoints and trends are working.

2872   Mon May 3 16:53:27 2010 josephbUpdateCDSUpdated lsc.mdl and the ifo plant model with memory locations

I've updated the LSC and IFO models that Rana created with new shared memory locations.  I've used the C1:IFO- for the ifo.mdl file outputs, which in turn are read by the lsc.mdl file.  The LSC outputs being lsc control signals are using C1:LSC-.  Optics positions would presumably be coming from the associated suspension model, and am currently using SUP, SPX, and SPY for the suspension plant models (suspension vertex, suspension x end, suspension y end).

I've updated the web view of these models on nodus.  They can be viewed at: https://nodus.ligo.caltech.edu:30889/FE/

I've also created a C1.ipc file in /cvs/cds/caltech/chans/ipc  which assigns ipcNum to each of these new channels in shared memory.

11745   Tue Nov 10 02:34:28 2015 gautamUpdateLSCUpdated interpretation of peaks

After thinking about the interpretation of the various peaks seen in the scan through 2 FSRs, I have revised the information presented in the previous elog. Yutaro pointed out that the modulation frequency isn't exactly 11MHz, but according to this elog, is 11.066209 MHz. So instead of using mod(11e6,FSR), I really should have been using mod(11.066209,FSR) and mod(5*11.066209,FSR) to locate the positions of the 11MHz and 55MHz sidebands relative to the carrier resonances. With this correction, the 'unknown' peaks identified in Attachment #1 in elog 11743 are in fact the 55MHz sideband resonances.

However, this means that the peaks which were previously identified as 55MHz sideband resonances have to be interpreted now - I'm having trouble identifying these. If we assume that the types of peaks present in the scan are 11 MHz sideband, 55MHz sideband, and the TEM00, TEM10, TEM20, TEM30, and TEM40 mode resonances, then the peaks marked in grey in Attachment #1 to this elog can be interpreted as TEM30 (right of a carrier resonance) and TEM40 (left of a carrier resonance) mode resonances - however, the fitted center frequencies differ from the expected center frequencies (determined using the same method as elog 469) by ~3% (for TEM30) and ~20% (for TEM40) - therefore I am skeptical about these peaks, particularly the 4th HOM resonances. In any case, they are the smallest of all the peaks, and any correction due to them will be small.

The updated modulation depths are as follows (computed using the same method as described in elog 11743, the updated plot showing the ratio of bessel functions as a function of the modulation depth is Attachment #2 in this elog):

@11.066209 MHz ---- 0.179

@5*11.066209 MHz --- 0.226

These numbers are now reasonably consistent with those reported in elog10211.

As for the mode-matching efficiency, the overall number is almost unchanged if I assume the TEM30 peaks are accurately interpreted: 92.11%. But the dominant HOM contribution comes from the first HOM resonance: (TEM00 = 1, TEM20 = 0.0325, TEM10 = 0.0475, TEM30 =  0.0056). These numbers may change slightly if the 4th HOM resonances are also correctly identified.

ETMx is still not well behaved and the mode cleaner isnt too happy either, so I think we will save the measurement of the round trip arm loss for daytime tomorrow.

11746   Tue Nov 10 11:06:02 2015 yutaroUpdateLSCUpdated interpretation of peaks
Quote:
 Quote: - modulation depth = 0.390 +/- 0.062

There are two modulation frequencies that make it to the arm cavities, at ~11MHz and ~55MHz. Each of these will have their own modulation depth indepedent of each other. Bundling them together into one number doesn't tell us what's really going on.

I'm sorry. I misunderstood two things when writing elog 11741: the number of modulation frequencies, and how to distinguish modulation peaks and HOM peaks.

Now, I report about interpretation of the peaks marked in grey in Attachment #1 in elog 11745.

Summary:

The peaks marked in grey are interpreted as 3rd and 4th HOM resonance, if we assume that the radius of curvature of ETMY is slightly different from measured value. (measured: 57.6 m --> assumed: 59.3 m)

What I have done:

I plotted the differences in frequency between HOM peaks and 00 mode peaks (see Attachment #1) vs. expected orders of modes. The plot is shown in Attachement #2.

By fitting these data points, I calculated most likely value of gradient of this plot. This value corresponds: g_ITMYg_ETMY=0.3781. However, measured data of the radii of curvature suggests that g_ITMYg_ETMY=0.358. Assuming that this disagreement comes from the difference between measured and real values of ROC of ETMY (ITM is almost flat so that change of ROC of ITM doesn't have significant effect on g_ITMg_ETM), ROC of ETMY should be 59.3 m, different from measured value 57.6 m.

What I'd like to know:

-- Is such disagreement of ROC usual? Could it happen?

-- Are there any other possible explanations for this disagreement (or interpretations of the peaks marked in grey)?

ELOG V3.1.3-