Lattice Motivation: Maintaining relationships between elements of two sets of objects is a common analysis task. Examples: Tracks  hits. Event hypotheses Vertices  tracks.  kinematic entities. Data analysis is the identification of increasingly complex relationships within the data. Documentation (almost up to date:) http://web.hep.uiuc.edu/home/jjt/Lattice/Lattice.html

Possible simplification: The problem: Everyone “rolls his own” code. • Redundant. • Buggy. Possible simplification: Manage this bookkeeping with a single shareable package. • Write and debug once. • Users can concentrate on analysis. CLEO’s solution: Make object relationships an object (Lattice). Properties: • Addition and removal of connections between objects. • Association of data with each connection (“link data”). • Complete set of data access methods.

Specifications: • Flexible º Any two sets of data can be connected. º Link data is user definable. º Lattices don’t interact. Objects can belong to multiple Lattices. • Minimal impact on existing code. º No performance penalty. º Little rewriting of working code: Data must have an Identifier type. (CLEO data already had this.) Gives type safety (LeftID ≠ RightID, usually).

The goal: • Establish and maintain connections between lists of data. ID = 1 2 M . N Links Right nodes Left nodes Lattice User data IDs do not need to be int The goal: • Establish and maintain connections between lists of data. • Links hold information that describes the connection. • Retrieve data in easy to use format. • Specify connectivity constraints.

Examples Clustering with classes of cluster membership. No overlaps allowed. Hits 1 2 8 Many One class 1 class 2 Clusters Track finding with hit sharing not allowed Tracks Hits c2 1 2 3 8 Many One Numbering is arbitrary. Lines might cross. Not allowed Tracks Hits c2 1 2 3 8 Many One Track finding with hit sharing allowed Clustering with classes of cluster membership. Overlaps allowed. Clusters Hits 1 2 8 Many One class 1 class 2

Issues: • Simple interface. Users only want to see one kind of container (STL vectors). • Unobtrusive. Impose no functional requirements on data classes, so new Lattices can be added without requiring code modification or affecting program behavior. • Persistence over write/read cycle. Lattice uses identifiers, not pointers to data. • Performance. Optimized for data access, at the expense of slower data insertion. This is hidden from the user; could be modified. • Adaptability. Generic implementation. A CLEO specific interface (i.e., to our data structures) is achieved by inheritance.

You are responsible for maintaining LinkData Construction and remodeling: Construct: (It’s a class template, so some instantiation is required.) pLattice = new Lattice<LeftData,RightData,LinkData>(Connectivity); You specify data types, link data, and the allowed connectivity. Remodel: (null pointer returned on failure) Make a new link: (your LinkData will be copied to it) Link* pLink = pLattice->connect(LeftID, RightID, LinkData&); Connect data through an existing link: Link* pLink = pLattice->connect(LeftID, Link&, RightID); Add datum to an existing link: Link* pLink = connect(Link&, RightID); You are responsible for maintaining LinkData

Data access functions: const vector<LeftID>* vLeft = pLattice->vLeftGivenLeft (LeftID); const vector<RightID>* vRight = pLattice->vRightGivenLeft(LeftID); const vector<Link*>* pLinks = linksGivenLeft(LeftID); const vector<LeftID>& vLeftID = pLink->vLeftID(); void connectLinks (LeftID, RightID, vector<Link*>&); void shareLinksLeft(LeftID, LeftID, vector<Link*>&); Verbose nomenclature - I don’t know that LeftID and RightID are different types. Too expensive to maintain. You supply vector; I fill it. linksGivenLeft connectLinks shareLinksLeft vLeftGivenLeft vRightGivenLeft vLeftID LinkData& ld = pLink->linkData(); Gives you write access to a link’s data. “It’s your data.” (GWB)

Status: • An integral part of the CLEO software environment for nearly two years (stable code, except when I “fix” something). • Being adapted (or considered) by two other experiments. • Not “plug and play,” but close.