Changeset 2172
- Timestamp:
- Oct 18, 2004, 5:28:04 PM (22 years ago)
- File:
-
- 1 edited
-
trunk/doc/design/ippSDRS.tex (modified) (20 diffs)
Legend:
- Unmodified
- Added
- Removed
-
trunk/doc/design/ippSDRS.tex
r2171 r2172 1 %%% $Id: ippSDRS.tex,v 1. 7 2004-10-19 01:35:26eugene Exp $1 %%% $Id: ippSDRS.tex,v 1.8 2004-10-19 03:28:04 eugene Exp $ 2 2 \documentclass[panstarrs]{panstarrs} 3 3 … … 433 433 434 434 \begin{figure} 435 \resizebox{6in}{!}{\includegraphics{pics/ImageServer}} 435 \begin{center} 436 \resizebox{4.5in}{!}{\includegraphics{pics/ImageServer}} 436 437 \caption{The components of the IPP Image Server.} 437 438 \label{fig:ImageServer} 439 \end{center} 438 440 \end{figure} 439 441 … … 730 732 \subsubsection{AP Database Tables} 731 733 732 The AP Database divides the sky into a regions, which are in turn 733 sub-divided into regions, in a hierarchical series. The regions are 734 used to subdivide the tables of images, objects, and detections. 735 These three tables are the three largest in terms of both data volume 736 and number of rows. Since nearly all interactions with the AP 737 Database performed by the IPP are limited in spatial coverage, 738 subdividing the tables allows a specific interaction to search only a 739 small subset of the data. The table of images is the smallest of the 740 three; the table of detections is likely to be the largest. As a 741 result, the images tables will be subdivided at a shallow hierarchical 742 level, while the objects and detections are subdivided on deeper (more 743 finely sampled) levels. The region table defines the sky regions and 744 specifies if the region corresponds to an image table, and object 745 table, and/or a detection table. It also specified which regions in 746 the next level of the hierarchy are contained by the region, and which 747 parent region it belongs to. In addition to improving the spatial 748 access to the image, object, and detection data, the region table 749 allows for the multiple computers to serve the database tables. The 750 region file specifies the machine which stores the specific table. 734 Table~\ref{APDBTables} lists the tables used by the AP Database. The 735 contents of these tables are outlined in 736 Appendix~\ref{APDBTableContents}. Below, we discuss how these tables 737 are used by the AP Database software. Three of the tables are not 738 simple tables but instead are divided into many subtables, each of 739 which represents a portion of the sky. These subtables may also be 740 distributed across different computers to distribute the processing 741 load. 751 742 752 743 The table of Images lists all of the images which provided the data in 753 744 the AP Database. In general, these images correspond to the Chips. 754 \tbd{how does the AP Database know about the relationship between a 755 collection of chips?}. This table includes sufficient astrometric 756 parameters to represent the coordinates of the detections to a 757 sufficient accuracy: \tbr{3rd order polynomial across the chip?}. 758 \tbr{does the AP Database know about FPA, Chip, Distortion Model, etc? 759 I think it probably needs to if it is going to solve for distortion 760 models. however, this operation may be a combination of AP DB 761 interaction and MD DB interaction.} 745 This table includes sufficient astrometric parameters to represent the 746 coordinates of the detections to a sufficient accuracy. 762 747 763 748 The Images in the image table group are stored in the Image table … … 791 776 non-detection statistics. 792 777 778 The table of regions is used to subdivide the tables of images, 779 objects, and detections. The AP Database divides the sky into a 780 hierarchy of regions (portions of the sky) each of which is in turn 781 sub-divided into smaller portions. These three tables are the three 782 largest in terms of both data volume and number of rows. Since nearly 783 all interactions with the AP Database performed by the IPP are limited 784 in spatial coverage, subdividing the tables allows a specific 785 interaction to search only a small subset of the data. The table of 786 images is the smallest of the three; the table of detections is likely 787 to be the largest. As a result, the images tables will be subdivided 788 at a shallow hierarchical level, while the objects and detections are 789 subdivided on deeper (more finely sampled) levels. The region table 790 defines the sky regions and specifies if the region corresponds to an 791 image table, and object table, and/or a detection table. It also 792 specified which regions in the next level of the hierarchy are 793 contained by the region, and which parent region it belongs to. In 794 addition to improving the spatial access to the image, object, and 795 detection data, the region table allows for the multiple computers to 796 serve the database tables. The region file specifies the machine 797 which stores the specific table. Figure~\ref{ABDBRegions} illustrates 798 this subdivision of the sky and the association between different 799 levels of the hierarchy with different subtables. 800 793 801 The Filters table identifies all of the physical filters (specific, 794 802 named pieces of glass) known to the system. A related table, … … 797 805 it may be a derived photometry system. \tbd{distinguish between 798 806 reference, average, and detection photcodes}. 807 808 \begin{table} 809 \begin{center} 810 \caption{AP Database Tables\label{APDBTables}} 811 \begin{tabular}{ll} 812 \hline 813 \hline 814 {\bf Table Name} & {\bf Description} \\ 815 \hline 816 Region Table & spatial distribution of tables \\ 817 Images & The images that have objects in the DB. \\ 818 Image Overlaps & Image regions which are touched by specific images. \\ 819 Objects & The objects --- average properties of multiple detections of the same object. \\ 820 Average Magnitudes & Average photometry in multiple filters \\ 821 Detections & Detections of sources in an image. \\ 822 Non-Detections & Non-detections of objects in an image. \\ 823 Filters & Filters understood by the system. \\ 824 Photcodes & Transformations between different photometric systems \\ 825 Database Machines & computers used to store the tables \\ 826 \hline 827 \end{tabular} 828 \end{center} 829 \end{table} 830 831 \begin{figure} 832 \begin{center} 833 \resizebox{6in}{!}{\includegraphics{pics/APDBRegions}} 834 \caption{AP DB Regions and Image / Object tables} 835 \label{fig:APDBRegions} 836 \end{center} 837 \end{figure} 838 839 \begin{figure} 840 \begin{center} 841 \resizebox{4.5in}{!}{\includegraphics{pics/APDB}} 842 \caption{AP DB components} 843 \label{fig:APDBRegions} 844 \end{center} 845 \end{figure} 799 846 800 847 \subsubsection{AP Database servers} … … 847 894 \end{table} 848 895 849 \begin{table} 850 \begin{center} 851 \caption{AP Database Tables\label{APDBTables}} 852 \begin{tabular}{ll} 853 \hline 854 \hline 855 {\bf Table Name} & {\bf Description} \\ 856 \hline 857 Region Table & spatial distribution of tables \\ 858 Images & The images that have objects in the DB. \\ 859 Image Overlaps & Image regions which are touched by specific images. \\ 860 Objects & The objects --- average properties of multiple detections of the same object. \\ 861 Average Magnitudes & Average photometry in multiple filters \\ 862 Detections & Detections of sources in an image. \\ 863 Non-Detections & Non-detections of objects in an image. \\ 864 Filters & Filters understood by the system. \\ 865 Photcodes & Transformations between different photometric systems \\ 866 Database Machines & computers used to store the tables \\ 867 \hline 868 \end{tabular} 869 \end{center} 870 \end{table} 896 \subsubsection{Notes} 897 898 how does the AP Database know about the relationship between a 899 collection of chips? 900 901 what is astrometry representation in image table? 3rd order polynomial 902 across the chip? 903 904 does the AP Database know about FPA, Chip, Distortion Model, etc? I 905 think it probably needs to if it is going to solve for distortion 906 models. however, this operation may be a combination of AP DB 907 interaction and MD DB interaction. 871 908 872 909 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 873 910 874 911 \subsection{Controller} 912 913 \begin{figure} 914 \begin{center} 915 \resizebox{4.5in}{!}{\includegraphics{pics/Controller}} 916 \caption{Schematic illustration of the Controller components} 917 \label{fig:Controller} 918 \end{center} 919 \end{figure} 875 920 876 921 The IPP uses a group of computers to store and process images and to … … 897 942 kernel handle the I/O load. 898 943 944 \subsubsection{Controller Nodes} 945 899 946 Computers managed by the IPP Controller are allowed to be in one of 900 947 several states, and the IPP Controller must interact with it in an … … 909 956 Computers may be set to the {\tt off} or {\tt dead} states by external 910 957 subsystems; it is the responsibility of the IPP Controller to return a 911 computer to the {\tt alive} state if possible. An example scenario: a 912 computer crashes. At this point the IPP Controller should detect that 913 the computer is no longer responsive and mark it {\tt dead}. It 914 should occasionally try to re-establish communication with the 915 computer, potentially with longer and longer delays between attempts. 916 A human could be notified if the computer seems to remain {\tt dead} 917 for a very long time. In another circumstance, a person needs to work 918 on a computer. They should have the ability to notify the IPP 919 Controller that the machine is off, perhaps with a prior notification 920 that the machine should be prepared to go off. Only when the person 921 is done working and testing the machine, and tells the IPP Controller 958 computer to the {\tt alive} state if possible. 959 960 The IPP Controller must honor requests (normally from the users) to 961 change the mode of any computing node on demand between {\tt off} and 962 {\tt dead}. This would normally be done after a computer has been 963 rebooted and is release to the IPP Controller for its use. It must 964 also be able to change the list of allowed tasks as requested by 965 external commands. 966 967 Two example scenarios illustrate the transition between these states. 968 First, imagine a computer crashes. At this point the IPP Controller 969 should detect that the computer is no longer responsive and mark it 970 {\tt dead}. It should occasionally try to re-establish communication 971 with the computer, potentially with longer and longer delays between 972 attempts. A human could be notified if the computer seems to remain 973 {\tt dead} for a very long time. In another scenario, a person needs 974 to work on a computer. They notify the IPP Controller that the 975 machine is off, perhaps with a prior notification that the machine 976 should be prepared to go off. When work on the machine is complete, 977 it should be placed in the {\tt dead} state. Only when the person is 978 done working and testing the machine, and tells the IPP Controller 922 979 that the machine is now {\tt dead} can the IPP Controller attempt to 923 980 re-start communications and processing on that computer. … … 931 988 tasks to run on specific CPUs or exclude specific tasks from specific 932 989 CPUs. 990 991 The Controller maintains a table of processing nodes available to it 992 and the status of these Nodes. When the Controller starts, it 993 attempts to launch a Node Agent on each of the available processing 994 nodes. Modes which are not responsive are placed into an inactive 995 state and retried occasionally. 996 997 \subsubsection{Controller Node Agents} 998 999 A Node Agent runs on each of the individual nodes to perform the tasks 1000 as directed by the Controller. The Node Agents communicate with the 1001 Controller via a socket connection. 1002 1003 A processing stage is executed in the UNIX user space, and is run as a 1004 fork by the Node Agent. The Node Agent must monitor the standard 1005 error and standard output of the processing stage and save them in 1006 separate buffers. If the process dies, the Node Agent must detect the 1007 crash. The Node Agent must respond to various commands from the 1008 Controller, as follows: 1009 1010 \paragraph{Report status} 1011 1012 The Node Agent returns the state of the Node (idle, busy, done), the 1013 state of the current processing stage (`none', `busy', `crash', 1014 `done'), and the exit status of the current processing stage, if 1015 available. 1016 1017 The four possible states of the Node indicate that the client has no 1018 current processing stage (`idle'), that it has a processing stage 1019 which is still running (`busy'), or that it has a processing stage 1020 which has completed. The last two states indicate if the current 1021 processing stage has crashed (`crash'), or if the current processing 1022 stage has exited gracefully (`done'). The reported exit state, if the 1023 process has completed without crashing, is the UNIX exit state 1024 reported by the processing stage: 0--256 with 0 indicating a 1025 successful completion. 1026 1027 \paragraph{Report stdout} 1028 1029 Send and flush the current stdout buffer. The Node Agent will return 1030 the complete contents of the stdout buffer via a buffered write and 1031 flush the buffer when it is finished. The Node Agent will not accept 1032 more data on the stdout buffer from the current processing stage until 1033 the send is complete and the buffer is flushed. The daemon must 1034 accept all of the buffer output. 1035 1036 \paragraph{Report stderr} 1037 1038 Identical to `report stdout', but for stderr. 1039 1040 \paragraph{Kill processing stage} 1041 1042 The Node Agent should send a kill signal to the current processing 1043 stage. When the processing stage has exited, the Node Agent should 1044 set the processing stage status to `crash' and the Node status to 1045 `done'. 1046 1047 \paragraph{Clear processing stage} 1048 1049 The Node Agent should set the current processing stage state to `none' 1050 and the Node state to `idle'. If a processing stage is currently 1051 running, it should be killed (signal 9 or 15) before the processing 1052 stage is cleared. 1053 1054 \paragraph{Start processing stage} 1055 1056 The Node Agent forks a specified command. The command should be a 1057 standard UNIX command without command line redirection or 1058 backgrounding. For this reason, the Node Agent must provide a layer 1059 of security, for example, by employing SSL authentication. 1060 1061 \subsubsection{Tasks} 933 1062 934 1063 The IPP Controller accepts tasks from other IPP subsystems. The task … … 960 1089 are maintained in the queue and never executed. 961 1090 1091 It may be useful for the Controller to distinguish between tasks 1092 dominated by I/O and tasks dominated by data processing. It is 1093 possible that one of each of these types of tasks may be sent to the 1094 same node without significantly impacting the system performance. 1095 Alternatively, it may be necessary to limit a single machine with 2 1096 CPUs to only one of each of these types of tasks (i.e., one processor 1097 will be working on I/O while the other is working on processing). 1098 Such details will be studied by the IfA IPP Team. 1099 962 1100 The IPP Controller monitors the output streams from the executing 963 1101 tasks and the exit status of the tasks. Each task is associated with … … 966 1104 other subsystems may determine if specific tasks have started or 967 1105 completed. 1106 1107 \subsubsection{External Interfaces} 968 1108 969 1109 The IPP Controller must accept commands from other IPP subsystems. … … 976 1116 must also be able to stop the current execution of a task and push it 977 1117 to the end of the queue and also change its priority. 978 979 The IPP Controller must honor requests (normally from the users) to980 change the mode of any computing node on demand between {\tt off} and981 {\tt dead}. This would normally be done after a computer has been982 rebooted and is release to the IPP Controller for its use. It must983 also be able to change the list of allowed tasks as requested by984 external commands.985 1118 986 1119 The IPP Controller must respond to informational requests regarding the … … 1007 1140 Server. 1008 1141 1009 It may be useful for the Controller to distinguish between tasks 1010 dominated by I/O and tasks dominated by data processing. It is 1011 possible that one of each of these types of tasks may be sent to the 1012 same node without significantly impacting the system performance. 1013 Alternatively, it may be necessary to limit a single machine with 2 1014 CPUs to only one of each of these types of tasks (i.e., one processor 1015 will be working on I/O while the other is working on processing). 1016 Such details will be studied by the IfA IPP Team. 1017 1018 The Controller maintains a table of processing nodes available to it 1019 and the status of these Nodes. When the Controller starts, it 1020 attempts to launch a Node Agent on each of the available processing 1021 nodes. Modes which are not responsive are placed into an inactive 1022 state and retried occasionally. 1023 1024 The Controller also maintains three tables of processing jobs: pending 1142 The Controller maintains three tables of processing jobs: pending 1025 1143 stages, active stages, and completed stages. The pending stages are 1026 1144 those which have not yet been performed. The active stages are those … … 1030 1148 clients and sends them new pending stages when they become free. 1031 1149 1032 \subsubsection{Node Agents}1033 1034 A Node Agent runs on each of the individual nodes to perform the tasks1035 as directed by the Controller. The Node Agents communicate with the1036 Controller via a socket connection.1037 1038 A processing stage is executed in the UNIX user space, and is run as a1039 fork by the Node Agent. The Node Agent must monitor the standard1040 error and standard output of the processing stage and save them in1041 separate buffers. If the process dies, the Node Agent must detect the1042 crash. The Node Agent must respond to various commands from the1043 Controller, as follows:1044 1045 \paragraph{Report status}1046 1047 The Node Agent returns the state of the Node (idle, busy, done), the1048 state of the current processing stage\footnote{Note that a processing1049 stage is considered ``current'' until it is cleared with {\em clear1050 processing stage} --- even if it has crashed or completed.} (`none',1051 `busy', `crash', `done'), and the exit status of the current1052 processing stage (`none', 0--256).1053 1054 The three states of the Node indicate that the client has no current1055 processing stage (`idle'), that it has a processing stage which is1056 still running (`busy'), or that it has a processing stage which has1057 completed.1058 1059 The processing stage states indicate the there is no current1060 processing stage (`none'), that the current processing stage is1061 running (`busy'), that the current processing stage has crashed1062 (`crash'), or that the current processing stage has exited gracefully1063 (`done'). The exit state is the exit state reported by the processing1064 stage (0--256 with 0 indicating a successful completion) or is an1065 indication that there is no current processing stage (`none').1066 1067 \paragraph{Report stdout}1068 1069 Send and flush the current stdout buffer. The Node Agent will return1070 the complete contents of the stdout buffer via a buffered write and1071 flush the buffer when it is finished. The Node Agent will not accept1072 more data on the stdout buffer from the current processing stage until1073 the send is complete and the buffer is flushed. The daemon must1074 accept all of the buffer output.1075 1076 \paragraph{Report stderr}1077 1078 Identical to `report stdout', but for stderr.1079 1080 \paragraph{Kill processing stage}1081 1082 The Node Agent should send a kill signal to the current processing1083 stage. When the processing stage has exited, the Node Agent should1084 set the processing stage status to `crash' and the Node status to1085 `done'.1086 1087 \paragraph{Clear processing stage}1088 1089 The Node Agent should set the current processing stage state to `none'1090 and the Node state to `idle'. If a processing stage is currently1091 running, it should be killed before the processing stage is cleared.1092 1093 \paragraph{Start processing stage}1094 1095 The Node Agent forks a specified command. The command should be a1096 standard UNIX command without command line redirection or1097 backgrounding. For this reason, the Node Agent must provide a layer1098 of security, for example, by employing SSL authentication.1099 1100 \subsubsection{Controller User Interface}1101 1102 1150 The IPP Controller provides a mechanism for users (either other 1103 1151 programs or humans) to interact with it. The user interface provides 1104 1152 commands to check the current processing job queues, the tables of 1105 1153 successful and failed jobs, to stop or delete jobs, etc. 1106 1107 \subsubsection{Notes}1108 1109 can a process send a message back to the controller before process is1110 complete? messages via controller?1111 1112 does the controller or the image server decide if a machine is offline1113 or both?1114 1115 I/O tasks vs CPU tasks?1116 1154 1117 1155 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% … … 1622 1660 \begin{figure} 1623 1661 \begin{center} 1624 \resizebox{ 8cm}{!}{\includegraphics{pics/phase2}}1662 \resizebox{6in}{!}{\includegraphics{pics/phase2}} 1625 1663 \caption{ \label{phase2} Phase 2 dataflow} 1626 1664 \end{center} … … 1675 1713 \begin{figure} 1676 1714 \begin{center} 1677 \resizebox{ 8cm}{!}{\includegraphics{pics/phase3}}1715 \resizebox{4.5in}{!}{\includegraphics{pics/phase3}} 1678 1716 \caption{ \label{phase3} Phase 3 dataflow} 1679 1717 \end{center} … … 1867 1905 \begin{figure} 1868 1906 \begin{center} 1869 \resizebox{ 8cm}{!}{\includegraphics{pics/phase4}}1907 \resizebox{6in}{!}{\includegraphics{pics/phase4}} 1870 1908 \caption{ \label{phase4} Phase 4 dataflow} 1871 1909 \end{center} … … 2260 2298 2261 2299 \subsection{Image Server Database Table Contents} 2300 \ref{ImageServerTableContents} 2262 2301 2263 2302 \begin{table} … … 2315 2354 2316 2355 \subsection{Metadata Database Table Contents} 2356 \ref{MetadataTableContents} 2317 2357 2318 2358 Tables \tbd{NN} -- \tbd{NN} list the basic contents of each of the … … 2655 2695 \end{table} 2656 2696 \clearpage 2697 2698 \subsection{AP Database Table Contents} 2699 \ref{APDBTableContents} 2700 2701 2657 2702 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 2658 2703
Note:
See TracChangeset
for help on using the changeset viewer.
