<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Matt,<div class=""><br class=""></div><div class="">This is good sleuthing, and very much needed, so thank you for doing this work.</div><div class=""><br class=""></div><div class="">Would it be possible to change the reconstruction so the ChiSq cut is only done on the unconstrained vertex? In other words, if the unconstrained vertex is OK, then the unconstrained, beamspot constrained, and target constrained vertexes are all written out to LCIO. If it fails the cut, then none of them are written out.</div><div class=""><br class=""></div><div class="">I am not sure, but I got the impression that we do not have an immediate, easy to use, method of linking the 3 different contained collections. If we guarantee that we <i class="">always </i>write all 3, and <i class="">in the same order</i>,  then you can simply make the assumption that the index in the collection will be the same, so you can easily link the three. (And yes, you would need to verify that this is really the case, but it would be easier than re-linking the collections.)</div><div class=""><div><br class=""></div><div>Not too familiar with that piece of the code, but my guess is that it would not be too difficult to implement. </div><div><br class=""></div><div>Not having a cut at all is also a possibility, but then you need to make these cuts later, and we would be writing some junky vertexes out. I think the reason for the cuts was to weed out some clearly bad ones.</div><div><br class=""></div><div>Best,</div><div><span class="Apple-tab-span" style="white-space:pre">  </span>Maurik</div><div><br class=""></div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 31, 2019, at 3:42 AM, Nelson, Timothy Knight <<a href="mailto:tknelson@slac.stanford.edu" class="">tknelson@slac.stanford.edu</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Puzzling.  We’ll look at this tomorrow.<br class=""><br class="">T<br class=""><br class=""><blockquote type="cite" class="">On Jan 31, 2019, at 12:15 AM, Solt, Matthew Reagan <<a href="mailto:mrsolt@slac.stanford.edu" class="">mrsolt@slac.stanford.edu</a>> wrote:<br class=""><br class="">Hi all,<br class=""><br class="">Long email, executive summary: we should remove the vertex chisq probability cut in the reconstruction. Details below.<br class=""><br class="">There is a cut in the reconstruction on the vertex chisq probability, which I think is part of the MOUSE cuts, that is causing issues for displaced A's. Where has this cut been verified (specifically for displaced A's)? Plots are attached that show the following story.<br class=""><br class="">There is currently a cut at 1.7e-16 for the current reconstruction which seems fine, except the distributions for the beamspot constrained and unconstrained probabilities look crazy, with bsc having a significant number events at a probability of 0 and the unconstrained distributions have events closer to 1 (I didn't check target constrained). For the same vertex, the reconstruction can write an unconstrained vertex that passes the cut, but not a bsc that doesn't pass the cut (which is definitely not what we want). This particularly effects high z events, including clean signal events, as bsc probability is highly anti-correlated with z. This is actually how I just noticed it today, while looking at displaced A's which have very few reconstructed high z events. This effect is not noticeable in either data or MC because the it really only effects high z events (both good signal and background).<br class=""><br class="">What's worse is that apparently the tuple maker requires a vertex to have both a bsc and unconstrained collection, so if it doesn't have a bsc vertex it throws them both away even if the unconstrained passes the cut (not true in the lcio). I first noticed it in the displaced A' tuples (which have the default cut of 0.00001, so even worse than the data reconstruction).<br class=""><br class="">What affect does this have on current pass4? It doesn't effect the core distributions much at all, which is why I didn't catch it yet. It only really affects high z signal and background (which is obviously important). The unconstrained collection is probably ok in the lcio files, it's more just the beamspot constrained collection and the ntuples.<br class=""><br class="">So, why do the vertex chisq probability distributions look weird? I don't know, I haven't had time to dig that far. But since I don't think we understand this effect, and we are trying to compute our data ASAP, we should remove the cut in the reconstruction for now. If there are consequences to removing this cut, someone should speak up (Tim, Miriam, Matt, Norman?).<br class=""><br class="">I hope I was clear, but I'm sure some of you will have questions. Also, if someone gets a chance, can someone verify these probability plots? Thanks.<br class=""><br class="">Matt Solt<br class=""><problem.pdf><br class=""></blockquote><br class=""><br class="">_______________________________________________<br class="">Hps-analysis mailing list<br class=""><a href="mailto:Hps-analysis@jlab.org" class="">Hps-analysis@jlab.org</a><br class="">https://mailman.jlab.org/mailman/listinfo/hps-analysis<br class=""></div></div></blockquote></div><br class=""></div></body></html>