The other thing which would be lovely to have access to is the pointing angle of the top-level parent with respect to the PV. That's going to be a key background rejecting variable for a very wide range of use-cases.
I'm not sure about the tracking efficiency, particularly for electrons, below that value. I'd try to see this thing working above it and then loosen if things are going well.
I not only don't object, I would be very grateful if you would!
I'd prefer having the same TCK as actually ran in the pit if possible, since the TCK is a useful shorthand for "running period" for studies. That's less relevant for this line than for other lines but I don't see the real advantage of the opposite choice either.
I agree, the TCK is what ran in the pit, not sure why it should be different here.
I think the second option might be better, yes, in particular if the rate is low. Since these events will be mainly used for debugging, meaning you aren't really going to be filling histograms from them but rather profiling, running sanitizers, etc. So you will by construction need to rerun on these events many times, which is not the typical workflow even for calibration jobs offline. Then I think it can be fairly annoying to have to skip past a bunch of calibration triggers every time you do this. If we don't isolate them I guess anyone actually using them will make a job to write a subset to a separate file for convenience anyway, so why not do this for them centrally.
What other kinds of events will populate Hlt2Calib? It isn't obvious to me that we want to put events which could (by construction) cause processing problems together with other kinds of calibration events. I understand small streams are not good for transfer to offline but isn't this a bit of a special case?
Since I'm having a boring Sunday shift let me add my 2 cents -- these types of pathological events can be quite interesting for understanding reconstruction corner cases. In the past we had events which blew up the reconstruction time or memory budget for various reasons, one which I remember were collimated jets produced from material interactions resulting in huge numbers of ghosts. Anyway it would be nice if they could be permanently archived in a dedicated offline disk area so they can be easily accessed for later studies. This assumes their rate will be very small, but if that turns out not to be the case we probably have bigger issues anyway.