40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 143 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  5449   Sun Sep 18 15:34:09 2011 KojiUpdateAdaptive FilteringModifications to LSC, RFM models, added OAF model

[Koji Kiwamu]

This modification of the LSC model made the rows of the LSC output matrix shifted. This caused the ASS scripts nonfunctional.

Kiwamu fixed the channel names in the ASS script.

Quote:

[Jenne, Mirko, with supervision from Jamie]

I modified the c1lsc model to have shmem outputs that go from the degrees of freedom to the OAF, and shmem inputs from the OAF's output to sum into the DoFs, just like Yoichi's FF stuff.  I also removed the old OAF_OUT, because it would only allow me to select one DoF at a time, and I will eventually want the ability to do multiple amounts of OAFing at the same time.  Hopefully.

 

  6110   Tue Dec 13 01:20:38 2011 DenUpdateAdaptive FilteringModifications to LSC, RFM models, added OAF model

Quote:

[Jenne, Mirko, with supervision from Jamie]

We are starting to create the new OAF model, so that it works with the new CDS system. 

 Why did you place Matt's code inside the simulink library and use the same library for all DOFs? I think this won't work out. Inside the .c code there are static variables. If all DOF use the same ADAPT_XFCODE() function, it means that they all mess there signals and coefficients with each other! Or the RCD during the compilation creates a copy of the function with the name of a library name in front? For example, ADAPT_MCL_ADAPT_XFCODE(). But then in the RCG manual it is claimed to name the .c file the same.

This problem can be fixed by creating .c files with proper names for each DOF. But here a memory question may arise. For 1 DOF we now have 28 witness channel. If we have a several minute filter, we use 28 * 104(filter length) * 3 (FIR coefficients, adapt input, corr input) * 8 (number of bytes in 1 double)  = 6.7 Mb / DoF. For 8 DOF we'll allocate ~55 Mb of memory in the kernel. The c1lsc cache size is 6 Mb per cpu. So we are definitely out of cache and it will take some time for a processor to communicate with ram. I wonder if it is OKEY for us to allocate this amount of memory as static arrays inside the kernel.

Now we use 6.7 Mb of memory because it seems to be a mistake with placing the same function for all DOF and we actually allocate for 1.

 

  2922   Wed May 12 12:32:04 2010 josephbConfigurationCDSModified /etc/rc.d/rc.local on megatron

I modified the /etc/rc.d/rc.local file on megatron removing a bunch of the old test module names and added the new lsc and lsp modules, as well as a couple planned suspension models and plants, to shared memory so that they'll work.  Basically I'm trying to move forward into the era of working on the actual model we're going to use in the long term as opposed to continually tweaking "test" models.

The last line in the file is now: /usr/bin/setup_shmem.rtl lsc lsp spy scy spx scx sus sup&

I removed mdp mdc mon mem grc grp aaa tst tmt.

  2542   Fri Jan 22 12:33:37 2010 josephb, alexUpdateComputersModified CDS_PARTS for Binary output

Turns out the CDSO32 part (representing the Contec BO-32L-PE binary output) rquires two inputs. One for the first 16 bits, and one for the second set of 16 bits.  So Alex added another input to the part in the library.  Its still a bit strange, as it seems the In1 represents the second set of 16 bits, and the In2 represents the first set of 16 bits.

I added two sliders on the CustomAdls/C1TST_ETMY.adl control screen (upper left), along with a bit readout display, which shows the bitwise and of the two slider channels. For the moment, I still can't see any output voltage on any of the DO pins, no matter what output I set.

 

  11574   Fri Sep 4 09:23:32 2015 IgnacioUpdateCDSModified Pentek schematic

Attached is the modifed Pentek whitening board schematic. It includes the yet to be installed 1nF capacitors  and comments. 

Attachment 1: schematic.pdf
schematic.pdf schematic.pdf schematic.pdf
  15941   Thu Mar 18 18:06:36 2021 gautamUpdateElectronicsModified Sat Amp and Coil Driver

I uploaded the annotated schematics (to be more convenient than the noise analysis notes linked from the DCC page) for the HAM-A coil driver and Satellite Amplifier.

  4251   Fri Feb 4 15:03:20 2011 josephbUpdateComputersModified cshrc.40m

Removed some lines from the PATH environment variable since they point to old codes which no longer work with the new frame builder and setup.

The change was:

#setenv PATH $LINUXPATH/bin:$GDSPATH/bin:$ROOTSYS/bin:$TDSPATH/bin:${SCRIPTPATH}:$PATH
setenv PATH $TDSPATH/bin:${SCRIPTPATH}:$PATH

  3940   Wed Nov 17 16:02:30 2010 josephbUpdateCDSModified feCodeGen.pl to fix filtMuxMatrix name generation

Problem:

Sometime in the last 3 weeks, probably when Alex brought his latest changes from Hanford to the 40m and did an SVN update, the code which generates the names of the filter .adl files links for the overall matrix view broke.

Fix:

I modified FE code gen to use $basename instead of the base name after the top name transform (this changes _ to - after the first 3 letters

@@ -3520,11 +3522,11 @@
 
                  my $tn = top_name_transform($basename);
                  my $basename1 = $usite . ":" . $tn . "_";
-                 my $filtername1 = $usite . $tn;
+                 my $filtername1 = $usite . $basename;

Still having problems:

The filter modules built with the matrix of filter modules run (offests/gains work), but will not load filter coefficients/filter names.  All the other filter modules outside the matrix seem to load fine.  At this point, doing a rebuild of any of the front end machines may cause the A2L filter banks to be unloadable.

 

  3860   Thu Nov 4 15:15:43 2010 josephbUpdateCDSModified feCodeGen.pl, fmseq.pl, and suspension screens

Feature Requested:

Have the CPU_meter change change color at various alarm levels.  These alarm levels have been set at 2/3 maximum for Minor alarm (yellow) and 9/10 maximum for Major alarm (red).

Implementation:

Rather than hand code each EPICS .db file to add the alarm files each time we rebuild the front ends, I decided to modify it at the source (since it strikes me as a generally useful alarm level for all front end codes).

First, I modified the feCodeGen.pl script.

I changed

print EPICS "OUTVARIABLE FEC\_$dcuId\_CPU_METER epicsOutput.cpuMeter int ai 0 field(HOPR,\"$rate\") field(LOPR,\"0\")\n";

to

print EPICS "OUTVARIABLE FEC\_$dcuId\_CPU_METER epicsOutput.cpuMeter int ai 0 field(HOPR,\"$rate\") field(LOPR,\"0\") field(HIGH,\"$two_thirds_rate\") field(HSV,\"MINOR\") field(HIHI,\"$     nine_tenths_rate\") field(HHSV,\"MAJOR\")\n";

I added the following two lines just before it as well:

$two_thirds_rate = int($rate * 2 / 3);

$nine_tenths_rate = int($rate * 9 / 10);

However, only the first four fields were actually added to the database file.  Apparently fmseq.pl, which populated the database, was hard coded to only handle up to 4 fields.

I modified the fmseq.pl script in /opt/rtcds/caltech/c1/core/advLigoRTS/src/epics/util/ so as to be able to handle up to 6 field values when writing EPICS .db files.

This change was accomplished by simply changing the following line

($junk, $v_name, $v_var, $v_type, $ve_type, $v_init, $v_efield1, $v_efield2, $v_efield3, $v_efield4 ) = split(/\s+/, $_);

to 

($junk, $v_name, $v_var, $v_type, $ve_type, $v_init, $v_efield1, $v_efield2, $v_efield3, $v_efield4, $v_efield5, $v_efield6 ) = split(/\s+/, $_);

everywhere it occurred.  There were something like 10 instances of it. Also, I added the two lines

        $vardb .= "    $v_efield5\n";
        $vardb .= "    $v_efield6\n";

after each set of

         $vardb .= "    $v_efield1\n";
         $vardb .= "    $v_efield2\n";
         $vardb .= "    $v_efield3\n";
         $vardb .= "    $v_efield4\n";

Lastly, I modified the CPU_METER bar graph on the C1SUS_DEFAULTNAME.adl screen (located in /opt/rtcds/caltech/c1/medm/master/) to use alarm levels, and then ran generate_master_screens.py.

 

  3606   Fri Sep 24 22:58:40 2010 josephbUpdateCDSModified front end medm screens

To startup medm screens for the new suspension front end, do the following:

1) From a control room machine, log into megatron

