40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 231 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  2578   Mon Feb 8 15:01:46 2010 robUpdateABSLSuddenly a much better alignment of PRC

Quote:

I just aligned PRM and locked PRC and I noticed that SPOB is much higehr than it used to be. It's now about 1800, vs 1200 than it used to be last week.

Isn't anyone related to that? If so, may I please know how he/she did it?

 oops, my bad.  I cranked the 33MHz modulation depth and forgot to put it back.  The slider should go back to around 3. 

  2579   Mon Feb 8 15:41:51 2010 AlbertoUpdateABSLSuddenly a much better alignment of PRC

Quote:

Quote:

I just aligned PRM and locked PRC and I noticed that SPOB is much higehr than it used to be. It's now about 1800, vs 1200 than it used to be last week.

Isn't anyone related to that? If so, may I please know how he/she did it?

 oops, my bad.  I cranked the 33MHz modulation depth and forgot to put it back.  The slider should go back to around 3. 

 I was actually hoping that the alignment got better.

  259   Thu Jan 24 12:50:50 2008 JohnSummaryTreasureSugar Napoleons
Some pictures from the group meeting yesterday.
Attachment 1: Sweeties.pdf
Sweeties.pdf
  8945   Wed Jul 31 09:51:43 2013 SteveUpdatesafetySujan receives safety training

Sujan got 40m specific basic safety training this morning.

Attachment 1: IMG_0031.JPG
IMG_0031.JPG
  7024   Wed Jul 25 11:25:27 2012 MashaUpdateGeneralSummary

This week, I have been mainly working on my new neural network project, and working with the BLRMS channels.

New Neural Network Project:

