...
SM: This is the blue curve in the plot.
Cheating on tracks.
Makes reconstructed particles -> jets.
Needs to be tuned.
NG: Updates from RC?
RC: No writeup, yet.
Compare clusterers and show "how you're doing". Close to a general package.
Hopefully, next week will have a writeup.
SM has parameters for NN clusterer. Would like to see if get these results.
Compare with fixed cone for energy and # of hits. (purity and efficiency)
SM: Can help decide which clusterers to use for which applications.
RC: Efficiency and purtiy -> it is always a tradeoff.
NG: Update from MC?
MC: Porting pflow code from hep.lcd. Now have most of it ported. Keeping in the contrib area, because it is not yet complete/finalized.
Added some "quick and dirty" code to get some of the geometrical information.
NG: What geo information is needed?
MC: What geometric element is a SpacePoint inside?
Solveable if subdetectors are cylindrical.
Haven't been able how to get a specific cell.
Discussing with Niels about missing features. EM not treated properly. How to combine EM and HAD code from myself and Niels.
RC: Niels stuff is not in?
MC: MST and MIP finder are more-or-less stable but not in main repository, yet.
RC: Could use MST from contrib area for benchmarking?
MC: Yes.
NG: AFA photons, might want to look at NN and fixed cone?
Probably going to be the optimal photon finder.
MC: Would like to be able to swap in one algorithm or another.
NG: Updates from NS?
NS: Working on fitter. Construction of the error matrix for the track, every point on the track f/ multiple scattering. Reading in thicknesses and radiation lengths to construct error matrix for the entire track -> weight matrix.
In the process, found a few problems with the helical swimmer, which should be resolved by TJ and JS.
JS did not count on negative radius for the helix. Bug with negative tan(lambda).
Helix for negative tracks?
Convention for negative tracks, omega = negative. Set the track for a helical swimmer from the track parameters. Pass the radius to the helix. In the helix constructor, there is no omega, just radius. But need to keep this information.
Trying to derive track parameters from any point on the track. In the swimmer, track doesn't have to be on POCA. From any point, momentum and point coordinates -> helix. Track parameters are POCA to reference point or (0,0,0). I was using MCParticles which don't necessarily originate close to IP. Putting MCParticle in helix swimmer -> swim back to original point.
Need a few more functions from swimmer.
Obtain a trajectory from the swimmer. Access the trajectory functions. Helix and Line are public interfaces or should allow people to use them.
TJ: Helix says signed radius of curvature.
NS: Think I solved these problems. Didn't put in the CVS.
JS: Test cases. Tried to get point along trajectory with negative distance. But doesn't work with POCA. DOCA works, point -> trajectory. POCA along trajectory does not work.
MC: Trajectory needs a few more accessors. What is the direction on a given point of the trajectory?
NS: In the helix, there is getMomentum() at a point, which is direction. Just need access to the helix itself. Useful to have getTrajectory() from the swimmer.
MC: Committed a bunch of accessors for the line but marked as deprecated, because should go into main interface.
NS: Distance is always positive.
TJ: Always make origin of POCA at (0,0,0)?
TJ: Take closest point in particular direction.
RP: Would like to second NS's request for more functionality. Right now, can initialize a swimmer with a track but not track parameters.
Methods for getting not just first intersection but arbitrary intersections (2nd, 3rd, 4th, etc.). Specific track parameters as single object and get intersections.
TJ: NS suggesting something different. Always give the cylinder intersections from (0,0,0) point.
MC: Could imagine where wouldn't want to start near (0,0,0).
RP: First POCA along trajectory where there are hits. May or may not be close to (0,0,0). Find some hits -> make track. Should be DOCA defined by the seed.
NS: Can get all other points easily if agree to have POCA as origin of the track. Method findPointAtLength(). Increase length by one rotation and will find all other points.
RP: No doubt that it can be done in the code. Encapsulate the facilities in main interface.
TJ: Noticed in MC's code, used ParallelLineException, but should use NaN, instead.
NG: Any more updates from RP?
RP: Discussion last week about what classes should come out of track digitization. Good suggestions from NS. Assume we're going forward with this? Someone needs to figure out raw hit format, persistence.
TJ: Trying to make compatible with LCIO. Can't arbitrarily change time to ID. Somewhat constrained by compatability with LCIO. Can change or "cheat".
NS: Waiting for TJ to define the TrackerHit interface. Right now, make TrackerHit implementation. Waiting for the final definition of what is a TrackerHit, e.g. Hep3Vector or array.
NG: Updates from JS?
JS: Trying to understand the helix problem, write tests to fix problem reported by NS. Might need help understanding the HelixSwimmer.
Still need a way to quantify the ZvTop performance, e.g. real position vs. found position, precision.
NG: org.lcsim forum has been added at linearcollider forum.
TJ: GL suggested including user name in CVS email messages.
MR: Found link for describing to lcd-dev mailing list on Confluence.
NG: Can show CVS comments in Netbeans 5.
Questions to forum, announcements on lcd-dev.
JS: Have logging facility?
TJ: Java supports logging.
getLogger() from Driver.
java.util.logging
JS: Would like to organize debugging printouts.
MR: Put in histograms to cheater code. Good idea?
TJ: getHistogramLevel() should determine whether hists are filled.
NS: Encountered case in geometry of sidaug05 where layers in reverse order of subdetector. Always order radius in increasing radius, z. In VertexBarrelSupport, foam layer is layer 0 and aluminum layer is layer 1 and has smaller r.
TJ: On fixed cone clusterer, RC added some methods, but names were kind of unclear.
RC: Just temporary until agree on common interface.