IMP logo
IMP Manual  for IMP version 2.16.0
glossary.md
1 Glossary {#glossary}
2 ========
3 
4 Several of the more common terms used in %IMP (often parts of class names) are
5 covered below.
6 
7 This is *not* intended to be a complete list of classes in %IMP. For that,
8 please see the [class list](../ref/annotated.html)
9 in the [Reference Guide](../ref/).
10 
11 **Model**
12 Typically, only a single Model is used in an %IMP run. Multiple
13 proteins or conformations can be (and often are) stored in a single model.
14 A single conformation is usually stored in a **Hierarchy**.
15 
16 **Attributes**
17 The **Model** contains a number of Particles, each of which can have any
18 number of attributes (and different Particles can have different sets of
19 attributes). For example, some Particles can have x, y and z attributes and so
20 act like points, while other Particles can have attributes that point to other
21 Particles and so act like bonds or other connections. Attributes are rarely
22 accessed directly, but instead **Decorator** objects are used.
23 
24 **ParticleIndex**
25 All of the Particles are stored in the Model as a simple one-dimensional
26 array. While they can be accessed as Particle objects, it is more
27 efficient just to use a Model pointer and an index into that array. This
28 index is termed a ParticleIndex. Any function that expects a ParticleIndex
29 can also be passed a Particle in Python, which is automatically converted.
30 
31 **Decorator**
32 A Decorator is an object that "wraps" an existing Particle and presents
33 a particular interface to it - it is not a Particle in its own right.
34 These are used rather than accessing Particle attributes directly. For
35 example, the IMP::core::XYZ Decorator is used to access point-like
36 Particles. See also **Hierarchy**.
37 
38 **Hierarchy**
39 While Particles are stored as a simple flat list inside the Model,
40 it is often useful to group them and set up parent-child relationships.
41 This is implemented in %IMP with a special "Hierarchy" Decorator.
42 For example, the IMP::atom::Hierarchy Decorator provides for a molecular
43 hierarchy, whereby a single "residue" Particle may contain a number of "atom"
44 Particles as children. See also **Leaves**.
45 
46 **ScoringFunction**
47 This is used to calculate how well a configuration in the Model satisfies
48 the Restraints (i.e. the score or energy of the system). Typically this
49 is just the sum of all Restraints. In most cases, there will only be one
50 ScoringFunction, but it is possible to create multiple such functions
51 (for example to score subsets of the system).
52 Contrast with **Score**.
53 
54 **Singleton**
55 Used to refer to a single Particle, as opposed to a pair,
56 triple or quad of Particles. For example, an
58 Particles, while an IMP::container::ListPairContainer contains a list
59 of pairs of Particles.
60 
61 **Container**
62 An object that contains a group of related Particles. This allows the same
63 set of Particles to be used in more than one Restraint or Constraint
64 without having to specify them multiple times. Some Containers also can
65 fill themselves automatically, for example with a list of all pairs of
66 Particles that are close in space (see IMP::container::ClosePairContainer).
67 
68 **Modifier**
69 A function that changes the attributes of a single Particle or pair,
70 triple or quad (IMP::SingletonModifier, IMP::PairModifier,
71 IMP::TripletModifier, IMP::QuadModifier respectively). For example,
72 IMP::core::TransformationSymmetry is a SingletonModifier
73 that rotates and translates a single Particle. Modifiers are most commonly
74 used by Constraints.
75 
76 **Predicate**
77 A function that returns a single integer value, given a single
78 Particle or pair, triple or quad of Particles (IMP::SingletonPredicate,
79 IMP::PairPredicate, IMP::TripletPredicate, IMP::QuadPredicate respectively).
80 Usually this is interpreted as a True/False value (non-zero/zero,
81 respectively). For example, IMP::core::ClosePairsFinder, which returns all
82 pairs of Particles that are nearby in space, can use a PairPredicate to
83 exclude certain pairs from this list.
84 IMP::atom::StereochemistryPairFilter is a PairPredicate that excludes all pairs
85 of atoms that are connected by bonds.
86 
87 **Restraint**
88 Every Restraint in %IMP is implemented as a function that returns a
89 score for some subset of the Model. Often this delegates to a **Score** object
90 to make the restraint more flexible. See also **ScoringFunction** for the total
91 score for the entire Model (which is typically just the sum of all
92 restraints). A Restraint is satisfied by modifying the system to minimize
93 its score.
94 
95 **Constraint**
96 Unlike a Restraint, a Constraint defines some invariant of the
97 system that cannot be violated (IMP::core::RigidBody uses a Constraint
98 internally, for example, to keep things rigid).
99 Each Constraint is implemented by changing the Model (using
100 a Modifier) prior to each ScoringFunction evaluation (and in some cases after
101 evaluation too) to ensure that the invariant is not violated.
102 **ScoreState** is a synonym.
103 
104 **ScoreState**
105 This is simply a synonym for **Constraint**.
106 
107 **Score**
108 A Score object calculates a score for a Particle, or pair, triple or quad
109 of Particles. For example, IMP::core::DistancePairScore scores two Particles
110 based on the Cartesian distance between them. Typically these are used
111 internally by Restraints.
112 Do not confuse with **Restraint** or **ScoringFunction**.
113 
114 **Mover**
115 One of the mechanisms for sampling the **ScoringFunction** is Monte Carlo (MC)
116 simulation. This relies on a number of **Mover** objects that perturb the
117 system in some way at each MC step. For example, IMP::core::BallMover is often
118 used with pointlike Particles to move them in Cartesian space.
119 
120 **Leaves**
121 The leaves of an %IMP **Hierarchy** are simply the children that don't in turn
122 have their own children. A commonly-used hierarchy is a molecular hierarchy,
123 in which often the atoms are the leaves (although this is not always the case;
124 where atomic information is not available the leaves may be residues, fragments
125 of sequence, or even entire proteins).
Index< ParticleIndexTag > ParticleIndex