Displaying reports 11241-11260 of 84715.Go to page Start 559 560 561 562 563 564 565 566 567 End
Reports until 14:01, Thursday 01 February 2024
H1 SUS (SUS)
rahul.kumar@LIGO.ORG - posted 14:01, Thursday 01 February 2024 - last comment - 13:41, Friday 02 February 2024(75677)
ZM4 (P-SAMS in HAM7) preload adjusted to change the radius of curvature of the mirror

Camille (CIT), Austin , Rahul

This morning we went to HAM7 chamber and changed the preload on ZM4 (P-SAMS) suspension as per the document E2300463_V1. This changed the RoC of ZM4 mirror without the PZT actuation. Given below are the details of our work - Camille will add pictures later on.

- After setting ZM4 into SAFE state we locked all three stages of the suspension. We had already taken healthy TF measurements before starting our work.

- The bottom mass cable was disconnected and carefully re-routed so that it stays away from the fixture plate.

- four add-on masses (basically 1/4-20 screws with washers) attached to the bottom mass was then removed.

- bottom mass Fixture plate (D2100121) was attached to the structure using six 8-32 screws.

- The bottom mass (already locked using EQ stops) was then further clamped using four 1/4-20 screws through the fixture plate. We had to adjust the height of the bottom mass to the align the threads with the holes on the fixture plate.

- Once the bottom mass was securely clamped, we removed the three set screws on the preloader.

- Using a torque wrench we increased the preload on the bottom mass by ~29 in.lb. (Total preload from torque after increase was 75 in.lb).

- We then followed all the above steps backwards (i.e set screws, add on mass put back, fixture plate removed, cable re-connected and the suspension set free).

- Once all done, we started damping the suspension and checked for any BOSEM flag changes - looked all fine.

- We took the transfer function measurements and ZM4 looked healthy.

Hence we took all the tools out and put the curtains back on HAM7 chamber.

Next, we will go into laser hazard with SQZ team and check for any changes in beam alignment and make adjustments as required.

Comments related to this report
camille.makarem@LIGO.ORG - 14:42, Thursday 01 February 2024 (75679)AWC
1st image: PSAMS locked in place with EQ stops.
2nd image: PSAMS locked with bottom mass fixture plate.
3rd image: Removal of set screws.
4th image: Preload adjustment with torque wrench.
5th image: Preload adjustment with torque wrench.
6th image: Torque wrench dial with the blue needle showing the total torque on the preloader (75 in lbs.)
Images attached to this comment
michael.zucker@LIGO.ORG - 08:21, Friday 02 February 2024 (75692)

Excellent! 

rahul.kumar@LIGO.ORG - 13:41, Friday 02 February 2024 (75710)SQZ, SUS

ZM5 offloaded as well, see LHO alog 75709.

H1 AOS
jason.oberling@LIGO.ORG - posted 12:15, Thursday 01 February 2024 - last comment - 10:54, Friday 02 February 2024(75669)
FARO Progress So Far

J. Oberling, R. Crouch, T. Guidry

Update on FARO progress so far.  Warning, incoming wall of text.

There have been issues accurately aligning to the LHO global coordinate system to the accuracy necessary for IAS work, specifically in getting good alignment to the global Z axis.  This is somewhat of a repeat of the struggles when prepping the FARO for the FCT (Filter Cavity Tube) install work; while we were able to get an alignment good enough to be well within the FCT installation tolerances, the tolerances for optic alignment are more stringent (+/-1.0 mm positional tolerance) so we have to get a better alignment to our global coordinate system.  To date we have worked in 2 areas: aligning to the global coordinate system, and accurately moving the FARO around the West Bay.  For reference, monument name and coordinate information can be found on the DCC at D1100291.

Global Coordinate System Alignment