ssh -X megatron

2) Move to the new medm directory, and more specifically the master sub-directory

cd /opt/rtcds/caltech/c1/medm/master/

3) Run the basic sitemap in that directory

medm -x sitemap.adl

 

The new matrix of filters replacing the old ULPOS, URPOS, etc type filters is now on the screens.  This was previously hidden.  I also added the sensor input matrix entry for the side sensor.

Lastly, the C1SUS.txt filter bank was updated to place the old ULPOS type filters into the correct matrix filter bank.

 

The suspension controls still need all the correct values entered into the matrix entries (along with gains for the matrix of filter banks), as well as the filters turned on.  I hope to have some time tomorrow morning to do this, which basically involves looking at the old screens copying the values over.  The watch dogs are still controlled by the old control screens.  This will be fixed on Monday when I finish switching the front ends over from their sub-network to the main network, at which point logging into megatron will no longer be necessary.

  3609   Sun Sep 26 18:29:23 2010 rana, JohnUpdateCDSModified front end medm screens

Issues I notice on first glance:

  1. The OSEM Sensor Input matrix and the DOF2COIL Output matrix screens should be their own screens and linked from the overview. Right now they are not. Where is the input matrix?
  2. The SIDE GAIN looks like zero on the main screen, but the side OSEM signal seems to be getting through to the SIDE filter bank. . I think the wiring of the SIDE signal through the input matrix is bogus.
  3. The OUTPUT matrix seems to be the transpose of the previous OUTPUT matrix and we have lost the wires that connect the inputs and outputs to the matrix. We ought to think about how best to represent things on the OVERVIEW screen; probably only need to have a minimal representation and allow power users to open up the detailed screen.
  4. The TIME string is whited out. How will this be done? Does each FE display its local time on its EPICS screens?
  5. So far unable to get any channels on DV. How do we look at channels / test points?
  6. As far as we can tell, there is no connection between the output of the SUSPOS, etc. filter banks and the OUTPUT MATRIX. So....nothing actually goes to the coil driver. Its hard to imagine that this new SUS could have ever worked. Is there any evidence that the damping actually worked in the past, or was it something like "well, the watchdog values came down to small numbers eventually..." ???
  7. We are trying to debug the simulink file, but....the wiki entry on how to do this is out of date (yet updated as recently as August!) some path stuff just probably needs to be edited.

 megamind-poster3.jpg

Basically the suspensions are not functioning yet and we can't attempt locking of the MC.

  3794   Wed Oct 27 11:34:40 2010 josephbUpdateCDSModified rc.local for front end machines

What was the problem:

On reboot, c1sus was in a strange state.  The epics IOC was running, along with tpman, but there were no loaded front ends.

People had to manually run sudo insmod c1SYSfe.ko.

What was the cause:

Awhile back Alex had commented out the line in the rc.local file which actually loaded the front end modules (i.e. c1x02fe.ko, c1susfe.ko, etc).  This was while debugging.  He never put it back.

What was the solution:

I uncommented the following line in /diskless/root/etc/rc.local file on the fb machine:

/opt/rtcds/caltech/c1/target/$i/scripts/startupC1rt

Now on reboot, the c1sus machine should start up all the front ends listed in the rtsystab file, located in /diskless/root/etc/ on the fb machine.

 

  3919   Mon Nov 15 11:13:12 2010 josephbUpdateCDSModified rc.local to not start mx_streams automatically

Problem:

c1iscex floods the network with about 1 gigabyte of error messages in a few seconds, writing to a log file in /opt/rtcds/caltech/c1/target/fb/logs/

Temporary change:

I commented out the following line in the rc.local file on the fb machine in the /diskless/root/etc/ directory:

#nice --20 ./mx_stream -s "$SYSTEMS" -d fb:0 >& logs/$HOSTNAME.log&

This disables the automatic start up of the mx_streams code on all the front ends.  This will prevent the network being brought to its knees by c1iscex while we debug the problem.

It also means on a reboot of the front ends, the mx_stream process needs to be started by hand until this change is reverted.

To do this, log into the front end and then change directory to /opt/rtcds/caltech/c1/target/fb

For c1sus, run:

./mx_stream -s c1x02 c1sus c1mcs c1rms c1rfm  -d fb:0

For c1ioo, run:

./mx_stream -s c1x03 c1ioo -d fb:0

 

  4918   Thu Jun 30 06:54:07 2011 josephbUpdateCDSModified the automated scripts for producing model webviews

Dave Barker pointed out last week that the webview of our simulink model files, generated from the installed models (i.e. in /opt/rtcds/caltech/c1/target/<system name>/simLink/) was not handling libraries properly.  Essentially the web pages generated couldn't see inside library parts.

This was caused by 2 problems.  The first being the userapps not being in the matlab path when the slwebview call was done, so it couldn't even find the libraries.  The second problem is the slwebview code by default doesn't follow libraries and links, and needs a special command to be told to do so.

I added the following lines to the webview_simlink_update.m file:

addpath('/opt/rtcds/caltech/c1/core/trunk/src/epics/simLink/lib')
for sub = {'cds','isc','isi','sus','psl'}
 for spath = {'common/models','c1/models/lib'}
   addpath(['/opt/rtcds/caltech/c1/userapps/release/' sub{1} '/' spath{1}]);
 end
end

I also changed the following:

temp = slwebview(final_files{x},'viewFile',false);

became

temp = slwebview(final_files{x},'viewFile',false,'FollowLinks','on','FollowModelReference','on');

After confirming these changes worked, I have sent a corrected version to Dave and Keith.

The webview results can be found at: https://nodus.ligo.caltech.edu:30889/FE/

 

 

  11114   Sat Mar 7 19:15:17 2015 JenneUpdateLSCModified zero crossing triggering

More work from yesterday. 

Rana and I had discussed on Thursday night that we probably want to be able to use the zero crossing of an error signal to trigger a servo on, but not to un-trigger it.  So, now the zero crossing trigger is latched, using the power trigger to reset the latch. 

Also, the input to the zero crossing trigger is the input to the MC servo, before the triggered switch.  This allows us to look at the normalized error signals rather than just the non-normalized ones, if that's what we're trying to lock on.  This signal is taken before the triggered switch, so that it's looking at whatever is coming out of the input matrix (including normalization).

So.  If the absolute value of the MC error signal goes below the threshold, it outputs a 1, no matter what the arm power is.  If the arm power is high, the power trigger also outputs a 1.  These are AND-ed together, so only if both are 1 do you actually trigger the MC filter bank.  If the zero crossing trigger has been set to 1, it will stay at 1 until the arm power goes low enough to untrigger the power trigger.  So, even if you have a little bit of noise on the error signal and it pops above the threshold momentarily, this won't cause the servo to un-trigger.

This is implemented using a "set-reset latch".  The output of the latch is the zero crossing trigger, which is AND-ed with the power trigger.  This final AND-ing, in addition to doing what we want, solves the ambiguity that is inherent in SR-latches for one combination of inputs. 

The trigger screen has been modified to reflect these model changes.

Here's a screenshot of the model, which includes some notes for anyone who opens the model since it's a bit confusing:

Attachment 1: LatchLogic_6March2015.png
LatchLogic_6March2015.png
  11216   Mon Apr 13 19:34:02 2015 ericqUpdateIOOModulation Frequency Tuned to IMC Length

