Changes between Version 1 and Version 2 of ScantableRedesignProposal

Timestamp:

08/13/10 11:27:29 (14 years ago)

Author:

Malte Marquarding

Comment:

--

ScantableRedesignProposal

@@ -18 +18 @@
  * implement an upgrade task for the old Scantable to the new Scantable schema ( not required for standard as Scantable is not assumed to be persistent)
 
+= Scantable vs MS =
+
+Even though both containers are based on {{{casa::Table}}} they use different philosophies in terms of access. The main differences are:
+
+== Frequency handling ==
+
+ * MS has the '''SPECTRAL_WINDOW_ID''' for identifying similar frequency set-ups
+ * Scantable has a combination of '''IFNO''' and '''FREQUENCY_ID''' to group similar frequencies.
+
+The concept of an ''IF'' for grouping doesn't really exist in the MS (there are entries which can be used for this in the '''SPECTRAL_WINDOW''' table
+An ''IF'' for example can have multiple '''FREQUENCY_ID'''s e.g. in case of doppler tracked data. Frequency alignment then unifies these.
+
+== Handling of spectral channels ==
+
+ * MS has two columns '''DATA''' and '''FLOAT_DATA''' containing {{{n_pol x n_channel}}} matrices of complex and float values respectively. In case of single-dish data the '''FLOAT_DATA''' column contains the spectra.
+
+ * Scantable has only one column '''SPECTRA''' and one row per polarisation containing a float vector of {{{n_channel}}}. Cross-correlations are stored as real and imaginary parts in separate rows. For example for polarimetry data. we have four rows containing '''XX, YY, Real(XY), Imag(XY)'''
+
+asap relies on these structures in almost all access methods. As such, changing the internal format to MS would mean almost a complete reimplementation of asap.
+
+
  
 = Relevant Documentation =