SUMMARY:
This evening we wanted to coordinate going out of Observing for L1 & H1 to run (2) calibration measurements (~30min). Unfortunately, I was not able to run the broadband measurement, but ran the simuLines measurement. It also took me extra time to return to Observing because it was not clear how to run this measurement with the new H1 Manager and H1 did not restore smoothly and had excitations which kept us out for a bit.
Attempt To Run Broadband PCAL measurement:
Vladimir and Jenne coordinated running 30min of calibration measurements at 5pm PT. I spent my first hour getting everything set up so I could quickly run the measurements.
- Followed instructions the Taking Calibration Measurements wiki, here.
- Started measurements with Lock Clock under the 3hr-thermalization time for H1 (~2hrs35min locked & Jenne said was OK).
- CALIBRATION_MONITOR screenshot attached
- This was my first time running these measurements with the new H1_MANAGER guardian node. A new procedural step is:
- Take ISC_LOCK to AUTO (from MANAGED)
- I then opened a Terminal & tried running: pydarm measure --run-headless bb, and this gave the following error:
corey.gray@cdsws13:~$ pydarm measure --run-headless bb
INFO | config file: /ligo/groups/cal/H1/ifo/pydarm_cmd_H1.yaml
INFO | available measurements:
pcal: PCal response, swept-sine (/ligo/groups/cal/H1/ifo/templates/PCALY2DARM_SS__template_)
ERROR: measurement 'pcal' template file not found: /ligo/groups/cal/H1/ifo/templates/PCALY2DARM_SS__template_
corey.gray@cdsws13:~$
After consulting with Jenne & Vladimir, we canceled attempting this measurement and moved on to the simuLines measurement.
simuLines script
- start - 1374970108.655441
- end - 1374971434.204420
Attached is a screenshot of the terminal and the testpoints which were on the board while it was running.
Delays In Restoring H1 & Returning to Observing:
Once simuLines was complete, I thought I could have H1_MANAGER restore H1 back to NLN, but after an attempt (or 2), that didn't work. So I had ISC_LOCK go to AUTO and then selected NLN and then took it to MANAGED. I then ran an INIT on H1_MANAGER, and I believe this restored H1. Still not sure if the latter is the preferred way.
Next, I followed the wiki instructions to work on CAL_AWG_LINES. It was in IDLE. But the wiki instructions said "Make sure CAL_AWG_LINES guardian is in state 10, LINES_ON, and you see its PCALY lines ON between 5 and 25 Hz." I believe I saw the PCALY lines, but we were in IDLE, so I toggled the Lines On/off via guardian per the instructions. But I could not go to Observing due to SDF Diff and CAL_AWG_LINES in bad state. Soooo...
- SDF first: CALEY. PCALY_DARM_GAIN had a gain of 1.0, so I REVERTED that (see attached).
- Then juggled around with the CAL_AWG_LINES guardian. The instructions said it wanted to be in the LINES_ON state, but the Guardian (& Log) showed IDLE was the state it needed to be in, so I eventually took it to IDLE.
But I still had excitations! (see attached) So, then I spent the next few minutes figuring out how to kill these excitations. Then finally returned to OBSERVING.
Since I'm not totally sure on the best way H1 should be restored in this sort of situation, I will not update that part of the wiki with regards to my experience tonight, due to:
- New H1_MANAGER
- pydarm measure --run-headless bb not being able to run
- QUES: In hindsight, is this the measurement I wanted to run? It's listed under the "Taking All TFs" section of the procedure (and it is listed as taking over 90min).
- The funky state H1 was in upon trying to RESTORE.
Apologies -- with the amount of software work needed to convert CAL_AWG_LINES to front-end oscillators -- I forgot the most important part: human coordination! CAL_AWG_LINES is now deprecated with the addition of new front-end oscillators as of yesterday, Aug 01 2023 (2023-08-01) -- check out LHO:71881. That means one no longer has to do any funny business finagling CAL_AWG_LINES to drive the collection of low-frequency, 8. 11. 15. and 24 Hz, lines. I've now updated the wiki page that Corey cites -- see that TakingCalibrationMeasurements no longer has any mention of CAL_AWG_LINES. Indeed, you (Corey), did the right thing by reverting the PCALY_DARM_GAIN; that was the path thru which CAL_AWG_LINES drove the above mentioned 4 lines. I'll make sure there're no more guardians that are toggling this gain today.