To start, we began by following our WIP procedure for global coordinate alignment.  Part of this is to refine said procedure, since I quickly threw this document together (almost 2 years ago now) after a phone call with PolyWorks tech support; we now have a red lined copy that I will use to update the WIP procedure.  Due to line of sight issues and monument shape (BTVE monuments are domes, not flat; direct line of sight to PSI-6 is blocked) we use a sphere fit rod to probe the monuments (place the point of the rod in the monument punch and trace out a sphere as best we can while keeping the rod point firmly in the punch (the monument punch limits how much of a sphere we can trace, and therefore the accuracy of Polyworks' sphere fit); the Polyworks software then fits the data to a sphere).  In this way we can enter the coordinates of our alignment monuments as the center point of a sphere, then use the sphere fit rod to probe the monument (useful for ones that are out of direct line of sight, like PSI-6, or ones that are not flat, like BTVE-1).  We have 2 sizes of sphere fit rod, a 3" and a 5".  We first used the 5" rod, as it's the same we used for FCT install setup, and the results of that alignment are shown in the 1st picture.  As can be seen, not very good (one can ignore the diameter measurement on this picture and all the ones that follow, the error there is a result of the limited sphere shape we can trace with the sphere fit rod; PolyWorks told us back in 2022 that the alignment algorithms do no consider this data, only X, Y, and Z).  We then used the 3" rod and repeated the alignment procedure, results shown in the 2nd picture.  This is seemingly a good bit better, but the issues arise when we then try to measure a known monument.  Unfortunately, due to a lack of known monuments in the LVEA West Bay, we don't have any independent monuments we can measure against that have an associated Z axis coordinate, so we have to use the same monuments we use to perform the alignment (i.e. BTVE-1, PSI-1, PSI-2, and PSI-6).  In addition, we can't use PSI-6 (located in the biergarten), because the SUS electronics rack closest to WBSC2 sits directly over it and blocks direct line of sight (we can see it when using a sphere fit rod, but not with a regular SMR nest).  When looking at the 3 available monuments we have, the FARO reports their coordinates as ~1.5mm higher than our documentation says they are; this is consistent across all 3 monuments, indicating a systemic error somewhere (or maybe the documentation is wrong?).  X and Y are accurate to <0.1 mm across all monuments measured.

This launched us on trying to find this 1.5mm error.  The first thing we tried is reading up on PolyWorks' alignment algorithms to see if there's something in the setup we're missing (PolyWorks' included reference guide is a wealth of information on the software).  From this we learned that the alignment algorithms are updateable after the fact (including adding and removing alignment features/monuments), and the software will then apply that update across all alignments in the project.  This includes adding and removing alignment targets on the fly, and changing how the routine considers the available data (weighting different monuments over others, which axes to use, etc.).  Part of our alignment procedure is to first align to X, Y, and axis tilt, then perform another alignment routine to align to the Z axis.  We noticed that the portion of the alignment routine that aligns to X, Y, and tilt was also considering Z, when it shouldn't be; the portion that aligned to Z was considering X and Y when it shouldn't be.  We can make these corrections on the fly, without having to re-measure anything, so we did.  The update changed the X and Y axis deviations, but caused no change in the Z axis deviations; the results of this correction are shown in the 3rd picture.  The X deviation for PSI-2 got a little worse but improved for the other 3 monuments, Y is practically the same across all 4, and Z was unchanged as expected.  But we still see the +1.5mm Z axis error when directly measuring these monuments (X and Y remain accurate to <0.1mm).

The next thing we considered is the difference between the monument surface and the monument punch.  The sphere fit rod measures to the point of the rod, which sits at the bottom of the punch while we use it to probe the monument location.  However, the Z axis coordinate for these monuments is registered to the surface of the monument, not the bottom of the punch.  Therefore in this setup the FARO is actually measuring the bottom of the punch, which then adds error to the coordinate system alignment.  Using our Center Punch Nest (an SMR nest with an included punch for marking monuments, abbreviated CPN from here on out) and a depth gauge we measured the difference between the monument surface and the bottom of the punch for each of our 4 alignment monuments (the punch portion of the nest only depresses as far as the punch can go, so we can measure the difference between the surface and the monument punch based on how far the nest punch can travel).  The results, assuming the surface of the monument is 0:

This means that when we use a sphere fit rod to probe these monuments we have to correct the global coordinate by the above amounts so we're measuring the correct point on the monument.  For example, the global Z axis coordiante for BTVE-1 is -1057.2mm, but when using a sphere fit rod we need to enter the corrected coordinate of -1058.0mm (-1057.2 - 0.8) into PolyWorks.

Tyler suggested we also check the local difference in the Z axis between our alignment monuments, using BTVE-1 as the origin.  We have a local coordinate survey from the late 90s for the PSI and BTVE monuments in the LVEA (the last time this was done); this data is available at D970210 in the file Rogers_LHO_PSIMonumentsAs-Built.pdf on page 2, and again in D1100291 in the file LHO_PSI_Monument_Z_Corr_MEZ220406a.xlsx, in Column C.  We used the FARO to check this, using a blank project so the FARO was not aligned to our global coordinate system.  Setup again in the West Bay in the same position we've been using to probe our alignment monuments, we oriented the FARO to local gravity (the FARO levels and then orients itself to the local gravity at its current location), then used an SMR with our CPN set over each monument punch to measure the difference in Z for each monument (deltaZPSI-X = ZBTVE - ZPSI-X); we're essentially using the FARO as an autolevel to perform a differential height survey.  Since we don't have direct line of sight to PSI-6 we set the CPN roughly inline with PSI-6 in X but set against the SUS rack so the FARO can see it (roughly 300mm +Y from the monument); this put the SMR on the vinyl floor, which we measured to be ~2mm thick using a set of calipers.  This could add some error, as we're not directly over PSI-6 and therefore cannot account for any height difference between our location and the monument (such as variations in the surface height of the concrete), but it's the best we have given our line of sight restrictions (the West Bay is crowded, but it's the only place where we have a collection of monuments with a registered Z axis coordinate).  Results and deltaZ from the old Rogers survey, all units in mm:

  Rogers As-Built Survey, 1997 FARO, 2024 Difference between Rogers/FARO
deltaZPSI-1 -826.3 -825.1 +1.2
deltaZPSI-2 -827.5 -826.4 +1.1
deltaZPSI-6 -822.4 -821.0 +1.4

