+Figure 1: Elixir node +
| abszero | find filter zeropts |
| applyfit | apply fit to new vector |
| applyfit2d | apply 2-d fit to new vector |
| badimages | look for images with anomalous astrometry |
| box | draw a box on the plot |
| buffers | list the currently allocated buffers |
| calextract | extract photometry calibration |
| calmextract | extract photometry calibration |
| cals | plot calibration data |
| catalog | plot catalog stars |
| ccd | plot color-color diagram |
| ccdextract | extract star coords from color-color diagram |
| center | center image on coords |
| cgrid | plot sky coordinate grid |
| clear | erase plot |
| cmatch | match two catalogs |
| cmd | plot cmd of stars in current region |
| cmdextract | extract stars based on cmd regions |
| cmpread | read data from cmp format files |
| concat | reduce vector dimension |
| contour | create contour from image |
| cplot | plot vectors in sky coordinates |
| create | create a new vector |
| csystem | convert between coordinate systems |
| ctimes | convert between time formats |
| cursor | get coords from cursor |
| czplot | plot scaled vectors in sky coordinates |
| datafile | define file to read vectors |
| date | get current date |
| ddmagextr | plot magnitude differences |
| ddmags | plot magnitude differences |
| delete | delete vectors or matrices |
| device | set / get current graphics device |
| dmagextract | extract stars based on differential magnitudes between filters |
| dmags | plot differential magnitudes between filters |
| dmt | plot mag scatter |
| dumpmags | custom dB dumping thingy |
| elixir | get status info from elixir |
| extract | extract vectors from catalogs |
| file | test for a file |
| fit | fit polynomial to vector pair |
| fit2d | fit 2-d polynomial to vector triplet |
| gaussj | solve Ax = B (N-D)\n |
| gcat | get catalog at location |
| gimages | get images at location |
| grid | plot cartesian grid |
| gstar | get star statistics |
| gtypes | get type fractions |
| histogram | generate histogram from vector |
| images | plot image boxes |
| imbox | plot expected image box |
| imdata | extract data for specific images |
| imdense | image density plot |
| imextract | extract vectors from catalogs |
| imlist | list image info |
| imphot | image photometry info |
| imrough | get info from imruf database |
| imsearch | get info from imreg database |
| imstats | plot image statistics |
| interpolate | interpolate between vector pairs |
| jpeg | write text line on graph |
| labels | define labels for plot |
| lcat | list catalogs in region |
| lcurve | plot lightcurve for a star |
| limits | define plot limits |
| mcreate | create a matrix |
| mextract | extract vectors from catalogs |
| mget | extract a vector from a matrix |
| mset | insert a vector in a matrix |
| pcat | plot catalog boundaries |
| photcodes | list photometry codes |
| photresid | plot photometry residuals |
| plot | plot a pair of vectors |
| pmeasure | plot individual measurements |
| precess | precess coordinates |
| write vectors to file | |
| procks | plot rocks |
| ps | define labels for plot |
| rd | load fits image |
| read | read vectors from datafile |
| region | define sky region for plot |
| resid | plot residuals |
| resize | set graphics/image window size |
| section | define section of graph |
| set | vector math |
| simage | plot stars in an image |
| sort | sort list of vectors |
| sprintf | formated print to variable |
| stats | give statistics on a portion of a buffer |
| style | set the style for graph plots |
| subpix | get subpixel positions |
| subraster | subraster of fits image |
| subset | expand vector dimension |
| textline | write text line on graph |
| tv | display an image on the Kii window |
| uniq | create a uniq vector subset from a vector |
| vclip | clip a vector |
| vectobuf | convert vector triplet to buffer |
| vectors | list vectors |
| vstat | get info from imreg database |
| wd | write an image to a file |
| write | write vectors to datafile |
| zap | delete pixels |
| zeropts | show filter zeropts |
| zplot | plot x y with size scaled by z |
+dvo: c +ambiguous command: c ( catalog cgrid clear create cursor ) ++ +The shell is an interpretive programming language. +Variables are set as follows: + +
+dvo: $fred = 10 ++ +Any expression within curly brackets {} is assumed +to be an arithmetical expression and is evaluated before the line is +executed. For example: + +
+echo {$fred*dcos(45)}
+
+
+would give the response 7.07107. There are math functions cos, sin,
+and tan, which operate on radian expressions, and also dcos, dsin,
+dtan, which operate on degree expressions. There are also the
+equivalent inverse functions: eg., asin and dasin return radians and
+degrees, respectively. The help section on Math defines all of the
+available math functions.
+
++! -- system call +? -- list commands +?? -- list variables +echo -- type this line +exec -- system call +exit -- exit program +help -- get help on a function +output -- redirect output to file +quit -- exit program +scan -- scan line from keyboard or file to variable +wait -- wait until return is typed +which -- show command ++ +Most of these are self-explanatory. The command ?? prints the system +variables. The help command will provide help on a single +command or, without any arguments, will list all available help +files (this includes general help not associated with a specific +command). + +
+break -- escape from function +for -- loops +if -- logical cases +input -- read command lines from a file +macro -- deal with the macros ++ +
+There are several options for programming in status. First, +a file which contains a series of commands can be executed with +input (filename). It is also possible to define macros which +will behave much like regular commands. A macro is defined by typing +macro name or macro create name followed by the +commands. Arguments to the macro are assigned to the variables $1 +.. $N and the number of arguments is given by $0. Macros may be +defined in input files, and in fact when status is +started, it loads the file ~/.statusrc which may contain +default macros. Simple loops and if statements can be performed, and +are quite useful for complex macros. + +
+'If' statements are similar in syntax to C if statements. Math +expresions in the if statement must be contained in curly braces, as +elsewhere. Variables with string values may use the logical == +operator to test if two strings are the same. 'For' loops are quite +simplistic. The form is: + +
+for var first last delta + (commands) +end ++ +
+The value of $var will start at the value first and increment by +delta after each loop. The loop will stop after $var is greater +than stop. The value delta is optional, with 1 assumed. +The value of $var may be changed during the loop, and if set +beyong the value of last will end the loop early. + +
+box -- draw a box on the plot +clear -- erase plot +create -- create a new vector +cursor -- get coords from cursor +grid -- plot cartesian grid +hist -- create histogram from a vector +labels -- define labels for plot +limits -- define plot limits +plot -- plot a pair of vectors +print -- write vectors to file +ps -- define labels for plot +set -- vector math +style -- set the style for graph plots +vectors -- list vectors +zplot -- plot scaled points ++ +
+In addition to scalar variables, status can manipulate and +display 1-D vector variables. Many of the commands which extract data +from the photometry database place the data in vectors as well as +plotting them. A vector can also be created based on a number +sequence with the command create name Nelements start delta. +The resulting vector has $Nelements$ entries, starting at a value of +$start$ and running until $start + delta*Nelements$. If $delta$ is +0.0, all elements will have the value of $start$. A histogram of a vector +may be made with the command hist, which creates a new vector +containing the histogram of the first vector. The data range and bin +size of the histogram are defined in same way as with create. This +makes it easy to create the index vector that goes with a histogram +vector: + +
+hist y Ny 1 100 0.1 +create dx 1 100 0.1 ++ +
+The above will create a histogram of y in Ny and the index in dx. +Plotting this with plot dx Ny will show the histogram. + +
+Vector math is performed with a command of the form set new = + (expression). The expression is some math function employing + vectors and scalars. A complete listing of the math operators + available in set can be found in the help for set. + +
+Once vectors are defined, they may be plotted. A pair of vectors can +be plotted against each other if they have the same number of entries. +The plotting is performed on the graphics window, Kapa. There are +actually several graphics windows available to status, any of +which may be used to plot at any time. Some of the more complex +operations default to either graphics window 0 or 1, depending on the +context. Except for those functions with a pre-defined window, all +plotting functions apply to the current graphics window unless an +option -n N is given to specify a different window. The +plotting style is determined by the command style which can set +the line width, the line type (solid, dashed, dotted, etc), the point +type (box, cross, etc), the point size, the color, and whether a pair +of vectors is plotted as a sequence of points, a set of connected +lines, or a histogram. Some functions which make plots use their own +styles, as discussed below. The function limits lets the user +set the range of the plot axes, or check the current setting. The +command plot will plot a pair of vectors on the current graphics +window using the current plotting style for that window. The command +zplot will plot a pair of vectors with the point size scaled by +a third vector, with maximum and minimum point sizes representing +specified values. The cursor command goes the other way: this +command puts the Kapa window in cursor mode and waits for input from +Kapa. The user can then type any alphanumeric key on the graphics +windows and will be told both the pointer location (in the graphics +coordinates) and will have the coordinates stored in status +variables. For example, by typing ``1'' in the sky display window, +the RA and DEC of the pointer are stored in the variables $R1 +and $D1. This command can be used to let the user define +locations or regions of interest on the Kapa window. (Future addition: +button, which does the same with the mouse buttons). + +
+gcat -- get catalog at location +gimages -- get images at location +gstar -- get star statistics +extract -- extract average vectors from catalogs +mextract -- extract measurement vectors from catalogs +imstats -- plot image statistics +imextract -- extract image vectors from database +lcat -- list catalogs in display region +cmatch -- match two catalogs ++ +
+There are a variety of other commands which directly refer to the +photometry database. Some of these functions extract data of various +types from the database, others perform more complex plotting +operations. The commands listed above are those which simply extract +data from the database. The first three list information relevant to +a specific RA, DEC location on the sky: gcat (RA) (DEC) lists +the catalog at the specified location and places the name in the +variable $CATNAME, gimages (RA) (DEC) lists all images +which overlap the specified location, gstars (RA) (DEC) (RADIUS) +lists data about the stars within a specified radius of the specified +location (all numbers above are given in decimal degrees). Similarly, +lcat lists the catalogs in the region. Imstats lists statistics +about each image + +
+The next three commands extract a specific piece of information from +the photometry database and places it in a vector. First, +extract will extract average values for each star and place +it in a vector. Next, mextract will extract measurement +values for each star and place it in a vector: as a result a single +star may have multiple entries in the measurement vectors. Finally, +imextract will extract image statistics into vectors (not yet +implemented). + + +
+catalog -- plot catalog stars +cgrid -- plot sky coordinate grid +cplot -- plot vectors in sky coordinates +czplot -- plot scaled vectors in sky coordinates +images -- plot image boxes +imdense -- image density plot +lcurve -- plot lightcurve for a star +pcat -- plot catalog boundaries +region -- define sky region for plot +resid -- plot residuals +simage -- plot stars in an image ++ +
+There are two types of database plotting functions: those that display +or refer to the spatial charateristics of the data and those that +refer to other types of charatersitics, such as the time domain. The +graphics window 0 is reserved for all plots of objects on the sky. +The command region defines the current sky coordinates for plots +in graphic window 0. The command pcat plots the outline of all +photometry database files which are within the currently defined +region (and by default, only those with data). images plots the +outline of the images in the image database, while imdense shows +the number of images at a location by randomly spacing dots within the +boundary of the images. The command cgrid +draws a grid in celestial coordinates on the for the current region. + +
+The most complex, but also one of the most useful command is +catalog, which plots the positions of stars in the photometry +database (and others) on the sky. There are many options to this +command. One set allows the user to plot stars from the photometry +database (the default), from the HST GSC, or from an ASCII text file +with RA, DEC, and Mag in specified columns. If the ASCII file has a +fixed number of bytes per line, the data can be more quickly loaded. +The size of the points may be scaled by the star magnitude, by the +number of observations of the star, or by the number of missing +datapoints for the star. In addition, points may be plotted only if +they land in specified magnitude ranges, or with specified numbers of +measurements, or missed measurements. Also, objects may be plotted +only if they have a specified Average.code, so that only asteroids or +only perfect stars may be plotted. The plotted vectors may be saved, +if desired, and the source catalog epoch may be specified as different +from J2000 (only valid for ASCII data). + +
+Several other commands relate to non-spatial charateristics of images +and stars. lcurve will plot a light curve for all stars within +some radius of a point. resid plots the photometry residuals +for a particular region file. + +
+Fig.~\ref{allsky} shows a map of the entire sky, and the location +of the images currently in the database. This picture was made with +the following commands: (output is not shown) + +
+dvo: region 0 0 90 gls +dvo: cgrid +dvo: style -lw 2 -c red +dvo: images +dvo: ps ++ +
+In this example, on the graphics window, the image boxes are shown in +red. The user now has the possiblitiy of using the cursor command to +narrow in on a specific region, and so forth. + +\begin{figure} +%\psfig{file=polar.ps,width=16cm} +\caption{\label{polar} \small + Map of the sky in polar project, and images added to database. } +\end{figure} + +
+Fig.~\ref{allsky} shows a map of the entire sky, and the location of +the images currently in the database from a polar project. This +picture was made with the following commands: (output is not shown) + +
+dvo: region 0 0 90 zea +dvo: cgrid +dvo: style -lw 2 -c red +dvo: images +dvo: ps ++ +
+In this example, on the graphics window, the image boxes are shown in +red. The user now has the possiblitiy of using the cursor command to +narrow in on a specific region, and so forth. + +\begin{figure} +%\psfig{file=catalog.ps,width=9cm} +\caption{\label{catalog} \small + Comparison between HST GSC and photometry database astrometry. } +\end{figure} + +
+Fig.~\ref{catalog} shows an example comparison of the photometry +database star positions and the HST Guide Star Catalog star positions. +The crosses are all objects in the photometry database, while the +boxes are only the stars identified as USNO stars. The circles are +the stars from the HST GSC. The size of both points is a function of +brightness. This plot was made with the following commands (starting +from the previous image): + +
+dvo: cursor (typed 1 on region of interest) +1 137.097858 22.698305 +q 137.097858 22.698305 +dvo: region $R1 $D1 0.2 TAN +dvo: cgrid +dvo: box +dvo: style -pt 0 +dvo: gcat $R1 $D1 + 0 n2230/1951.cpt * +dvo: style -pt 2; cat -all -m 12 18 +dvo: style -pt 1; cat -all -m 12 18 -ID $USNO +dvo: style -pt 7; cat -all -m 12 18 -g +Index: unk/Ohana/doc/www/html/Elixir-DB/gastro.htm =================================================================== --- /trunk/Ohana/doc/www/html/Elixir-DB/gastro.htm (revision 4725) +++ (revision ) @@ -1,104 +1,0 @@ - - - - -
-The gastro program determines the astrometric transformation for an -image based on the cmp/smp file. This file contains both the table of -object data and the complete image FITS header. Using the header -astrometric information as a starting point, gastro loads the -reference astrometry objects appropriate for the region and determines -the matching objects between the image and the reference. These -objects are used, with iteration to improve the sample, to determine -the astrometric transformation with up to 3rd order polynomials. - -
-gastro filtname.cmp -options: - -h - -help - -v - -p (photcode) - -plot - -maglims - -nstars - -fx - -fy - -coords (ra) (dec) - -dump - -mdmp - -cdmp - -loneos - -gastro configuration variables: -OFFSET_RADIUS - max allowed offset in gcenter -MIN_MATCHES - min number of matched stars for linear fit -MINIMUM_RADIUS - target matching radius in gfit iterations -MAX_ERROR - maximum allowed error in solution -MAX_NONLINEAR - maximum angle between axes -MAX_PRECISE - unused? -DEFAULT_RADIUS - unused? - -ROUGH_ASTROMETRY - source of initial astrometry terms - -CCD_PC1_1 - initial guess pc1_1 -CCD_PC2_2 - initial guess pc2_2 -CCD_PC1_2 - initial guess pc1_2 -CCD_PC2_1 - initial guess pc2_1 -ASEC_PIX - initial guess arcsec / pix - -POLAR_ALIGNMENT - provide polar alignment of telescope mount? -POLAR_AXIS_RA - RA of telescope polar axis -POLAR_AXIS_DEC - DEC of telescope polar axis -RA_OFFSET - RA offset -DEC_OFFSET - DEC offset (degenerate?) - -NFIELD - select stars from region NFIELD x detector size -NPOLYTERMS - number of orders to allow -MMIN - minimum magnitude of allowed star -ROT_ZERO - zero of tested rotation range -dROT - rotation step size -NROT - number of rotation tests = 2NROT + 1 -GSCFILE - name of HST GSC table file -GSCDIR - name of HST GSC data directory -LONEOS_REGIONS - table of location coordinates -USNO_CDROM - name of USNO data directory -ASTRO_REFCAT - reference catalog format to read -CATDIR - name of ptolemy database -PHOTCODE_FILE - table of photcodes - -gastro2 configuration variables: -OFFSET_RADIUS - unused -MIN_MATCHES - unused -DEFAULT_RADIUS - unused -MINIMUM_RADIUS - -MAX_ERROR - -MAX_NONLINEAR - -MAX_PRECISE - -CCD_PC1_1 - -CCD_PC2_2 - -CCD_PC1_2 - -CCD_PC2_1 - -ASEC_PIX - -NFIELD - -NPOLYTERMS - -ROT_ZERO - -dROT - -NROT - -POLAR_ALIGNMENT - -GSCFILE - -GSCDIR - -2MASS_DIR - -POLAR_AXIS_RA - -POLAR_AXIS_DEC - -RA_OFFSET - -DEC_OFFSET - -LONEOS_REGIONS - -USNO_CDROM - -ASTRO_REFCAT - -CATDIR - -ROUGH_ASTROMETRY - -PHOTCODE_FILE - -GASTRO_MAX_NSTARS - - -Index: unk/Ohana/doc/www/html/Elixir-DB/gcompare.htm =================================================================== --- /trunk/Ohana/doc/www/html/Elixir-DB/gcompare.htm (revision 4725) +++ (revision ) @@ -1,21 +1,0 @@ - - - - -
-The gcompare program determines compares two lists of objects with X,Y -coordinates and prints the matched entries. A radius of matched is -given, and all pairs of objects between the two lists which lie within -the given radius are printed. The delta coordinates may also be -optionally printer, or the unmatched objects in either the first or -second list. An offset for the center can be optionally applied. - -
-gcompare file1 Nx Ny file2 Nx Ny radius [options] -options: - -d - -m - -n1 - -n2 - -c x y -Index: unk/Ohana/doc/www/html/Elixir-DB/imclean.htm =================================================================== --- /trunk/Ohana/doc/www/html/Elixir-DB/imclean.htm (revision 4725) +++ (revision ) @@ -1,24 +1,0 @@ - - - - -
-The imclean program converts the basic photometry output list from -dophot, sextractor, or gophot, into a standard format for other Elixir -subsystems, with both the table of object data and the complete image -FITS header. - -
-imclean filename.fits filename.obj filtname.cmp -imclean -sex filename.fits filename.sx filename.smp -options: - -h - -help - -v - -coords (ra) (dec) - -p (photcode) - -astrom (file) - -sex - -chad - -key KEYWORD VALUE -Index: /trunk/Ohana/doc/www/html/Elixir-DB/index.htm =================================================================== --- /trunk/Ohana/doc/www/html/Elixir-DB/index.htm (revision 4726) +++ /trunk/Ohana/doc/www/html/Elixir-DB/index.htm (revision 4726) @@ -0,0 +1,18 @@ + + + + +This section describes Elixir Database interface tools provided by +Ohana. The Elixir database consists of the following tables: + +
+In a large data analysis project such as Elixir, there are usually +certain sub-systems which resemble an assembly line: A continuous +stream of objects, each one very similar to the next, enters a +factory. They pass through a series of stages at which some process +occurs, each step along the way being performed in essentially the +same way for each object it encounters. At the end of the assembly +line, a new object (or objects) appears, fashioned from the original +that entered at the other end. + +
+Consider, for example, a scientific analysis of images from the +telescope. Each image is essentially the same as any other, differing +only in detail. A sequence of steps is performed on each image: for +example, detrending, object detection, and astrometry. As the +analysis proceeds, each step performs a transformation on its input +object, creating a new, slightly modified object. The result of the +analysis step may create a new data file, or they may simply alter +some portion of the file provided. + +
+Because each step in the analysis is identical for every image, there +is a regularity to the commands which are executed. For example, +consider an input science image called image01.fits . The series +of commands needed to arrive at the final results might consist of: + +
+detrend image01.fits image01.flt +detect image01.flt image01.dat +astrom image01.dat image01.astro ++ +
+Each step in this analysis sequence produces a new file, and each file +is only different in a portion of the filename. If the input image +had been called image02.fits, we could easily reconstruct the +above sequence of commands, replacing image01 for +image02. + +
+We developed the program `elixir' to make it very easy to define a +sequence of steps which are performed identically for a sequence of +similar objects in a list. Elixir is very flexible: the sequence of +operations for a given implementation are defined in a simple text +configuration file, and can consist of essentially any operations +which fit into the assembly-line model. Each implementation can be +drastically different, and need not operated just on images, but any +anslyis sequence. We call a specific implementation an `elixir', and +usually give the elixir a name relevant to its task. + +
+Because of the assembly-line nature of the elixir model, it is easy to +extend the concept from one computer to a network of computers. Not +only does `elixir' construct the commands as needed, it also executes +those commands on any of a collection of computers, keeping track of +which computers are currently being used and which are currently +free. + +
+
+Figure 1: Elixir node
+
+To visualize the elixir process, consider each of the analysis steps +as a node, as shown in Figure 1. Each node has three queues, an input +queue of pending objects, a 'success' queue, and a 'failure' queue. +Each node represents a single command, such as 'detrend' in the +example above. The node receives as input a word or a set of words +which define the object being analysed. Associated with each node is +a set of rules to generate the complete command, including possible +variations on the input words, as necessary. In the example above, +the input list might simply consist of the input image names, +image01.fits , image02.fits , etc. The rule for the `detrend' +node would construct the command detrend image01.fits +image01.flt . + +
+Each node in Elixir uses its rule to generate a command, such as +detrend image01.fits image01.flt and start its execution. When this +command is finished being executed, the node passes the associated +words to either the `success' or the `failure' queues, based on the +command's exit status. Each success and failure queues are connected +in turn to the pending queue of another node. In this way, a +successful `detrend' command for image01.fits would pass the +word image01.fits to its success queue, which is in turn +connected to the pending queue of the `detect' node. There is a +special node called 'global' which represents the entire elixir +process. The pending, success, and failure queues of the global node +represent the global input and output of the elixir analysis. Thus, +objects are introduced into the process by placing them in the global +input queue. The objects are finished when they reach either the +global success or failure queues (having a status for the entire +process of 'success' or 'failure'). + +
+In order for a node to execute a command, it needs to be given a +machine on which to run the command. Elixir maintains a pool of +available computers. When a node is ready to execute a command, it +requests a machine from the pool of free computers. If none are free, +it waits for a while then tries again. If a computer is free, the +node receives control of the machine, and starts the execution of its +process. The node then monitors the output from the machine, saving +all messages in a log file specific to the current object. +Eventually, the process finishes, and the node passes the object to +the appropriate output queue. At this point, it returns the machine +to the pool of free machines, and grabs the next object from its +pending queue, if any. This process limits the number of executing +processes to the number of available machines. This is a very simple, +but very reliable way of balancing the load on each machine. As long +as none of the analysis steps individually overloads the machine +resources, each machine will be used at an appropriate level. + +
+The machines which are available to the Elixir process are simply +listed in the elixir configuration file. This makes it easy to change +the collection of machines used for a given elixir implementation. In +practice, if the analysis steps for a particular elixir underload each +of the machines available to it, multiple entries for each machine can +be included in the configuration list, increasing the demands on the +individual machines. + +
+
+Figure 2: Example elixir command system
+
+The Elixir configuration file makes if very easy to define a sequence +of commands and the rules for generating the command line arguments. +In the configuration file, most lines consist of keyword / value +pairs. The keyword can consist of any non-white space. The value may +contain any ASCII characters at all, including spaces. If there are multiple +entries of the same keyword, the last one provides the value. +Keywords defined in the configuration file may be referred to +elsewhere by appending a dollar sign: $KEYWORD. The entire +configuration file is loaded before variables such as this are parsed, +so order is not important. + +
+In addition to the keyword / value entries, there are a limited number +of other possible entries. Lines with a leading hash mark (#) are +commented out. A line beginning with the word 'input' is a command to +load additional configuration information from another file. In this +special case, variables used to define the filename must already exist +in the configuration file loaded so far. These details about the +configuration file are relevant to other programs in addition to +`elixir'. + +
+Finally, we come to the portion of the configuration file which +defines the components of the specific elixir implementation. Each +node in the elixir process is defined by a block which looks like +this: + +
+process detrend +detrend.arg 0 detrend +detrend.arg 5 %s &0 +detrend.arg 0 %s.flt BASE(&0) +detrend.success detect +detrend.failure global ++ +
+The first line here, process detrend , defines the node. The +next three lines, beginning with detrend.arg , define the syntax +of the command associated with that node. The first entry is the +program, the next two lines generate the first and second argument to +the program. The executed command ( detrend ) and the name of the +node are not required to be the same. It is particularly important to +note that the order of these lines in the configuration file matters: +the order of the command-line arguments is the order of the lines in +the configuration file. + +
+These lines define how to generate the arguments by providing a +C-style format statement and a set of arguments to the format +statement. Let us first consider the input list. The input list to +Elixir describes a set of objects to be analysed. In our example +above, these consisted of the names of the raw science images: + +
+image01.fits +image02.fits +image03.fits ++ +and so on. In this example, there is only one word on each line to +describe the objects. It is possible to have multiple words to +describe a single object. For example, to define a specific CCD image +in both MEF & SPLIT style images, one could use lines like: + +
+image01.fits X SPLIT +image.fits 00 MEF +image.fits 01 MEF +image.fits 02 MEF +image03.fits X SPLIT ++ +In this example, the first word is a file name, the second defines the +CCD for MEF images (and is ignored for SPLIT), the third identifies +the image type, SPLIT vs MEF. In the elixir configuration file, the +first word on each line is identified by &0, the second by &1, etc. +Thus, in the process detrend example above, the line which reads + detrend.arg 5 %s &0 constructs an argument which just consists +of the first word for each line. + +
+The following line shows the use of the filename manipulation +functions available within the Elixir configuration system. These +functions are only available when defining the Elixir node command +line arguments. In this example, detrend.arg 0 %s.flt +BASE(&0) , the argument is constructed by taking the first word +(&0), stripping off the path and extension from the file name (ie, +taking /path/file.ext and returning 'file'), and appending the string +'.flt' to that word. This de-construction of the filename is provided +by the BASE function. Other string manipulation functions are +available, mostly functions relevant to manipulating file names. Some +of the available functions are: + +
+These configuration formatting lines are somewhat limited compared +with standard C formatting commands: There can only be one word +defined by the format (ie., no white space is allowed). The only +formatting command currently allowed is %s. + +
+The only remaining portion of these format lines which has not yet +been described is the number in the second position. The number in +the second space on each line represents part of the flow control +process. A positive definite number here says that the word formed by +this line is a filename which must exist before the process should be +run. The number tells how many seconds elixir should wait for the +object to appear before giving up on this object. This timeout is +provided for various possible uses. One basic use is to avoid NFS +latency problems. It is not unusual under NFS for a file created on +one machine not to appear on a cross-mounted disk on a second machine +for some tenths of seconds or so. + +
+The final two lines which define this elixir node are used to make the +connection between the node and other nodes. The first, +detrend.success detect , tells elixir to connect the success queue of the +detrend process to the pending queue of the `detect' process. The +second line, detrend.failure global , tells elixir to connect the +failure queue of this process to the global failure queue. Similarly, +the success queue of the last node should be connected to the global +success queue. + +
+There is also a set of configuration entries which define global +concepts for the elixir, including the actions of the global input / +output queue. The required entries of this type of listed here: +
+global.success /path/analysis.success +global.failure /path/analysis.failure +global.source /path/analysis.source +global.msg /path/analysis.msg +global.end /path/analysis.end +global.Nargs 3 +global.logfile 0 %s.log BASE(&0) +global.pending detrend +global.timeout 1200.0 ++ +
+The first two entries, global.success and +global.failure +define the output files for the globals success and failure queues. +When an object lands on either of these queues, the object and the +exit status are written to the named file, and the object is marked as +being completed. The entry global.pending defines the first +node in the process. global.timeout defines a timeout period in +seconds: if a process provides not output for this much time, elixir +decides that it has hung and kills it. The entry global.logfile +defines the rules for generating a log file name for each object, +using a syntax identical to the command-line argument generation +lines. global.end is a file to which elixir writes a collection +of processing statistics after a complete analysis is done. +global.msg provides a way for elixir to communicate with other +processes. Finally, we leave the description of global.source +until after we describe how objects are passed to Elixir. + + Elixir Communication Issues + +
+The input to an elixir process is a list consisting of lines with +words which define the specific objects, such as a list of image +names. There are two ways in which elixir may be presented such a +list. In the simple case, when the program is started, a filename is +given as a command line argument. This file contain a complete list +of names for the elixir run. The lines from this list are loaded and +passed to the global.pending queue, which in turn passes them to the +first node. Once the elixir process has finished with all of the +entries in the file, it exits, and the process is complete. + +
+The other possibility is to use a mechanism we call an input FIFO. In +our implementaton, a FIFO is not a standard UNIX fifo-type special +file. We have avoided the use of true fifos for two reasons. First, +it would be necessary for a special file to be created for each +implementation of elixir (by root), which makes it a non-trival task +to create a new elixir implementation. Second, the data in a standard +UNIX fifo is ephemeral. If the programs on either end of the fifo are +not running, there is no guarantee that the data will remain (the +situation with socketed connections is even worse). Instead, we have +chosen to implement a type of FIFO by using a normal UNIX file which +one program writes to and another reads the data from. To avoid +conflicts between programs, we simply lock the file each time we are +accessing it. Messages are passed to Elixir using this mechanism, and +so are the lines which define new objects. + +
+If elixir is not invoked with a list file on the command line, it +instead monitors the file defined by global.source . Anytime +elixir looks for object entries in this file, the file is locked +first. Then, when the lines have been loaded, the file is cleared. +In this way, a second program can add lines to this file at arbitrary +times without danger of losing any entries, whether or not the +particular elixir is already running. When the external program +writes to the file, it also locks it, so elixir will not load the +entries before it is ready. Then, when it has written the entries, the +file is unlocked, ready for elixir to grab the new list of names. + +
+In this mode, elixir runs continuously, waiting for more entries in +the FIFO file. A mechanism to end the elixir run is made possible by +having elixir recognized a special word in the FIFO. If elixir +encounters the word EOF, it will no longer accept input from the FIFO, +and will exit when all of the entries it has already loaded have been +processed. The same goal can be accomplished by passing the elixir a +message saying 'STOP' via the message FIFO. + +
+Elixir runs like a daemon, in the background with no output directly +to the screen (except for serious errors). It is possible to monitor +the progress of the elixir run by communicating through the message +FIFO. Elixir monitors the message fifo for several specific requests, +and responds to them as they arrive. Typically a request will include +a command, such as STATUS and a filename, where the requested +information should be placed. Other messages include 'STOP' (halt +processing and exit when all objects have been processed), 'KILL' +(halt all processing immediately), and 'TIME' (provide a set of +statistics on process times). + +
+Elixir uses either the rsh or ssh commands to make the connections to +the remote machines. All machines are treated as remote, even the +machine on which elixir is run. Elixir forks off a process which logs +into the remote machine and starts a new shell (csh). The STDIN, +STDOUT, and STDERR connections are used for communication between the +remote shell and elixir. Programs are started by executing the +command in the shell. + +
+The configuration file used by Elixir may also contain configuration +information for a variety of other programs. Elixir saves a copy of +the complete configuration and passes this filename to those programs +which can interpret it with the PTOLEMY environment variable. This +name tells the Elixir programs what configuration file to load. By +specifying this value as an environment variable, it will override +other choices so that elixir can guarantee that the programs it +launches have a consitent, known set of configuration choices. + +
+The other unique feature in the command line aids the process control.
+Every command is followed by an echo of the words "PROCESS DONE". As
+the programs run, elixir monitors the output stream looking for three
+special phrases. One is this 'PROCESS DONE' phrase. Another is the
+word "SUCCESS" and the third is the word "ERROR". By looking for
+combinations of these words, elixir can determine if the program ended
+successfully, failed, or if the computer crashed. To interact well
+with Elixir, programs should send the correct word "SUCCESS" or
+"ERROR" on exit. If necessary, one can wrap the program in a shell
+which monitors the exit status and sends the correct word. If this is
+not possible, it is always possible to assume the process always ends
+successfully and include these words as an echo on the command line.
+
+
+
+
+ A short note about our use of filelocks . We have implemented a
+somewhat complex type of file lock mechanism. We do not want to use a
+standard NFS implemented lock, particularly for the locks on our
+database files. The problem the standard filelocking mechanism under
+UNIX/NFS is that the lock only exists if the program holding the lock
+is running. This is insufficient to maintain data integrity.
+Consider a database which consists of several distinct files. A
+particular write operation to the database may need to manipulate more
+than one file, and it needs to be sure those files are not also
+changed by another program in the meantime. To avoid this, it should
+set a lock (on the files or on the whole database). Then it should
+write to the files, then it should clear the lock. Consider, though,
+what would happen in the program were to crash or be killed after
+writing the first file, but before writing the second. The data in
+the two would be inconsistent. At that point, if a second program
+tried to write to the database, it could easily corrupt the data,
+making it rather difficult to correct the problem. With the standard
+UNIX/NFS locks, the lock is ephemeral - it only exists as long as the
+program is running (and certainly only while the machine is up). In
+this example, it is easy to imagine that, by the time the second
+program comes along, the files are out of sync but the lock is no
+longer set. We wanted a lock that would be guaranteed to exist until
+it was actively cleared, either by the program in its usual way, or by
+a person (or program) which has found the problem and fixed it.
+
+
+To implement such a lock, we create a lock in two stages. The file
+that is being locked (ie, filename) is associated with the lockfile of
+the form .filename.lck. The lockfile is locked with NFS style locks.
+Then the word BUSY is written to the lockfile. At this point the NFS
+lock doesn't matter, and can be cleared or left. Even if the program
+dies, the word BUSY remains to prevent another program from taking the
+lock. When it is time to clear the lock, the file is either deleted
+or the word IDLE is written to it.
+
+
+mkdetrend is the interface to the Elixir detrend creation system. + +
+All date/times are in the form YYYY/MM/DD,HH:MM:SS, with HH:MM:SS optional. + +
+By default, commands apply to the currently active camera/run, but +these may be specified on the command line with the -camera (camera) +and -run (run) flags. + +
| create (camera) (run) (start) (stop) | create a new mkdetrend run for the given camera, normally automatically performed by ert. |
| create run (runid) | create a new mkdetrend run based on the mkrun table information. |
| config (camera) (run) | set the current active config |
| state | show the state of the active config |
| init | start the init stage of mkdetrend processing |
| run | start the main processing, or re-processing |
| reg | register the completed images in the detrend database |
| clean | clean the camera/run directories; recovery from this command will require a complete reprocessing. |
| reset (level) | reset the configs. if level is 'hard', all will be reset. if level is 'update', configs may be reset to 'init' or 'update', depending on their state. |
| update | perform an update run (identify new images, process residuals, but do not generate master). |
| auto (cmd) | automatic processing commands |
| dup (config) | duplicate the given config |
| del (config) | delete the given config |
| def (config) (start) (stop) | set the start & stop times for the given config |
| set (config) (state) | manually set the config state |
| list.init | run just the list.init stage |
| split | run just the split stage |
| flips | run just the flips stage |
| norm | run just the norm stage |
| scat | run just the scat stage |
| merge | run just the merge stage |
| update.list | run just the update.list stage |
| update.stats | run just the update.stats stage |
| htmldup | |
| htmldef | |
| htmldel | |
| htmlmod | |
| htmlkeep | |
| htmlconfig | |
| html1 | |
| html2 | |
| html3 |
| dads | |
| dads.top | |
| meval | |
| eval | |
| fix.masters | |
| check.splits |
+mkfringe is the interface to the Elixir fringe creation system. + +
+All date/times are in the form YYYY/MM/DD,HH:MM:SS, with HH:MM:SS optional. + +
+By default, commands apply to the currently active camera/run, but +these may be specified on the command line with the -camera (camera) +and -run (run) flags. + +
| create (camera) (run) (start) (stop) | create a new mkfringe run for the given camera, normally automatically performed by ert. |
| create run (runid) | create a new mkfringe run based on the mkrun table information. |
| mkconfig (camera) (run) | create an mkfringe config table based on an existing mkdetrend date range |
| config (camera) (run) | set the current active config |
| state | show the state of the active config |
| init | start the init stage of mkfringe processing |
| run | start the main processing, or re-processing |
| reg | register the completed images in the detrend database |
| map | start the map run (requires manually setting state to map) |
| map.reg | register mode maps |
| clean | clean the camera/run directories; recovery from this command will require a complete reprocessing. |
| dup (config) | duplicate the given config |
| del (config) | delete the given config |
| def (config) (start) (stop) | set the start & stop times for the given config |
| set (config) (state) | manually set the config state |
| list.init | run just the list.init stage |
| list.reinit | run just the list.reinit stage |
| detrend | run just the detrend stage |
| merge | run just the merge stage |
| mkrough | run just the mkrough stage |
| defringe | run just the defringe stage |
| mksmooth | run just the mksmooth stage |
| regimage | run just the regimage stage |
| htmldup | |
| htmldef | |
| htmldel | |
| htmlmod | |
| htmlkeep | |
| htmlconfig | |
| html1 | |
| html2 | |
| html3 | |
| htmlmodes | |
| htmlmaps | |
| htmlmapkeep |
| dads | |
| dads.top | |
| eval |
+The nightd daemon is a easily-customized daemon which performs a +defined set of tasks on a nightly basis. The program behavior is +defined by the resource file, loaded at the start of execution. The +program can have any name, and loads the resource file with the name +~/.programrc; ie, the implementation used by elixir to control the +night elixir real-time systems is called 'ert' and it loads the file +~/.ertrc. + +
+HOME /h/skyprobe + +DATA_PATH $HOME/data +PID_FILE $HOME/.skyprobe.pid +LOG_FILE $HOME/sp_daemon.log + +CCD_TEMP -20 +EXPTIME 30 + +INIT_COMMAND sp_command cool $CCD_TEMP +INIT_COMMAND sp_command init $DATA_PATH/&DATE +MAIN_COMMAND sp_command expose $EXPTIME $DATA_PATH/&DATE/sp_&DATE_&TIME.fits +DONE_COMMAND sp_command warm + +NIGHT_START 18:00 +NIGHT_STOP 06:00 + +PERIOD 60 +TIMEOUT 300 ++ +
+Above is shown a typical nightd configuration script. The nightd +configuration defines commands and execution time scales. The start +and end times of the night are defined by the entries NIGHT_START and +NIGHT_STOP. The nightd configuration script defines three classes of +commands: INIT, MAIN, DONE. The INIT commands are executed in the +order listed in the configuration script at the start of the night, +while the DONE commands are executed at the end of the night. The +MAIN commands are executed on a regular basis from START to STOP using +the interval defined by PERIOD (seconds). The program monitors these +processes and checks for completion within the TIMEOUT period; +otherwise, the command is sent the kill signal. + +
+The entries PID_FILE and LOG_FILE are required entries. The PID_FILE +stores the process id, user and machine for the given nightd +implementation, and prevents multiple intances of the same process. +The LOG_FILE is used for all error messages. The other entries in the +configuration script define variables to be use elsewhere in the +script. There are a few special variables: \&DATE, \&TIME, ???, which +are expanded by nightd before the execution. + +
+The nightd program takes several possible arguments on the command +line: + +
+nightd start +nightd stop +nightd status +nightd config ++ +
+The 'start' command starts up the nightd program. Currently, nightd +does not fork itself into the background, so it is necessary to place +it in the background manually (nightd start &). It is not necessary +to redirect the output; nightd will send all data to LOG_FILE if it +can be opened and written to. On start, nightd will check for the +existence of the PID_FILE and give an error to stdout (not LOG_FILE) +if it exists; only one implementation may run at a time. Currently, +nightd does not check for the existence of the process identified in +the PID_FILE. It is necessary for the user to confirm that such a +process exists on the named machine. + +
+The 'stop' command halts execution of the given nightd program. It +uses the information in the PID_FILE to remotely log onto the machine +where the process is being executed and send the STOP signal. Nightd +will give an error if there is no PID_FILE, implying no currently +running nightd. It is necessary to have rsh access between machines +for this to work. + +
+The status command shows the pid information for the currently running +nightd, or says that it is not running. + +
+ Index: /trunk/Ohana/doc/www/html/Elixir-Tools/applyscat.htm =================================================================== --- /trunk/Ohana/doc/www/html/Elixir-Tools/applyscat.htm (revision 4726) +++ /trunk/Ohana/doc/www/html/Elixir-Tools/applyscat.htm (revision 4726) @@ -0,0 +1,3 @@ +applyscat takes a raw master flat-field image and a scatter correction +frame and constructs a corrected flat-field image. + Index: /trunk/Ohana/doc/www/html/Elixir-Tools/fhead.htm =================================================================== --- /trunk/Ohana/doc/www/html/Elixir-Tools/fhead.htm (revision 4726) +++ /trunk/Ohana/doc/www/html/Elixir-Tools/fhead.htm (revision 4726) @@ -0,0 +1,12 @@ +
+ fhead (fitsfile) ... [-x N] + + print out the FITS header, adding return chars to the end of each + line, stopping at the END (not printed). By default, the primary + header unit is printed. If the -x is provided the Nth extension's + header unit is printed, with 0 being the first extension after the + PHU. Multiple files may be provided, in which case the headers are + printed in sequence, with tags between the headers. + + +Index: /trunk/Ohana/doc/www/html/Elixir-Tools/fields.htm =================================================================== --- /trunk/Ohana/doc/www/html/Elixir-Tools/fields.htm (revision 4726) +++ /trunk/Ohana/doc/www/html/Elixir-Tools/fields.htm (revision 4726) @@ -0,0 +1,10 @@ +
+ fields (key) ... [-x N] + + Read from stdin a list of file names. For each file name, print in + sequence the value of the given FITS header keywords. Any number of + keys may be present. By default, the key/values are taken from + primary header unit. If the -x is provided the Nth extension's + header unit is used instead, with 0 being the first extension after + the PHU. +Index: /trunk/Ohana/doc/www/html/Elixir-Tools/fits_insert.htm =================================================================== --- /trunk/Ohana/doc/www/html/Elixir-Tools/fits_insert.htm (revision 4726) +++ /trunk/Ohana/doc/www/html/Elixir-Tools/fits_insert.htm (revision 4726) @@ -0,0 +1,17 @@ +
+ fields (file) (header) [-X N] [-comment N line] + + Add header entries to the given file. The header information to be + inserted is read from the provided header file, which contains + abbreviated FITS header lines: each line must consist of a keyword + and data value, following the FITS conventions, but lines are broken + with returns, and there are no required keys or minimum number of + lines. By default, the primary header unit is used, but if the -X + flag is used, the Nth extension is used instead, where 0 corresponds + to the first extension after the PHU. If the -comment option is + provided, the Nth comment is replaced with the provided line. By + default, this function will search for blank lines and overwrite the + data in-situ. However, if it is necessary to extend the header, a + new file will be written. + +Index: /trunk/Ohana/doc/www/html/Elixir-Tools/ftable.htm =================================================================== --- /trunk/Ohana/doc/www/html/Elixir-Tools/ftable.htm (revision 4726) +++ /trunk/Ohana/doc/www/html/Elixir-Tools/ftable.htm (revision 4726) @@ -0,0 +1,24 @@ +
+ ftable (filename) [options] + + options: + -x N: operate on extension N (0 is default) + -n EXTNAME: operate on named extension (incompatible with -x) + -row N: print row number N + -column n: print column named n + -ncolumn N: print column number N + -list: print extension names + -layout print the table layout (fields) + + Print out FITS table data, or FITS table header data. By default, + the entire FITS table is printed. Command-line options may be used + to restrict the output to a single column or single row. Additional + options may be used to list all extension names or to print out the + complete table fields for the selected extension. By default, the + key/values are taken from the first extension. If the -x is + provided the Nth extension's header unit is used instead, with 0 + being the first extension after the PHU. If the -n option is + provided, the named extension (matching keyword EXTNAME) is used. + + +Index: /trunk/Ohana/doc/www/html/Elixir-Tools/gastro.htm =================================================================== --- /trunk/Ohana/doc/www/html/Elixir-Tools/gastro.htm (revision 4726) +++ /trunk/Ohana/doc/www/html/Elixir-Tools/gastro.htm (revision 4726) @@ -0,0 +1,69 @@ + + + + +
+The gastro program determines the astrometric transformation for an +image based on the cmp/smp file. This file contains both the table of +object data and the complete image FITS header. Using the header +astrometric information as a starting point, gastro loads the +reference astrometry objects appropriate for the region and determines +the matching objects between the image and the reference. These +objects are used, with iteration to improve the sample, to determine +the astrometric transformation with up to 3rd order polynomials. + +
+gastro filtname.cmp +options: + -h + -help + -v + -p (photcode) + -plot + -maglims + -nstars + -fx + -fy + -coords (ra) (dec) + -dump + -mdmp + -cdmp + -loneos + +gastro configuration variables: +OFFSET_RADIUS - max allowed offset in gcenter +MIN_MATCHES - min number of matched stars for linear fit +MINIMUM_RADIUS - target matching radius in gfit iterations +MAX_ERROR - maximum allowed error in solution +MAX_NONLINEAR - maximum angle between axes +MAX_PRECISE - unused? +DEFAULT_RADIUS - unused? + +ROUGH_ASTROMETRY - source of initial astrometry terms + +CCD_PC1_1 - initial guess pc1_1 +CCD_PC2_2 - initial guess pc2_2 +CCD_PC1_2 - initial guess pc1_2 +CCD_PC2_1 - initial guess pc2_1 +ASEC_PIX - initial guess arcsec / pix + +POLAR_ALIGNMENT - provide polar alignment of telescope mount? +POLAR_AXIS_RA - RA of telescope polar axis +POLAR_AXIS_DEC - DEC of telescope polar axis +RA_OFFSET - RA offset +DEC_OFFSET - DEC offset (degenerate?) + +NFIELD - select stars from region NFIELD x detector size +NPOLYTERMS - number of orders to allow +MMIN - minimum magnitude of allowed star +ROT_ZERO - zero of tested rotation range +dROT - rotation step size +NROT - number of rotation tests = 2NROT + 1 +GSCFILE - name of HST GSC table file +GSCDIR - name of HST GSC data directory +LONEOS_REGIONS - table of location coordinates +USNO_CDROM - name of USNO data directory +ASTRO_REFCAT - reference catalog format to read +CATDIR - name of ptolemy database +PHOTCODE_FILE - table of photcodes +Index: /trunk/Ohana/doc/www/html/Elixir-Tools/gastro2.htm =================================================================== --- /trunk/Ohana/doc/www/html/Elixir-Tools/gastro2.htm (revision 4726) +++ /trunk/Ohana/doc/www/html/Elixir-Tools/gastro2.htm (revision 4726) @@ -0,0 +1,68 @@ + + + + +
+gastro2 is the successor to gastro. The gastro2 program determines +the astrometric transformation for an image based on the cmp/smp file. +This file contains both the table of object data and the complete +image FITS header. Using the header astrometric information as a +starting point, gastro2 loads the reference astrometry objects +appropriate for the region and determines the matching objects between +the image and the reference. These objects are used, with iteration +to improve the sample, to determine the astrometric transformation +with up to 3rd order polynomials. + +
+gastro filtname.cmp +options: + -h + -help + -v + -p (photcode) + -plot + -maglims + -nstars + -fx + -fy + -coords (ra) (dec) + -dump + -mdmp + -cdmp + -loneos + +gastro2 configuration variables: +OFFSET_RADIUS - unused +MIN_MATCHES - unused +DEFAULT_RADIUS - unused +MINIMUM_RADIUS - +MAX_ERROR - +MAX_NONLINEAR - +MAX_PRECISE - +CCD_PC1_1 - +CCD_PC2_2 - +CCD_PC1_2 - +CCD_PC2_1 - +ASEC_PIX - +NFIELD - +NPOLYTERMS - +ROT_ZERO - +dROT - +NROT - +POLAR_ALIGNMENT - +GSCFILE - +GSCDIR - +2MASS_DIR - +POLAR_AXIS_RA - +POLAR_AXIS_DEC - +RA_OFFSET - +DEC_OFFSET - +LONEOS_REGIONS - +USNO_CDROM - +ASTRO_REFCAT - +CATDIR - +ROUGH_ASTROMETRY - +PHOTCODE_FILE - +GASTRO_MAX_NSTARS - + +Index: /trunk/Ohana/doc/www/html/Elixir-Tools/gcompare.htm =================================================================== --- /trunk/Ohana/doc/www/html/Elixir-Tools/gcompare.htm (revision 4726) +++ /trunk/Ohana/doc/www/html/Elixir-Tools/gcompare.htm (revision 4726) @@ -0,0 +1,21 @@ + + + + +
+The gcompare program determines compares two lists of objects with X,Y +coordinates and prints the matched entries. A radius of matched is +given, and all pairs of objects between the two lists which lie within +the given radius are printed. The delta coordinates may also be +optionally printer, or the unmatched objects in either the first or +second list. An offset for the center can be optionally applied. + +
+gcompare file1 Nx Ny file2 Nx Ny radius [options] +options: + -d + -m + -n1 + -n2 + -c x y +Index: /trunk/Ohana/doc/www/html/Elixir-Tools/glockfile.htm =================================================================== --- /trunk/Ohana/doc/www/html/Elixir-Tools/glockfile.htm (revision 4726) +++ /trunk/Ohana/doc/www/html/Elixir-Tools/glockfile.htm (revision 4726) @@ -0,0 +1,22 @@ +
+ glockfile (filename) (type) (duration) + + lock the given file, using the Elixir locking functions, for the + specified number of seconds. The lock type may be SOFT, XCLD, or + HARD. These have the following meanings: + + SOFT : read-only lock; will not block a SOFT lock. will only last + for the duration of the program. + + XCLD : write lock; blocks, and is blocked by, all lock types. will + only last for the duration of the program. + + HARD : write lock; blocks, and is blocked by, all lock types. If + the program is interrupted, the lock will remain until cleared by + hand (by deleting the file with the name .filename.lck, where + 'filename' is replaced the the name of the locked file. + + + + +Index: /trunk/Ohana/doc/www/html/Elixir-Tools/imclean.htm =================================================================== --- /trunk/Ohana/doc/www/html/Elixir-Tools/imclean.htm (revision 4726) +++ /trunk/Ohana/doc/www/html/Elixir-Tools/imclean.htm (revision 4726) @@ -0,0 +1,24 @@ + + + + +
+The imclean program converts the basic photometry output list from +dophot, sextractor, or gophot, into a standard format for other Elixir +subsystems, with both the table of object data and the complete image +FITS header. + +
+imclean filename.fits filename.obj filtname.cmp +imclean -sex filename.fits filename.sx filename.smp +options: + -h + -help + -v + -coords (ra) (dec) + -p (photcode) + -astrom (file) + -sex + -chad + -key KEYWORD VALUE +Index: /trunk/Ohana/doc/www/html/Elixir-Tools/index.htm =================================================================== --- /trunk/Ohana/doc/www/html/Elixir-Tools/index.htm (revision 4726) +++ /trunk/Ohana/doc/www/html/Elixir-Tools/index.htm (revision 4726) @@ -0,0 +1,9 @@ + + + + +This section describes basic Elixir tools provided by Ohana. These +include a set of FITS file interaction programs (fields, fhead, +ftable, fits_insert), a few data analysis tools (gastro, gastro2, +mosastro, imclean), and a variety of other useful for astronomy and +data-handling programs. Index: /trunk/Ohana/doc/www/html/Elixir-Tools/list_astro.htm =================================================================== --- /trunk/Ohana/doc/www/html/Elixir-Tools/list_astro.htm (revision 4726) +++ /trunk/Ohana/doc/www/html/Elixir-Tools/list_astro.htm (revision 4726) @@ -0,0 +1,20 @@ +
+ list_astro + + read a series of lines consisting of 4 columns. the columns + represent the X,Y coordinate of a series of objects in first one + coordinate frame, then in a second coordinate frame. list_astro + will return the linear transformation (and errors) from the first + frame to the second frame in the form: + + X0 X1 X2 dX + Y0 Y1 Y2 dY + + where + + X = X0 + X1*x + X2*y + Y = Y0 + Y1*x + Y2*y + + and dX and dY are the errors in the output coordinate frame. + +Index: /trunk/Ohana/doc/www/html/Elixir-Tools/medianfilter.htm =================================================================== --- /trunk/Ohana/doc/www/html/Elixir-Tools/medianfilter.htm (revision 4726) +++ /trunk/Ohana/doc/www/html/Elixir-Tools/medianfilter.htm (revision 4726) @@ -0,0 +1,13 @@ +
+ medianfilter output (fmin) (fmax) + + Read a series of image names from standard input. The input images + must all be the same dimensions, and are expected to correspond to + matching pixels. For each pixel, the data values are sorted. The + data values within the range (fmin) to (fmax) are selected, where + (fmin) and (fmax) are fractions between 0 and 1, and represent the + fraction of the sorted stack of pixels. The mean of the selected + data within this range is then calculated. The output file consists + of pixels with these output values. + +Index: /trunk/Ohana/doc/www/html/Elixir-Tools/mktemp.htm =================================================================== --- /trunk/Ohana/doc/www/html/Elixir-Tools/mktemp.htm (revision 4726) +++ /trunk/Ohana/doc/www/html/Elixir-Tools/mktemp.htm (revision 4726) @@ -0,0 +1,12 @@ +
+ mktemp [template] + + provides the mktemp function for systems which do not provide such a + UNIX command tool. mktemp constructs the name of a unique file and + returns it on stdout. By default, the filename will be + /tmp/tmp.XXXXXX where XXXXXX is substituted with a string of + characters to enforce uniqueness. If the template filename is + provided, consisting of a valid filename ending in .XXXXXX, then + this template is used to construct the temporary file. + +Index: /trunk/Ohana/doc/www/html/Elixir-Tools/mosastro.htm =================================================================== --- /trunk/Ohana/doc/www/html/Elixir-Tools/mosastro.htm (revision 4726) +++ /trunk/Ohana/doc/www/html/Elixir-Tools/mosastro.htm (revision 4726) @@ -0,0 +1,12 @@ +
+ + mosastro () + + perform mosaic astrometry on a collection of FITS images. The input + consists of SMP files (see gastro) which have valid astrometric + solutions. Mosastro determines a complete mosaic astrometry + solution, including a polynomial term for the telescope optical + distortion and individual polynomials for each chip. + + +Index: /trunk/Ohana/doc/www/html/Elixir-Tools/precess.htm =================================================================== --- /trunk/Ohana/doc/www/html/Elixir-Tools/precess.htm (revision 4726) +++ /trunk/Ohana/doc/www/html/Elixir-Tools/precess.htm (revision 4726) @@ -0,0 +1,10 @@ +
+ precess (in) (out) + + read a series of RA,DEC coordinate pairs (in decimal degrees) and + precess them from the (in) equinox to the (out) equinox. Equinoxes + are decimal years in the J2000 system, or in the B1950 system if + prepended by 'B'. B and J may be used to substitude for B1950 and + J2000 respectively. + +Index: /trunk/Ohana/doc/www/html/Elixir-Tools/radec.htm =================================================================== --- /trunk/Ohana/doc/www/html/Elixir-Tools/radec.htm (revision 4726) +++ /trunk/Ohana/doc/www/html/Elixir-Tools/radec.htm (revision 4726) @@ -0,0 +1,11 @@ +
+ radec [-hh | -hms] + + read a series of coordinate pairs and convert between decimal and + sexigesimal representations. If the option -hh is given, the input + is expected to be decimal degrees and the output will be sexigesimal + (hours minutes seconds). If the option -hms is given, the input is + expected to be sexigesimal and the output will be decimal degree. + Whitespace must be used for all separators. + +Index: unk/Ohana/doc/www/html/developer/includes.htm =================================================================== --- /trunk/Ohana/doc/www/html/developer/includes.htm (revision 4725) +++ (revision ) @@ -1,5 +1,0 @@ - - - - -Sorry! The page you requested is not yet available. Index: unk/Ohana/doc/www/html/home.htm =================================================================== --- /trunk/Ohana/doc/www/html/home.htm (revision 4725) +++ (revision ) @@ -1,59 +1,0 @@ - - - - -
-Ohana is the collection of programs written by Eugene Magnier which -form a major portion of the Elixir software. These pages document the -user interface to the various Ohana programs. - -
-Within the Ohana software system, there are several types of programs -and program groups. There are basic, independent C programs, groups -of related C programs which address a common Elixir system, C programs -which run as daemons, and C programs which provide an interactive -command language environment. There are also a number of perl, csh, -and tcl scripts. - -
-The top-level of the Ohana software tree includes the Makefile, a -system-dependent configuration file, and the directories src, bin, -lib, and include. Within the bin, lib, and include directories, there -are subdirectories by computer architecture. These allow a -segregation of the architecture dependent binary files, and provide -some flexibility for working will various types of hardware. The -Makefiles require the environment variable ARCH to be set to make -complilation choices and to place the binaries in their appropriate -locations. The ohana user may choose to include this directory in -their path, in which case they should define the variable in their -resource files (.cshrc / .bashrc / etc) using the sample given in -getarch, and set the pathname to the value ohana/bin/$ARCH, which will -then correctly expand depending on what machine the user is one. An -alternative is to treat the ohana tree as the program development -tree, and to export the binaries to an architecture-dependent external -location. - -
-Within the src directory are all of the program and library -source-code subdirectories. Many of the programs are contained within -their own unique src subdirectory, but there are a few execeptions. -First, the perl, csh, and tcl scripts are collected together in perl, -csh, and tcl subdirectories. Second, there are a variety of simple, -small C-programs in the directory misc. Third, there is a collection -of related C programs which provide user interfaces to the Elixir -databases. These are collected together in the imregister-3.0 -subdirectory. - -
-Each of the program and library subdirectories contain their own src, -bin, and include directories. When the programs are compiled, the C -files in src are compiled to .o files with names which include the -$ARCH value: src/foo.c -> src/foo.linux.o. The output executable is -written to the bin directory with a name which also includes the -binary: bin/foo.linux. These are then installed in the appropriate -ohana/bin/ARCH directories with 'make install'. In the case of the -program directories which include multiple C programs, the make file -takes commands of the form 'make program', 'make program.install', -'make program.clean', etc, which perform the requested operation on -the specific program. The generic commands 'make' and 'make install' -will operate on the complete collection of programs. Index: /trunk/Ohana/doc/www/html/sequence.idx =================================================================== --- /trunk/Ohana/doc/www/html/sequence.idx (revision 4725) +++ /trunk/Ohana/doc/www/html/sequence.idx (revision 4726) @@ -1,5 +1,7 @@ -home.htm -subsystems -components -perl-scripts +Elixir-System +Elixir-Tools +Elixir-DB +Opihi-Programs +IPP-subsystems +DVO developer Index: /trunk/Ohana/doc/www/html/template.htm =================================================================== --- /trunk/Ohana/doc/www/html/template.htm (revision 4725) +++ /trunk/Ohana/doc/www/html/template.htm (revision 4726) @@ -14,9 +14,9 @@
+|
|  Ohana Home | Elixir Home | CFHT Home | Ohana Home | Elixir Home | CFHT Home | |