Terminology » History » Version 1
Amber Herold, 04/14/2010 03:18 PM
1 | 1 | Amber Herold | h1. Terminology |
---|---|---|---|
2 | |||
3 | h2. Terminology |
||
4 | |||
5 | |||
6 | |||
7 | |||
8 | h2. Application |
||
9 | |||
10 | |||
11 | |||
12 | A Leginon application is image acquisition process that is built of several smaller |
||
13 | pieces called 'nodes'. An application defines your preferred scheme for how to acquire |
||
14 | images. An application definition includes which nodes to use, how they are connected, and |
||
15 | where they are running (possibly distributed across several machines). These three concepts |
||
16 | of applications (nodes, events, launchers) are described in more detail below. A typical |
||
17 | application involves several stages of image acquisition and image processing. Once an |
||
18 | application is designed, it can be used repeatedly for different sessions. An application |
||
19 | design can be exported for use on other Leginon installations. |
||
20 | |||
21 | |||
22 | |||
23 | |||
24 | |||
25 | h2. Session |
||
26 | |||
27 | |||
28 | |||
29 | A session is defined as an execution from start to finish of a Leginon application. All |
||
30 | data (images, results, etc.) that are created by Leginon is associated with some session. |
||
31 | The first thing a user must do when starting Leginon is create a session, or continue an |
||
32 | existing session. |
||
33 | |||
34 | |||
35 | |||
36 | |||
37 | |||
38 | h2. Instrument |
||
39 | |||
40 | |||
41 | |||
42 | An instrument is the microscope/camera system used for acquiring data during a |
||
43 | particular session. The facility at which Leginon is installed may have several different |
||
44 | microscopes, each with a unique camera setup. Each system is an instance of an |
||
45 | Instrument. |
||
46 | |||
47 | |||
48 | |||
49 | |||
50 | |||
51 | h2. Node |
||
52 | |||
53 | |||
54 | |||
55 | Nodes are the building blocks of Leginon applications. Nodes are defined for specific |
||
56 | tasks. For instance, an "Acquisition" node is designed to acquire images when it receives |
||
57 | targets from another node, which is typically some type of 'TargetFinder' node. Nodes can |
||
58 | "publish" the data they create. This means they are making their data public for other nodes |
||
59 | to use. The other nodes can "research" to find a specific item of data. Nodes may |
||
60 | communicate with each other by generating "events". |
||
61 | |||
62 | |||
63 | |||
64 | |||
65 | |||
66 | h2. Event |
||
67 | |||
68 | |||
69 | |||
70 | An event is a message sent out from a node to notify other nodes that something of |
||
71 | interest has happened. A common example is to announce that some data has been published. |
||
72 | Another example is to announce that some process has finished. The declaration of which |
||
73 | events are routed between which nodes is part of the application design process. |
||
74 | |||
75 | |||
76 | |||
77 | |||
78 | |||
79 | h2. Manager |
||
80 | |||
81 | |||
82 | |||
83 | Manager is the master of all nodes in an application. Its existence is usually |
||
84 | transparent while running a session, but it is responsible for starting up the application |
||
85 | with all its nodes and event bindings. It works behind the scenes to ensure that events are |
||
86 | properly distributed throughout the system. |
||
87 | |||
88 | |||
89 | |||
90 | |||
91 | |||
92 | h2. Launcher |
||
93 | |||
94 | |||
95 | |||
96 | A Launcher is the parent process for a set of nodes. There is typically one launcher |
||
97 | running on each machine that you intend to have nodes running on. The assignment of which |
||
98 | nodes will be started on a particular launcher is defined as part of the application. |
||
99 | |||
100 | |||
101 | |||
102 | |||
103 | |||
104 | h2. Preset |
||
105 | |||
106 | |||
107 | |||
108 | A preset is a piece of data which encapsulates the state of an instrument. At any time, |
||
109 | the current state of an instrument (magnification, image shifts, camera settings, etc) can |
||
110 | be recorded for later use. There is a particular class of Node called the PresetsManager |
||
111 | which maintains a list of presets for the current Leginon session. These presets are used by |
||
112 | other nodes to set the state of the instrument prior to acquiring an image. This allows for |
||
113 | a series of images to be acquired at a consistent state, but possibly different targets (see |
||
114 | below). This is very similar to the "Low Dose" system on many microscopes, which consists of |
||
115 | a few presets like "Search", "Focus", and "Exposure". The Leginon PresetsManager is a more |
||
116 | generalized approach which allows for and unlimited number of presets to be used (like |
||
117 | several search presets at different magnifications, or multiple exposure presets at |
||
118 | different defocus). |
||
119 | |||
120 | |||
121 | |||
122 | |||
123 | |||
124 | h2. Target |
||
125 | |||
126 | |||
127 | |||
128 | A target is a location where an image will be acquired. Targets are often selected from |
||
129 | existing images (using a TargetFinder node). Acquisition nodes are responsible for |
||
130 | interpreting Targets and then acquiring images of them. |