I've been fiddling with the mode cleaner and green beat box today, to try and get an absolute frequency calibration for MC2 motion. The AC measurements have all turned out weird, I get fractional power laws instead of the 1/f^2 that we expect from the MC2 pendulum. At DC, I get a rough number of 15 green kHz per MC2 count, but this translates to ~7e-10 m/count which is in contrast to the 6e-9 m/count from 2009. I will meditate on this a bit. 


In any case, while working at the IOO rack, I tuned the 11MHz modulation frequency, as was done in ELOGs 9324 and 10314, by minimizing one of the beats of the 11MHz and 29.5MHz sidebands. 

The new modulation frequency / current IMC FSR is 11.066209 +- 1 Hz, which is a only a few ppm change from the tuning from last July.

This implies a IMC round trip length of 27.090800m +- 2um.

Attached is a plot showing the beat of 55-29.5 going down as I changed the marconi frequency. 

 

Attachment 1: fMod_tuning.pdf
fMod_tuning.pdf
  8264   Sat Mar 9 19:29:27 2013 KojiUpdatePSLModulation depth

Last night I measured the modulation depth of the MC incident beam.


Method:

The beam is taken from one of the  PO beam at the wedge plate before the IMC.
After removing the knife edge to dump this beam, the beam is sent to the west side
of the PSL table and put into the OSA cavity.
[The beam dump was returned after the measurement.]

I had some confusion and after all I use the OSA labeled as AS OSA rather than the one on the PSL table.
[The AS OSA was returned to the AP table.]

The transmission was detected by PDA255 and filtered by ITHACO 1201 preamp with G=10, no HPF, 30kHz LPF.
It was confirmed that the peak amplitudes are not reduced by the LPF filter. The resulting time series
was recorded by an oscilloscope.

Three measurements have been taken. The 11MHz peaks are offset by the carrier peak. They appropriately
removed. The ratio of the sideband and carrier peaks is converted to the modulation depth using the following formula.

P_sb / P_ca = [J1(m)/J0(m)]^2


Measurement

The modulation depth for the 11MHz: 0.190 +/- 0.003

The modulation depth for the 55MHz: 0.2564 +/- 0.0003

The three scans showed very similar numbers. That's why the statistical error is such small.
I don't think the systematic error is not such good.

This number is much different form the previous meaurement by Mirko.

http://nodus.ligo.caltech.edu:8080/40m/5519 m=0.14 (11MHz) & 0.17 (55MHz)
but the measured voltages and the modulatio depths are inconsistent.

http://nodus.ligo.caltech.edu:8080/40m/5462 m=0.17 (11MHz) & 0.19 (55MHz)

Probably the modulation depths should be checked by the IMC again.
However, it is certain that the 55MHz modulation exists, and even larger than the 11MHz one.

The next is to confirm that the modulation frequency is matched with the IMC FSR.
It is to make sure that the modulation is transmitted to the main IFO without attenuation.

Attachment 1: mod_depth.pdf
mod_depth.pdf
  15715   Mon Dec 7 22:54:30 2020 gautamUpdateLSCModulation depth measurement

Summary:

I measured the modulation depth at 11 MHz andf 55 MHz using an optical beat + PLL setup. Both numbers are ~0.2 rad, which is consistent with previous numbers. More careful analysis forthcoming, but I think this supports my claim that the optical gain for the PDH locking loops should not have decreased.

Details:

  • For this measurement, I closed the PSL shutter between ~4pm and ~9pm local time. 
  • The photodiode used was the NF1611, which I assumed has a flat response in the 1-200 MHz band, and so did not apply any correction/calibration.
Attachment 1: modDepth.pdf
modDepth.pdf
  15769   Sat Jan 16 18:59:44 2021 gautamUpdateLSCModulation depth measurement

I decided to analyze the data I took in December more carefully to see if there are any clues about the weird LSC sensing.

Attachment #1 shows the measurement setup.

  • The PSL shutter was closed. All feedback to both lasers was disconnected during the measurement. I also disabled the input switch to the FSS Box - so the two laser beams being interfered shouldn't have any modulations on them other than the free running NPRO noise and the main IFO modulations.
  • Everything is done in fiber as I had the beams already coupled into collimators and this avoided having to optimize any mode matching on the beat photodiode.
  • The pickoff of the PSL is from the collimator placed after the triply resonant EOM that was installed for the air BHD experiment.
  • The other beam is the EX laser beam, arriving at the PSL table via the 40m long fiber from the end (this is the usual beam used for ALS).
  • I didn't characterize precisely the PLL loop shape. But basically, I wasn't able to increase the SR560 gain any more without breaking the PLL lock. Past experience suggests that the UGF is ~20 kHz, and I was able to get several averages on the AG4395 without the lock being disturbed.

Attachment #2 shows the measured spectrum with the PSL and EX laser frequency offset locked via PLL.

  • The various peaks are identified.
  • There are several peaks which I cannot explain - any hypothesis for what these might be? Some kind of Sorensen pollution? They aren't any multiples of any of the standard RF sources. They are also rather prominent (and stationary during the measurement time, which I think rules out the cause being some leakage light from the EY beam, which I had also left connected to the BeatMouth during the measurement).
  • In the previous such characterization done by Koji, such spurious extra peaks aren't seen.
  • Also, I can't really explain why some multiples of the main modulation are missing (could also be that my peak finding missed the tiny peaks)?
  • The measuremet setup is very similar to what he had - important differences are 
    • Much of the optical path was fiber coupled.
    • Beat photodiode is NF1611, which is higher BW than the PDA10CF.
    • The second laser source was the Innolight EX NPRO as opposed to the Lightwave that was used.
    • The RF source has been modified, so relative phasing between 11 MHz and 55 MHz is different.

Fitting the measured sideband powers (up to n=7, taking the average of the measured upper and lower sideband powers to compute a least squares fit if both are measured, else just that of the one sideband measured) agains those expected from a model, I get the following best fit parameters:

\begin{align*} \Gamma_1 &= 0.193 \pm 0.004 \\ \Gamma_2 &= 0.246 \pm 0.008 \\ \phi &= 75.5^{\circ +17.5^{\circ}}_{\, -40.3^{\circ}} \end{align*}

To be explicit, the residual at each datapoint was calculated as

\Delta = \bigg| \frac{\rm{model}-\rm{measurement}}{\rm{model}}\bigg|^2.

The numbers compare favourably with what Koji reported I think - the modulation depths are slightly increased, consistent with the RF power out of the RF box being slightly increased after I removed various attenuators etc. Note the large uncertainty on the relative phase between the two modulations - I think this is because there are relatively few sidebands (one example is n=3) which has a functional dependence that informs on phi - most of the others do not directly give us any information about this parameter (since we are just measuring powers, not the actual phase of the electric field). 

Attachment #3 shows a plot of the measured modulation profile, along with the expected heights plugging the best fit parameters into the model. The size of the datapoint markers is illustrative only - the dependence on the model parameters is complicated and the full covariance would need to be taken into account to put error bars on those markers, which I didn't do. 

Attachment #4 shows a time domain measurement of the relative phasing between the 11 MHz and 55 MHz signals at the EOM drive outputs on the RF source box. I fit a model there and get a value for the relative phase that is totally inconsistent from what I get with this fit. 

Attachment 1: PLL.pdf
PLL.pdf
Attachment 2: modDepth.pdf
modDepth.pdf
Attachment 3: modProfile.pdf
modProfile.pdf
Attachment 4: EOMpath_postMod.pdf
EOMpath_postMod.pdf
  13642   Tue Feb 20 13:59:30 2018 KojiUpdateGeneralModulation depth measurement for an aLIGO EOM

Last night I worked at the PSL table for the modulation depth measurement for an aLIGO EOM. Let me know if the IFO behavior is unusual.

