I (think) I have finished the new PMC base riser. The eDrawing of it (so you can view it on any computer) has been uploaded to the PMC wiki page.
I also attach it here, for comments.
Its going to need some kind of way to locate the PMC on the top. In the previous design, we had the 3 balls to decouple the body from the base. That design was flawed due to the roughness of the holes in the PMC body.
Also probably need some kind of relief on the bottom. Its possible that it would be OK like this, but I am unsure if the shop can maintain the flatness we want over the whole length and/or the flatness of any given (OLD) optical table over ~8". Its probably not a good idea to have to torque this (aluminum?) to make it conform to the optical table's shape.
Hmmm, so, this was just meant to be a riser that goes underneath the old PMC mount, to raise it from 3" beam height to 4" beam height. I will make another one that is a complete mount, designed for 4" beam height. Please hold........... .......... ....... ..... ... .
[Rana, Jamie, Jenne]
SPOB DC hasn't been so good lately, so we installed a new PO DC PD on the PO table. We used a 30% reflecting beam splitter (BS1-1064-30-1025-someotherstuff). We didn't check with a power meter that it's a 30% BS, but it seems like that's about right. The beamsplitter is as close as we could get to the shutter immediately in front of the regular POB/SPOB PD's, since that's where the beam gets narrow. The new picked-off-pickoff beam goes to a Thorlabs 100A PD. We haven't yet checked for reflected beams off the PD, but there is a spare razor blade beam dump on the table which can be used for this purpose. The output of this PD goes to the LSC rack via a BNC cable. (This BNC cable was appropriated from it's previous "use" connecting a photodiode from the AP table to a bit of air just next to the LSC rack.) Our new cable is now connected where the old SPOB DC cable used to be, at the input of a crazy Pomona Box tee.
For reference, the new levels of POB DC and SPOB DC, as measured by their BNC DC out connections is ~4mV each. Since the beamsplitter is 70% transmissive, we used to be getting about 5.7mV on each PD.
The new photodiode puts out about 40mV, but it has an ND1.0 filter on, so if more gain is needed, we can take it off to get more volts.
I have placed the G&H mirrors and the Y1 as pictured in my proposed layout in elog 8649. The distance between the 2" lens and the PDs has increased, so the focus point is all wrong. I have measured the distances between optics on the table, and will pick new lenses and finish the POP layout later today or tomorrow.
For now, here are the powers measured using the Ophir power meter:
PRM-ITMY lock, POPDC was ~190 counts
5.29 uW after Y1 weird angle. Can't see beam before then to measure
5.27 uW before BS50
3.5 uW before razor PD
3.00 uW before 110PD
4.94 uW before y1 (after G&H's)
4.92 uW after y1
2.66 uW before razor PD
1.61 uW before 110PD
I have a lens solution for the new POP QPD, plotted below. To get the beam size, I started with the waist at the ITM, so the out of vacuum table starts around 6 meters on this plot. Also, "PD" is the QPD, but the position marked on the plot is the maximum distance from the 2nd lens. In reality, I will place it a few cm after the lens. Once I've got that laid out, I'll move the 110PD (and its lens) and the camera around so that they are in good spots relative to the beam size.
Here is a photo of the way I left the table last Thursday. The notations in orange indicate what I need to do to make the actual table match my lens solution.
I have placed the lenses and the PDs in their new positions on the POP path. As Koji had pointed out to me in reply to elog 8663, what really matters to get the beam size I want on the QPD is the distance between the lenses, and not so much the absolute position of the lenses (since the Rayleigh range of the POP beam coming out of the vacuum is so long), so I left the 2" lens in place, and made the distance between the Y1 and the QPD's lens 35 cm.
I didn't move the camera very much, mostly just enough to get the beam centered on the TV. I need to check where this is in terms of the beam shape, to see where I should move it to, so that I'm getting useful beam motion information by looking at the camera.
The steering mirror for the POP110 PD is still between the camera and the steering mirror for the QPD, there's just much less space between those 3 elements than there was previously. I put the POP110 PD's lens and the PD itself in such a way that the PD is at the focus.
The PD which used to be the ASC razor blade PD has been put back in the cabinet. The cable that was plugged into it was being used for POPDC. I will need to switch things back so that POPDC is once again coming from the POP110 PD. Also, I need to bring over the power supply for the QPD, and lay some cables between the supply/readout box and the IOO chassis (where Jamie has freed up some channels for me).
Also, while I was on the POX table, I was reminded that we need to deal with the ITMX oplev situation, which Gautam detailed in elog 8684. I will ask Steve to take care of it when he's back from vacation.
... I need to ... lay some cables between the supply/readout box and the IOO chassis (where Jamie has freed up some channels for me).
I have made 3 dongles that go from 2-pin lemo to BNC so that I can connect the 3 QPD signals (X, Y, Sum) to the IOO ADC (Pentek Generic board in 1Y2, which also has the MC channels).
The interface board with the 2-pin lemo connectors doesn't have anything in the DCC for the document number (D020432), so I asked BAbbott, and he said: "After a bit of searching, I found that on psage 2 of D020006-A-pdf ( https://dcc.ligo.org/LIGO-D020006-x0 ), Pin 1 of each LEMO connector is the + leg, and pin 2 is the - leg. This means that you should connect the center conductor of the BNC (if you don't have any 2-wire twisted-pair cables around) should be connected to pin 1 of the LEMO, and the outer conductor should be connected to Pin 2. According to http://il.rsdelivers.com/product/lemo/epg0b302hln/2-way-size-0b-pcb-mount-socket-10a/1305621.aspx Pin one is the top one on the right-angled LEMO." According to page 50 of the lemo data sheet, pin1 is the one with the mark next to it, when you are looking at the solderable end.
I put the POPDC cable back to the DC output of the bias tee that is the first thing at the LSC rack that the POP110 PD sees. So, now we should be back to the old nominal PRCL locking, with the addition of the new QPD.
I'm going to give it a whirl.....
I've installed new filters for the T240 -> PRM static online angular feedforward that were trained after some of the recent changes to the signal chain of the relevant signals (i.e. the counts->velocity calibration that Rana did for the seismometers, and fixing the improper dewhitening of the POP QPD channels used as the Wiener target.)
Quickly trying them out now shows about the same level of performance as the previous ones, but the real performance I care about is during after-hours locking-time, so I'll take more measurements tonight to be posted here.
New PRM ASC was implemented. [to be cnt'd]
As the designed ASC filters in this entry had too little phase margins (~10deg), I had to compromise the servo design.
The design was modified and tested again. This will be reported by a following entry.
Incidentally, I have adjusted the demodulation phases of REFL33/55/165 for PRMIsb so that the PRCL is eliminated from the Q signals.
REFL33 125.5 deg -> +136.5 deg
REFL55 45.0 deg -> + 25.0 deg
REFL165 -79.5 deg -> + 44.5 deg
This change of the demod phase for REFL165 was a bit surprising.
I did not check the sign, so it could be -135.5 deg. But still this is a bit change.
The new PRM ASC design
FM1: zero at 0Hz, pole at 2000Hz, gain at 2000Hz = 2000
zero: f: 0.5Hz q: 1 / 4Hz, q: 2 / f: 1Hz, q: 3
pole: f: 2Hz q: 3 / f: 2.7Hz, q: 2 / f: 1Hz, q: 15
FM9: (HF Roll-off)
pole: f: 40Hz q: 1/Sqrt(2) (2nd order butterworth)
Servo gain: -0.023
FM1: zero at 0Hz, pole at 2000Hz, gain at 2000Hz = 2000
zero: f: 0.5Hz q: 1 / 4Hz, q: 2 / f: 1.5Hz, q: 10
pole: f: 1.02Hz q: 10 / f: 3Hz, q: 5 / f: 2Hz, q: 6
FM9: (HF Roll-off)
pole: f: 40Hz q: 1/sqrt(2)
Servo gain: -0.027
The loop gains were adjusted to have the UGFs of 10Hz. The measured openloop transfer functions were compared with the model.
The transfer functions for yaw are well matched. However, the pitch ones don't. It seems that the pitch loop has extra low pass
which I can't locate. The possibility is the analog electronics of the pitch loop.
The effect of the control between 0.3Hz to 3Hz are well represented by the model. The attachment 2 shows the free running
angle fluctuation, the ones with the control engaged, and the estimated spectra. Indeed, the estimated spectra well represent
the measured angular spectra.
The 40m produces a large amount of paper and cardboard waste. It would be worth it if we disposed those kind of garbages for recycling.
I set up two new garbage bins in the lab: one in the control rooms that adds up to the can/bottle recycling bin, and one other one in the office area, next to the printer for general paper disposal.
People in the lab are strongly invited to make use of the two new garbage bins and recycle their paper and cardboard waste.
Boxes can be larger than the garbage bin, so I'd recommend people to crash them before throwing them into the bin.
We have two new Basler acA640-100gm cameras. These are power over ethernet (PoE) and very tiny.
Today, Tega and I would like to vent the pump spool an dinstall the new FRG-400 Agilent Pressure Gauges (per elog 15703). The attached picture shows the volume needed to be vented highlighted in red, and the gauges that need to be replaced/removed (purple dot next to the name).
The vent plan is as follows:
Shut down TP2
Install new gauges
Will add to post with updates post vent.
[Jordan, JC, Tega]
We have installed all the FRGs and updated the VAC medm screens to display their sensor readings. The replacement map is CC# -> FRG#, where # in [1..4] and PRP1 -> FRG5. We now need to clean up the C1VAC python code so that it is not overloaded with non-function gauges (CC1,CC2,CC3,CC4,PRP1). Also, need to remove the connection cables for the old replaced gauges.
I have configured a NEW Prologix GPIB-Ethernet controller to use with HP8591E Spectrum analyzer that sits right next to the control room computers.
Static IP: 192.168.113.109
I have no clue how to give it a name like "something.martian" and to update the martian host table (Somebody please help!!)
I have no clue how to give it a name like "something.martian" and to update the martian host table (Somebody please help!!)
The instructions for adding a name to the martian DNS table are in the wiki page that I pointed you to:
The instructions at https://wiki-40m.ligo.caltech.edu/Martian_Host_Table are outdated!
The name server configuration is currently at /etc/bind/zones/martian.db [ source: elog:10067 ]
Anyway, I need superuser access to edit the files, which I don't have. Even if I did know the password, I don't think it's a good idea for me to be messing around. So any of the 40m folks please update the martian table to include:
Now that we have multiple machines we'd like to run the new front end code on, I'm finding it annoying to have to constantly copy files back and forth to have the latest models on different machines. So I've come to the conclusion that Rana was right all along, and I should working somewhere in /cvs/cds/caltech which gets mounted by everyone.
However, this leads to the svn problem: I.e. I need recent code checked out from the RCG repository, but our current /cvs/cds/caltech/cds/advLigo directory is covered by the 40m SVN. So for the moment, I've checked out the advLigoRTS from https://redoubt.ligo-wa.caltech.edu/svn/advLigoRTS/trunk into /cvs/cds/caltech/cds/advLigoRTS. This directory will be kept as up to date as I can keep it, both by running svn update to get Alex/Rolf's changes and on my end by keeping the new and updated models. It will remain linked the RCG repository and not the 40m repository. At some point a better solution is needed, but its the best I can come up with for now.
Also, because we are starting to compile on different machines sometimes, you may run into a problem where a code won't run on a different machine. This can be fixed by commenting out some lines in the startup script. Go to the /cvs/cds/caltech/scripts directory. Then edit the associated startSYS file by commenting out the lines that look like:
if [ `hostname` != megatron ]; then
echo Cannot run `basename $0` on `hostname` computer
Unfortunately, this gets reverted each time "make SYS" and "make install-SYS" gets run.
The other issue this leads to is that some machines don't have as many CPUs available as others. For example our new thin 1U machines have only 4 dual cores (8 CPUs total). This means the specific_cpu setting of any of the codes cannot be higher than 7 (cores being numbered 0 through 7). Core 0 is reserved for the real time kernel, and Core 1 will be used on all machines for the IO processor. This leaves only cores 2 through 7 available for models to use which include LSC, LSP, SUS, SUP, SPY, SCY, SPX, SCX, OMC, OMP, OAF, OAP?, IOC, IOP. Since there are more than 6 models, duplication in final production code of specific_cpus will be necessary. Codes which are all running on Megatron at one point will have to be rebuilt with new specific_cpu values when run on the actual final machine.
Here's the (calibrated) transimpedance of the new REFL55 PD.
T(55.3) / T_(11.06) = 93 dB
I made a little box for the new RF amplifiers we'll be using for the green beatnotes, to keep things tidy on the PSL table. They are both Minicircuits model ZHL-3A-S.
I took TFs of their response with the agilient analyzer (calibrating out the cables, splitters, etc.) Powered at +24V, we get a solid ~27dB of gain up to around 200MHz, which is fine for our needs. The phase profile is mostly a 6-7 nsec delay, which is negligible for ALS. Data files are attached.
Koji looked at me like I was crazy for using a BNC connector for the DC power. I haven't yet been able to find panel mount banana connectors, but when I do, I'll replace it.
I was working around the PSL table this morning.
1. I have fibers running from the Y end and the PSL table to the Optical Fiber Module for Frequency Offset Locking.
Y+PSL out power is ~200uW. From the transimpedance and responsivity specs of the RFPD (ThorLabs FPD310), we expect ~100uW or -10dBm RF power. I have not hooked up the RF output to a spectrum analyser to confirm this as yet.
2. Also, Steve and I ran RF cables (LMR-195A) from the PSL table to the FC module on the IOO rack.
Joe helped me compile the lsc simulink model, and now we have R&D phase rotation.
Right now, we have to do our own math, and figure out what relative phase to put in. Soonly, I'll figure out how to do subtraction, and we can put in the measured value.
More details when I'm not running around like crazy...
Okie dokie. Last night I had modified the c1lsc.mdl to accommodate the R & D phase rotation. I also made pretty new screens. This morning however, the adventures began.....
Under Joe's supervision, I ran "make c1lsc". The error that came up was something about things not being connected. Joe assures me that this is a temporary problem, that Rolf is already working on. The reason is that right now the LSC model is "flat", i.e. it doesn't have a bunch of sub-boxes and sub-screens in the simulink model. Somehow this causes badness. Joe stuck all the guts of the LSC model into a sub-model. He then enabled "top_names", which makes the channels use the name of the sub-model, not the sub-model AND the main model (so since the sub-model is called LSC, our channels are just C1:LSC-OTHER_STUFF, rather than C1:LSC-LSC_OTHER_STUFF). This fixed things so that the compiling worked (when we did "make c1lsc"). The one other thing that we changed was to delete all of the little "Outs" that were attached to EPICS readouts. These are unneccessary and don't go anywhere, and when we made the sub-model, they made a bunch of empty outputs (unconnected outs on the main simulink model). So, after doing that, we were able to compile, and do "make install-c1lsc", and all was good in the world. Mostly.
Joe then noticed that I was using the CDS part "cdsPhase", which only takes one phase input. I wanted "cdswfsPhase", which actually does the R&D phase rotation that we want. Perhaps Alex/Rolf/whoever should change the name of that CDS part. We switched all of the cdsPhase blocks to be cdswfsPhase, and recompiled. All was still good in the world. Mostly.
The last thing that was funny was that when I wanted to execute the medm screens, they would still look at the old _IQ_MTRX_1_1 and _IQ_MTRX_2_1 values, rather than the newly defined _PHASE_R and _PHASE_D channels, even though while editing the medm screen, it looked like it was pointing to the right place. Anyhow, I opened the text file version of the C1LSC_PDX.adl, and changed the channel names to the _R and _D versions by hand. I don't know if we edit the screens and run generate_screens.py again, if we'll have to re-edit the .adl text files.
After fixing this, all really was good in the world.
Perhaps though, this making a subsystem business broke the filters somehow? Foton is looking at the wrong text file now? Something? The filters are all still there, they just got moved down a level. Joe said that he and Rolf are on it, and he should be able to put the LSC model back to being "flat" in the next few days.
We recieved an overlay from Chris Stoughton which he used for a ZCU11 board. The overlay is supposed to be compatible with the RFSoC 2x2 and help enable the Multi-Tile Synchronization (MTS) we need. He also provides a .py with the necessary low level connection to the board and its memory along with a few sample notebooks.
Progress So Far:
As Jenne suggested last night, I changed the C1PEM overview in Epics. Previously, the C1PEM_OVERVIEW.adl screen had two separate visualizations, one for LP and one for BP for each channel. I changed the format so that there is only one frame per RMS channel, showing all of the input and output as before, but continuously, to demonstrate the actual RMS process.
First, the input is bandpass filtered, then multiplied by itself (squared), then lowpass filtered, and then square rooted to yield the final output. I have kept the previous files, but have applied this new format to all of the RMS ACC*, GUR1, GUR2, and STS1 channels.
As Rana suggested yesterday, I made channels for 0.01 - 0.03 Hz and 0.03 - 0.1 Hz, and created filters for them, which I will work on some more now.
As requested, I placed an order for an assortment of new RF cables: SMA male-male, RG405.
They're expected to arrive mid next week.
I re-ordered the below cables, this time going with flexible, double-shielded RG316-DS. Jordan will pick up and return the RG-405 cables after the holidays.
Our favorite (flexible) RF cable is Belden's 1671J (Jacketed solder-soaked coax cable). It is compatible RG405. I'm not sure if there is off-the-shelf SMA cables with 1671J.
After updating the 40 m finesse file to incorporate the new SRC length (and the removal of SR2), we find that the current SRM radius curvature is fine. Thus a replacement of SRM is NOT required.
Basically, the new one-way SRC gouy phase is 11.1 deg according to Finesse, which is very close to the previous value of 10.8 deg. Thus the transmode spacing should be essentially the same.
In the first attached plot is the mode content calculated with Finesse. Here we have first offset DARM by 1m deg and misaligned the SRM by 10 urad. From the top to bottom we show the amplitude of the carrier fields, f1, and f2 sidebands, respectively. The red vertical line is the nominal operating point (thanks Koji for pointing out that we do signal recycling instead of extraction now). No direct co-resonance for the low-order TEM modes. (Note that the HOMs appeared to also have peaks at \phi_srm = 0. This is just because the 00 mode is resonant and thus the seed for the HOMs is greater. )
We can also consider a clean case without mode interactions in the second plot. Indeed we don't see co-resonances of high order modes.
We removed the old SRM and PRM from their cages, and are temporarily storing them in the rings which we use to hold the optics while baking. Steve will work on a way to store them more permanently.
We then hung the new SRM (SRMU03) and new PRM (SRMU04) in the cages. We were careful not to break the wires, so the heights will not have changed from the old heights.
The optics have not been balanced yet. That will hopefully happen later this week.
Thanks to Steve's work on some L brackets, and Kiwamu's lifting help, we now have a new SUS IO chassis in the new 1X4 rack (formerly the 1Y4 rack), just below the new SUS and LSC computers. I have decided to call the sus machine, c1sus, and give it IP address 192.168.113.85. We also put in a host interface adapter, OSS-HIB2-PE1x4-1x4 Re-driver HIB, which connects the computer to the IO chassis.
The IP was added to the linux1 name server. However, the computer itself has not been configured yet. I'm hoping to come in for an hour or two tomorrow and get the computer hooked up to a monitor and keyboard and get its network connection working, mount /cvs/cds and get some basic RCG code running.
We also ran ethernet cables for the SUS machine to the router in 1X6 (formerly 1Y6) as well as a cable for megatron from 1X3 (formerly 1Y3) to the router, in anticipation of that move next week.
During the day, I realized we needed 2 more ADCs, one of which I got from Jay immediately. This is for two 110Bs and 4 Pentek ADCs. However, there's a 3rd 110B connected to c0dcu1 which goes to a BNC patch panel. Original Jay thought we would merge that into 4 pin lemo style into the 2nd 110B associated with the sus front ends. We've decided to get a another ADC and adapter. That will have to be ordered, and generally take 6-8 weeks. However, it may be possible to "borrow" one from another project until that comes in to "replace" it. This will leave us with our BNC patch panel and not force me to convert over 20 cables.
I also discovered we need one Contec DIO-1616L-PE Isolated Digital IO board for each Chassis, which I wasn't completely aware of. This is used to control the ADCs/DACs adapter boards in the chassis. It means we need still need to put a Binary Output board in the c1iscex chassis. Hopefully the chassis as they come in come from Downs continue to come with the Contec DIO-1616L-PE boards (they have so far).
The current loadout of the SUS chassis is as follows:
Far left slot, when looking from the front has the OSS-MAX-EXP-ELB-C board, used to communicate with the c1sus computer.
Slot 1 ADC PMC66-16AI6455A-64-50M
Slot 2 DAC PMC66-16AO16-16-F0-OF
Slot 3-6 BO Contec DIO-32L-PE Isolated Digital Output board
Slot 7 ADC PMC66-16AI6455A-64-50M
Slot 8-9 DAC PMC66-16AO16-16-F0-OF
Slot 10-11 ADC PMC66-16AI6455A-64-50M
Slot 12 Contect DIO-1616L-PE Isolated Digital IO board
Slot 1 ADC adapter D0902006
Slot 2 DAC adapter D0902496-v1
Slot 7 ADC adapter D0902006
Slot 8-9 DAC adapter D0902496-v1
Slot 10-11 ADC adapter D0902006
The new SUS screen can be reached via sitemap -> IFO SUS button -> NEW ETMX dropdown menu link. Please use and provide feedback. Not sure exactly if we need/want the display screens after the IOP model on the right of the medm screen. I have not been able to locate the corresponding channels but did not want to remove them until I was sure that we don't plan to add these features to our screens. When all bugs have been ironed out, we can use appropriate macro substitution for the other optics.
The next feature to add is the BLRMS to the coil and PD channels. I plan to combine the PEM BLRMS medm implementation with the sus_single_BLRMS model block (located in /opt/rtcds/userapps/release/cds/c1/models). This way we use the latest BLRMS block in "/opt/rtcds/userapps/release/cds/common/models/BLRMS.mdl" whilst also leveraging the previous work done on the sus_single_BLRMS model, which neatly fits into our current SUS model.
Work on the medm screen for SUS RMS monitor is ongoing. The next step would be to incorporate this into the SUS medm screen, add the BLRMS model to the SUS controller model, recompile, check that the channels are being correctly addressed, then load the appropriate bandpass and lowpass filters.
Turns out the BLRMS monitoring channels for MC1, MC2, MC3, ITMY and SRM already exist in c1pem. So I modified the new SUS screen to display the BLRMS info for the aforementioned optics. Next step is to add the BLRMS monitor for PRM, ITMX, ETMX and ETMY. This would require extending the number of inputs for the "SUS" block in c1pem to accomodate the additional inputs from the remaining optics.
Now that the 3f locking looks so cool for the PRMI, I suppose that the PRMI + arm stuff will be very successful.
At LLO, I've just noticed the screens that they have for the single pendulums / TTs. I'm attaching a screenshot of the one Zach is using for the steering into the OMC. We should grab these and replace our existing SUS screens with them.
Totally agree. The old suspension screen should be driven away.
I have received the new screwdriver bits that will work with the two electric screwdrivers we have. I have distributed them in the 40m. Some are in the electronics stations and some are in the toolbox in the lab. The new electric screwdriver (which looks like a drill but takes typical screwdriver bits) is in the room with the workshop. It is in the blue Makita box. For some reason, lots of the old bits were rounded because of incorrect use. I have thrown the unuseable ones out.
I also requested some screw extractors in case we need them. the one we have now is really big and may not work on smaller screws.
I was looking at the new seismometer data and plotted the coherence between the different arms of C1:PEM_GUR1 and C1:PEM_GUR2. There was not much coherence in the X arms, Y arms, or Z arms of each seismometer, but there were within the x and y arms of the seismometer.
I think the area we should focus on with filtering is lower ranges, between 0.01 and 0.1, because that it where coherence is most clearly high. It is higher in high frequencies but also incredibly noisy, meaning it probably wouldn't be good to try to filter there.
In my previous post here, a new servo design was discussed. Although the exact design used will depend on the particular noise requirements for the 40m and the Bridge Labs (requirements will be considered separately for each application), I still have to yet to see those formalized. Despite this, I have been simulating an example servo circuit with three switchable stages. The design can be found at: New Servo.
Essentially, this circuit consists of three unity gain buffers that can be switched into different filtering states. Attached is a plot of the transfer function of this particular circuit with successive stages turned on. The curve (0) corresponds to all of the filters being switched off, so the total behavior is that of a unity gain buffer. The curve (1) corresponds to the first stage being turned on with the 2nd and 3rd still acting as unity gain buffers. This first state has a gain of ~80 dB at DC and a pole at ~10 Hz which sets the unity gain crossing at ~100 kHz. The curves (2) and (3) correspond to the second and third stage being turned on, respectively. Each of these stages has a pole at DC (i.e. ~infinite gain) and a zero at 10^4 Hz. For f > 10^4 Hz, these stages have gain ~ 1, as we can see in the transfer function below.
I have also performed some noise analysis of this circuit. Attached are a few plots produced by LISO showing the resistor and op-amp noise separately (it was too cluttered on one plot) at the output node of the servo. Both of these plots have a "Sum Noise" trace, which is the sum for every circuit element and is thus identical between plots. The third noise spectrum included is simply the noise at the output referenced to the input with the previously computed transfer function. I'm not sure if there is a simple method embedded in LISO to reference the noise at the output node to the input, but it should be as simple as numerically dividing the noise spectrum by the transfer function between input and output.
Next, I will be attempting time-dependent simulations of this simple circuit using delayed switches instead of manually controlled ones.
Yesterday Chris and I completed setup of the Supermicro machine that will serve as a dedicated host for developing and testing RTCDS sim models. It is currently sitting in the stack of machines in the FE test stand, though it should eventually be moved into a permanent rack.
It turns out the machine cannot run 10 user models, only 4. Hyperthreading was enabled in the BIOS settings, which created the illusion of there being 12 rather than 6 physical cores. Between Chris and Ian's sim models, we already have a fully-loaded machine. There are several more of these spare 6-core machines that could be set up to run additional models. But in the long term, and especially in Ian's case where the IFO sim models will all need to communicate with one another (this is a self-contained cymac, not a distributed FE system), we may need to buy a larger machine with 16 or 32 cores.
IPMI was set up for the c1sim cymac. I assigned the IPMI interface a static IP address on the Martian network (192.168.113.45) and registered it in the usual way with the domain name server on chiara. After updating the BIOS settings and rebooting, I was able to remotely power off and back on the machine following these instructions.
Although not directly related to the FE testing, today I added a new machine to the test stand which will be dedicated to running sim models. Chris has developed a virtual cymac which we plan to run on this machine. It will provide a dedicated testbed for SimPlant and other development, and can host up to 10 user models.
I used one of the spare 12-core Supermicro servers from LLO, which I have named c1sim. I assigned it the IP address 192.168.113.93 on the Martian network. This machine will run in a self-contained way that will not depend on any 40m CDS services and also should not interfere with them.
As payment for borrowing 2 of our seismometers, Zach has made us a new Trillium cable, to go from the granite station to the readout box, which we can put into 1X7, where the PEM ADC is. To put the T-240 in side the can, and seal it, we need a little jumper cable from the seismometer to the granite, but for now, we can just pass this cable underneath the can.
LiYuan has kindly done some Total Integrating Sphere (TIS) measurements on ITMU01 and ITMU02. A summary of the measurement is attached. I uploaded the measurements and some analysis script to nodus at /home/export/home/40m_TIS. I created a Wiki page for the measurements and linked to it from the core optics page.
These TIS measurements look very similar to the TIS of the LIGO optics. Further analysis shows that the scatter loss is 10+/-1.7 ppm for ITMU01 and 8.6+/-0.4 ppm for ITMU02.
In this calculation, a gaussian beam the same size bouncing off the 40m ITMs is assumed to scatter from the mirrors. The error is calculated by moving the beam around randomly with STD of 1mm.
In LiYuan's setup, TIS is measured for scattering angles between 1 and 75 degrees. If we go further and assume that the scatter is Lambertian we can extrapolate that the total loss is 10.9+/-1.9 ppm for ITMU01 and 9.2+/-0.5 ppm for ITMU02.
These measurements complete the loss budget nicely since with the 6ppm loss predicted from the phase maps, the total loss in the arm cavities would be 6+10+10=26ppm which is very close to the 28ppm loss that was measured after the arm cavity optics were cleaned.
The main C1 summary pages are back online now thanks to Max and Duncan, with a gap in pages from June 8th to July 4th. Also, I've added my new VMon and Sensors tabs to the SUS parent tab on the main pages. These new tabs are now up and running on the July 7th summary page.
Here's a link to the main nodus pages with the new tabs: https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20160707/sus/vmon/
And another to my ldas page with the tabs implemented: https://ldas-jobs.ligo.caltech.edu/~praful.vasireddy/1150848017-1150848317/sus/vmon/
Let me know if you have any suggestions or see anything wrong with these additions, I'm still working on getting the scales to be right for all graphs.
I started to receive emails from cron every 15min. Is the email related to this? And is it normal? I never received these cron emails before when the sum-page was running.
I don't know much about how the cron job runs, I'll forward this to Max.
Max says it should be fixed now. Have the emails stopped?
This should be fixed now—apologies for the spam.