Rana and I read a paper which demonstrated the use of a neural network to control an inverted pendulum. Since the test masses are, in simplest terms coupled harmonic oscillators with six degrees of freedom, we suspect something similar can be done. The logic behind trying to use a neural network as a control system lies in the fact that the actual motion of the test masses is a complicated function of many variables (including environment variables, such as temperature and seismic disturbance as well), and neural networks, at the core, are function approximators, which can approximate a function as a combination of polynomials (with error 0 in a closed interval) or of sigmoidal functions (which, in the papers I've read, seems to be possible in practice - the authors also reference some theoretical results regarding this). Thus, this network could, in theory take the displacement in the degrees of freedom of the OSEMS and generate the actuation force.

However, there was the question of building a neural network which explicitly took the history of a time series into account, and not only implicitly in the neuron weights. Thus, I found recurrent neural networks, which, for some T (this will ultimately be related to the sampling frequency, or spectrum of the signal),  has T hidden sub-layers which pass in the output of the T previous iterations.

I have written Matlab code that generates, for a given T and neuron vector (the number of neurons in each of the T layers) a recurrent neural network (it still, like my old network, uses gradient descent and sigmoidal activation functions). However, I needed a system to run it on, so I began playing around with Simulink. I have never used this system before, so I took a bit of time doing the tutorials, but I currently have a damped, driven harmonic oscillator which accepts a force at each time step and outputs a displacement (taking into account the earlier forces). This afternoon, I think I will link it to my recurrent neural network, which can accept a displacement and output a force, and see what happens. These networks are notoriously slow to converge, but I could at least check to see that my code (and understanding of the algorithm) is correct. Should this work, I can also try hooking it up to Sasha's simulation, which is more complex than an oscillator with one degree of freedom.

As Far as Seismic Things Go:

I haven't worked with seismic noise itself very much this week, although the signals could be used as inputs to a neural network. I moved the STS1 and GUR1 cables, which I realized were crossed and thus stupidly placed (my fault) and now have STS1 on the very end of the Y arm (GUR1 is about 10 meters down the X arm, however, so Jenne and I will probably have to make a cable). I also found granite and foam, so at least the STS can be given a final position at the end of the arm.

BLRMS:

I added two new channels to the BRLMS, for 0.01 - 0.03 Hz and 0.03 - 0.1 Hz, so that we can better observe distant earthquakes. I also changed the MEDM screen for all of the ACC, GUR, and STS RMS channels (I think Liz is also using this for her MIC channels), combining the low pass and high pass filter screens into a screen demonstrating the complete RMS process, which squaring and square roots. I have also changed the RMS filters, and wrote an Elog about that process.

The paper Rana and I read is Charles W. Anderson, Learning to Control and Inverted Pendulum Using Neural Networks

A good paper of recurrent neural network basics is Mikael Boden, "A guide to recurrent neural networks and backpropagation"

 


 

 

  13601   Fri Feb 2 21:12:46 2018 Udit KhandelwalSummaryGeneralSummary - 2018/02/02

Tip-Tilt Suspension CAD:
Discussed with Koji about motivation to simplify the design of this assembly, which has many unnecessary over-constraints. I have started to cad alternate parts with the aim of removing these over-constraints.

40m Lab CAD:
Acquired a stack of original engineering drawings of the vacuum chambers from Steve which I will take home, get scanned, and then use as reference for the cad i'm working on.

Other:
Started paperwork at west bridge office to get paid as an "occasional employee". Hopefully I receive old money.

  13865   Fri May 18 18:14:18 2018 Udit KhandelwalSummaryGeneralSummary 05/18/2018

Tip-Tilt Suspension Design:

Designed a new ECD plate and changed dimensions of the side arms after discussing with Koji. After getting feedback on the changes, I will finish the assembly and send it to him to get approved for manufacturing.

 

  13884   Wed May 23 19:24:37 2018 Udit KhandelwalSummaryGeneralSummary 05/23/2018

Tip-Tilt Redesign Project with Koji:

Did further itirations to the ECD backplate. Going to determine minimum thickness between magnet hole and plus sign for eddy current damping.

Chamber optical table layouts

Finished the positioning of optics and instruments in SolidWorks for the Vertex chambers. The reference for positioning is "40m_upgrade_layout_Dec2012.dwg", and solidworks files I created are in the main 40m CAD folder.

  13638   Fri Feb 16 21:03:17 2018 Udit KhandelwalSummaryGeneralSummary 2018/02/16

40m Lab Cad:
Updated the dimensions of and fleshed out the chambers in greater detail, by referring to the engineering drawings that Steve gave to me. I have scanned and uploaded most of these drawings to Dropbox in [40mShare]>[40m_cad_models]>[Vacuum Chamber Drawing Scans]. The excel file "LIGO 40m Parts List" in the [40m Lab CAD] folder also lists the Steve drawings I referenced for dimensions of each part.


Next steps:
1. Finish details of all chambers.
2. Start placing representative blocks on the optical table.

  13677   Fri Mar 9 20:35:41 2018 Udit KhandelwalSummaryGeneralSummary 2018/03/09

1. Optical Table Layout 

I had discussed with Koji a way to record coordinates of optical table equipments in a text file, and load to solidworks. The goal is to make it easier to move things around on the table in the CAD. While I have succeeded in importing coordinates through txt files, there is still a lot of tediousness in converting these points into sketches. Furthermore, the task has to be redone everytime a coordinate is added to or changed in the txt file. Koji and I think that this can all be automated through solidworks macros, so I will explore that option for the next two weeks.

2. Vacuum Chamber CADs 

Steve will help find manufacturing drawings of the BS chamber. I have completed the ETM chambers, while the ITM ones are identical to them so I will reuse parts for the CAD. 

  11380   Fri Jun 26 23:18:52 2015 Eve ChaseUpdateCDSSummary Page Updates

Motivation:

My SURF project largely focuses on updating and improving the 40m summary pages. I began to explore and experiment with the already existing summary page code to better understand the required code and eventually lead to tangible improvements of the summary pages.

 

What I did:

I practiced moving from one tab of the summary pages to another. Specifically, I copied the ETM Optical Levers plot from SUS: OpLev to Sandbox, without removing it from its original location. Additionally, I created my own tab to further test the summary pages, titled “Eve”.

KA ed: The configuration files are located at /cvs/cds/caltech/chans/GWsummaries. It is under svn control.

Result:

All changed appeared on the summary pages without much hassle and without any errors.

  11585   Wed Sep 9 11:33:58 2015 ranaUpdateSummary PagesSummary Page updates
  • Made most plots in IOO tab only plot when MC_TRANS > 10000 using Eve's MC_LOCK state definition.
  • added the 0.03 - 0.1 Hz and 10-30 Hz bands to the PEM SEIS BLRMS tab and set the y-scales to the same as SeismicRainbowSTS.stp
  • set state PMC_LOCK in PSL tab and made some of those plots only plot when PMC trans > 0.6.
  • SUS-OL page showed me that the ETM yaw spectrum was wacky, which lead me to find that it was completely uncentered. Stop leaving the room lights ON Steve!!  angry I also set the quadrant offsets by blocking the QPD with a piece of metal (teflon doesn't work).
  • set c1summary to only plot some when X or Y arms are locked
  12400   Thu Aug 11 11:51:38 2016 PrafulUpdateComputer Scripts / ProgramsSummary Pages

The summary pages have been updated with the new naming seismometer channel naming conventions. Here's a link to them working on my own page: https://ldas-jobs.ligo.caltech.edu/~praful.vasireddy/1154908817-1154909717/pem/seismic/
 

Let me know if the actual pages aren't working when they come back online or if there's something that needs to be changed.

  7032   Wed Jul 25 17:35:44 2012 LizUpdateComputer Scripts / ProgramsSummary Pages are in the right place!

The summary pages can now be accessed from the "Daily Summary" link under LOGS on the 40 meter Wiki page.

  16893   Mon Jun 6 16:09:23 2022 ranaConfigurationDetCharSummary Pages: seis BLRMS

I updated the config file c1pem.ini in /users/public_html/detcharsummary/ConfigFiles, and commited it so I hope it works, but I did not have git push permissions. Does anyone know what is the idea here? Should we do our own personal git clone and modify that way or shoudl we do it with the control account.

Wiki needs to clear out all the outdated information on this workflow.

The changes are to make the y-scales useful. Currently, all of the past seis BLRMS plots are not so useful because the scales have not been set based on the actual signal levels. Let's see if this works, and we  can re-evaluate after a few weeks.

  11884   Tue Dec 15 18:08:22 2015 Max IsiUpdateGeneralSummary archive cleaning cron job

I have added a new cron job in pcdev1 at CIT using the 40m shared account. This will run the /home/40m/DetectorChar/bin/cleanarchive script one minute past midnight on the first of every month. The script removes GWsumm archive files older than 1 month old.

  3169   Wed Jul 7 17:05:30 2010 steve, ranaUpdateSAFETYSummary of Crane Damage/Malfunction

The 1 Ton yellow crane support beam jammed up at Friday morning, June 25.

 

The 40m vertex crane has a folding I-beam support to reach targeted areas. The rotating I-beam is 8 ft long. The folding extension arm gives you another 4 ft.

The 12 ft full reach can be achieved by a straightening of the 4 ft piece. There is a spring loaded latch on the top of the I-beam that locks down when the two I-beams align.

This lock joins the two beams into one rigid support beam for the jib trolley to travel.  The position of this latch is visible when standing below, albeit not very well.

To be safe it is essential that this latch is locked down fully before a load is put on the crane.

 

We were preparing to pump down the 40m vacuum system on Friday morning. The straight alignment of the 8 and 4 ft piece made us believe that

the support beams were locked. In reality, the latch was not locked down. The jib trolley was driven to the end of the 12 ft I-beam. The 200 lbs ITM-east door was lifted

when the 4 ft section folded 50 degrees around the pivot point. This load of door + jib-trolley + 4 ft I-beam made the support beam sag about 6 inches

The door was removed from the jib hoist with the blue Genie-lift. The sagging was reduced to ~3".

 

The Genie-lift platform was raised to support the sagging crane jib-trolley. The lab was closed off to ensure safety and experts were called in for consultation. It was decided to bring in professional riggers.

 

Halbert Brothers, Inc. rigging contractor came to the lab Tuesday morning to fix the crane. The job was to unload the I-beam with safety support below. They did a very good job.

 

The static deformation of I-beams sprung back to normal position. There are some deformation of the I-beam ~2 mm where the beams were jammed under load.

It is not clear if this is a new deformation or if the crane sections have always been mis-aligned by a couple of mm.

 

The crane was tested with 450 lbs load at 12 ft horizontal travel position. The folding of I-beams were repeatedly tested for safe operation. Its a 1 ton crane, but we tested it with 450 lbs because that's what we had on hand.

 

We're working on the safety upgrade of this lift to prevent similar accident from happening.

Pictures below:

Atm 1)   load testing 2007

Atm 2)   jammed-sagging under ~400 lbs, horizontal          

