I set up an accelerometer on the beam tube and measured the accelerations as I simulated the tapping that I observed during cleaning, and my tapping experiment mentioned here: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=19038. Examination of the time series indicated that accelerations during typical taps reached about 1 m/s^2. I suspect that some taps reached 1g. The figure shows spectra for metal vs. fist taps. The above link notes that I was unable to produce glitches while hitting the beam tube with my fist. The fist and metal taps both had about the same maximum acceleration of 1 m/s^2 (ambient acceleration levels are about 4 orders of magnitude lower), so the source of the difference in liberating the particles is probably not acceleration. Instead, it may be the change in curvature of the beam tube, which would be expected to be greater at higher frequencies. The responses from metal taps in figure 1 peak at about 1000 Hz while the fist taps peak at about 100 Hz. These results are consistent with a hypothesis that the metal oxide particles are liberated by fracture associated with changes in curvature rather than simple vertical acceleration.
When I was producing glitches in DARM for the link above, I noticed that we did not get glitches every metal tap but every several metal taps. I tried to quantify this by making many individual taps at several locations along the beam tube. Unfortunately, we lost lock with the first loud glitch and I did not get a chance to repeat this before the vent. Nevertheless, it would be good for DetChar to look for smaller glitches at the time of the taps given below. Allow a 1 second window centered around the times given below for my tap timing uncertainty. I tapped once every ten seconds, starting at ten seconds after the top of the minute so that there were six taps per minute.
UTC times, all on June 14
Location Y-1-8
20:37 - 20:38 every ten seconds
20:47 - 20:50 every ten seconds
Next to EY
20:55 - every ten seconds until loss of lock at 20:56:10
I don't think the IFO stayed locked for the whole time. The summary page says it lost lock at 20:48:41, and a time series of DCPD_SUM (first plot) seems to confirm that. I did a few spectrograms, and Omega scanned each 10 seconds in the second series, and the only glitch I find is a very big one at 20:48:00.5. Here is an Omega scan. The fourth tap after this one caused the lock loss. Detchar will look closer at this time to see if there are any quiet glitches. First we'll need to regenerate the Omicron triggers... they're missing around this time probably due to having too many triggers caused by the lockloss. I'm not sure why there's a discrepancy in the locked times with Robert's report.
Any chance this could be scattered light? at 1 m/s^2 and 1 kHz, it is a displacement of 25 nm, so you don't need fringe wrapping.
I think that you would expect any mechanism that does not require release of a particle to occur pretty much with every tap. These glitches dont happen with every tap.