Guide for Particle Flow Algorithm developers in org.lcsim
This page documents the framework for developing PFA algorithms, explains the conventions used, and gives example implementations.
Conventions
In order to make the PFA components as interchangeable as possible, we have adopted some conventions. These were discussed at the January 2005 Boulder simulation workshop
. They will probably evolve slowly over time.
- PFAs should be structured as a series of Driver
s. This way, components can be swapped in and out easily.
- When PFA Drivers need to communicate with each other, they should do it by storing objects or collections of objects in the event via the put() and get() methods.
- Groups of hits should be stored as Hitmap
s. The HitMap class is an extension of HashMap<Long,CalorimeterHit>. Each entry corresponds to one hit, giving the CellID and the hit itself.
- Often, a Driver takes a HitMap as input, performs some operation on it, and produces a modified version of the HitMap as part of the output. The output HitMap should be a new, separate object (i.e. the original HitMap should be left unchanged at the end). Example code to read in and write out hitmaps is given below.
- Clusters should be stored in the event as List<Cluster>.
Worked examples
Here are some example code snippets showing how to combine drivers to produce a PFA. These are written to be read by people rather than compilers, so they may need extra tweaks to run in practice. If you know of other patterns, or if you see that these examples have become out of date, please update them.
HitMap manipulation
There are several classes in the org.lcsim.util.hitmap
package which can be used to manipulate HitMaps. These are generally wrapped as Drivers so that they can be dropped into a PFA template. Here is a quick list:
- Add, subtract, or clone a named HitMap in the event via a driver:
- HitMapAddDriver
- HitMapSubtractDriver
- HitMapCloneDriver
- Convert formats (including the previous Map<Long,CalorimeterHit> format for backwards-compatability):
- HitMapToClusterListDriver
- HitMapToHitListDriver
- MapToHitMapDriver
- HitListToHitMapDriver
- ClusterListToHitMapDriver
- Filter the hits in a hitmap:
- HitMapFilter
- HitMapFilterDriver
A very trivial PFA
See TrivialPFA.java in CVS
for a worked implementation. TrivialPFA can be accessed from the examples page within JAS, though you will have to compile and load it manually. Here is an even simpler piece of code:
Using DigiSim
Thanks to Guilherme, we have a digitisation simulation package called DigiSim which is available under org.lcsim.digisim. There is an example driver at org.lcsim.plugin.web.examples.DigiSimExample
. Borrowing heavily from that, here is an example snippet showing how to use the output from DigiSim:
Reading in and writing out HitMaps
If you are writing your own drivers to use in a PFA, you will probably need to read in HitMaps, and maybe also write out a modified HitMap. Here is a snippet showing how to do this.
How to make things appear in WIRED or the Event Browser in JAS3
One nice feature of JAS3 is that when you open a file in org.lcsim mode, you can upload stuff to the event and have it appear in the org.lcsim Event Browser and the WIRED display (see: [Displaying analysis objects with wired]). But there are a few tricks to make this work:
- For the Event Browser, there must be a handler class in org.lcsim.plugin.browser to tell it how to display the table. Otherwise, the thing you uploaded will appear in the list but won't display anything useful.
- For WIRED, you also need a handler class or the thing you uploaded won't be visible.
- Currently, these expect things to be uploaded as a List<Object>. So if the objects are in another format – such as a hitmap – they won't be readable.
Here is a code snippet that allows you to display hitmaps:
Outline of a complete PFA
Based on the discussions at Boulder, here is an outline (very abstracted!) of what a real PFA might look like.
Caveat: That is not real, compilable code! The real thing will not look exactly like it, since several problems were quietly swept under the carpet. But it illustrates the general structure.
Pieces of a PFA
One of the main advantages of a modular approach is that algorithms can be shared and re-used with minimal coding. In this section we'll look at some of the pieces of a PFA and show how they can be implemented with existing classes.
Here are some classes that are in CVS and that slot into this framework. (Note: This list is definitely not complete – it's just some of the ones I'm familiar with.)
When writing classes, please strive for flexibility and reuseability.
- org.lcsim.recon.cluster.nn.NearestNeighborClusterDriver
: This is a general-purpose clusterer. It uses a nearest-neighbor approach, starting from seed points and recursively adding nearby hits, where "nearby" is defined in terms of numbers of cells in each direction. The driver looks up every List<CalorimeterHit> in the event and applies the clusterer to each, writing out the clustered hits as a List<Cluster>. The name of each output list is the name of the input list plus a common extension (default is "NearestNeighborClusterDriver").
- org.lcsim.recon.cluster.mst.MSTClusterDriver
: This is another general-purpose clusterer. It also works with a nearest-neighbor approach, but with a user-definable metric. The default metric is 3D distance between the centers of the two hit cells. This is in general more computationally expensive than the NN clusterer, but is less sensitive to changes in the detector geometry. The driver also has hooks to let the user veto certain kinds of hits or clusters.
- org.lcsim.recon.cluster.mipfinder.MIPClusterDriver
: This clusterer is intended to find MIPs and track segments. It looks for sequences of isolated or near-isolated hits in adjacent layers.
- org.lcsim.recon.cluster.clumpfinder.ClumpFinder
: This driver reads in a HitMap and tries to find dense clumps of hits. These are written out as a list of Clusters, and left-over hits are written out as a HitMap.
Here is some example code showing how these pieces can be combined. Notice how quite a bit of the code is just manipulation of HitMaps and cluster lists.
Things that need doing
Updates needed in the code:
- A real, live PFA in this format
- Standard routines for telling you how well your PFA did (Ron's ClusterAnalysis?)
- Example(s) in the main org.lcsim tree, probably under org.lcsim.plugin.web.examples
Updates needed on this page:
- Detail on the various PFA components (MIP finder, photon finder, hadron clusterer, cluster identifier, ...) – probably that belongs in sub-pages.
- Link to relevant things
- More code examples