Atm.3)   jammed-folded 50 degrees, vertical     

Atm.4)   static deformation of I-beams

Atm.5)   unloading in progress with the help of two A-frames          

Atm.6)   it is unloaded

Atm.7-8) load testing        

Atm.9)   latch locked down for safe operation            

Atm.9)   zoom in of the crane sections misalignment    

Attachment 1: DSC_0026_00.JPG
DSC_0026_00.JPG
Attachment 2: P1060408.JPG
P1060408.JPG
Attachment 3: P1060415.JPG
P1060415.JPG
Attachment 4: P1060413.JPG
P1060413.JPG
Attachment 5: P1060421.JPG
P1060421.JPG
Attachment 6: P1060423.JPG
P1060423.JPG
Attachment 7: P1060441.JPG
P1060441.JPG
Attachment 8: P1060436.JPG
P1060436.JPG
Attachment 9: P1060425.JPG
P1060425.JPG
Attachment 10: P1060432.JPG
P1060432.JPG
  13472   Wed Dec 13 17:46:08 2017 Udit KhandelwalSummaryGeneralSummary of Current Tasks

40m Lab CAD

1. 40m_bldg.dwg has 2D drawing of the 40m building

  • After importing file as a 2D sketch into solidworks, make sure to retrace all the lines before performing any 3D extrusion stuff.
  • Made walls 3m high

2. 40m_VE.dwg has the Vaccuum Envelope.

  • Divided the file into individual sketches for the tubes, test mass, and beam splitter chambers (so they can be individually modified later if required).

3. 40melev.dwg has the relative positioning between (1) and (2).

  • Using this file to position objects inside building cad.

4. All files can be found in Dropbox folder [40m SOS Modeling], which should be renamed to [40m CAD].

5. Next step would be to add the optical table, mirrors.

Tip-Tilt Suspension

1. Current objective: (refer to D070172) - Increase the length of the side arms (so it matches the dimensions of D960001), while keeping the test mass subassembly at the same height.
2. Future objective: Resonant frequency FEM of the frame (sans the test mass), and then change height to get the desired frequency.

Past Work

  • Completed solidworks model of SOS (D960001). I understand this is not the focus right now so this is for reference that the model is ready to be used.

Comments

  • I will be in India from 16th December until 6th January so this is my final visit for this year. I have enough material to work from home, and will correspond with Koji over email regarding Lab CAD and tip-tilt suspension.
  407   Mon Mar 31 14:01:40 2008 jamieSummaryLSCSummary of DC readout PD non-linearity measurements
From March 21-26, I conducted some measurements of the response non-linearity of some mock-up DC readout photodetectors. The detectors are simple:
Vbias ---
        |
       PD
        |-------- output
     resistor
        |
       ---
        -
This is a description of the final measurement.

The laser current modulation input was given a 47Hz sine wave at 20mV. A constant small fraction of the beam was shown onto the reference detector, and a beam that was varied in DC power level was incident on the test detector. Spectra were taken from both detectors at the same time, 0.25Hz bandwidth, over 100 averages.

At each incident power level on the test detector, the Vpk in all multiples of the modulation frequency were measured (ie. V[i*w]). The difference between the 2f/1f ratio in the test and reference was then calculated, ie:
V_test[2*w]/V_test[1*w] - V_ref[2*w]/V_ref[1*w]
This is the solid black line in the plot ("t21-r21_v_power.png").

The response of a simulated non-linear detector was also calculated based on the Vpk measured at each harmonic in the reference detector, assuming that the reference detector had a purely linear response, ie:
V_nl[beta,2*w]/V_nl[beta,1*w] - V_l[2*w]/V_l[1*w]
these are the dashed colored lines in the plot ("t21-r21_v_power.png").

The result of the measurement seems to indicate that the non-linearity in the test detector is less than beta=-1.

The setup that was on the big optics table south of the laser, adjacent to the mode cleaner, is no longer needed.
Attachment 1: t21-r21_v_power.png
t21-r21_v_power.png
  6422   Thu Mar 15 08:48:40 2012 RyanSummaryCDSSummary of Syracuse Visit to 40m Mar 5-9 2012

JIMS Channels in PEM Model

The PEM model has been modified now to include the JIMS(Joint Information Management System) channel processing. Additionally Jim added test points at the outputs of the BLRMS.

For each seismometer channel, five bands are compared to threshold values to produce boolean results.  Bands with RMS below threshold produce bits with value 1, above threshold results in 0.  These bits are combined to produce one output channel that contains all of the results.

A persistent version of the channel is generated by a new library block that called persist which holds the value at 0 for a number of time steps equal to an EPICS variable setting from the time the boolean first drops to zero. The persist allows excursions shorter than the timestep of a downsampled timeseries to be seen reliably.

The EPICS variables for the thresholds are of the form (in order of increasing frequency):
C1:PEM-JIMS_GUR1X_THRES1
C1:PEM-JIMS_GUR1X_THRES2
etc.
 
The EPICS variables for the persist step size are of the form:
C1:PEM-JIMS_GUR1X_PERSIST
C1:PEM-JIMS_GUR1Y_PERSIST
etc.

The JIMS Channels are being recorded and written to frames:

The two JIMS channels at 2048:
[C1:PEM-JIMS_CH1_DQ] Persistent version of JIMS channel. When bit drops to zero indicating something bad (BLRMS threshold exceeded) happens the bit stays at zero  for >= the value of the persist EPICS variable.
[C1:PEM-JIMS_CH2_DQ] Non-persistent version of JIMS channel.

And all of the BLRMS channels at 256:
Names are of the form:
[C1:PEM-RMS_ACC1_F0p1_0p3_DQ]
[C1:PEM-RMS_ACC1_F0p3_1_DQ]

For additional details about the JIMS Channels and the implementation, please see the previous elog entries by Jim.

 

Conlog

I have a working aLIGO Conlog/EPICS Log installed and running on megatron.

Please see this wiki page for the details of use:
https://wiki-40m.ligo.caltech.edu/aLIGO%20EPICs%20log%20%28conlog%29

I also edited this page with restart instructions for megatron:
https://wiki-40m.ligo.caltech.edu/Computer_Restart_Procedures#megatron

Please see Ryan's previous elog entries for installation details.