What I did was:

  • Cranked up the HEPA speed to 100
  • Placed an aLIGO EOM in the AUX beat path (south side of the PSL laser). (It is still on the PSL table as of Feb 20, 2018)
  • Closed the PSL shutter
  • Turned off the main Marconi forr 11MHz. The freq and output power of this marconi have not been touched.
  • Turned off the freq generation unit
     
  • Worked on my measurement with the spectrum and network analyzers + aux marconi.
     
  • Turned down the HEPA speed to 30
  • Turned on the freq generation unit
  • Turned on the main Marconi
  • Opened the PSL shutter => IMC locked
  13652   Thu Feb 22 17:19:47 2018 KojiUpdateGeneralModulation depth measurement for an aLIGO EOM

aLIGO EOM test: Setup

  • The modulation signal was supplied from an aux Marconi.
  • Between the Marconi and the EOM, a 20dB coupler (ZFDC-20-5) was inserted. There the Marconi was connected to the output port, while the EOM was to the input port. This way, we can observe how much of the RF power is reflected back to Marconi.
  • The beat setup (40m ELOG 13567) was used for the measurement. The EOM was placed in the beam path of the beat setup in the PSL side.
  • To eliminate the modulation sidebands of 11MHz and 55MHz, the 40m Marconi and the freq generator were turned off (in this order).
  • The nominal amplitude of the carrier beat note was -15dBm ~ -16dBm.
  • The cable from the source to the EOM was ~3m. And the loss of this cable was ~0.4dB.

Measurement

  • The EOM had three input ports. 
  1. 9MHz input - In reality, there was no matching circuit.
  2. Center port - matched at 24.1MHz and 118.3MHz. 24.1MHz port has no amplification (just matching), and 118.3MHz is resonant.
  3. 45.5MHz port - resonantly matched at 45.5MHz
  • The Marconi output power was set to be +13dBm. For the 45MHz measurement, 20dB attenuator is inserted right next to the Marconi so that the VSWR seen from the Marconi was improbed. (Marconi did not like the full reflection of unmatched circuit and shutdown due to the protection function.)
  • The amplitude ratios between the sidebands and the carrier were multiplied by a factor of 2, to obtain the modulaiton depths. ( BesselJ(1,m)/BesselJ(0,m) ~ m/2 )
     
  • The result is found in Attachment 2.
    • The center port showed the modulation response of 0.7mrad/V and 15mrad/V for 24.1MHz and 118.3MHz, respectively. This suggests that the amplification factor for 118.3MHz is ~x21.
    • The VSWR of the center port is below 1.5 at the target frequencies. That's as tuned in Downs and has not been changed by the crystal replace.
    • The 45MHz port has the modulation response of 0.034mrad/V. This later tuned out that the amplification of ~x19. The circuit is well matched at the resonant frequency.
       
  • The linearity was checked with the 45MHz port (Attachment 3). The input power (idrectly connected to the EOM without 20dB attn) was varied between -17dBm to +13dBm. There was no sign of non linearity.
     
  • The modulation response at 24MHz was compared at various input ports. (Attachment 4)
    • The input signal was amplified tobe 23dBm by ZHL-3A for better sideband visibility. The actual amplifier output was ~30dBm, and a 6dB ATTN was used to improve the VSWR to protect the amplifier.
    • The 9MHz port showed 3.6mrad/V and 1.8mrad/V with the port unterminated and terminated, respectively. This factor of two difference is as expected.
      This 1.8mrad/V is roughly x2.6 higher compared to the one of the matched 24/118MHz port. This is close number to the ratio of the plate sizes (14mm/5mm = 2.8).
    • With the current condition, the 9MHz (unterminated), 9MHz (terminated), 24/118MHz, and 45MHz ports requires 22dBm, 27dBm, 36dBm, and 21dBm to realize the current modulation depth of 0.014 at 24MHz.
    • Comparing this matched 9MHz performance, the amplification of the 45MHz port at 45MHz was determined to be ~x19.
       
  • Considering these results, the modulation response of the center port at 24MHz seems too low. We don't want to supply 36dBm for the 0.014rad modulation (nominal number for H1).
    Here are some thoughts:
    • Use the 45MHz or 9MHz port for 24MHz modulation. Probably the unit is unmatched but, we can come up with the idea to improve the VSWR at 24MHz somehow?
    • Redistribute the plate length to have better modulation at 24MHz. Can we achieve sufficient modulation capability with the frequency of the long and short ports swapped? We hope that we don't need to start over the matching of the 24/118MHz again because the capacitances of the ports are almost the same.
Attachment 1: IMG_3436.JPG
IMG_3436.JPG
Attachment 2: modulation_depth.pdf
modulation_depth.pdf
Attachment 3: modulation_linearity.pdf
modulation_linearity.pdf
Attachment 4: modulation_24MHz.pdf
modulation_24MHz.pdf
  13725   Mon Apr 2 15:14:21 2018 KojiUpdateGeneralModulation depth measurement for an aLIGO EOM

The new matching circuit was tested.

Results:

f_nominal  f_actual  response    required mod.  drivng power
 [MHz]      [MHz]    [mrad/V]     [rad]         needed [dBm]
  9.1       9.1        55         0.22      =>   22
118.3     118.2        16         0.01      =>    6

 45.5      45.4        45         0.28      =>   25
 24.1       N/A         2.1       0.014     =>   27

Comments:

- 9.1MHz and 118.3MHz: They are just fine.

- 24.1MHz: Definitely better (>x3) than the previous trial to combine 118MHz & 24MHz.
  We got about the same modulation with the 50Ohm terminated bare crystal (for the port1).
  So, this is sort of the best we can do for the 24.1MHz with the current approach.
  The driving power of 27dBm is required at 24.1MHz

- About the 45MHz
  - The driving power of 27dBm is required at 24.1MHz
  - The maximum driving power with the AM stabilized driver is 23dBm, nominally to say.
  - I wonder how we can reduce resistance (and capacitance) of the 45MHz further...?
  - I also wonder if the IFO can be locked with reduced modulation (0.28 rad->0.2 rad)
  - Can the driver max power be boosted a bit? (i.e. adding an attenuator in the RF power detection path)

 

Attachment 1: modulation_depth.pdf
modulation_depth.pdf
Attachment 2: impedance_eom.pdf
impedance_eom.pdf
  13819   Sat May 5 22:32:07 2018 KojiUpdatePSLModulation depth measurement for the 3IFO aLIGO EOM

The 3IFO EOM was formerly tuned as the H2 EOM, so the resonant frequencies are different from the nominal aLIGO ones.

PORT1: 8.628MHz / 101 +/- 6 mrad_pk/V_pk
PORT2: 24.082MHz / 41.2 +/- 0.7 mrad_pk/V_pk
PORT3: 43.332MHz / 62.2 +/- 4 mrad_pk/V_pk

9MHz modulation is about x2.4 better than the one installed at LHO.
24MHz modulation is about x14 better. (This is OK as the new 24MHz is not configured to be resonant.)
45MHz modulation is about x1.4 better.
 

  13818   Sat May 5 20:30:21 2018 KojiUpdatePSLModulation depth measurement for the 3IFO aLIGO EOM and aftermath

Caution: Because of this work and my negligence, the RF output of the main Marconi for the IFO modulation is probably off. The amplifier (freq gen. box) was turned on. Therefore, we need to turn the Marconi on for the IFO locking.

I worked on my EOM m easurement using the beat setup. As there was the aux injection electronics, I performed my measurement having tried not to disturb the aux setup. The aux Marconi, the splitted PD output, and an open channel of the oscilloscope were used for my purpose. I have brought the RF spectrum analyzer from the control room. I think I have restored all the electronics back as before. I have re-aligned the beat setup after the EOM removed. Note that the aux NPRO, which had been on, was turned off to save the remaining life of the laser diode.

  13842   Tue May 15 10:42:14 2018 KojiUpdatePSLModulation depth measurement for the 3IFO aLIGO EOM and aftermath

