HAM6 HEPI is locked. SEI state is ISI DAMPED HEPI OFFLINE.
Didn't get the computer running so locked blind. Current position relative to nominally isolated position is:

h1nds3 is acquiring all the epics channels that the regular daq acquires and is recording them as of 1253978688. As a backup to the regular daqd system h1nds3:8088 can be used to read the epics data stored to frames (VE, FMCS, ...). This is only the slow data, no fast data is being recorded here. I will be finishing up some spot checks on the data to make sure they match the production stream. If there are not problems seen we will leave the machine alone until the end of the vent.
I picked a channel from the VE overview and streamed the data from h1nds1 and h1nds3. The data is the same, h1nds3 is able to stream it back a little faster. This is the difference between directly writing the data on h1nds3 and traversal from h1dc0 to h1nds1 + some processing time involved in that transfer. See attached screen shot. The top is the feed from h1nds1, the bottom is from h1nds3.
Some timing information for future reference. The minute trend frames are taking around 4s to write, the raw frames are taking 2s to write. The raw frames are 20MB. The second trends are 103MB. I need a longer sample period to find the size for the minute trends (need to get a frame file that is full, not zero filled for the start). I've attached a screen shot of a strip tool showing some stats on h1nds3.
Issues I ran into with setting this up. The main issue I ran into was with the ini file parser in the standalone_edc. It did not like trailing spaces, so when it checked to make sure channels were only being allowed at 16Hz and as floats, trailing spaces gave it issues. The parser should be replaced with the one daqd uses to parse the master file. Another issue that I ran into in testing is that when DCU ids where not set the same between the ini file and the standalone edc, data wasn't recorded in the daqd. This should be fixed by pulling the dcuid from the ini file.
Richard has closed the laser shutter and turned the interlock keys for TCSX, TCSY, and SQZ lasers.
Ops Shift Transition: 10/01/2019, Day Shift 15:00 – 23:00 (08:00-16:00) - UTC (PT)
State of H1: Planned Engineering
Intent Bit: Commissioning
Weather: 0-5 mph wind
Primary 0.03 – 0.1Hz: 0.01 um/s
Secondary 0.1 – 0.3Hz: 0.1 um/s
Outgoing Operator: Corey
Quick Summary: Starting October commissioning month, IFO down, lasers being shuttered, SC off
TITLE: 10/01 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 117Mpc
INCOMING OPERATOR: Niko
SHIFT SUMMARY:
BRSx continues to NOT be used.
O3A is officially COMPLETE! (& we had plenty of people checking to see if H1 would break lock early, but it held up until 8am!)
LOG:
Reconciled ISC SDFs after intentional lock loss in prep for O3 break. J. Kissel AS_A Accepted new whitening settings that Evan installed LHO aLOG 52171. (see first attachment) The following channels appear to be set upon entrance in to nominal low now, or somewhere along the way, but the behavior during acquisition appears to have changed on Sept 26/27 2019. Probably related to LHO aLOG 52150, so I'm accepting them as is: H1:IMC-MCL_FM_TRIG_THRESH_[ON/OFF] H1:LSC-MCL_FM_TRIG_THRESH_[ON/OFF] H1:LSC-DARM_FM_TRIG_THRESH_[ON/OF] H1:LSC-TRIG_TRX_10_17 Accepted as 0.0. Has been so since September 26 2019. Appears guardian controlled. This is the POP A_DC OUT to IFO_TRIG matrix element in the trigger matrix. (see second attachment) Of course, in the rush to get everything started, folks started chning things that are not related to the standard DOWN state, so I capture whats left in the state we're in now, 30 minutes after the start of the break: SQZ system is OFF. (That's the 10 CS_ECAT_PLC4 diffs) TCS lasers are keyed OFF (That's the 2 TCSCS diffs) The IMC is OFFLINE (That's the two SUSMC2 diffs) The ISI BS is in its usual ISOLATED DAMPED state (that's the 23 ISIBS diffs) The SUSPRM and SUSSRM have the usual confusing problems with the coil driver switching state (this is a known bug) HEPI HAM6 has been brought down such that it can be physically locked and put on its stops.
PEM Injections Seg Fault J. Kissel While the second attempt was successful, the first attempt at running the regular PEM injections failed due to seg fault. I attach the text of the errors dumped to the command line.
H1 locked/observed over 19.5hrs. All is quiet environmentally with outside temps in the upper 30s.
After I finished lunch H1 had a huge glitch which hovered above the ADS lines for a good 10+ seconds....
And then I watched it break lock. :-/ I guess I should have been quicker with getting to the ADS lines to ramp down gains, but I'm not that quick (or ready).
Working on trying to get H1 back up to get atleast another 1-2hrs before Oct break begins!
TITLE: 10/01 Owl Shift: 07:00-15:00 UTC (00:00-08:00 PST), all times posted in UTC
STATE of H1: Observing at 117Mpc
OUTGOING OPERATOR: Patrick
CURRENT ENVIRONMENT:
SEI_CONF state: WINDY_NO_BRSX
Wind: 8mph Gusts, 7mph 5min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.11 μm/s
Low Microseism & winds for this last graveyard of O3A. Woo Woo!
QUICK SUMMARY:
H1 has been locked/observing for about 15.75hrs (kudos to Patrick for riding through that EQ without getting to use EARTHQUAKE state!). And continue to operate H1 WITHOUT BRSx (i.e. in the SEI_CONF state of WINDY_NO_BRSX).
Continue to have MX FMCS low temperature alarms and INVALID/connection issues.
This is the last graveyard yard shift for O3A as we begin a month-long commissioning break in October after this shift....or it could start earlier if H1 drops out of lock near end of shift (let's see what can happen these next 8hrs!).
DetChar Note: Not sure this has been noted/broadcasted, but the H1 Summary Pages have been down since my shift last night. So, this is why we can't see the H1 Glitch (DMT-Omega) page on our nuc0 wall computer. Tagging DetChar about this in case it hasn't been brought to your attention. L1's Summary Page looks fine.
TITLE: 09/30 Eve Shift: 23:00-07:00 UTC (16:00-00:00 PST), all times posted in UTC STATE of H1: Observing at 116Mpc INCOMING OPERATOR: Corey SHIFT SUMMARY: Currently standing down for GRB. Rode through eq without changing SEI_CONF from WINDY_NO_BRSX. LOG: 23:11 UTC Gerardo to mid X to pick up equipment 04:22 UTC Notification of incoming earthquake from Pitcairn Islands. Can't change SEI_CONF to EARTH_QUAKE due to BRSX. 05:50 UTC mid X temp alarm 06:43 UTC GRB G352073 LLO confirmed but is relocking Fermi: 591604915, TRIGGER_DUR: 0.256 [sec] Stand Down
Have remained locked and in observing. No issues.
In anticipation of having less power through the rotations stage, I've increased the gain on IO GigE cameras 2 and 3 (cameras 29 and 09)
To implement WP 8381 I have been setting up a standalone epics recorder on a currently spare daqd box h1nds3.
Work done today:
* Added 4x2TB disks in a raid5 configuration for 6TB of storage
* Installed the mbuf and gpstime drivers
* This machine is not on the site timing system, so the time is system time/ntp based.
* Built daqd_shmem, local_dc, and standalone_edc from git master.
While the raid is building I am running some tests against simulated data writing to the main (small) disk.
This will be collecting the roughly 40k EPICS channels and recording them locally.
It will be accessed via NDS at h1nds3:8088 (do not use this yet, you will only get simulated channels).
Install notes:
* all config files for this ad-hoc build are being put in /etc/edcu
* standalone_edc is run as:
* standalone_edc -b edc_daq -d 52 -i /etc/edcu/edcu.ini -p H3:
* write to the edc_daq memory buffer
* dcuid = 52 to match production edc (meaningless in this situation, but it needs some number)
* Setting a prefix of H3: to the 3 edcu specific channels (connection count, currently connected channels, currently disconnected channels)
* local_dc is run as:
* local_dc -s edc -b ifo -m 64 -d /etc/edcu
* read from the edc_daq buffer and place in the the ifo output buffer which is 64MB, config is in /etc/edcu
* daqd_shmem is run as:
* daqd_shmem -c /etc/edcu/daqdrc
* configured to read data from the ifo buffer with a size of 64MB
FAMIS 11032
Laser Status:
Front End Power is 32.51W (should be around 30 W)
70W Output Power is 69.63W
Front End Watch is GREEN
70W Watch is GREEN
PMC:
It has been locked 6 days, 2 hr 29 minutes (should be days/weeks)
Reflected power = 11.68Watts
Transmitted power = 52.66Watts
PowerSum = 64.35Watts.
FSS:
It has been locked for 0 days 9 hr and 37 min (should be days/weeks)
TPD[V] = 4.402V (min 0.9V)
ISS:
The diffracted power is around 2.2%
Last saturation event was 0 days 9 hours and 37 minutes ago (should be days/weeks)
FAMIS 12867 None appear overly elevated.
These should be the EPICS database entries for the invalid FMCS channels in the alarm handler (copied from svn):
grecord(ai, "$(IFO):FMC-MX_AH_DSCHRG_DEGF")
{
field(DTYP, "BacNet")
field(INP, "@bacnet13001 0 2 85")
field(SCAN, ".1 second")
field(DESC, "discharge")
field(EGU, "degF")
field(PREC, "2")
field(FLNK, "$(IFO):FMC-MX_AH_DSCHRG_DEGC")
field(LINR, "LINEAR")
}
grecord(ai, "$(IFO):FMC-MX_AH_COOLTEMP_1_DEGF")
{
field(DTYP, "BacNet")
field(INP, "@bacnet13001 0 10 85")
field(SCAN, ".1 second")
field(DESC, "cooling temp 1")
field(EGU, "degF")
field(PREC, "2")
field(FLNK, "$(IFO):FMC-MX_AH_COOLTEMP_1_DEGC")
field(LINR, "LINEAR")
}
grecord(ai, "$(IFO):FMC-MX_AH_COOLTEMP_2_DEGF")
{
field(DTYP, "BacNet")
field(INP, "@bacnet13002 0 10 85")
field(SCAN, ".1 second")
field(DESC, "cooling temp 2")
field(EGU, "degF")
field(PREC, "2")
field(FLNK, "$(IFO):FMC-MX_AH_COOLTEMP_2_DEGC")
field(LINR, "LINEAR")
}
Attached are 500 lines from the IOC log.