Future Work

  • Determine useful thresholds for each band
  • Generate MEDM Screens for JIMS Channels
  • Add a decimation option to channels
  • Add EPICS Strings in PEM model to describe bits in JIMS Channels
  • Add additional JIMS Channels: Testing additional characterization methods
  • Implement a State Log on Megatron: Will Provide a 1Hz index into JIMS Channels
  • Generate a single web page that allows access to aLIGO Conlog/EPICS Log and State Log

 

  1783   Thu Jul 23 10:05:38 2009 AlbertoUpdatePSLSummary of the latest adventures with the alignment of the mode cleaner

Alberto, Koji,

Summary of the latest adventures with the alignment of the mode cleaner

Prior events.

  • Last week, on July 12th the RFM network crashed (elog entry 1736). I don't know for sure which one was the cause and which one the effect, but also C1DAQADW was down and it didn't want to restart. Alex fixed it the day after.
  • On the evening of Sunday July 20th I noticed that the mode cleaner was unlocked. A closer inspection showed me that MCL was frozen at -32768 counts. To fix that I rebooted C1DCUEPICS and burtrestored to snapshots from the day before.
  • On Tuesday July 21st another failure of the RFM Network made necessary a reboot of the frame builder and of all front end computers (entry 1772). As a consequence, the mode cleaner couldn't get locked anymore, even if the mirror's sliders in the MC-Align MEDM screen were in the proper positions. At that time I missed to check the MC suspension positions as a way to ensure that the MC hadn't really changed. Although later, as it turned out, that would have been useless anyway since all the data record prior to the computers crash of that day somehow had been corrupted (entry 1774). Neither the MC2 LSC control or MC ASC control could engage so I (erroneously) thought that some tune of the periscope might help. So I did but, since the Mode Cleaner was misaligned, that had the effect of spoiling the good matching of the periscope to the MC cavity.
  • Yesterday, Wednesday July 22nd, I found out about the sticky slider effect (entry 1776). At that point we didn't have anymore a way to know that the MC optics were actually in their proper original alignment state because of the lack of a reference for those in the data record (as I wrote above). I had to go back to the periscope and fix the alignment.


Chronicles of periscope and MC alignment

Yesterday morning I started aligning the periscope but it turned out to be trickier than usual. With the ASC (Alignment Sensing Control) off and only the length controls on, the Mode Cleaner didn't lock easily, although I knew I wasn't very far from the sweet spot.

In the afternoon the struggle continued and the matching of the the beam to the MC cavity became just worse. At some point I noticed that the ASC inputs somehow had got on - although the ASC still looked disabled from the MClock MEDM main screen. So I was actually working against the Wave Front Sensors and further worsening the periscope alignment.

That hurled me to the weeds. After hours of rowing across the stormy waters of a four-dimensional universe I got to have occasional TEM00 flashes at the transmission but still, surprisingly, no MC locking. Confused, I kept tuning the periscope but that just kicked me off road again.

Then at about 7pm Koji came to my rescue and suggested a more clever and systematic way to solve the problems. He suggested to keep record of the MC mirrors alignment state and re-align the cavity to the periscope. Then we would gradually bring the cavity back to the original good position changing the periscope alignment
at the same time.

 

That would have worked straight away, if we hadn't been fighting against a subtle and cruel enemy: the 40m computer network. But I (as John Connor), and Koji (as the Terminator) didn't pull back.

Here's a short list of the kinds of weapons that the computers threw to us:

  1. After a while the FSS entered a funny state. It showed transmission: we had light at the MC (and even flashes) but the MEDM readout of the FSS transmitted power after the cavity was low (~0.019). Also the spot on the monitor showed a slightly different pattern from how I remembered it. On the other side the transmission camera didn't show that typical halo as usual.
  2. MCL was frozen at 32768. I ran the MCDown and MCUp script a couple of times and that unstuck it.
  3. On op340m we found that the MC autolocker script wasn't running. So I restarted it. Still nothing changed: bright and sharp flashes appeared on the monitor (sign of a not too bad alignment) but no lock.
  4. I rebooted C1IOO. No change.
  5. I rebooted C1DCUEPICS and burtrestored the EPICS computers to Jul 19th. No change.
  6. Then I burtrestored the c1psl.snapshot and that finally did something. The FSS reflected spot changed and the halo appeared again at its transmission camera. Soon after the MC got locked.


We then proceeded with Koji's plan. In an iterative process, we aligned the MC cavity maximizing the transmission and tuned the periscope in order to match the Faraday input of the interferometer. The last thing we did it by looking at the camera pointing at the Faraday isolator.

We found that we didn't have to tune the periscope much. That means that all afternoon I didn't really go too far, but the autolocker wasn't working properly, or it wasn't working at all.

Then we ran the alignment script for the X arm but it didn't work before we aligned the steering mirrors.

Then we ran it three times but could not get more than 0.87 at TRX. That means that there we still have to work on the alignment to the Faraday. That's job for today in the trenches of the lab.

 

  3738   Mon Oct 18 18:33:46 2010 KojiSummaryCOCSummary of the main mirrors & their phasemap measurement

I have made a summary web page for the 40m upgrade optics.

https://nodus.ligo.caltech.edu:30889/40m_phasemap/

I made a bunch of RoC calculations along with the phase maps we measured.
Those are also accommodated under this directory structure.

Probably.... I should have used the wiki and copy/paste the resultant HTML?

  6521   Wed Apr 11 17:56:26 2012 JenneUpdateGeneralSummary of things to figure out with the IFO

Questions:

Power recycling gain

   * It should be ~40, but we observe/measure it to be ~7.  Even if mode matching of ~50% is assumed, gain is calculated to be ~15

   * Would like to measure PR gain independent of mode matching, if possible

Power recycling cavity mode matching

   * Reflectivity of PRMI was measured to be ~50%.  That's pretty high.  What's going on?

   * Even if we're mode matched to the arm, are we appropriately mode matched to the PRC?

Is beam from MC clipped in the Faraday?

   * We had to use MC axis for input pointing since PZTs aren't totally working.

   * Need to measure IPPOS beam for different MC alignments to see if horizontal waist measurement stays constant.

PRM flipped?

   * Not likely, but it can't hurt to confirm for sure.

   * Want to know, since it could give us a different plan for MMT moving than if the PRM is correct.

Thick optic non-normal incidence in IPPO - does this exaggerate astigmatism, which would help explain IPPOS measurement?