So the FARO indicates that the Rogers As-Built survey from 1997 was not correct, so we adjusted the global Z axis coordinates for our 3 PSI monuments using the above FARO data.  We then further adjusted the Z axis coordinates using the difference between the punch depth and the monument surface.  This gives us the following global Z axis coordinates for our alignment monuments, all units in mm:

  New global Z using FARO height Global Z for bottom of monument punch
BTVE-1 -1057.2 (unchanged) -1058.0
PSI-1 -1880.8 -1881.9
PSI-2 -1877.7 -1878.4
PSI-6 -1876.2 -1876.8

We then used these new global Z axis coordinates for the bottom of the monument punch to align the FARO to our global coordinate system, results shown in the 4th picture.  We created points based on the global Z of the monuments themselves, and performed a Build/Inspect operation to get our deviations in X, Y, and Z (again using the CPN to place the SMR over the monument punch; the CPN registers to the monument surface); these results are shown in the final picture.  As can be seen, the reported X and Y axis measurements are good to better than 0.05mm, but we still have some significant error in Z.  It's much better than the ~1.5mm we were seeing previously, but nowhere near as good as X and Y.

We also noticed from the FARO's position that we could see height monument 903 (information in T1100187); this height mark is registered to the local LVEA coordinate system, and is on a metal post.  Using a autolevel we placed a temporary magnetic SMR nest in line with the height mark.  From this we could get X and Y coordinates for a spot very close, but not exactly on, the height mark (X is right on it, but Y is roughly 1" +Y).  With these X and Y coordinates we can transform the registered local Z coordinate to a global one (see T0900340) and compare to what the FARO says (the ~1" offset in Y is not an issue, as the Y axis tilt is very small at 12.5µrad, which causes a 0.3µm error in the global Z (yes, that's micrometers)).  We did this very quickly with a cell phone calculator, and did not get a screenshot or picture of the results (my fault), but the FARO thinks that height mark 903 is ~4.2mm higher than we would expect after converting its local Z to a global Z.  We have no other height marks we can place a nest by to do this same measurement, so we currently have no way to know if this error is in the height mark itself or something with the FARO (or a combo of the 2).  Will have to move the FARO around (which we can do accurately, see next section) to find something else to look at.

What's causing this error?  At this point in time we are not sure.  Some thoughts:

Moving FARO

