Changes between Version 164 and Version 165 of ippToPsps

Timestamp:

Oct 5, 2011, 1:48:12 PM (15 years ago)

Author:

rhenders

Comment:

--

ippToPsps

@@ -69 +69 @@
 Due to the potential for changes in both input and output for {{{ippToPsps}}}, rather than hard-coding table descriptions, the code is heavily configurable. As such, the tables descriptions are stored as [http://www.ivoa.net/Documents/VOTable/20040811/REC-VOTable-1.1-20040811.html VOTable] files (for [http://svn.pan-starrs.ifa.hawaii.edu/trac/ipp/browser/trunk/ippToPsps/config/detection/tables.vot example]), which are a standard of the [http://www.ivoa.net/ IVOA]. Because VOTables are an XML format, they are both human and machine readable, expandable and self-describing. These VOTables are generated directly from the PSPS schema using a [http://svn.pan-starrs.ifa.hawaii.edu/trac/ipp/browser/trunk/ippToPsps/perl/pspsSchema2xml.pl script], so that any changes to the schema can be easily passed-along to {{{ippToPsps}}}.
 
-Additionally, a more general configuration file is used to detail the names of databases, location of output files, datastore settings etc. The path to one of these configuration files is the sole argument to running the code (see below). An example can be seen [http://svn.pan-starrs.ifa.hawaii.edu/trac/ipp/browser/trunk/ippToPsps/jython/configs/lap.xml here].
+Another configuration file is used to describe a particular 'loading campaign', complete with the names of databases, location of output files, datastore settings etc. The path to one of these configuration files is usually the sole argument when running any of the programs described below. An example can be seen [http://svn.pan-starrs.ifa.hawaii.edu/trac/ipp/browser/trunk/ippToPsps/jython/configs/lap20110809.xml here].
 
 Editing a config is easy, as it is XML format and most fields are self-explanatory. Others that are less obvious will be explained below in the ''Using the software'' section.
@@ -77 +77 @@
 For the special case where we have a 'locked' DVO database, i.e. one that is complete and will not grow any further, we can improve ippToPsps processing time by first generating MySQL tables that include all detections from DVO rather than just the detections-per-exposure (or stack) as above. For this we can use the dvoToMySQL tool, found [http://svn.pan-starrs.ifa.hawaii.edu/trac/ipp/browser/trunk/ippToPsps/jython/dvoToMySQL.py here]
 
-It may take a matter of days to convert a relatively small DVO database to MySQL, however, querying the MySQL database is hugely faster than accessing DVO directly, especially for regions of sky with a high density of detections, such as the medium deep fields. (This was seen when loading MD4 prior to the Boston meeting in May 2011. DVO access per exposure was 40 minutes, whereas, once imported to MySQL, query time was roughly 30 seconds.)
+It may take a matter of days to convert a relatively small DVO database to MySQL, however, querying the MySQL database is hugely faster than accessing DVO directly, especially for regions of sky with a high density of detections such as the medium deep fields. (This was seen when loading MD4 prior to the Boston meeting in May 2011. DVO access per exposure was 40 minutes, whereas, once imported to MySQL, query time was roughly 30 seconds.)
 
 '''Image ID confusion'''