Is PRC waist same size / position as arm cavity waist, given the current "known" positions of all the optics?

   * How is this effected by moving the PRM?

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

Measurements to take and what information they give us:

IPPOS beam scan, with MC as-is

   * Confirm (or not) IPPOS measurements from last week

IPPOS beam scan with different MC alignments

   * Will tell us about Faraday clipping, if any

AS beam scan, misaligned PRM, misaligned SRM, misaligned ITMX, single bounce from ITMY

   * Can only take this measurement if beam is bright enough, so we'll just have to try

   * Will confirm IPPOS measurement, but includes going through the thick PRM, so can compare to calculated intra-PRC mode

REFL beam scan (already done....is the data satisfactory? If so, no need to redo), single bounce off of PRM

   * Will tell us about the potential PRM flipping

   * Need to compare with calculated mode at REFL port for flipped or non-flipped PRM

Look at POP camera, see 2nd pass through cavity

   * Try to match 1st and 2nd pass.  If they don't match, we're not well matched to PRC mode

Look at beam directly on ETMY cage, then beam from ETM, bounce off ITM, back to ETM cage

   * If the beams are the same size, we're well matched to arm cavity mode

   * Use fancy new frame-grabber.

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

MMT code things to calculate, and what information it gives us:

REFL beam path, for PRM flipping comparison

Thick IPPO non-normal incidence - I'm not sure how to do this yet, since I only know how non-normal incidence changes effective radii of curvature, and this is a flat optic, so *cos(theta) or /cos(theta)  won't do anything to an infinite RoC

Compare PRC waist to arm cavity waist, using "known" optic positions

Mode matching sensitivity to MC waist measurements

Mode matching sensitivity to PRM position

  5127   Fri Aug 5 20:37:34 2011 jamieSummaryGeneralSummary of today's in-vacuum work

[Jamie, Suresh, Jenne, Koji, Kiwamu]

After this morning's hiccup with the east end crane, we decided to go ahead with work on ETMX.

Took pictures of the OSEM assemblies, we laid down rails to mark expected new position of the suspension base.

Removed two steering mirrors and a windmill that were on the table but where not being used at all.

Clamped the test mass and moved the suspension to the edge of the table so that we could more easily work on repositioning the OSEMs.  Then leveled the table and released the TM.

Rotated each OSEM so that the parallel LED/PD holder plates were oriented in the vertical direction.  We did this in the hopes that this orientation would minimize SD -> POS coupling.

For each OSEM, we moved it through it's full range, as read out by the C1:SUS-ETMX_{UL,UR,LL,LR,SD}PDMon channels, and attempted to adjust the positions so that the read out was in the center of the range (the measured ranges, mid values, and ultimate positions will be noted in a follow-up post).  Once we were satisfied that all the OSEMs were in good positions, we photographed them all (pictures also to follow).

Re-clamped the TM and moved it into it's final position, using the rails as reference and a ruler to measure as precisely as possible :

ETMX position change: -0.2056 m = -20.56 cm = -8.09 in (away from vertex)

Rebalanced the table.

Repositioned the mirror for the ETMX face camera.

Released TM clamps.

Rechecked OSEM centering.

Unblocked the green beam, only to find that it was displaced horizontally on the test mass about half an inch to the west (-y).  Koji determined that this was because the green beam is incident on the TM at an angle due to the TM wedge.  This presents a problem, since the green beam can no longer be used as a reference for the arm cavity.  After some discussion we decided to go with the TM position as is, and to realign the green beam to the new position and relock the green beam to the new cavity.  We should be able to use the spot position of the green beam exiting the vacuum at the PSL table as the new reference.  If the green X beam exiting at the PSL table is severely displaced, we may decide to go back in and move ETMX to tweak the cavity alignment.

At this point we decided that we were done for the day.  Before closing up, we put a piece of foil with a hole in it in front of the the TM face, to use as an alignment aperture when Kiwamu does the green alignment.

Kiwamu will work on the green alignment over the weekend.  Assuming everything works out, we'll try the same procedure on ETMY on Monday.

  5130   Sat Aug 6 03:10:05 2011 SureshSummaryGeneralSummary of today's in-vacuum work

The table below gives the OSEM positions as seen on the slow chanels C1:SUS-ETMX_{UL,UR,LL,LR,SD}PDMon

ETMX_OSEMs.png

Note that the side OSEM has the fast channel (OUTPUT) available and we used that to locate it.

When we began work the OSEMs were photographed so that we have a record of their locations till now.  It was difficult to get accurate estimate of the magnet offset inside the OSEM we could not see the screen on the camera while clicking.  We then took some pictures after finishing the work. These are given below

 

          Before_osem_adj.JPG         After_osem_adjustment.JPG

 

The picture of the left is from before OSEMs were moved. It can be seen that OSEMs are rotated to make sure that the magnets avoid touching the teflon sheets which hold the shadow sensors.  The picture on the right shows the positions of the OSEMs after we adjusted their positions.  This time we kept the teflon sheets vertical as shown to minimise the coupling between the Side and Axial directions.

We needed to reposition them once again after we moved the tower to the center of the table.

Pictures with more detail will be posted to the wiki later.

 

 

 

 

  5131   Sat Aug 6 13:38:02 2011 ranaSummaryGeneralSummary of today's in-vacuum work

This OSEM placement is just the OPPOSITE of what the proper placement is.

Usually, we want to put them in so that the LED beam is vertical. This makes the OSEM immune to the optic's vertical mode.

The orientation with the horizontal LED beam makes the immunity to the side mode better, but may spoil the vertical.

In reality, neither of these assumptions is quite right. The LED beam doesn't come out straight. That's why Osamu and I found that we have to put in some custom orientations.

Also, the magnet gluings relative to the OSEM bracket centers are not perfectly aligned. So...I am saying that the OSEMs have to be oriented empirically to reduce the couplings which we want to reduce.

 

  11431   Mon Jul 20 16:45:15 2015 Max IsiConfigurationGeneralSummary page c1sus.ini error corrected

Bad syntax errors in the c1sus.ini config file were causing the summary pages to crash: a plot type had not been indicated for plots 5 and 6, so I've made these "timeseries."
In the future, please remember to always specify a plot type, e.g.:

BAD:

5 = C1:SUS-ETMX_SUSPIT_INMON.mean,
       C1:SUS-ITMY_SUSPIT_INMON.mean,

