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