The marconi RF output was turned on and thus the RF generator condition was restored to the nominal state on Friday 11th.

  13593   Wed Jan 31 16:29:42 2018 gautamUpdateALSModulation depths

I used the Beat Mouth to make a quick measurement of the PMC and EX modulation depths. They are, respectively, 60mrad and 90mrad. See Attachments #1 and #2 for spectra from the beat photodiode outputs, monitored using the Agilent analyzer, 16 averages, IF bandwidth set to resolve peaks offset from the main beat frequency peak by 33.5MHz for the PMC and by ~230kHz for the EX green PDH.

For this work, I had to re-align the IFO so as to lock the arms to IR. c1susaux was unresponsive and had to be power-cycled. As mentioned in the earlier elog, to avoid saturating the Fiber Coupled beat PDs, I placed a ND=0.5 filter in the fiber collimator path, such that the coupled power was ~1mW, which is well inside the safe regime.

For the EX modulation depth, I could have gotten multiple estimates of the modulation depth using the higher order products that are visible in the spectrum, but I didn't.

Attachment 1: PMCmodDepth.pdf
PMCmodDepth.pdf
Attachment 2: XPDH.pdf
XPDH.pdf
  16952   Mon Jun 27 18:54:27 2022 yutaUpdateLSCModulation depths measurement using Yarm cavity scan

[Yehonathan, Yuta]
EDITED by YM on 22:11 June 27, 2022 to correct for a factor of two in the modulation index

Since we have measured optical gain in MICH to be an order of magnitude less compared with Yehonathan's FINESSE model (40m/16923), we measured the power at AS55 RF PD, and measured the modulation depths using Yarm cavity scan.
We found that 50/50 beam splitter which splits AS55 path into RF PD and RF QPD was not included in the FINESSE model. Measured modulation index were as follows:

TEM00 peak height: 0.6226 +/- 0.0237
RF11 peak height: 0.0067 +/- 0.0007
RF55 peak height: 0.0081 +/- 0.0014
RF11 modulation index: 0.208 +/- 0.012
RF55 modulation index: 0.229 +/- 0.020
RF11 modulation index: 0.104 +/- 0.006
RF55 modulation index: 0.114 +/- 0.010

Here, modulation depth m is defined in E=E_0*exp(i*(w*t+m*sin(w_m*t))), and m m/2 equals to square of the intensity ratio between sidebands and TEM00.

Power measurement at AS55 RF PD:
 - ITMY and ITMX single bounce reflection was measured to be 50-60 uW at the front of AS55 RFPD.
 - In the FINESSE model, it was expected to be ~110 uW with 0.8 W input to PRM (0.8 W * 5%(PRM) * 50%(BS) * 50%(BS) * 10%(SRM) * 10%(AS2) gives 100 uW)
 - In AP table, AS55 beam was split into two paths with 50/50 beam splitter, one for AS55 RF PD and one for AS WFS and AS110. This will be included in the FINESSE model.

Modulation depth measurement using Yarm cavity scan:
 - Aligned Yarm using ASS, and unlocked Yarm to get the 2sec scan data of C1:LSC-TRY_OUT_DQ, C1:LSC-POY11_I_ERR_DQ, C1:LSC-AS55_I_ERR_DQ.
 - TRY data was used to get TEM00 peak heights
 - POY11/AS55 data was used to find RF11/RF55 sideband peaks, and height was measured at TRY (see attached).
 - If we define m to be E=E_0*exp(i*(w*t+m*sin(w_m*t))), the amplitude of TEM00 I_00 is proportional to J_0(m) and the amplitude of upper/lower sideband I_f1 is proportional to J_1(m), where J_n(m) is the bessel function of the first kind.
 - m can be calculated using 2*sqrt(I_f1 / I_00).
 - Results were shown above. Error is calculated from the standard deviation of multiple measurements with multiple peaks,
 - The code for doing this lives in https://git.ligo.org/40m/measurements/-/blob/main/LSC/YARM/modulationIndex.ipynb

Discussion:
 - Power at AS55 account for the factor of 2, In the FINESSE model, modulation index of 0.3 was used (could be m=0.3/2 or m=0.3; needs check). These combined can explain a factor of 3 at least (or 6).
 - Gautam's measurement in Jan 2021 (40m/15769) gives almost double modulation index, but I'm not sure what is the definition Gautam used. It agrees with Gautam's measurement in Jan 2021.

Attachment 1: YarmModIndex.png
YarmModIndex.png
  10314   Thu Jul 31 23:43:00 2014 KojiUpdateIOOModulation frequency adjustment

The main IFO modulation frequency was adjusted to match with the FSR of the IMC.

The new frequency is 11.066128 MHz. This corresponds to the IMC round-trip length of 27.0910 m

This has been done by looking at the peak at 25.845MHz (5* fmod - 29.5MHz) in the MC REFL PD mon.

  16190   Mon Jun 7 15:37:01 2021 Anchal, Paco, YehonathanSummaryCamerasMon 7 in Control Room Died

We found Mon7 in control room dead today afternoon. It's front power on green light is not lighting up. All other monitors are working as normal.

This monitor was used for looking at IMC camera analog feed. It is one of the most important monitors for us, so we should replace it with a different monitor.

Yehonathan and Paco disconnected the monitor and brought it down. We put it under the back table if anyone wants to fix it. Paco has ordered a BNC to VGA/HDMI converter to put in any normal monitor up there. It will happen this Wednesday. Meanwhile, I have changed the MON4 assignment from POP to Quad2 to be used for IMC.

  16204   Wed Jun 16 13:20:19 2021 Anchal, PacoSummaryCamerasMon 7 in Control Room Replaced

We replaced the Mon 7 with an LCD monitor from back bench. It is fed the analog signal from BNC converted into VGS with a converter box that Paco bought. We can replace this monitor with another monitor if it is required on the back bench. For now, we definitely need a monitor to show IMC camera's up there.

Attachment 1: IMG_20210616_083810.jpg
IMG_20210616_083810.jpg
  2456   Mon Dec 28 10:29:31 2009 JenneUpdateComputersMonday Morning Bootfest

Nothing like a good ol' Bootfest to get back into the swing of things after vacation....

It was a regular bootfest, keying crates and running everyone's startup.cmd .  There wasn't any RFM funny business which we had been dealing with a lot earlier in December (maybe Kiwamu took care of that part of things last night).

After finishing the bootfest, I tried to re-enable the watchdogs.  I noticed that the optics weren't damping at all (not that any of them were swinging crazily, they just weren't damped like regular).  This was traced to the OSEM sensor inputs and outputs being disabled on all of the suspensions' screens.  I suspect that no burt-restoring happened after c1dcuepics was powercycled yesterday. 

All of the optics are now happy as clams.

  5239   Mon Aug 15 14:10:56 2011 JenneUpdateSUSMonday SUS update

The moral of the story here is that none of the suspensions are overwhelmingly awesome, but most of them will be fine if we leave them as-is.

SUS DoF Plot Input Matrix "BADness" (1==good)
ITMX inMatDiag.png       pit     yaw     pos     side    butt
UL    0.438   1.019   1.050  -0.059   0.717 
UR    0.828  -0.981   1.128  -0.215  -0.956 
LR   -1.172  -1.201   0.950  -0.275   1.241 
LL   -1.562   0.799   0.872  -0.120  -1.087 
SD   -0.579  -0.847   2.539   1.000  -0.170 

 
4.68597
 
 ITMY  inMatDiag.png        pit     yaw     pos     side    butt