GOOD:

3 = C1:SUS-ETMX_SUSPIT_INMON.mean,
       C1:SUS-ITMY_SUSPIT_INMON.mean timeseries

By the way, the pages will continue to be unavailable while I transfer them to the new shared account.

  12135   Wed May 25 14:21:29 2016 Max IsiUpdateGeneralSummary page configuration

I have modified the c1summary.ini and c1lsc.ini configuration files slightly to avoid overloading the system and remove the errors that were preventing plots from being updated after certain time in the day.

The changes made are the following:
1- all high-resolution spectra from the Summary and LSC tabs are now computed for each state (X-arm locked, Y-arm locked, IFO locked, all);
2- I've removed MICH, PRCL & SRCL from the summary spectrum (those can still be found in the LSC tab);
3- I've split LSC into two subtabs.

The reason for these changes is that having high resolution (raw channels, 16kHz) spectra for multiple (>3) channels on a single tab requires a *lot* of memory to process. As a result, those jobs were failing in a way that blocked the queue, so even other "healthy" tabs could not be updated.

My changes, reflected from May 25 on, should hopefully fix this. As always, feel free to re organize the ini files to make the pages more useful to you, but keep in mind that we cannot support multiple high resolution spectra on a single tab, as explained above.

  15309   Wed Apr 22 13:52:05 2020 gautamUpdateDetCharSummary page revival

Covid 19 motivated me to revive the summary pages. With Alex Urban's help, the infrastructure was modernized, the wiki is now up to date. I ran a test job for 2020 March 17th, just for the IOO tab, and it works, see here. The LDAS rsync of our frames is still catching up, so once that is up, we can start the old condor jobs and have these updated on a more regular basis.

  15696   Wed Dec 2 18:35:31 2020 gautamUpdateDetCharSummary page revival

The summary pages were in a sad state of disrepair - the daily jobs haven't been running for > 1 month. I only noticed today because Jordan wanted to look at some vacuum trends and I thought summary pages is nice for long term lookback. I rebooted it just now, seems to be running. @Tega, maybe you want to set up some kind of scripted health check that also sends an alert.

  11375   Thu Jun 25 12:03:42 2015 Max IsiUpdateGeneralSummary page status

The summary pages have been down due to incompatibilities with a software update and problems with the LDAS cluster. I'm working at the moment to fix the former and the LDAS admins are looking into the latter. Overall, we can expect the pages will be fully functional again by Monday.

  11376   Thu Jun 25 14:18:46 2015 Max IsiUpdateGeneralSummary page status

The pages are live again. Please allow some time for the system to catch up and process missed days. If there are any further issues, please let me know.
URL reminder: https://nodus.ligo.caltech.edu:30889/detcharsummary/

Quote:

The summary pages have been down due to incompatibilities with a software update and problems with the LDAS cluster. I'm working at the moment to fix the former and the LDAS admins are looking into the latter. Overall, we can expect the pages will be fully functional again by Monday.

 

  11411   Tue Jul 14 16:47:18 2015 EveUpdateSummary PagesSummary page updates continue during upgrade

I've continued to make changes to the summary pages on my own environment, which I plan on implementing on the main summary pages when they are back online.

 

Motivation:

