Changeset 13869
- Timestamp:
- Jun 18, 2007, 5:34:03 PM (19 years ago)
- File:
-
- 1 edited
-
trunk/doc/manual/manual.tex (modified) (7 diffs)
Legend:
- Unmodified
- Added
- Removed
-
trunk/doc/manual/manual.tex
r13847 r13869 1 %%% $Id: manual.tex,v 1. 7 2007-06-15 20:52:48eugene Exp $1 %%% $Id: manual.tex,v 1.8 2007-06-19 03:34:03 eugene Exp $ 2 2 \documentclass[panstarrs,spec]{panstarrs} 3 3 … … 275 275 processing. \note{halt does not current stop pcontrol}. 276 276 277 \subsubsection{ippTools} 277 \subsubsection{ippTools \& ippScripts} 278 279 The IPP uses a \code{mysql} database to keep track of the data to be 280 analysed and the results of analysis steps. The IPP user interacts 281 with this database via a set of programs called \code{ippTools} and 282 \code{ippScripts}. The difference between these is that the 283 \code{ippTools} are somewhat lower-level programs to interact directly 284 with the database, while the ippScripts perform a more complex 285 operation, sometimes wrapping multiple calls to commands within 286 \code{ippTools}. 287 288 \begin{itemize} 289 \item \code{ipp_serial_inject.pl} : inject data into the IPP database. 290 \item \code{dettool -definebyquery} : define a new detrend run. With 291 this command, the user defines a set of criteria which define a 292 collection of input images to be used to generate a detrend image. 293 The parameters which define the output detrend image also 294 specified. 295 \item \code{dettool -updatedetrun} : manually set the state of a 296 detrend run. 297 \item \note{extend this list...} 298 \end{itemize} 299 300 The ippTools accept a common set of command-line arguments which 301 modify their behavior: 302 \begin{itemize} 303 \item \code{-pretend} : show the expected result, but do not apply the 304 results to the database 305 \item \code{-simple} return results with one line for each output 306 component. Without this flag, the results are returned with the 307 versbose, but self-documenting, psMetadataConfig format. 308 \item \code{-dbname} specify the database to use 309 \item \note{extend this list...} 310 \end{itemize} 278 311 279 312 \subsection{Operational Scenarios} 280 313 281 314 \subsubsection{Reducing an Observing Run} 315 316 For a single observing run, the user will typically have data from 317 several nights, both science and raw detrend images. The following 318 steps illustrate the analysis with data from a sample observing run. 319 We assume the user has already installed the IPP software and the 320 external software (mysql, apache, php, etc), set up the configuration 321 for the camera, defined a project for this analysis, started pantasks, 322 and loaded the analysis tasks. This example shows the steps to build 323 the detrend data and process the science data. 324 325 The first step is to inject all of the data into the IPP database with 326 the command \code{ipp_serial_inject.pl}. It is possible to define 327 abstract data storage paths in the user's \code{.ipprc} file in the 328 \code{DATAPATH} section. Each line gives the relationship between an 329 abstract data location and the real-world UNIX path to that data. The 330 script \code{ipp_serial_inject.pl} will interpret the location of the 331 data in terms of the DATAPATH hierarchy when identifying the data for 332 the database. When injecting the data, it is convenient to define a 333 working directory with the \code{--workdir} option to 334 \code{ipp_serial_inject.pl}. The science processing steps will use 335 this location to store the output data products. 336 337 % complete command here 338 339 As the images are injected, they will be placed in the table of 340 \code{new} exposures. If \code{pantasks} is running with the modules 341 loaded, the images will be processed for registration. In this step, 342 a minor analysis of the image statistics and an examination of the 343 header information is performed, and the results used to provide 344 further information about the images in the database. As images are 345 registered, they migrate from the \code{new} to the \code{raw} 346 tables. These tables can be view in the \code{ippMonitor} under the 347 \code{Load & Setup} pages. 348 349 Once the images have been injected, the user will want to create, in 350 order, bias, dark, shutter, flat, and fringe frames. As these are 351 created, they may be used to generate the next level of image. It is 352 important not to define, eg, a flat run before the lower-precedence 353 elements are defined. At the moment, it is not possible to define a 354 detrend analysis which blocks until a previous detrend analysis is 355 complete. To start, define a bias based on a query to the database: 356 357 % example command hrere 358 359 \code{dettool -dbname name -definebyquery -det_type bias etc} 360 361 For a small observing run, it is probably possible to include all bias 362 images in the initial pass. IPP will iteratively reject complete 363 input images which are outliers from the ensemble, as well as 364 individual pixels. In the \code{ippMonitor}, rejected images will be 365 greyed out in the residual pages. Examine the resulting residual 366 images. If there are patterns to the residuals, it may be necessary 367 to define subgroups, perhaps by time or ccd temperature. For example: 368 369 % example command here. 370 371 After a bias or set of biases are defined, follow the same process for 372 a dark frame. It may be necessary to supply a non-linear dark current 373 correction (perhaps one for each amplifier or chip). The script 374 \code{ipp_darkstats.pl} can be used to examine this trend. 375 376 If a shutter correction is necessary, make sure to obtain data which 377 can be used to generate the correction: a series of flat-field images 378 with a range of exposure times, particularly near the short end of the 379 range. If the shutter correction will be skipped, set the SHUTTER 380 entries in the camera's ppImage.config file to FALSE. 381 382 A flat-field image is next. Initially, we must define a raw 383 flat-field image, from dome or twilight flat-field images. Below, we 384 will discuss the generation of a flat-field correction image from 385 dithered science images. Do not forget to specify the filter for each 386 flat-field image 387 388 % example command. 389 390 Up to now, we have been ignoring the bad pixel mask. At this point, 391 the user may generate a bad pixel mask from the collection of 392 processed flat-field images. Use the script \code{UNKNOWN} to build a 393 mask image. Turn on the use of the mask by setting \code{MASK} to 394 true in the \code{ppImage.config} file. It is probably a good idea to 395 now re-run the previous stages with the mask applied: this will result 396 in better statistics for the residual images. 397 398 If certain filters require a fringe image, the user may inform the IPP 399 of this fact by setting the FRINGE.FILTERS entry in the 400 \code{ppImage.config} file. Use a set of night-time sky images to 401 generate a fringe frame. \note{how to specify more than one fringe 402 mode?} 403 404 Activate the chip-level science analysis tasks in pantasks: chip.on. 405 With this off, no data will be processed before the detrend images are 406 ready. Once this is turned on, the science images will start to be 407 processed \note{discuss blocks; re-queue; versions}. 408 409 \note{specifying the dvo output database} 282 410 283 411 \subsubsection{Pipeline Reduction : CFHT Queue Runs} … … 498 626 \subsection{psconfig} 499 627 628 \note{use the write-up in psconfig for this section} 629 630 \begin{verbatim} 500 631 * pscheckperl : search for and install, if needed, external Perl modules 501 632 * pschecklibs : search for and install, if needed, external C libraries … … 504 635 * psdist : build IPP distributions (requires CVS access) 505 636 * tagsets : tables defining the C and Perl components to be built 637 \end{verbatim} 506 638 507 639 The IPP is a large and complex software system. A major goal of the … … 1339 1471 \subsection{missing libX11.so} 1340 1472 1341 RedHat RHEL 3 & 4 (likely other RedHat variants as well) for \emph{amd64} seem1473 RedHat RHEL 3 \& 4 (likely other RedHat variants as well) for \emph{amd64} seem 1342 1474 to often be installed without a \code{libX11.so} under 1343 1475 \code{/usr/X11R6/lib64/}. This will cause 64bit builds trying to link against … … 1347 1479 yourself. Eg.. 1348 1480 1349 \begin{verbati um}1481 \begin{verbatim} 1350 1482 su - 1351 1483 cd /usr/X116/lib64 1352 1484 ln -s libX11.so.6.2 libX11.so 1353 \end{verbati um}1485 \end{verbatim} 1354 1486 1355 1487 or with \code{sudo}: 1356 1488 1357 \begin{verbati um}1489 \begin{verbatim} 1358 1490 cd /usr/X116/lib64 1359 1491 sudo ln -s libX11.so.6.2 libX11.so 1360 \end{verbati um}1492 \end{verbatim} 1361 1493 1362 1494 … … 1365 1497 installing IPP software. Note that \code{\$prefix/lib} will also need to be manually added the enviroment variable \code{LD_LIBRARY_PATH} if your not using jhbuild. E.g for ksh/bash users: 1366 1498 1367 \begin{verbati um}1499 \begin{verbatim} 1368 1500 export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/[foo]/[yourinstallprefix]/lib 1369 \end{verbati um}1501 \end{verbatim} 1370 1502 1371 1503
Note:
See TracChangeset
for help on using the changeset viewer.