UL    1.157   0.185   1.188  -0.109   0.922 
UR    0.020  -1.815   0.745  -0.051  -0.970 
LR   -1.980  -0.090   0.812  -0.024   1.158 
LL   -0.843   1.910   1.255  -0.082  -0.949 
SD   -0.958   1.080   1.859   1.000   0.325  
4.82756
ETMX  inMatDiag.png        pit     yaw     pos     side    butt
UL    0.338   0.476   1.609   0.316   1.046  
UR    0.274  -1.524   1.796  -0.069  -1.180  
LR   -1.726  -1.565   0.391  -0.100   0.938  
LL   -1.662   0.435   0.204   0.286  -0.836  
SD    0.996  -2.629  -0.999   1.000  -0.111
 
 
 4.32072
 ETMY  inMatDiag.png        pit     yaw     pos     side    butt
UL    1.123   0.456   1.812   0.231   0.936 
UR   -0.198  -1.489   0.492  -0.096  -1.098 
LR   -2.000   0.055   0.188  -0.052   0.764 
LL   -0.679   2.000   1.508   0.275  -1.201 
SD    0.180  -0.591   3.355   1.000   0.200  
 10.643
 BS  inMatDiag.png        pit     yaw     pos     side    butt
UL    1.575   0.697   0.230   0.294   1.045 
UR    0.163  -1.303   1.829  -0.133  -0.958 
LR   -1.837  -0.308   1.770  -0.171   0.944 
LL   -0.425   1.692   0.171   0.257  -1.053 
SD    0.769   0.345  -3.380   1.000   0.058 
6.111
 
 PRM  inMatDiag.png        pit     yaw     pos     side    butt
UL    0.597   1.553   2.000  -0.469   1.229  
UR    1.304  -0.447   0.383  -0.043  -0.734  
LR   -0.696  -1.048  -0.277   0.109   0.687  
LL   -1.403   0.952   1.340  -0.317  -1.350  
SD    0.518  -1.125  -1.161   1.000   0.394  

 
 8.43363
SRM inMatDiag.png       pit     yaw     pos     side    butt
UL    0.831   1.039   1.153  -0.140   1.065 
UR    1.071  -0.961   1.104  -0.057  -1.061 
LR   -0.929  -0.946   0.847  -0.035   0.837 
LL   -1.169   1.054   0.896  -0.118  -1.037 
SD    0.193  -0.033   1.797   1.000   0.045 
 4.17396

 

  230   Wed Jan 9 20:36:42 2008 GoUpdateTreasureMoney in lab
Go's Desk.
Attachment 1: DSC_0370.JPG
DSC_0370.JPG
  3263   Thu Jul 22 01:02:08 2010 ranaUpdateTreasureMonsters, LNVR, and Phase noise

On Picasa

  3265   Thu Jul 22 07:19:56 2010 AlbertoUpdateTreasureMonsters, LNVR, and Phase noise

Quote:

On Picasa

 "They (shellfish) shall be an abomination to you; you shall not eat their flesh, but you shall regard their carcasses as an abomination." (Leviticus 11:11)

  15507   Thu Aug 6 00:34:38 2020 YehonathanUpdateBHDMonte Carlo Simulations

I've pushed an MCMC simulation to the A+ BHD repo (filename MCMC_TFs.ipynb). The idea is to show how random offsets around ideal IFO change the noise couplings of different DOFs to readout.

At each step of the simulation:

1. Random offsets for the different DOFs are generated from a normal distribution. The RMSs are taken from experimental data and some guesses and can be changed later. The laser frequency is tuned to match the CARM offset.

These are the current RMS detunings I use:

DOF RMS Taken from
DARM 10fm PHYSICAL REVIEW D 93, 112004 (2016), Table 2
CARM 1fm PHYSICAL REVIEW D 93, 112004 (2016), Table 2
MICH 3pm PHYSICAL REVIEW D 93, 112004 (2016), Table 2
PRCL 1pm PHYSICAL REVIEW D 93, 112004 (2016), Table 2
SRCL 10pm PHYSICAL REVIEW D 93, 112004 (2016), Table 2
OMCL 0.1pm Guess
OMC Breadboard angle 1\mu rad Guess
Differential arm loss 15ppm Guess
BHD BS imbalance 10% Guess
OMC finesse imbalance 5ppm Guess

2. A transfer function is computed for the noisy DOFs.

3. Projected noise is calculated.

These are the noise level for the DOFs:

DOF Noise Taken from
MICH 2e-16 m PHYSICAL REVIEW D 93, 112004 (2016), Fig 9
PRCL 0.5e-17 m PHYSICAL REVIEW D 93, 112004 (2016), Fig 9
SRCL 5e-16 PHYSICAL REVIEW D 93, 112004 (2016), Fig 9
OMCL 2.5e-17*(100/f)^(1/2) LIGO-G1800149
OMC Breadboard angle 1nrad Guess
RIN 2e-9 Optics Letters Vol. 34, Issue 19, pp. 2912-2914 (2009)

 

The attachments show the projected noise levels for the noisy DOFs. Each curve is a different instance of random offsets. The ideal case - "zero offsets" is also shown.

OMC Comm and OMC diff refer to the common and differential length change of the OMCs.

Attachment 1: MICH_Aplus_MCMC.pdf
MICH_Aplus_MCMC.pdf
Attachment 2: PRCL_Aplus_MCMC.pdf
PRCL_Aplus_MCMC.pdf
Attachment 3: SRCL_Aplus_MCMC.pdf
SRCL_Aplus_MCMC.pdf
Attachment 4: OMC_Comm_Aplus_MCMC.pdf
OMC_Comm_Aplus_MCMC.pdf
Attachment 5: OMC_Diff_Aplus_MCMC.pdf
OMC_Diff_Aplus_MCMC.pdf
Attachment 6: OMC_Angle_Yaw_Aplus_MCMC.pdf
OMC_Angle_Yaw_Aplus_MCMC.pdf
Attachment 7: OMC_Angle_Pitch_Aplus_MCMC.pdf
OMC_Angle_Pitch_Aplus_MCMC.pdf
Attachment 8: L0_RIN_Aplus_MCMC.pdf
L0_RIN_Aplus_MCMC.pdf
  15509   Fri Aug 7 11:23:47 2020 ranaUpdateBHDMonte Carlo Simulations

that's great. I think we would like to figure out how to present this so that its clear what the distribution of TFs is. Maybe we can plot the most likely curve as well as a shaded region indicating the 5% and 95% values?

Quote:

I've pushed an MCMC simulation to the A+ BHD repo (filename MCMC_TFs.ipynb). The idea is to show how random offsets around ideal IFO change the noise couplings of different DOFs to readout.

and then we add the loops

  15512   Mon Aug 10 07:13:00 2020 YehonathanUpdateBHDMonte Carlo Simulations

I fixed some stuff in the MCMC simulation:

1. Results are now plotted as shades from minimum to maximum. I tried making the shade the STD around a mean but it doesn't look good on a log scale when the STD is bigger than the mean.

2. Added comparison with aLigo. The OMCL diff and comm motions in A+ are both compared to the single OMCL DOF of aLigo.

3. I fixed a serious error in the code that produced incorrect results.

4. Imbalances in the IFO such as differential arm loss are generated randomly at the beginning and stay fixed for the rest of the simulation instead of being treated as an offset.

5. The simulation now runs with maxtem=2. That is, TEM modes up to 2nd order are considered.

The results are attached.

 

Attachment 1: MICH_AplusMCMC.pdf
MICH_AplusMCMC.pdf
Attachment 2: PRCL_AplusMCMC.pdf
PRCL_AplusMCMC.pdf
Attachment 3: SRCL_AplusMCMC.pdf
SRCL_AplusMCMC.pdf
Attachment 4: OMC_Comm_AplusMCMC.pdf
OMC_Comm_AplusMCMC.pdf
Attachment 5: OMC_Diff_AplusMCMC.pdf
OMC_Diff_AplusMCMC.pdf
Attachment 6: OMC_Angle_Yaw_AplusMCMC.pdf
OMC_Angle_Yaw_AplusMCMC.pdf
Attachment 7: OMC_Angle_Pitch_AplusMCMC.pdf
OMC_Angle_Pitch_AplusMCMC.pdf
Attachment 8: L0_RIN_AplusMCMC.pdf
L0_RIN_AplusMCMC.pdf
  15539   Tue Aug 25 05:51:29 2020 YehonathanUpdateBHDMonte Carlo Simulations