I created my own summary page environment and manipulated data from June 30 to make additional plots and change already existing plots. The main summary pages (https://nodus.ligo.caltech.edu:30889/detcharsummary/ or https://ldas-jobs.ligo.caltech.edu/~max.isi/summary/) are currently down due to the CDS upgrade, so my own summary page environment acts as a temporary playground to continue working on my SURF project. My summary pages can be found here (https://ldas-jobs.ligo.caltech.edu/~eve.chase/summary/day/20150630/); they contian identical plots to the main summary pages, except for the Summary tab. I'm open to suggestions, so I can make the summary pages as useful as possible.

 

What I did:

  • SUS OpLev: For every already existing optical lever timeseries, I created a corresponding spectrum, showing all channels present in the original timeseries. The spectra are now placed to the right of their corresponding timeseries. I'm still playing with the axes to make sure I set the best ranges.
  • SUSdrift: I added two new timeseries, DRMI SUS Pitch and DRMI SUS Yaw, to add to the four already-existing timeseries in this tab. These plots represent channels not previously displayed on the summary pages
  • Minor changes
    • Added axis labels on IOO plot 6
    • Changes axis ranges of IOO: MC2 Trans QPD and IOO: IMC REFL RFPD DC
    • Changes axis label on PSL plot 6

 

Results:

So far, all of these changes have been properly implemented into my personal summary page environment. I would like some feedback as to how I can improve the summary pages.

 

 

  11257   Sun Apr 26 20:10:10 2015 max isiHowToGeneralSummary pages

I have set up new summary pages for the 40m: http://www.ligo.caltech.edu/~misi/summary/
This website shows plots (time series, spectra, spectrograms, Rayleigh statistics) of relevant channels and is updated with new data every 30 min.

The content and structure of the pages is determined by configuration files stored in nodus:/users/public_html/gwsumm-ini/ . The code looks at all files in that directory matching c1*.ini. You can look at the c1hoft.ini file to see how this works. Besides, a quick guide to the format can be found here http://www.ligo.caltech.edu/~misi/iniguide.pdf

Please look at the pages and edit the config files to make them useful to you. The files are under version control, so don’t worry about breaking anything.

Do let me know if you have any questions (or leave a comment in the pages).

  11261   Mon Apr 27 21:42:07 2015 ranaUpdateVACSummary pages

We want to have a VAC page in the summaries, so Steve - please put a list of important channel names for the vacuum system into the elog so that we can start monitoring for trouble.

Also, anyone that has any ideas can feel free to just add a comment to the summary pages DisQus comment section with the 40m shared account or make your own account.

  11279   Mon May 11 12:17:19 2015 max isiHowToGeneralSummary pages

I have created a wiki page with introductory info about the summary page configuration: https://wiki-40m.ligo.caltech.edu/Daily summary help

We can also use that to collect tips for editing the configuration files, etc.

Quote:

I have set up new summary pages for the 40m: http://www.ligo.caltech.edu/~misi/summary/
This website shows plots (time series, spectra, spectrograms, Rayleigh statistics) of relevant channels and is updated with new data every 30 min.

The content and structure of the pages is determined by configuration files stored in nodus:/users/public_html/gwsumm-ini/ . The code looks at all files in that directory matching c1*.ini. You can look at the c1hoft.ini file to see how this works. Besides, a quick guide to the format can be found here http://www.ligo.caltech.edu/~misi/iniguide.pdf

Please look at the pages and edit the config files to make them useful to you. The files are under version control, so don’t worry about breaking anything.

Do let me know if you have any questions (or leave a comment in the pages).

 

  15370   Wed Jun 3 11:20:19 2020 gautamUpdateDetCharSummary pages

Summary:

The 40m summary pages have been revived. I've not had to make any manual interventions in the last 5 days, so things seem somewhat stable, but I'm sure there will need to be multiple tweaks made. The primary use of the pages right now are for vacuum, seismic and PSL diagnostics.

Resources:

Caveats:

  • Intermittent failures of cron jobs
    • The status page relies on the condor_q command executing successfully on the cluster end. I have seen this fail a few times, so the status page may say the pages are dead whereas they're actually still running.
    • Similarly, the rsync of the pages to nodus where they're hosted can sometimes fail.
    • Usually, these problems are fixed on the next iteration of the respective cron jobs, so check back in ~half hour.
  • I haven't really looked into it in detail, but I think our existing C1:IFO-STATE word format is not compatible with what gwsumm wants - I think it expects single bits that are either 0 or 1 to indicate a particular state (e.g. MC locked, POX and POY locked etc). So if we want to take advantage of that infrastructure, we may need to add a few soft EPICS channels that take care of some logic checking (several such bits could also be and-ed together) and then assume either 0 or 1 value. Then we can have the nice duty cycle plots for the IMC (for example).
  • I commented out the obsolete channels (e.g. PEM MIC channels). We can add them back later if we so desire.
  • For some reason, the jobs that download the data are pretty memory-heavy: I have to request for machines on the cluster with >100 GB (yes 💯GB) ! of memory for the jobs to execute to completion. The frame-data certainly isn't so large, so I wonder what's going on here - is GWPy/GWsumm so heavy? The site summary pages run on a dedicated cluster, so probably the code isn't built for efficiency...
  • Weather tab in PEM is still in there but none of those channels mean anything right now.
  • The MEDM screenshot stuff is commented out for now too. This should be redone in a better way with some modern screen grab utilities, I'm sure there are plenty of python based ones.
  • There seems to be a problem with the condor .dag lockfile / rescue file not being cleared correctly sometimes - I am looking into this.
  15812   Wed Feb 17 13:59:35 2021 gautamUpdateDetCharSummary pages

The summary pages had failed because of a conda env change. We are dependent on detchar's conda environment setup to run the scripts on the cluster. However, for some reason, when they upgraded to python3.9, they removed the python3.7 env, which was the cause of the original failure of the summary pages a couple of weeks ago. Here is a list of thoughts on how the pipeline can be made better.

  1. The status checking is pretty hacky at the moment.
    • I recommend not using shell via python to check if any condor jobs are "held".
    • Better is to use the dedicated python bindings. I have used this to plot the job durations, and it has worked well.
    • One caveat is that sometimes, there is a long delay between making a request via a python command, and condor actually returning the status. So you may have to experiment with execution times and build some try/except logic to catch "failures" that are just the condor command timing out and not an actual failure of the summare jobs.
  2. The status check should also add a mailer which emails the 40m list when the job is held. 
    • With htcondor and python, I think it's easy to also get the "hold reason" for the job and add that to the mailer.
  3. The job execution time command is not executing correctly anymore - for whatever reason, the condor_history command can't seem to apply the constraint of finding only jobs run by "40m", although running it without the constraint reveals that these certainly exist. Probably has to do with some recent upgrade of condor version or something. This should be fixed.
  4. We should clear the archive files regularly. 
    • The 40m home directory on the cluster was getting full. 
    • The summary page jobs generate a .h5 archive of all the data used to generate the plots. Over ~1 year, this amounts to ~1TB.
    • I added the cleanArchive job to the crontab, but it should be checked.
    • Do we even need these archives beyond 1 day? I think they make the plotting faster by saving data already downloaded locally, but maybe we should have the cron delete all archive 
  5. Can we make our own copy of the conda env and not be dependent on detchar conda env? The downside is that if something dramatic changes in gwsumm, we are responsible for debugging ourselves.

Remember that all the files are to be edited on nodus and not on the cluster.

  11382   Mon Jun 29 17:40:56 2015 Max IsiUpdateGeneralSummary pages "Code status" page fixed

It was brought to my attention that the "Code status" page (https://nodus.ligo.caltech.edu:30889/detcharsummary/status.html) had been stuck showing "Unknown status" for a while.
This was due to a sync error with LDAS and has now been fixed. Let me know if the issue returns.

  11546   Sun Aug 30 13:55:09 2015 IgnacioUpdateIOOSummary pages MCF

The summary pages show the effect of the MCL FF on MCF (left Aug 26, right Aug 30):

 

I'm not too sure what you meant by plotting the X & Y arm control signals with only the MCL filter ON/OFF. Do you mean plotting the control signals with ONLY the T-240Y MCL FF filter on/off? The one that reduced noise at 1Hz?

 

 

  12910   Mon Mar 27 20:29:05 2017 ranaSummaryDetCharSummary pages broken again

Going to the summary pages and looking at 'Today' seems to break it and crash the browser. Other tabs are OK, but 'summary' is our default page.

I've noticed this happening for a couple of days now. Today, I moved the .ini files which define the config for the pages from the old chans/ location into the /users/public_html/detcharsummary/ConfigFiles/ dir. Somehow, we should be maintaining version control of detcharsummary, but I think right now its loose and free.

  11401   Fri Jul 10 17:57:38 2015 Max IsiUpdateGeneralSummary pages down

The summary pages are currently unstable due to priority issues on the cluster*. The plots had been empty ever since the CDS updated started anyway. This issue will (presubmably) disappear once the jobs are moved to the new 40m shared LDAS account by the end of next week.

*namely, the jobs are put on hold (rather, status "idle") because we have low priority in the processing queue, making the usual 30min latency impossible.

  12432   Tue Aug 23 09:50:17 2016 Max IsiUpdateGeneralSummary pages down due to cluster maintenance

Summary pages down today due to schedulted LDAS cluster maintenance. The pages will be back automatically once the servers are back (by tomorrow).

  12440   Thu Aug 25 08:19:25 2016 Max IsiUpdateGeneralSummary pages down due to cluster maintenance

The system is back from maintenance and the pages for last couple of days will be filled retroactively by the end of the week.

Quote:

Summary pages down today due to schedulted LDAS cluster maintenance. The pages will be back automatically once the servers are back (by tomorrow).

 

  11434   Tue Jul 21 21:33:22 2015 Max IsiUpdateGeneralSummary pages moved to 40m LDAS account

The summary pages are now generated from the new 40m LDAS account. The nodus URL (https://nodus.ligo.caltech.edu:30889/detcharsummary/) is the same and there are no changes to the way the configuration files work. However, the location on LDAS has changed to https://ldas-jobs.ligo.caltech.edu/~40m/summary/ and the config files are no longer version-controlled on the LDAS side (this was redundant, as they are under VCS in nodus).

I have posted a more detailed description of the summary page workflow, as well as instructions to run your own jobs and other technical minutiae, on the wiki: https://wiki-40m.ligo.caltech.edu/DailySummaryHelp

  12394   Wed Aug 10 17:30:26 2016 Max IsiUpdateGeneralSummary pages status
Summary pages are currently empty due to a problem with the code responsible for locating frame files in the cluster. This should be fixed soon and the
pages should go back to normal automatically at that point. See Dan Kozak's email below for details.


Date: Wed, 10 Aug 2016 13:28:50 -0700
From: Dan Kozak <dkozak@ligo.caltech.edu>


> Dan, maybe it's a gw_data_find problem?

Almost certainly that's the problem. The diskcache program that finds
new data died on Saturday and no one noticed. I couldn't restart it,
but fortunately it's author just returned from several weeks vacation
today. Smile He's working on it and I'll let you know when it's back up.

--
Dan Kozak
dkozak@ligo.caltech.edu
  12399   Thu Aug 11 11:09:52 2016 Max IsiUpdateGeneralSummary pages status
This problem has been fixed.

> Summary pages are currently empty due to a problem with the code responsible for locating frame files in the cluster. This should be fixed soon and the
> pages should go back to normal automatically at that point. See Dan Kozak's email below for details.
>
>
> Date: Wed, 10 Aug 2016 13:28:50 -0700
> From: Dan Kozak <dkozak@ligo.caltech.edu>
>
>
> > Dan, maybe it's a gw_data_find problem?
>
> Almost certainly that's the problem. The diskcache program that finds
> new data died on Saturday and no one noticed. I couldn't restart it,
> but fortunately it's author just returned from several weeks vacation
> today. Smile He's working on it and I'll let you know when it's back up.
>
> --
> Dan Kozak
> dkozak@ligo.caltech.edu
  5428   Thu Sep 15 22:31:44 2011 ManuelUpdateSUSSummary screen

I changed some colors on the Summary of Suspension Sensor  using my italian creativity.

I wrote a script in Python to change the thresholds for the "alarm mode" of the screen.

The script takes a GPS-format start time as the 1st argument and a duration time as the second argument.

For every channel shown in the screen, it compute the mean value during this time.

The 3rd argument is the ratio between the mean and the LOW threshold. The 4th argument is the ratio between the mean and the LOLO threshold.

Then it sets the thresholds simmetrycally for HIGH and HIHI threshold.

It does that for all channels skipping the Gains and the Off Sets because this data are not stored.

For example is ratio are 0.9 and 0.7 and the mean is 10, thresholds will be LOLO=7, LOW=9, HIGH=11, HIHI=13.

You can run the script on pianosa writing on a terminal '/opt/rtcds/caltech/c1/scripts/SUS/set_thresholds.py' and the arguments.

I already run my program with those arguments: 1000123215 600 0.9 0.7

The time is of this morning at 5:00 for 10 minutes

 

This is the help I wrote

HELP: This program set the thresholds for the "alarm mode" of the C1SUS_SUMMARY.adl medm screen.

 Written by Manuel Marchio`, visiting student from University of Pisa - INFN for the 2011 summer at Ligo-Caltech. Thrusday, 15th September 2011.

The 1st argument is the time in gps format when you want to START the mean

The 2nd argument is the DURATION

The 3rd argument is the ratio of the LOW and the HIGH thresholds. It must be in the range [0,1]

The 4th argument is the ratio of the LOLO and the HIHI thresholds. It must be in the range [0,1]

Example: path/set_thresholds.py 1000123215 600 0.9 0.7

and if the the mean is 10, thresholds will be set as LOLO=7, LOW=9, HIGH=11, HIHI=13

 

Attachment 1: sussum.png
sussum.png
  5467   Mon Sep 19 18:05:27 2011 ranaUpdateSUSSummary screen

Quote:

I changed some colors on the Summary of Suspension Sensor  using my italian creativity.

I wrote a script in Python to change the thresholds for the "alarm mode" of the screen.

I've started to fix up the script somewhat (as a way to teach myself some more python):

* moved all of the SUS Summary screen scripts into SUS/SUS_SUMMARY/

* removed the hardcoded channel names (a list of 190 hand-typed names !!!!!!!)

* fixed it to use NDS2 instead of try to use the NDS2 protocol on fb:8088 (which is an NDS1 only machine)

* it was trying to set alarms for the SUS gains, WDs, Vmons, etc. using the same logic as the OSEM PD values. This is non-sensical. We'll need to make a different logic for each type of channel.

New script is called setSensors.py. There are also different scripts for each of the different kinds of fields (gains, sensors, vmons, etc.)

Some Examples:

pianosa:SUS_SUMMARY 0> ./setDogs.py 3 5
Done writing new values.

sussum.png

  5500   Wed Sep 21 16:22:14 2011 ranaUpdateSUSSummary screen

The SUS SUMMARY screen is now fully activated. You should keep it open at all times as a diagnostic of the suspensions.

No matter how cool you think you are, you are probably doing something bad when trying to lock, measure any loop gains, set matrices, etc. Use the screen.

 

This is the link to the automatic snapshot of the SUS SUMMARY screen. You can use it to check the Suspensions status with your jPhone.

Auto SUS SUMMARY Snapshot

When the values go yellow its near the bad level. When its red, it means the optic is misaligned or not damped or has the wrong gain, etc.

So don't ignore it Steve! If you think the thresholds are set too low then change them to the appropriate level with the scripts is SUS/

ELOG V3.1.3-