Previous: Why a new format, and which?
Up: APPENDIX: Data Exchange Proposal
Next: Software
Previous Page: Why a new format, and which?
Next Page: Software

Implementation decisions

The BINTABLE format is merely a prescription to store tabular data, but there are a number of implementation details that have to be decided on, before we all start to write our data in some kind of FITS format. Although any FITS reader should be able to read (and/or skip) our NBODY data, only specialized readers would know what to do with the data. General table browsers, such as the FTB program, should however be able to manipulate such datasets. We note the following implementaton decisions:

• Naming conventions of the column names (the TTYPE's). This will be the most visible part of the implementation. Apart from registering the extension name (NBODY) with the FITS office, our community needs to agree on things like the column names, units, coordinate systems etc. See the example below.

• Datasets with different kinds of particles, which have different attributes. For example, SPH particles have extra attributes (such as temperature and density) which pure N-body particles formally don't have. It would not always be very efficient to tag along such unneeded data-attributes. The ``variable length array'' construct, proposed within the BINTABLE proposal could solve this problem, but this has to be worked out. Another possible solution is to store them in separate so-called FITS extensions. This is clearly a much simpler and easier to understand implementation.

• Some variables may be global variables, and result into more efficient storage. For example, if all the masses ( MASS) are the same, they may be stored in the header (which however is in ASCII). Another example is TIME; although in principle each particle may have it's own variable time, a snapshot is commonly defined with a unique time for all particles.

• For certain complex situations extra data structures may be needed to fully describe an experimental situation; for example, describing hierarchical double and triple stars could be stored in an accompanying table, since FITS allows for this. The names and descriptions of these extensions would need to be part of the standard too, but they can always be added to the proposal at a later date.

___________________________________________________
Previous: Why a new format, and which?
Up: APPENDIX: Data Exchange Proposal
Next: Software
Previous Page: Why a new format, and which?
Next Page: Software