I re-plotted the MCMC results as semi-transparent lines so that probable lines stick out.

This also reveals what is behind the extreme sparsity in the aLIGO simulation results (In the previous post).

There seem to be some bi-stability/phase transition/whatever in the aLIGO simulation. The aLIGO transfer functions are very sensitive to one or more of the DOFs. Not sure which yet.

Attachment 1: MICH_AplusMCMC.pdf
MICH_AplusMCMC.pdf
Attachment 2: PRCL_AplusMCMC.pdf
PRCL_AplusMCMC.pdf
Attachment 3: SRCL_AplusMCMC(1).pdf
SRCL_AplusMCMC(1).pdf
Attachment 4: OMC_Diff_AplusMCMC.pdf
OMC_Diff_AplusMCMC.pdf
Attachment 5: OMC_Comm_AplusMCMC.pdf
OMC_Comm_AplusMCMC.pdf
Attachment 6: OMC_Angle_Yaw_AplusMCMC.pdf
OMC_Angle_Yaw_AplusMCMC.pdf
Attachment 7: OMC_Angle_Pitch_AplusMCMC.pdf
OMC_Angle_Pitch_AplusMCMC.pdf
Attachment 8: Main_Laser_RIN_AplusMCMC.pdf
Main_Laser_RIN_AplusMCMC.pdf
  15569   Mon Sep 14 07:50:01 2020 YehonathanUpdateBHDMonte Carlo Simulations

Turns out what was causing the instability in the aLIGO plots were the lock commands which I forgot to remove before running the simulation. Removing these also made the simulation much faster.

Other than that I improved other stuff in the simulations:

  • The LO phase in the aPlus simulation is now optimized for the lowest noise at 100Hz.
  • Added RF PDs diagnostics (see attachments 8 for aPlus and 9 for aLIGO). The thresholds (red dashed lines in attachments 8,9) for cutting marginal simulations are set such that roughly 30% of the simulations are discarded.
  • Removed DHARD because it jacks up the RF PD readings in aPlus for some reason.
  • Fixed the sign of laser frequency shift in response to CARM offset.

Still need to do:

  • Incorporate Jon’s noise curves.
  • Add phase noise for LO beam.
  • Add arm reflectivity imbalance.
  • Add mirror curvature imbalance.
  • Include feedback loops using Pytickle.

Feel free to add to the todo list.

Attachment 1: MICH_AplusMCMC.pdf
MICH_AplusMCMC.pdf
Attachment 2: PRCL_AplusMCMC.pdf
PRCL_AplusMCMC.pdf
Attachment 3: SRCL_AplusMCMC(1).pdf
SRCL_AplusMCMC(1).pdf
Attachment 4: OMC_Comm_AplusMCMC.pdf
OMC_Comm_AplusMCMC.pdf
Attachment 5: OMC_Diff_AplusMCMC.pdf
OMC_Diff_AplusMCMC.pdf
Attachment 6: OMC_Angle_Yaw_AplusMCMC.pdf
OMC_Angle_Yaw_AplusMCMC.pdf
Attachment 7: OMC_Angle_Pitch_AplusMCMC.pdf
OMC_Angle_Pitch_AplusMCMC.pdf
Attachment 8: Main_Laser_RIN_AplusMCMC.pdf
Main_Laser_RIN_AplusMCMC.pdf
Attachment 9: aPlus_RF_Diagnostics.pdf
aPlus_RF_Diagnostics.pdf
Attachment 10: aLIGO_RF_Diagnostics.pdf
aLIGO_RF_Diagnostics.pdf
  15631   Fri Oct 16 09:16:37 2020 YehonathanUpdateBHDMonte Carlo Simulations

Pushed another update to MCMC simulation. This includes:

  • Added new imbalances: ITM transmission, ITM & ETM RoCs.
  • Added new static offsets: DHARD, DSOFT, CHARD, CSOFT. All pitch. The RMS is calculated from the data Jon fetched with /input_noises/input_noises.ipynb.
  • SRCL noise ASD and RMS are now taken from data in /input_noises.
  • RF PD diagnostics were redone: Instead of post-discarding marginal simulations, simulations are now discarded when one or more of the RF PDs demodulated signal does not cross zero when the associated DOFs are scanned by 1um in the offset state.

The DOFs<->RFPD associations I use are:

DARM AS_f2_I
CARM REFL_f1_I
MICH POP_f2_Q
PRCL POP_f1_I
SRCL REFL_f2_I

However, one thing that bothers me is that for some reason ~ 15 out of 160 aLigo simulations are discarded while none for A+. It can also be seen that the A+ simulations are more spread-out which might be related.

The new simulation results are attached.

Attachment 1: MICH_AplusMCMC.pdf
MICH_AplusMCMC.pdf
Attachment 2: PRCL_AplusMCMC.pdf
PRCL_AplusMCMC.pdf
Attachment 3: SRCL_AplusMCMC.pdf
SRCL_AplusMCMC.pdf
Attachment 4: OMC_Comm_AplusMCMC.pdf
OMC_Comm_AplusMCMC.pdf
Attachment 5: OMC_Diff_AplusMCMC.pdf
OMC_Diff_AplusMCMC.pdf
Attachment 6: OMC_Angle_Yaw_AplusMCMC.pdf
OMC_Angle_Yaw_AplusMCMC.pdf
Attachment 7: OMC_Angle_Pitch_AplusMCMC.pdf
OMC_Angle_Pitch_AplusMCMC.pdf
Attachment 8: Main_Laser_RIN_AplusMCMC.pdf
Main_Laser_RIN_AplusMCMC.pdf
  15637   Thu Oct 22 11:48:08 2020 YehonathanUpdateBHDMonte Carlo Simulations

I found this H1 alog  entry by Izumi confirming that the calibrated channels CAL-CS_* need the same dewhitening filter.

This encouraged me to download the PRCL and MICH data and using Jon's example notebook. I incorporated these noise spectra into the MCMC simulation. The most recent results are attached.

I am still missing:

  • Laser frequency noise
  • Laser RIN
  • Estimation of the LO phase noise
  • Estimation of the BHD breadboard angular noise

Also, now the MCMC repeats a simulation if it doesn't pass the RF PDs test so the number of valid simulations stays the same. I'm still not sure about why the A+ simulations are much more robust to these tests than aLigo simulations.

Attachment 1: MICH_AplusMCMC.pdf
MICH_AplusMCMC.pdf
Attachment 2: PRCL_AplusMCMC.pdf
PRCL_AplusMCMC.pdf
Attachment 3: SRCL_AplusMCMC.pdf
SRCL_AplusMCMC.pdf
Attachment 4: OMC_Comm_AplusMCMC.pdf
OMC_Comm_AplusMCMC.pdf
Attachment 5: OMC_Diff_AplusMCMC.pdf
OMC_Diff_AplusMCMC.pdf
Attachment 6: OMC_Angle_Yaw_AplusMCMC.pdf
OMC_Angle_Yaw_AplusMCMC.pdf
Attachment 7: OMC_Angle_Pitch_AplusMCMC.pdf
OMC_Angle_Pitch_AplusMCMC.pdf
Attachment 8: Main_Laser_RIN_AplusMCMC.pdf
Main_Laser_RIN_AplusMCMC.pdf
  15727   Thu Dec 10 14:48:00 2020 YehonathanUpdateBHDMonte Carlo Simulations

I have rebuilt the MCMC simulation in an OOP fashion and incorporated Lance/Pytickle functionality into it. The usage of the MCMC now is much less messy, hopefully.

