# Presentation: 909308

## Lattice

- 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.

**Lattice**

## 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
- 	o	Any two sets of data can be connected.	o	Link data is user definable.	o Lattices don’t interact. 		Objects can belong to multiple Lattices.
- • 	Minimal impact on existing code.
- 	o	No performance penalty.	o 	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.
- • 	Links hold information that describes the connection.
- • 	Retrieve data in easy to use format.
- • 	Specify connectivity constraints.

## Examples

## 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.

## 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);

## 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.

- LinkData& ld = pLink->linkData();
- Gives you write access to a link’s data.

## 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.