| 35 | | A place to store hard-coded values to go directly into PSPS tables. Currently only the {{{init}}} batch type uses this. |
| 36 | | == Table shapes == |
| 37 | | |
| 38 | | All FITS tables mirror PSPS database tables. Since the PSPS schema will probably remain in a state of flux for some time, rather than hard-coding table descriptions, instead {{{ippToPsps}}} reads table shapes from an XML config. This config can be regenerated from the master PSPS schema using a Perl script ({{{pspsSchema2xml.pl}}}) in the scripts directory. The same script also generates C header files for each batch-type. These headers contains enums for each PSPS table and are used by the code at runtime. This helps minimise code changes. |
| 39 | | |
| 40 | | == Initialization data == |
| 41 | | |
| 42 | | The table shapes of the initialisation batch are handled as above. The actual initialisation data (lists of filters etc), which is liable to change, is held in a config and used by {{{ippToPsps}}} to populate the tables in the FITS file. This data is also used when generating other batch types, detections for example, as look-up tables for setting survey ID etc. |
| 43 | | |
| 44 | | == IPP to PSPS mappings == |
| 45 | | |
| 46 | | Most data to be loaded into the FITS tables comes from IPP {{{smf}}} or {{{cmf}}} files. For many columns, there is a direct mapping between these files and the PSPS database column. These mappings are detailed in a config. |
| | 35 | A place to store hard-coded values to go directly into PSPS tables. Currently only the {{{init}}} batch type uses this to populate the init tables with, for example, filter types, survey names etc. This same file is also used by other batch types as look-up tables for setting survey IDs, filters etc. |
| 63 | | When run, the above programs generate a single FITS file, which is then packaged up and published to the datastore by the Perl code, ready for collection by the {{{DXLayer}}} (below). |
| | 52 | When run, the above programs generate a single FITS file, which are then packaged up and published to the datastore by the Perl code, ready for collection by the {{{DXLayer}}} (below). |
| | 53 | |
| | 54 | === Design === |
| | 55 | |
| | 56 | Each batch type (detection, stack, init etc) is it's own class, all of which inherit from the Batch base-class, which handles features common to all batches, such as creating and opening output FITS files, connecting to the GPC1 database, connecting with the DVO database etc. This keeps duplicated code at a minimum. The Batch is an abstract class, i.e. it should not, and cannot, be instantiated. |
| | 57 | |
| | 58 | Each class has a single header file and a single source file. Public fields and methods are visible in the class (struct) definition in the header. Private members and functions are declared as static in the associated source files, thus keeping them encapsulated. All class code is contained in a single C file. Methods are accessed via function pointers in the structure. |