I made an example that calculates the closed-loop noise-coupling from SRCL sensing and displacement to DARM in A+. I used the control filters that Kevin defined in his controls example.

The resulting noise budget is in attachment 1. The code is in the 40m/bhd git.

 

I also investigated why aLIGO simulations behave so different than the A+ simulation (See few previous elogs in this thread). That is why aLIGO results are much less variable, and the simulations in aLIGO barely pass the validity checks, while A+ simulations almost always pass.

The way I check for the validity of a kat model is by scanning all the DOFs and checking that the corresponding sensing RFPDs demodulated signals cross zero. Attachment 2 shows these scanning for 3 such RFPDS for 3 cases:

A+ model with maxtem = 2

ALigo model with maxtem = 2

ALigo model with maxtem = 'off'

It seems like the scanning curves for A+ and ALigo with no HOMs are well behaved and look like normal PDH signals, while the ALigo with maxtem = 2 curves look funky. I believe that the aLIGO+HOMS curves indicate that the IFO is not really in a good locking point. All the IFO lockings were done by using the locking methods straight out of the PyKat package. 

Attachment 1: MCMCLance_NoiseBudget_Example.pdf
MCMCLance_NoiseBudget_Example.pdf
Attachment 2: IFO_Check.pdf
IFO_Check.pdf
  15732   Fri Dec 11 09:28:52 2020 ranaUpdateBHDMonte Carlo loop coupling Simulations

Cool. Can you give us Bode plots of the open loop gain for each of the 5 length control loops?

Quote:

I have rebuilt the MCMC simulation in an OOP fashion and incorporated Lance/Pytickle functionality into it. The usage of the MCMC now is much less messy, hopefully.

 

  15734   Mon Dec 14 11:09:28 2020 YehonathanUpdateBHDMonte Carlo loop coupling Simulations

I spent a few hours monkeying around with the control filters. They are totally made up and also it's my first time trying to design control filters.

The OLTFs of the different length controls are shown in attachment 1.

The open-loop couplings of the DOFS to DARM are shown in attachment 2.

Note that in Lance/Pytickle the convention is that CLTFs are 1/(1 - G). Where G is the OLTF.

Quote:

Cool. Can you give us Bode plots of the open loop gain for each of the 5 length control loops?

 

 

Attachment 1: MCMC_LANCE_OLTFs.pdf
MCMC_LANCE_OLTFs.pdf
Attachment 2: MCMC_LANCE_OLCoupling2DARM.pdf
MCMC_LANCE_OLCoupling2DARM.pdf
  15758   Mon Jan 11 16:11:51 2021 YehonathanUpdateBHDMonte Carlo loop coupling Simulations

I dived into the alog to make the OLTFs in the MC_controls example more realistic. I was mainly inspired by these entries:

https://alog.ligo-la.caltech.edu/aLOG/uploads/47116_20190708131007_carmolg_20190702.png

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=18742

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=20466

and Evan's and Dennis's Theses.

Attachment 1 shows the new OLTFs. I tried to make them go like 1/f around the UGF and fall as quickly as possible at higher frequencies. I didn't do more advanced stability checks.

I also noticed that imbalances and detunings in the MC simulation can change the plants significantly. Especially DARM, CARM, and sometimes PRCL. I added the option to fix some OLTFs throughout the simulation. At every iteration, the simulation computes the required control filter to fix the selected OLTFs such that it will match the OLTFs in the undetuned and balanced IFO.

 

 

 

Attachment 1: MC_LANCE_OLTFs.pdf
MC_LANCE_OLTFs.pdf
  15759   Mon Jan 11 19:10:10 2021 ranaUpdateBHDMonte Carlo loop coupling Simulations
  • looking better, but the CARM plot still looks weird.
  • you should plot from 0.01 - 10,000 Hz
  • All of the loops should have true integrators below 1 Hz.
  • I don't think these loops are stable; the Bode plot is not a good way to check stability for LTI systems since you can be fooled by phase wrapping.
  14213   Sun Sep 23 20:15:35 2018 KojiSummaryOMCMontecarlo simulation of the phase difference between P and S pols for a modeled HR mirror

Link to OMC_Lab ELOG 308

  16038   Thu Apr 15 18:33:39 2021 KojiUpdateCDSMore 16bit ADC adapter boards

We received 10x 16bit ADC adapter boards from Todd. S2100687~S2100696

The number of soldered resistors seems to be less than that on the schematics. They are related to duotone, so check if it's OK upon use.

Attachment 1: P_20210415_183139_1.jpg
P_20210415_183139_1.jpg
  14849   Sat Aug 17 16:49:23 2019 gautamUpdateCDSMore 1Y3 work

Work done today:

  1. All ribbon cable connections to the backplane of the 1Y2 Eurocrates were removed. The cables themselves were cleared for more space to work with.
  2. 20x 15ft DB37 Cables were run between 1Y2 and 1Y3 via overhead cable tray.
  3. Backplane interface boards were installed for 1Y2 Eurocrate boards.
  4. Connections were made between the Acromag chassis and the eurocrate electronics modules.

Testing of functionality:

  1. Fast BIO switching was verified to work for the following photodiodes:
    • AS55, AS110, REFL11, REFL33, REFL55, REFL165, POX11, POY11, POP22, POP110.
    • No light was incident on the PDs.
    • Test was done by increasing the whitening gain to +45 dB, and then looking at the ASD of the electronics noise between 50 Hz and 500 Hz with the whitening enabled/disabled. We expect x10 difference between the two states. This was seen.
  2. "DetMon" channels were verified to work - see Attachment #1
    • Y-axis units is volts
    • Test was done by toggling the output of the 11 MHz Marconi, and looking for a change.
    • As seen in the attachment, all 5 monitor channels show a change.
    • This needs to be calibrated into some sensible units - I don't know why the different modulation frequencies have such different readbacks from supposedly identical Demod Board monitor points.
    • Not sure if the ~10 V reported by the REFL165 monitor point is real or saturated.
    • These channels are installed to signal/help debug the infamous ERA-5 decay problem, but maybe already some are decayed?
  3. QPD interface channels were verified to work - see Attachment #2
    • Test was done by shining a green laser pointer on QPD quadrants.

Much testing remains to be done, but I defer further testing till Monday - the main functionality to be verified in the short run is the whitening gain stepping. The strain-relief of cables and general cleanup will be undertaken by Chub. Current state of affairs is in Attachment #3, leaves much to be desired in terms of cleanliness.

I will also setup the autoburt for the new machine on Monday. We will also need to add some channels to C0EDCU.ini if we want to trend them over some years (e.g. RF signal powers for monitoring ERA-5 health).

* c1lsc FE was rebooted using the usual script, and everything seems to be healthy in CDS-land again, see Attachment #4.

Quote:

Next steps: 

  1. We did not get around to running the DB37 cables between the Acromag chassis and the 1Y2 Eurocrates today - this operation itself took the whole day as we also needed to lay out some support struts etc on the rack to support the Sorensens and the Acromag chassis.
  2. Once the Acromags are connected to the Eurocrates, we have to run in-situ tests to make sure the appropriate functionality has been restored.
  3. We must have bumped something in the c1lsc expansion chassis - the CDS FE overview screen is reporting some errors (see Attachment #3). I will fix this.
  4. General tidiness, strain-relief etc.
Attachment 1: Screen_Shot_2019-08-17_at_3.00.57_PM.png
Screen_Shot_2019-08-17_at_3.00.57_PM.png
Attachment 2: Screen_Shot_2019-08-17_at_3.12.23_PM.png
Screen_Shot_2019-08-17_at_3.12.23_PM.png
Attachment 3: IMG_7804.JPG
IMG_7804.JPG
Attachment 4: Screenshot_from_2019-08-17_17-04-47.png
Screenshot_from_2019-08-17_17-04-47.png
ELOG V3.1.3-