We were able to move the FARO into the biergarten area using a collection of glued nests (set during FCT install) and magnetic nests.  This was done independently of our gloabl coordinate alignment work.  We were aligned to our global coordinate system (although we're still questioning the accuracy), but only looking at how accurately we could move the FARO (device target deviations between moves and device positional uncertainty at each location), which does not depend on being accurately aligned to any set coordinate system.  When doing a move you want a minimum of 3 targets, but PolyWorks support has repeatedly told us that you really want at least 6.  While the software will use 3, using 6 or more greatly increases the accuracy of the move.  We were able to use roughly 8 targets to move into the biergarten area and back out near the Test Stand.  In total we did 3 device moves for a total of 4 device positions: position 1 at our intial setup point, position 2 closer to the FCT to have better line of sight into the biergarten, position 3 in the biergarten area but outside of the cleanroom, and position 4 back in the West Bay near the test stand.  The largest target deviation we saw between device positions was ~0.2mm.  In addition, PolyWorks has a routine to calculate the positional uncertainty of the FARO.  This routine reported a positional uncertainty of <0.05mm for each device position, indicating that we can accuratly move the FARO around.  This was good to confirm, as we're going to have to move the FARO around the LVEA to find other monuments with known global Z axis coordinates to test our global coordinate system alignment.

Next Steps

Images attached to this report
Comments related to this report
michael.zucker@LIGO.ORG - 08:20, Friday 02 February 2024 (75691)

Outstanding progress, agree the discrepancies are puzzling. I might suggest picking up the factory scribe lines on BSC, manifold and gate valve large flanges, if you can see them (might need a water hose level between the sides to correct for clocking).  True, these will have cumulative installation error (spec potentially ± 2mm radially, though recall none that bad). And they could just as well be referred to faulty historic survey (!) But, at the end of the day, we may want to just follow the chambers anyway, wherever they have wandered...

jason.oberling@LIGO.ORG - 10:54, Friday 02 February 2024 (75706)

Yesterday, Ryan and I went out and tried a couple of things.  First, I used the 3" sphere fit rod to probe the monuments in a test of how much probing technique could potentially change the alignment results.  Turns out, a good bit.  We changed nothing in our alignment procedure except I probed the alignment monuments using the 3" sphere fit rod while Ryan drove the computer.  The results of the alignment routine and the subsequent Build/Inspect on our monuments are shown in the first two pictures.  As can be seen, a good bit different from our previous attempt with Ryan probing the monuments.  While not surprising, this shows that probing technique with the sphere fit rod potentially has a large effect on the accuracy of the alignment.

We next repeated this process, except we changed monuments PSI-1 and PSI-2 from spheres to points.  We can only do this for these 2 monuments, as the top of BTVE-1 is dome shaped and we do not have direct line of sight to PSI-6.  We had to offset the Z axis coordinate for PSI-1 and PSI-2 by +50.8mm to account for the CPN we used to probe these monuments, hence the diffferent Z axis coordinates (the software does not automatically compensate for the nest offset when doing a simple probe operation, but it does do this compensation with a Build/Inspect operation).  Nothing else in the process changed.  Results are shown in the final 2 pictures.  As can be seen, some alignment deviations became worse and some became better, but the Build/Inspect results were all better across the board (but still not within the aLIGO monument placement tolerance of +/- 0.2mm).

What does this mean?  As stated previously, due to the lack of known monuments in the West Bay and lack of line of sight to other known monuments we currently can't tell if this error is in the FARO setup or in our monument coordinates.  But what this does tell me is that we need to get away from using the sphere fit rods as much as we can.  This won't be possible for BTVE-1 due to its dome shape, but I think we can do this for PSI-6.  The PolyWorks alignment routines are updatable on the fly and after the fact (meaning we can add an alignment monument to the routine after we've already performed said alignment routine).  From reading the reference guide, it seems to me that we could use BTVE-1, PSI-1, and PSI-2 to do an initial alignment to the global coordinate system, move the FARO to a location with direct line of sight to PSI-6, then probe PSI-6 as a point instead of a sphere and add it to the alignment routine; it's our hope that this allows us to get a more accurate shot at PSI-6 and therefore a better alignment to our global coordiante system.  This is the next thing we want to test, and will also look into Mike's suggestion of the chamber door flange scribes (these can be a little difficult, as the blue HEPI support piers make the line of sight to these scribes pretty narrow).  The ultimate goal here is to get a good alignment for the FARO and then map out the LVEA monuments, adding more where and when we need to; the hope is that we can then use those monuments to align the FARO from anywhere in the LVEA without having to constantly resort to this intial alignment routine (and therefore getting away from using the sphere fit rods entirely).

Another potential issue we noticed, is there is now a running clean room next to our FARO setup, set over the mechanical test stand (to be used, I think, for sorting 3IFO SUS parts from a large ISI storage container into individual SUS storage containers).  Proper coordination was done in advance and we didn't expect this to be an issue, but this week we have had problems probing monument PSI-6 that we did not have in the prior 2 weeks.  While it's not confirmed the clean room is the cause, air temperature gradients and air currents can affect the accuracy of the FARO so this could also be influencing our results.  Will also try doing these alignment tests with the clean room off and see if we get better results.

Images attached to this comment
H1 CDS
david.barker@LIGO.ORG - posted 11:15, Thursday 01 February 2024 (75673)
Added ndscope trends to track EX pumpdown

The EX pumpdown trends were added to the CDS Ndscope Trends:

https://lhocds.ligo-wa.caltech.edu/exports/dave/vac_ex_press_1_day.png

1 day

LHO FMCS
eric.otterman@LIGO.ORG - posted 10:58, Thursday 01 February 2024 (75672)
Mid X air handler damper control
After discussing with Richard, we changed to manual control of the outside air dampers back to automatic on the air handlers. They had previously been in manual to control building static pressure, but as the mid stations are decommissioned, building static pressure is no longer a major concern. Automatic damper control will allow the system to cool with outside air instead of relying on chilled water, thereby reducing energy usage. It will take some time for the PI loop to relearn its controlling effectiveness so there may be fluctuations in space temp and supply air temp. There is also more noticeable airflow noise which may need to be considered. These changes will be evaluated at MX first.  
H1 PEM (OpsInfo)
ryan.crouch@LIGO.ORG - posted 10:51, Thursday 01 February 2024 - last comment - 11:31, Tuesday 13 February 2024(75671)
Dust monitor levels

The dust monitor IOC was restarted this morning by Dave which can reset the alarm levels. Following document E1600132, I confirmed that the alarms levels are still set properly, The CS dm alarms, 5, 6 & 10 are set to the "Class-100" (major alarm at 100 counts for both 0.3u and 0.5u as opposed to their normal 10000 for 0.5u and 7000 for 0.3u) as defined in the document since these monitors are by vented open chambers. Once the chambers are closed back up I'll put the CS dm alarm thresholds back.

Comments related to this report
ryan.short@LIGO.ORG - 15:32, Monday 05 February 2024 (75734)OpsInfo

I've set the alarm levels for dust monitors 6 and 10 back to their nominal levels of 7000 counts minor and 10000 counts major for both 0.3u and 0.5u since HAM3 is closed and the cleanroom is off. Dust monitor 5 (HAM6) remains at the lower alarm level of 70 counts minor and 100 counts major.

ryan.crouch@LIGO.ORG - 11:31, Tuesday 13 February 2024 (75844)

DM5 is actually the DM by HAM3 and DM6 is by HAM5/6/7. So I set DM5 back to its higher levels since the doors back on and I lowered DM6s to CLASS 100 levels till the doors go back on later this week. 

LHO VE
david.barker@LIGO.ORG - posted 10:16, Thursday 01 February 2024 (75670)
Thu CP1 Fill

Thu Feb 01 10:04:30 2024 INFO: Fill completed in 4min 27secs

Images attached to this report
H1 General
anthony.sanchez@LIGO.ORG - posted 08:13, Thursday 01 February 2024 (75661)
Thursday Ops Day Shift Start

TITLE: 02/01 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: USEISM
    Wind: 7mph Gusts, 4mph 5min avg
    Primary useism: 0.05 μm/s
    Secondary useism: 1.07 μm/s
QUICK SUMMARY:
CDS OVERVIEW looks green.
HAM6 HEPI and ISI are currently tripped.

Expected Work:
Robert is expected to head back into HAM3 to Damp Baffles, take pics, and fix any problems.
VAC team is expecting to leak check the ENDX and start working on Feed Throughs on BSC8.



 

 

H1 TCS
thomas.shaffer@LIGO.ORG - posted 19:09, Wednesday 31 January 2024 - last comment - 16:09, Friday 02 February 2024(75657)
TCS chiller line leak testing and expansion joint swap

Summary: WP11663 & WP11664 Today Camilla, Jason, Chris S, and I confirmed the leak location in the TCSX supply line on the rubber portion of the expansion joint. We then replaced all 4 expansion joints and then pressurized the lines with air to test for leaks overnight.

Longer version: Last week while swapping the TCSX laser we sprang a leak in the TCSX supply line (alog75550). After regrouping and planning how to proceed, we planned to first confirm that the leak was actually coming from the expansion joint, replace all of these joints if necessary since the rubber has a lifespan of ~5-10 years and it was installed in 2013/2014, then retest before adding water to the system to ensure no leaks. Today, we did a gravity drain of all of the lines and disconnected the lines from both tables, then bagged the expansion joint where the suspected leak was, and then with Chris S's help, added a bit of air to the system. We started with a low 20psi injected with a blow gun attachment pushed onto the quick connect at the chiller end of the line. We couldn't see, hear, or feel any air so we started upping the pressure in steps. We added some soapy water to the joint in hopes of making bubbles. Eventually at ~80psi I was able to see a brief bubble form before the soap was then sucked into the crack that we suspected the leak came from, presumably from a Bernoulli effect with the air flowing through the pipe. We did it again and got the same results. Leak confirmed Attachment 1

We then replaced the 4 expansion joints with new ones (Spear mfg EJ21-010SR). One of the four was slightly shorter, maybe 8mm, but we were able to find slack in the system to make up for it. Previously the joints were at a slight angle, so we added some pool noodle in the wall feedthrough tube to raise the pipe on the mechanical room side of the joint slightly (Attachment 2). This seemed to help straighten the lines and hopefully put less strain on the lines or joint (Attachment 3 Attachment 4). There is still some sagging over the pipe bridge, but we will find a solution for that another day (Attachment 5).

With the four joints replaced we needed to test them. After conferring with Richard, we rewrapped the joints with a thick plastic and secured with Kapton tape (Attachment 6), then fired the compressor up again at 50psi output and added a bit of air to one line with the dry connect still connected. Once we confirmed that it would hold the bit of air we put in, we put in the full 50psi. We did this for all 4 sections - X & Y supply and return. We let it sit for 30 minutes and then confirmed that the lines were still pressurized. While the lines all felt equally pressurized when we release the pressure, we noticed a single drop of water in the plastic that was wrapped around the joints. We were not sure if this was coming out of the line, or just a spot we missed while replacing them. Seeing through the for water residue is challenging. So, we repressurized the lines and will leave them overnight like this. On our way out Jason and I saw a drop of water in the bag but in a different place. And again, we aren't sure if this is new water or just from a hidden spot we didn't dry. The pressure test overnight might give us some more clues.

Images attached to this report
Comments related to this report
corey.gray@LIGO.ORG - 09:12, Thursday 01 February 2024 (75662)EPO

Tagging EPO for TCS photos.

thomas.shaffer@LIGO.ORG - 16:09, Friday 02 February 2024 (75714)

[Late log, forgot to hit post yesterday]

On Thursday morning the lines were found to all still have air pressure. Since we didn't have a pressure gauge hooked up, I would just push on the dry quick connect release to let air escape. TCSX return line had the least amount of air come out based on this very inaccurate measure, but I might not have put as much in this line to begin with. Again, all lines still had air pressure in them, so our next steps would be to test with water when cleared.

H1 AOS
robert.schofield@LIGO.ORG - posted 17:30, Wednesday 31 January 2024 - last comment - 09:13, Thursday 01 February 2024(75654)
MC baffle by HAM3 upgraded and nozzle baffles installed on all blank ports in MC tube

Mitchell, Corey, Tony, Robert, and the SLiC team

Today we modified the MC baffle by HAM3 so that it was angled at ten degrees. We had problems with two of the bolts connecting brackets and the baffle. Alcohol and gentle working got them in and out, but I think they will be problematic in the future too.  We completed the baffle modification and then we installed nozzle baffles in all blanked-off viewports in the input MC tube.  Damping and beam spot photos tomorrow.  The figure shows a couple of photos of the work, Corey's photos and videos are here.

Non-image files attached to this report
Comments related to this report
corey.gray@LIGO.ORG - 09:13, Thursday 01 February 2024 (75663)EPO

Tagging EPO for Stay Light Baffle photos.

H1 AOS (AOS, ISC)
keita.kawabe@LIGO.ORG - posted 17:05, Wednesday 31 January 2024 - last comment - 14:05, Thursday 01 February 2024(75651)
Quiet HAM6 day (Rahul, Betsy, Keita)

We put the OMCS baffles back on except the -Y side vertical panel, which had a non-standard screw/washer/O-ring configuration. It turns out that that was done intentionally back in Aug/2016 because otherwise the OMC trans beam won't come out of the shroud hole (alog 28944).

The shroud panels had finger marks from gloves as well as spots that look like dust particulates (1st attachment). We wiped using IPA and wipes, which reduced the finger marks (2nd attachment). Though they look much better in the picture, in reality we might have been just spreading it over the larger surface. Some spots didn't move at all. Anyway, we cleaned the panels using ionized nitrogen gun (for particulates) immediately followed by alcohol-wipe.

There was one particularly bad spot, see Betsy's picture.

3rd and 4th pictures show Rahul and Betsy working on a small horizontal top panel. 5th picture shows the OMC surrounded by the shroud panels.

After attaching the shroud panels (except for the -Y side vertical one), we found that one of the white DCPD cables interfered with the top glass panel, so Betsy pulled the cable up higher in the cable retainer attached to the suspension cage. PZT cable was really close to the other DCPD cable, but the PZT cable doesn't have a retainer, so I bent that cable to form a large arc to avoid interference. On -X side, Rahul found that one of the QPD cables is very close to a BOSEM cable, so he worked on that.

These resulted in some change in the OMCS alignment, and top osem numbers shifted according to Rahul. My hope is that this is benign enough we can take care of that using mostly OM2 and OMC.

Rahul measured the TF for OMCS and they're OK.

Tomorrow we'll attach the remaining panel, recenter BOSEMs for OMC and OM2,  and I'll start the electronics check.

Images attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 20:17, Wednesday 31 January 2024 (75659)

A couple PR photos, and the one of the panel with the particularly offensive mark - note the residue around it as if there was a previous attempt to remove it. It did not move for me either, my guess is it's actually a little divot. Will install it as is.

Images attached to this comment
corey.gray@LIGO.ORG - 09:14, Thursday 01 February 2024 (75664)EPO

Tagging EPO for Output Mode Cleaner photos.

rahul.kumar@LIGO.ORG - 14:05, Thursday 01 February 2024 (75678)SUS

This morning I re-adjusted the BOSEMs on OM2 (all four of them) and OMCS (T1 and T3).

Also, I attached the one remaining side baffles.

I will take TF measurements and check the health of both the suspensions.

H1 AOS
david.barker@LIGO.ORG - posted 16:30, Wednesday 31 January 2024 - last comment - 09:50, Thursday 01 February 2024(75649)
LVEA Dust Monitor temperature channels are bad, dust particle measurements are good.

Following the DAQ+EDC restart yesterday, Tue 30 Jan 2024, the LVEA Dust monitor temperature channels have flatlined at 25F. This has been see before late last year in exactly the same curcumstances, see alog:

28nov2023_alog

The actual dust particle measurements continue to be good, only the temperatures are broken.

In the 2023 case, just under 3 days later at 03:39 Fri 01 Dec 2024 the temperature channels sponteneously fixed themselves and came back to life.

If the temps are still stuck tomorrow morning we will try a restart of the DUST LVEA IOC.

Comments related to this report
david.barker@LIGO.ORG - 09:50, Thursday 01 February 2024 (75668)

I restarted the h1dustlvea IOC on h0epics this morning at 08:40, this has not fixed the issue.

This time the EDC connected to the values seen on the MEDM, previously they were all at 25F. 

All the dust monitors show reasonable temps except PSL101 which came up with 25F and is staying there.

The core problem persists: CA clients which establish callbacks (MEDM, EDC) are stuck with the value they got at connection. Running caget every second most of the time returns a steady value, with an occassional 25F or VAL+n returned.

We have situations wherein the EDC has one value, the MEDM has another and caget has a third.

In this example I am running "caget H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF" every second:

H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 25 *
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 70 *
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
H1:PEM-CS_TEMP_LVEA5_DUSTMON_DEGF 68
 

H1 AOS
robert.schofield@LIGO.ORG - posted 16:53, Tuesday 30 January 2024 - last comment - 09:16, Thursday 01 February 2024(75637)
MC Baffle by HAM2 successfully angled to ten degrees

Robert, Mitchell, Corey, Tony, TJ, Alena, Eddie, Betsy, the SLiC team.

The baffle by HAM2  can, at 5 degrees, specularly reflect some scattered light back to beam spots and has been shown to produce scattering noise (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=74772). Today we changed the angle of the baffle to 10 degrees using new hardware designed at CIT. The new hardware and the procedure worked well. The figure shows photos of the work.

Non-image files attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 20:21, Wednesday 31 January 2024 (75660)

Here's TJ in HAM3 locking the ISI via only 1 open door and squeezing through around either side of the table.

Also a door crew snapshot.

Images attached to this comment
corey.gray@LIGO.ORG - 09:16, Thursday 01 February 2024 (75665)EPO

Tagging EPO for Stray Light Baffle & Door Removal photos.

H1 PEM (ISC, PEM, TCS)
marc.pirello@LIGO.ORG - posted 16:45, Friday 26 January 2024 - last comment - 11:39, Thursday 01 February 2024(75592)
CER Accelerometer Chassis Installed

Replaced the Endevco Accelerometer Power Conditioners with LIGO Accelerometer Power Conditioners. WP11653

Order in the rack:

U19 - Accelerometer Power Conditioner S2300062

U16-U17 AA Chassis S1300101

U14 - Accelerometer Power Conditioner S2300063

U13 - Accelerometer Power Conditioner S2300065

U12 - Accelerometer Power Conditioner S2300069

U11 - Accelerometer Power Conditioner S2300064

Still have EX, EY, MX, MY, FCES to complete.

M. Pirello, J. Jimerson. R. Schofield

Comments related to this report
marc.pirello@LIGO.ORG - 16:28, Tuesday 30 January 2024 (75636)

Mid Y, we were not able to connect power, we installed the chassis and will revist.

Installed Accelerometer Chassis at EX, cables connected and chassis powered up.  One of the Acelerometer cable connectors is loose and will be repaired later this week but it is functional.

Signal Order Asbuilt:

Slot = Cable Number = Accelerometer Number

1 = 4 = PEM EY BSC10

2 = 7 = PEM EY EBAY

3 = empty = empty

4 = 1 = PEM EY OPLEV

5 = empty = empty

6 = empty = PEM EY BSC6

7 = 6 =Black Cable

8 = 2 = PEM EY BSC10

9 = 3 = PEM EY TRN

10 = 5 = PEM EY BSC ACC X

We have no slot 10 on the new chassis therefore we moved cable 5 to slot 5, and moved the PEM EY BSC ACC X cable to match on the back.

Once we matched the cables we rearranged the signals to match the numbering on the front, i.e. cable 1 goes to slot 1, cable 2 goes to slot 2, etc...

Slot = Cable Number = Accelerometer Number

1 = 1 =  PEM EY OPLEV

2 = 2 = PEM EY BSC10

3 = 3 =  PEM EY TRN

4 = 4 = PEM EY BSC10 (this cable had a loose connector, but registered as an accelerometer)

5 = 5 = PEM EY BSC ACC X (this cable did not register as an accelerometer)

6 = 6 = Black Cable (this cable is unlabeled)

7 = 7 = PEM EY EBAY

8 = empty (This needs AA and signal)

9 = empty (This needs AA and signal)

J. Jimerson, M. Pirello

marc.pirello@LIGO.ORG - 17:01, Wednesday 31 January 2024 (75652)

Further investigation into EY Accelerometers

Slot = Cable Number = Accelerometer Number

1 = 1 =  PEM EY OPLEV

2 = 2 = PEM EY BSC10_Y (Should be BSC10_ACC_X)

3 = 3 =  PEM EY TRN (should be BSC10_ACC_Y)

4 = 4 = PEM EY BSC10_Z 

5 = 5 = PEM EY BSC ACC X (should be TRN_TBL_ACC_Y)

6 = 6 = Black Cable (this cable is unlabeled) * same issue as EX

7 = 7 = PEM EY EBAY

8 = empty (This needs AA and signal)

9 = empty (This needs AA and signal)

Same as EX, CH2 moves to CH3, CH3 moves to CH5, CH5 moves to CH2.

marc.pirello@LIGO.ORG - 11:39, Thursday 01 February 2024 (75674)PEM

Removed S2300069 from CS PEM rack, this is not supposed to be installed here.

H1 SYS
betsy.weaver@LIGO.ORG - posted 20:11, Thursday 25 January 2024 - last comment - 09:21, Thursday 01 February 2024(75564)
Vent work progress update

So far, the O4 break vent & commissioning work is proceeding as planned, with only minor hiccups.  Yesterday's TCS water leak caused a pause to the HAM6 in-chamber OMC alignment work, but we were able to resume this morning pretty quickly with only a short amount of time down.

The attached snapshot shows the planned schedule outline with green checkmarks next to the items completed so far on the left hand side.  On the right is a running log of the activities which have taken place daily (for ease of viewing all in one place).

Teams currently on:

 

Non-image files attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 14:26, Friday 26 January 2024 (75582)
Images attached to this comment
corey.gray@LIGO.ORG - 09:21, Thursday 01 February 2024 (75666)EPO

Tagging EPO for FARO Alignment, baffle, Output Mode Cleaner photos.

H1 TCS
camilla.compton@LIGO.ORG - posted 11:23, Thursday 25 January 2024 - last comment - 09:23, Thursday 01 February 2024(75550)
CO2X Laser Swap

TJ, Jason, Camilla, Fil.

WP11612, FRS25384, swapping because current CO2X laser was slowly deteriorating, details in 75249.

Removed: Access 50LT 20706.21015D. Installed 20306-20419D, which was refurbished/re-gassed in March 2020. Table layout: T1200007.

Still to do after the CO2X cooling line issue is solved:

Images attached to this report
Non-image files attached to this report
Comments related to this report
camilla.compton@LIGO.ORG - 09:09, Friday 26 January 2024 (75567)

FRS 30283 Created for this issue. 

corey.gray@LIGO.ORG - 09:23, Thursday 01 February 2024 (75667)EPO

Tagging EPO for Thermal Compensation System (TCS) photos.

H1 CAL
anthony.sanchez@LIGO.ORG - posted 15:23, Wednesday 06 December 2023 - last comment - 13:33, Thursday 01 February 2024(74643)
PCAL EX End Station Measurements & Lab Measurements

X End Station Measurement:
During the Tuesday maintenace, the PCAL team(Rick Savage, Dana Jones, & Tony Sanchez) went to EndX with Working Standard Hanford aka WSH(PS4) and took an End station measurements.

The EndX Station Measurements were carried out according to the procedure outlined in Document LIGO-T1500062-v15, Pcal End Station Power Sensor Responsivity Ratio Measurements: Procedures and Log, and was completed by 11:45 am.
Note:
After the normal measurement, we did a few auxilary measurments.

LIGO-T1500062-v15 Measurement Log

First thing we did is take a picture of the beam spot before anything is touched! I then put the target apature cap on the RX sphere to see how far off from center the beam is.

Martel:
Martel Voltage sources voltage into the PCAL Chassis's Input 1 channel. We record the GPStimes that a -4.000V, -2.000V and a 0.000V voltage was applied to the Channel. This can be seen in Martel_Voltage_Test.png. We also did a measurement of the Martel's voltages in the PCAL lab to calculate the ADC conversion factor, which is included on the above document.

Plots while the Working Standard(PS4) is in the Transmitter Module during Inner beam being blocked, then the outer beam being block, followed by the background measurment: WS_at_TX.png.

The Inner, outer, and background measurement while WS in the Receiver Module: WS_at_RX.png.

The Inner, outer, and background measurement while RX Sphere is in the RX enclosure, which is our nominal set up without the WS in the beam path at all.:  TX_RX.png.

The last picture is of the Beam spot after we had finished the measurement. Note this beam spot is only ONE beam but the beam postitons were not adjusted during the measurement.

All of this data is then used to generate LHO_EndX_PD_ReportV2.pdf which is attached, and a work in progress in the form of a living document. This document was created with the PCALPARAMS['WHG'] = 0.916985 # PS4_PS5 as of 2023/04/18
And Not the latest number [PCALPARAMS['WHG'] = 0.91536 # 12/05/2023].
But I did run the report with the latest number just for my own curiosity and marked it down as a "Monday End Station measurement" performed on 2023-12-04 so it sits right behind the real measurement on the 5th and it doesn't vary by much: LHO_ENDX_PD_TEST_REPORT.pdf


All of this data and Analysis has been commited to the SVN :
https://svn.ligo.caltech.edu/svn/aligocalibration/trunk/Projects/PhotonCalibrator/measurements/LHO_EndX/


This is where the measurement normally ends, but instead we took a few more iteresting measurements.

Auxilary Measurements:
Rx Sphere is in it's nominal location and the WS was not in the beam path at all.  
Opened the Shutter GPStime 1385839530
RxPD = 0.2234 before moving the beam block.
Moved the beam block allowing both beams to hit RX sphere.
start time 1385839590
End time 1385839890

Shutter both beams for a background measurement.
Start time 1385839945
RxPD = 4.30966e-5
End time 1385840005

The OFSPD_OFFSET was set to 6.0. This should be the maximum power we reach while normally operating.
start time 1385840225
RXPD = 0.805388
TXPD = 0.813297
End time 1385840525


PCAL Lab Responsivity Ratio Measurement:
A WSH/GSHL (PS4/PS5)FrontBack Responsivity Ratio Measurement was ran, analyzed, and pushed to the SVN.
The analysis of this measurement produces 4 PDF files which we use to vet the data for problems.
raw_voltages.pdf
avg_voltages.pdf
raw_ratios.pdf
avg_ratios.pdf


Obligitory BackFront PS4/PS5 Responsivity Ratio:
A WSH/GSHL (PS4/PS5)BF Responsivity Ratio measurement was ran, analyzed, and pushed to the SVN.
The analysis of this measurement produces 4 PDF files which we use to vet the data for problems.
raw_voltages2.pdf
avg_voltages2.pdf
raw_ratios2.pdf
avg_ratios2.pdf

This adventure has been brought to you by Rick Savage, Dana Jones & Tony Sanchez.

 

 

Images attached to this report
Non-image files attached to this report
Comments related to this report
anthony.sanchez@LIGO.ORG - 13:33, Thursday 01 February 2024 (75676)

Two new measurements were added to the svn, one on the 3rth of Dec, and another on the 4th.
The one on the 4th , xtD20231204  actually happened on Dec 5th and uses much of the data from Dec 5th except starttime 7 and 8 on the config.py file were changed to reflect the time that we had both beams on the RX sensor instead of only the Inner or outer.
This resulted increasing in magnitude of the Rx Calibrarion. More information can be found on the SVN. 

The one on the 3rd , xtD20231203  actually happened on Dec 5th as well and uses much of the data from Dec 5th except starttime 7 and 8 on the config.py file were changed to reflect the time that we had both beams on the RX sensor AND ther OFS OFFSET was set to 6.0.
This resulted increasing in magnitude of the Rx Calibrarion. More information can be found on the SVN. 

Displaying reports 11241-11260 of 84715.Go to page Start 559 560 561 562 563 564 565 566 567 End