Detector framework performance improvements

[decibelcooper]

Three separate improvements are included in this request:

• Replaced inverse cosine function in GeomOp3D.intersects(Point3D, Polygon3D) with the function provided in the Java Fast Math library (thanks to Sergei Chekanov for discovering this library).
• Prevent unnecessary recursion in DetectorElement.findDetectorElement(Hep3Vector). Recursion does not occur if not in parent volume, and loop over children breaks when a match is found.
• Prevent unnecessary looping over faces in AbstractPolyhedron.inside(Hep3Vector). Loop now breaks when point is found to be on wrong side of any face. I am also skeptical that the line above should be the way it is, where it returns Inside.SURFACE. This could in principle occur in the plane of a surface while not on the surface of the actual 3D object.

All of these combined tend to speed up digitization by better than an order of magnitude.

EDIT: Also added fix for parent artifact name

[JeremyMcCormick]

What was the extent of testing done to verify these changes? Is there any test case or other program I can run to verify?

[decibelcooper]

Hi Jeremy. Thank you for reviewing this!

The changes in this PR have been verified by examining the digitization and tracking output from DIS events simulated in our SiD-based geometry. Again, there are three independent changes here...

• For the modifications to AbstractPolyhedron.inside(Hep3Vector) and detectorElement.findDetectorElement(Hep3Vector), the output was not expected to change at all, and so a literal diff was performed between the output of the unmodified code and the modified for 100 DIS events. This was performed by simply dumping the output lcio structures into a text format with IDs that are subject to change suppressed. The diff revealed that the structures are identical to the printed precision. All tracker raw data, tracker hits, and tracks generated with the original code are replicated by the modified code.
• As for the use of net.jafama.FastMath.acos() in GeomOp3D.intersects(Point3D, Polygon3D), it is expected that accuracy changes, and in fact, the output is no longer identical. Performance and accuracy claims of the package can be found here, which indicate good accuracy along with the performance boost. Since the output is not identical, the results were verified by looking at tracking performance. The tracking performance was found to be the same.

A few materials used in drawing these conclusions can be found here, where the two plots indicate no detectable change in tracking performance over 100 DIS events, and the gzipped tarball contains the text dumps that were diff'd. Certainly, 100 events is not a lot to compare tracking performance, and I believe Sergei Chekanov has made comparisons with high stats, but I don't know if these comparisons are documented.

P.S. I have done a tiny non-functional clean up of the modification to AbstractPolyhedron.java (here) this evening. This has been verified as well to make sure.

EDIT: I also fixed an indentation problem that I introduced here

[decibelcooper]

It is also important to mention that in the test case mentioned above, the digitization+tracking time goes from 18653 ms to 515 ms per event, for a factor of 36 reduction in wall (~cpu) time.

[JeremyMcCormick]

Thank you. This looks nice! I will try to merge this in once I can get around to doing a bit of testing independently on the changes.

[JeremyMcCormick]

Apologies for not responding for awhile. I'm going to need to do some extensive testing with these changes on some downstream projects, so I will import this into an lcsim branch for testing. I may then close this PR until that branch is ready to be merged, as I would like to merge in these changes from a branch rather than fork, assuming everything looks okay.

[JeremyMcCormick]

Changes are copied to the iss13 branch. I will make a new PR from that branch when ready.