Changeset 6055 for trunk/doc/dvo/dvo.tex
- Timestamp:
- Jan 19, 2006, 12:58:19 AM (21 years ago)
- File:
-
- 1 edited
-
trunk/doc/dvo/dvo.tex (modified) (7 diffs)
Legend:
- Unmodified
- Added
- Removed
-
trunk/doc/dvo/dvo.tex
r6035 r6055 19 19 \pagenumbering{arabic} 20 20 21 \subsection{Photometric systems and the DVO Photcodes} 21 \section{Overview} 22 23 DVO, the Desktop Virtual Observatory, is a software system which 24 stores data related to astronomical objects derived from various 25 sources, and provides mechanisms to related multiple detections 26 together as astronomical objects. DVO deals with two related 27 concepts: {\em objects} and {\em detections}. The {\em objects} are 28 descriptions of astronomical objects while the {\em detections} are 29 the specific measurements of those objects, typically measured from 30 astronomical images. A collection of {\em detections} may be used to 31 derive average quantities which describe a particular {\em object}. A 32 third class of measurement to be considered are those supplied by 33 external references. Such measurements may be treated as {\em 34 detections}, with the caveat that access to the raw measurements and 35 metadata are usually unavailable: the reported measurements and errors 36 must be accepted as they are reported. 37 38 DVO stores the collections of detections which were derived from 39 specific images. It provides a mechanism to determine the image from 40 which a specific detection was derived, and in conjunction with the 41 Image Server locate the corresponding data file. DVO also makes it 42 possible to extract all detections derived from a specific image and 43 to determine quantities such as the pixel coordinates of the detection 44 on the image. 45 46 DVO also has the capability to associate multiple detections of a 47 specific object. Several major classes of objects will be present, 48 each of which must be handled correctly. DVO distinguished the 49 following types of objects. 50 51 {\bf Stars, compact galaxies, and QSOs} will have nearly fixed 52 locations relative to other distant stars, with only small deviations 53 for individual measurements. The association between multiple 54 detections of such objects is made on the basis of their coincident 55 positions. DVO determines the average position of the object and the 56 deviations of the individual detections from that average on the basis 57 of the ensemble of individual detection. 58 59 {\bf Solar System Objects} do not have a fixed location. Detections 60 of such objects are linked by their orbits, and depend on both the 61 position and the time of the image. DVO does not attempt to make this 62 link; this is the role of the MOPS system. However, it has the 63 ability to accept identifications made externally with specified 64 detections and to return the identifier of the moving object 65 associated with the specific detections. These associations also 66 include descriptive information such as the offset of the detection 67 from the predicted location of the detection based on the orbit. This 68 functionality is required to allow DVO to ignore known moving object 69 detections from other types of queries. 70 71 {\bf High-proper-motion objects} in the general vicinity of the solar 72 system fall in between these first two classes of objects. Their 73 proper motion and parallax response is significant enough ($>0.2$ 74 arcsec in 1 year) that they are not well-described by an average 75 location and a collection of offsets. These objects are better 76 described by a distance and a proper motion vector. DVO provides the 77 association between the specific detections and an average object 78 which includes finite parallax and proper motion. 79 80 {\bf Orphaned detections} are not associated with a specific 81 astronomical object of any of the above classes. Most of these will 82 be spurious (not representing real objects), some will be from solar 83 system objects for which orbits are not yet determined, some will be 84 from faint stars near the detection limits, and some will be from 85 short-term transients which have only been detected once. DVO 86 maintains these detections until they have been associated with one of 87 the objects above. DVO provides mechanisms by which individual 88 detections may be migrated back and forth between the orphan state and 89 association with an astronomical object. 90 91 DVO stores the information about the detection, the related objects, 92 and the images which provided the measurements. For every detection, 93 DVO provides the mechanisms to link the detection back to the image 94 which supplied it. DVO also provides the capability to determine the 95 images containing a specific location but for which no detection was 96 made. The minimum set of information which must be carried for these 97 non-detections is the image and the associated object or orphan. 98 99 DVO also stores the relationships between various 100 photometric systems and the evolution of that relationship. It 101 provides mechanisms to convert between the measured instrumental 102 magnitude of a detection with a specific filter, detector, and 103 telescope, and at a particular time and the implied magnitude in the 104 average Pan-STARRS photometry system, given a determined set of 105 calibrations. It also provides the capability to convert magnitudes 106 in one system to the magnitudes in another system; an example of such 107 a conversion is between the average Pan-STARRS filter systems and the 108 various reference systems appropriate for those filters. 109 110 \section{Photometric systems and the DVO Photcodes} 22 111 23 112 One of the major roles of DVO is to relate different photometric … … 26 115 number of different detectors. We may have observations from 27 116 different telescopes in similar filters. We may have reference data 28 related to some filter, but obtained and published by other 29 observers. We would like to related these measurements together in 30 optimal ways, making use of whatever information we have available. 31 DVO providesseveral mechanisms to enable these relationships.117 related to some filter, but obtained and published by other observers. 118 We would like to related these measurements together in optimal ways, 119 making use of whatever information we have available. DVO provides 120 several mechanisms to enable these relationships. 32 121 33 122 We identify three distinct types of photometry measurements within … … 208 297 parameters. 209 298 210 \section{Overview}211 212 DVO, the Desktop Virtual Observatory, is a software system which213 stores data related to astronomical objects derived from various214 sources, and provides mechanisms to related multiple detections215 together as astronomical objects. DVO deals with two related216 concepts: {\em objects} and {\em detections}. The {\em objects} are217 descriptions of astronomical objects while the {\em detections} are218 the specific measurements of those objects, typically measured from219 astronomical images. A collection of {\em detections} may be used to220 derive average quantities which describe a particular {\em object}. A221 third class of measurement to be considered are those supplied by222 external references. Such measurements may be treated as {\em223 detections}, with the caveat that access to the raw measurements and224 metadata are usually unavailable: the reported measurements and errors225 must be accepted as they are reported.226 227 DVO stores the collections of detections which were derived from228 specific images. It provides a mechanism to determine the image from229 which a specific detection was derived, and in conjunction with the230 Image Server locate the corresponding data file. DVO also makes it231 possible to extract all detections derived from a specific image and232 to determine quantities such as the pixel coordinates of the detection233 on the image.234 235 DVO also has the capability to associate multiple detections of a236 specific object. Several major classes of objects will be present,237 each of which must be handled correctly. DVO distinguished the238 following types of objects.239 240 {\bf Stars, compact galaxies, and QSOs} will have nearly fixed241 locations relative to other distant stars, with only small deviations242 for individual measurements. The association between multiple243 detections of such objects is made on the basis of their coincident244 positions. DVO determines the average position of the object and the245 deviations of the individual detections from that average on the basis246 of the ensemble of individual detection.247 248 {\bf Solar System Objects} do not have a fixed location. Detections249 of such objects are linked by their orbits, and depend on both the250 position and the time of the image. DVO does not attempt to make this251 link; this is the role of the MOPS system. However, it has the252 ability to accept identifications made externally with specified253 detections and to return the identifier of the moving object254 associated with the specific detections. These associations also255 include descriptive information such as the offset of the detection256 from the predicted location of the detection based on the orbit. This257 functionality is required to allow DVO to ignore known moving object258 detections from other types of queries.259 260 {\bf High-proper-motion objects} in the general vicinity of the solar261 system fall in between these first two classes of objects. Their262 proper motion and parallax response is significant enough ($>0.2$263 arcsec in 1 year) that they are not well-described by an average264 location and a collection of offsets. These objects are better265 described by a distance and a proper motion vector. DVO provides the266 association between the specific detections and an average object267 which includes finite parallax and proper motion.268 269 {\bf Orphaned detections} are not associated with a specific270 astronomical object of any of the above classes. Most of these will271 be spurious (not representing real objects), some will be from solar272 system objects for which orbits are not yet determined, some will be273 from faint stars near the detection limits, and some will be from274 short-term transients which have only been detected once. DVO275 maintains these detections until they have been associated with one of276 the objects above. DVO provides mechanisms by which individual277 detections may be migrated back and forth between the orphan state and278 association with an astronomical object.279 280 DVO stores the information about the detection, the related objects,281 and the images which provided the measurements. For every detection,282 DVO provides the mechanisms to link the detection back to the image283 which supplied it. DVO also provides the capability to determine the284 images containing a specific location but for which no detection was285 made. The minimum set of information which must be carried for these286 non-detections is the image and the associated object or orphan.287 288 DVO also stores the relationships between various289 photometric systems and the evolution of that relationship. It290 provides mechanisms to convert between the measured instrumental291 magnitude of a detection with a specific filter, detector, and292 telescope, and at a particular time and the implied magnitude in the293 average Pan-STARRS photometry system, given a determined set of294 calibrations. It also provides the capability to convert magnitudes295 in one system to the magnitudes in another system; an example of such296 a conversion is between the average Pan-STARRS filter systems and the297 various reference systems appropriate for those filters.298 299 299 \section{DVO Database Tables} 300 300 … … 499 499 data types and input/output methods without significant re-coding. 500 500 501 \tbd{DVO mysql table storage is not yet implemented} 502 501 503 \section{addstar : Insert Image \& Detection Set} 502 504 … … 505 507 \caption{\label{catalog} \small a figure } 506 508 \end{figure} 507 508 \tbd{fill out discussion of the addstar client/server implementation}509 509 510 510 One of the most basic operations needed by DVO is to insert a … … 527 527 faint orphans. 528 528 529 \subsection{addstar -refs : Insert Reference Objects} 530 531 This operation is very similar to the previous one. A collection of 532 reference objects are added to the database as a collection of 533 detections. The reference photometry should in general be given its 534 own photometry code. The reference data is different from the image 535 detection set because the associated image information is not 536 included. Thus, no corresponding images are added to the database. 537 538 \section{relphot : Relative Photometry Analysis} 529 A wide range of options are available to addstar. These can be used 530 to modify the object matching rules, to reduce the number of tables 531 which are updated, to specify the output data format, and so forth. A 532 few options modify the behavoir in substantial ways, as discussed in 533 the two sections below. 534 535 \tbd{flesh out discussion of the options} 536 537 \subsection{Insert Reference Objects} 538 539 \code{addstar -ref (filename)} 540 541 This mode of addstar reads a text file and adds the listed objects to 542 the database as a reference photcode type. A collection of reference 543 objects are added to the database as a collection of detections. The 544 reference photometry should in general be given its own photometry 545 code. The reference data is different from the image detection set 546 because the associated image information is not included. Thus, no 547 corresponding images are added to the database. 548 549 \subsection{Insert Catalog Objects} 550 551 \code{addstar -cat (name) -region ra ra dec dec} 552 553 In this mode, any of several all-sky or large-scale reference catalogs 554 are used for the input sources. The catalog objects are added to the 555 database as reference objects. The valid catalogs consist of 2MASS, 556 USNO, GSC. Tycho and USNO-B will be added shortly. Specific 557 photcode names are defined for each of these catalogs, and must be 558 appropriately requested and defined in the photcode table. The 559 optional region restriction limits the insert to a subset of the sky. 560 The user does not always want to add 50GB of 2MASS detections to any 561 DVO database... 562 563 \subsection{Addstar Client/Server Interactions} 564 565 DVO currently uses stand-alone programs which are run from the command 566 line (like addstar, or the programs listed below), or it works with 567 the interactive DVO shell, which allows the user to query portions of 568 the database. These programs all interact with the database tables 569 directly, making use of file locking to prevent conflicts. 570 571 Unlike the other DVO programs (currently), it is possible to run 572 addstar as a client/server system. In this configuration, the program 573 \code{addstard} is launched to run in the background as a server. It 574 monitors a socket waiting for clients to contact it. The client 575 program, \code{addstarc} appears to the user identical to the 576 stand-alone addstar. However, rather than directly insert data into 577 the database, \code{addstarc} contacts the addstar server and sends it 578 the detections and associated image data (along with the information 579 about the user options). The daemons accepts the incoming data and 580 then loads this data into the database, just as the stand-alone 581 addstar does. 582 583 The purpose of the addstar client/server design is three-fold. First, 584 the client can be used by processes to send data to the DVO database 585 and then immediately exit. The addstar loading process is one of the 586 more time-critical functions within the IPP. However, unlike the 587 other portions of the IPP, the addstar processes must operate in 588 serial, at least when they are updating the same portion of the sky 589 (or the image table). If the IPP analysis routines all needed to run 590 the stand-alone addstar program, they would eventually block waiting 591 for each addstar to complete, preventing other processing from 592 continuing. The addstar client / server model allows the processing 593 node to invoke the addstar client, sending the data to the addstar 594 server. The addstar server will then be the entity that manages the 595 serialization of the incoming data stream. The addstar server has two 596 threads which run in parallel. One thread monitors the socket and 597 accepts new data sets from addstar clients, adding the data to an 598 internal queue. The other thread pulls data off of the queue and 599 updates the database with the data. 600 601 A second advantage of the client/server interaction is that only the 602 new detections need to be sent across the network. To update the 603 database, addstar must load the average objects for the region from 604 the database tables. In the stand-alone mode, the addstar program 605 loads this data via NFS across the network from whatever device stores 606 the addstar tables. In the client/server model, the addstar server 607 always runs locally on the machine which holds the database tables. 608 Thus, for the server, all database access is local disk access. 609 610 The final advantage of the client/server model is that it enables the 611 parallel database model, which is not yet implemented as of Jan 612 2006. In this model, there are multiple addstar servers. Each one has 613 a fraction of the sky in the local tables. The identification of 614 which table is managed by this host/addstar server is stored in the 615 SkyRegion table. The addstar server simply accepts incoming 616 detections from the addstar clients. Any detections which it receives 617 which fall within the boundaries of tables that it manages are updated 618 as normal. The server then identifies the other addstar servers which 619 are responsible for the other detections. It then sends these 620 detections to those servers using the same socket communication used 621 by the addstar clients. The addstar server must also be ready accept 622 detections from other addstar servers. This relationship is 623 completely parallel, and any addstar client may send its data to any 624 addstar server, letting the servers hash out who owns what. The only 625 difficulty with this model is in handling sources near the boundaries 626 of the tables. Note that this issues exists whether those tables are 627 distributed across multiple machines or not. 628 629 Addstar uses the following strategy to handle detections on the table 630 boundaries. Detections are first added to each table completely 631 ignoring the neighboring tables. A detection which is close to the 632 boundary may either be associated with an average object contained 633 within the table, or not. If it is, the detection is associated with 634 that average object. If not, a new average object is created at the 635 location of the detection. So far, this process is identical to the 636 behavoir in the middle of the table. One a longer time-scale, a 637 process is run which mediates the table boundaries. In this analysis, 638 the two neighboring tables are simultaneously examined. The border 639 region, in a strip wider than the correlation radius, is examined in 640 detail. If two objects within the border region fall within 2x the 641 correlation radius of each other, their individual detections are 642 re-examined. These detections are re-added to a temporary table which 643 encompases the overlap. the resulting objects will in general have 644 detections from either side of the boundary. The average objects are 645 kept within the table as normal, but the detections are allowed to 646 migrate between the tables to stay with their object. \tbd{this 647 boundary cleanup process is not implemented to date}. 648 649 \section{Relphot : Relative Photometry Analysis} 539 650 540 651 This operation uses the overlaps of images and multiple observations 541 652 of the same objects to determine the relative photometry zero-points 542 for a collection of images. This is a task that wil berun much more653 for a collection of images. This is a task that is run much more 543 654 infrequently than the object insertion tasks. 544 655 545 \section{relphot} 546 547 \begin{verbatim} 548 * load data 549 o images: match photcode and time range, reset flags 550 o measure: select subset matching restritions on: photcode, time, dM, Minst, Mag, dophot == 1 551 * iterate to find Mcal, image.flags: 552 * write out modified Mcal values to image table 553 * write out modified Mcal values to measure table 554 * write out modified Mrel values to average table 555 \end{verbatim} 556 557 relphot has two primary purposes: 558 559 \begin{verbatim} 560 * calculate Mcal for images / measures 561 * calculate Mrel for stars 562 \end{verbatim} 563 564 relphot can also be used to determine the mosaic grid used to generate photometrically corrected flats (-grid option). 565 566 \subsection{data exclusion} 567 568 relphot uses only a subset of the photometry data to calculate Mcal 569 and Mrel. In the first stage, calculation of the Mcal values, relphot 570 loads the photometry data from each relevant catalog and creates an 571 internal subset catalog with the function bcatalog, excluding some of 572 the irrelevant data. In addition, it uses flags to mark some of the 573 data as invalid for the processing. bcatalog exclusions 574 575 \begin{verbatim} 576 * measure.photcode not equivalent to requested photcode 577 * measure.dophot != 1 578 * measure.Mcat > MAG_LIM 579 * measure.dM > SIGMA_LIM 580 * measure.Minst out of range (ImagMin - ImagMax) [optional] 581 * measure.t out of range (TSTART, TSTOP) 582 \end{verbatim} 583 584 flagged data 585 flagged image data 586 587 images can be flagged by setting bits of image.code stars can be 588 flagged by setting bits of average.code measures can be flagged by 589 setting bits of measure.flag 590 591 \begin{verbatim} 592 image.code 593 ID_IMAGE_NOCAL : ignore, irrelevant 594 ID_IMAGE_POOR : image measured bad 595 ID_IMAGE_SKIP : externally known bad dMcal > VALUE 596 FLAG_IMAGE_SCATTER clean_images fabs(Mcal) > VALUE 597 FLAG_IMAGE_ZEROPT clean_images dMcal > VALUE 598 FLAG_IMAGE_SCATTER clean_mosaics fabs(Mcal) > VALUE 599 FLAG_IMAGE_ZEROPT clean_mosaics mark_images does not seem to do 600 anything useful? 601 average.code Ngood < MEAS_TOOFEW setMrel Ngood < 602 MEAS_TOOFEW clean_measures ChiSq > STAR_CHISQ clean_stars dM > 603 STAR_SCATTER clean_stars average.code (STAR_BAD) is not saved by 604 relphot: it is set by clean_stars, clean_measures, and setMrel, but 605 not setMrelOutput. STAR_BAD should only be internal since it depends 606 on the photcode, but is not associated with a specific photcode in the 607 data. Just in case, it is reset to 0 in setMrelFinal. measure.flag X,Y 608 out of range setExclusions 3 sigma clipping clean_measures 609 \end{verbatim} 610 611 setting Mrel final value 612 613 setMrelFinal is used to set the final average.Mrel values. We do this 614 in 4 stages. In each stage, we set the Mrel values for stars which 615 have not already been set, based on the current exclusion settings. At 616 successive stages, we relax the exclusions, allowing the more spurious 617 objects to have a valid Mrel value to be set. In this loop, we 618 actually run setMrelOutput twice: once to get the approximate Mrel 619 value, then we flag the outlier measurements with 620 \code{clean_measure}, then we redetermine the Mrel values on this 621 basis, and mark the stars for exclusion from the next iteration. 622 623 \begin{verbatim} 624 exclude on 625 photcode 0 1 2 3 626 time range 0 1 2 3 627 MEAS_POOR 0 1 2 3 628 MEAS_TOOFEW 0 1 2 3 629 dophot == 10 0 1 2 630 inst mag 0 1 2 631 dophot != 1,2 0 1 632 ID_IMAGE_POOR 0 1 633 ID_IMAGE_SKIP 0 1 634 dophot != 1 0 635 measure.dM 0 636 \end{verbatim} 637 638 for all relphot runs, Mrel is re-calculated, and measures are marked at least if they are outliers in mag or ccd area. setMrel.output needs to do a few things differently from setMrel: 639 640 \begin{verbatim} 641 * set measure.Mcal (skipped in setMrel.basic) 642 * set average.Mrel if N < TOO_FEW (not STAR_BAD) (optional!) 643 * use MAX (stats.error, stats.sigma) (optionally) 644 * allow STAR_BAD? 645 \end{verbatim} 646 647 \section{uniphot : Zero Point Analysis} 656 The relphot analysis is currently performed with a single Sky region 657 as the starting point. All images (or all chips from all mosaic 658 iamges) which overlap the sky region are identified in the image 659 table. This set of images are considered set A. Next, all skyregions 660 which are overlapped by all of these images are selected. Finally, 661 all additional images which overlapped the new regions only are 662 selected. These are considered as image set B. The image selections 663 are also restricted to images of a single, user-selected photcode. 664 665 All of the objects and detections which are contributed by the images 666 in sample A are extracted from the average and measure tables. Only a 667 subset of the detections for which the S/N is greater than a 668 user-selected limit are kept. Other restrictions, such as time range 669 or instrumental magnitude ranges may also be specified. The 670 collection of average objects, their detections, and the images from 671 which they were derived now define a system of photometry equations. 672 In this system, every image has a calibration offset magnitude 673 ($M_{cal}$), every object has an average magnitude in a relative 674 system ($M_{rel}$), and every detection of that object has a magnitude 675 defined by the equation $M = M_{rel} + M_{cal}$. The goal is to solve 676 for the values of $M_{ref}$ and $M_{cal}$. 677 678 There are two points to note about this operation. First, the system 679 of equations is generally much too large to solve directly; we must 680 use an iterative technique to converge on a solution. Second, it is 681 important in the analysis to use robust averaging and identify 682 detections, stars, or images which are deviant in some way. These 683 should be marked and given set weight in the solution. These cases 684 may represent poorly measured objects (perhaps detections on or near a 685 bad column), variable stars, and images obtained in poor weather 686 conditions. 687 688 Relphot can also be used to determine the mosaic grid used to generate 689 photometrically corrected flats (-grid option). 690 691 \section{Uniphot : Zero Point Analysis} 648 692 649 693 This operation uses the time history of relative photometry zero … … 1482 1526 \end{itemize} 1483 1527 1528 1529 1530 \subsection{Relphot data exclusion} 1531 1532 relphot uses only a subset of the photometry data to calculate Mcal 1533 and Mrel. In the first stage, calculation of the Mcal values, relphot 1534 loads the photometry data from each relevant catalog and creates an 1535 internal subset catalog with the function bcatalog, excluding some of 1536 the irrelevant data. In addition, it uses flags to mark some of the 1537 data as invalid for the processing. bcatalog exclusions 1538 1539 \begin{verbatim} 1540 * measure.photcode not equivalent to requested photcode 1541 * measure.dophot != 1 1542 * measure.Mcat > MAG_LIM 1543 * measure.dM > SIGMA_LIM 1544 * measure.Minst out of range (ImagMin - ImagMax) [optional] 1545 * measure.t out of range (TSTART, TSTOP) 1546 \end{verbatim} 1547 1548 flagged data 1549 flagged image data 1550 1551 images can be flagged by setting bits of image.code stars can be 1552 flagged by setting bits of average.code measures can be flagged by 1553 setting bits of measure.flag 1554 1555 \begin{verbatim} 1556 image.code 1557 ID_IMAGE_NOCAL : ignore, irrelevant 1558 ID_IMAGE_POOR : image measured bad 1559 ID_IMAGE_SKIP : externally known bad dMcal > VALUE 1560 FLAG_IMAGE_SCATTER clean_images fabs(Mcal) > VALUE 1561 FLAG_IMAGE_ZEROPT clean_images dMcal > VALUE 1562 FLAG_IMAGE_SCATTER clean_mosaics fabs(Mcal) > VALUE 1563 FLAG_IMAGE_ZEROPT clean_mosaics mark_images does not seem to do 1564 anything useful? 1565 average.code Ngood < MEAS_TOOFEW setMrel Ngood < 1566 MEAS_TOOFEW clean_measures ChiSq > STAR_CHISQ clean_stars dM > 1567 STAR_SCATTER clean_stars average.code (STAR_BAD) is not saved by 1568 relphot: it is set by clean_stars, clean_measures, and setMrel, but 1569 not setMrelOutput. STAR_BAD should only be internal since it depends 1570 on the photcode, but is not associated with a specific photcode in the 1571 data. Just in case, it is reset to 0 in setMrelFinal. measure.flag X,Y 1572 out of range setExclusions 3 sigma clipping clean_measures 1573 \end{verbatim} 1574 1575 setting Mrel final value 1576 1577 setMrelFinal is used to set the final average.Mrel values. We do this 1578 in 4 stages. In each stage, we set the Mrel values for stars which 1579 have not already been set, based on the current exclusion settings. At 1580 successive stages, we relax the exclusions, allowing the more spurious 1581 objects to have a valid Mrel value to be set. In this loop, we 1582 actually run setMrelOutput twice: once to get the approximate Mrel 1583 value, then we flag the outlier measurements with 1584 \code{clean_measure}, then we redetermine the Mrel values on this 1585 basis, and mark the stars for exclusion from the next iteration. 1586 1587 \begin{verbatim} 1588 exclude on 1589 photcode 0 1 2 3 1590 time range 0 1 2 3 1591 MEAS_POOR 0 1 2 3 1592 MEAS_TOOFEW 0 1 2 3 1593 dophot == 10 0 1 2 1594 inst mag 0 1 2 1595 dophot != 1,2 0 1 1596 ID_IMAGE_POOR 0 1 1597 ID_IMAGE_SKIP 0 1 1598 dophot != 1 0 1599 measure.dM 0 1600 \end{verbatim} 1601 1602 for all relphot runs, Mrel is re-calculated, and measures are marked at least if they are outliers in mag or ccd area. setMrel.output needs to do a few things differently from setMrel: 1603 1604 \begin{verbatim} 1605 * set measure.Mcal (skipped in setMrel.basic) 1606 * set average.Mrel if N < TOO_FEW (not STAR_BAD) (optional!) 1607 * use MAX (stats.error, stats.sigma) (optionally) 1608 * allow STAR_BAD? 1609 \end{verbatim} 1610
Note:
See TracChangeset
for help on using the changeset viewer.
