xarray-ms 0.3.5__tar.gz → 0.3.7__tar.gz

{xarray_ms-0.3.5 → xarray_ms-0.3.7}/PKG-INFO

@@ -1,14 +1,14 @@
 Metadata-Version: 2.4
 Name: xarray-ms
-Version: 0.3.5
+Version: 0.3.7
 Summary: xarray MSv4 views over MSv2 Measurement Sets
 Author-email: Simon Perkins <simon.perkins@gmail.com>
 License-File: LICENSE
 Requires-Python: >=3.10
-Requires-Dist: arcae>=0.3.2
+Requires-Dist: arcae<0.4.0,>=0.3.2
 Requires-Dist: cacheout>=0.16.0
 Requires-Dist: typing-extensions>=4.12.2
-Requires-Dist: xarray>=2025.0
+Requires-Dist: xarray<2025.9.1,>=2025.0
 Provides-Extra: dev
 Requires-Dist: pre-commit>=3.8.0; extra == 'dev'
 Requires-Dist: tbump>=6.11.0; extra == 'dev'
@@ -18,6 +18,7 @@ Requires-Dist: pydata-sphinx-theme>=0.15.4; extra == 'doc'
 Requires-Dist: pygments>=2.18.0; extra == 'doc'
 Requires-Dist: sphinx-copybutton>=0.5.2; extra == 'doc'
 Requires-Dist: sphinx>=8.0.2; extra == 'doc'
+Requires-Dist: sphinxcontrib-spelling; extra == 'doc'
 Provides-Extra: testing
 Requires-Dist: dask>=2024.5.0; extra == 'testing'
 Requires-Dist: distributed>=2024.5.0; extra == 'testing'

xarray_ms-0.3.7/doc/source/api.rst

@@ -0,0 +1,31 @@
+API
+===
+
+Opening Measurement Sets
+------------------------
+
+The standard :func:`xarray.open_datatree` method should
+be used to open a :class:`~xarray.DataTree` interface
+to the underlying Measurement Set data.
+
+.. code-block:: python
+
+    >>> datatree = xarray.open_datatree("/data/data.ms", partition_schema=["FIELD_ID"])
+
+These methods defer to the relevant methods on the
+`Entrypoint Class <entrypoint-class_>`_.
+Consult the method signatures for information on extra
+arguments that can be passed.
+
+
+.. _entrypoint-class:
+
+Entrypoint Class
+----------------
+
+Entrypoint class for the MSv2 backend.
+
+.. autoclass:: xarray_ms.backend.msv2.entrypoint.MSv2EntryPoint
+    :members: open_datatree, open_dataset
+
+.. _partitioning-schema:

{xarray_ms-0.3.5 → xarray_ms-0.3.7}/doc/source/changelog.rst

@@ -3,6 +3,22 @@
 Changelog
 =========
 
+0.3.7 (03-10-2025)
+------------------
+* Documentation updates (:pr:`134`)
+* Temporarily restrict xarray to \< 2025.9.1 (:pr:`136`) until
+  `xarray#10808 <https://github.com/pydata/xarray/issues/10808_>`_
+  is resolved.
+* Restrict arcae to \< 0.4.0 to prevent
+  API-breaking write support changes (:pr:`136`)
+* Provide a physically realistic SPECTRAL_WINDOW::REF_FREQUENCY in simulated data (:pr:`133`)
+
+
+0.3.6 (22-09-2025)
+------------------
+* Document Partitioning Strategies and Irregular Grid Handling (:pr:`132`)
+* Document MSv4 compliance and roadmap (:pr:`131`)
+
 0.3.5 (17-09-2025)
 ------------------
 * Remove deploy to test-pypi (:pr:`130`)

{xarray_ms-0.3.5 → xarray_ms-0.3.7}/doc/source/conf.py

@@ -11,12 +11,13 @@
 project = "xarray-ms"
 copyright = "2024 - 2025 NRF (SARAO) and Rhodes University (RATT) Centre"
 author = "Simon Perkins"
-release = "0.3.5"
+release = "0.3.7"
 
 # -- General configuration ---------------------------------------------------
 # https://www.sphinx-doc.org/en/master/usage/configuration.html#general-configuration
 
 extensions = [
+  "sphinxcontrib.spelling",
   "sphinx.ext.autodoc",
   "sphinx.ext.autosummary",
   "sphinx.ext.extlinks",

{xarray_ms-0.3.5 → xarray_ms-0.3.7}/doc/source/index.rst

@@ -13,5 +13,7 @@ xarray-ms documentation
    introduction
    install
    tutorial
+   partitioning
+   roadmap
    api
    changelog

{xarray_ms-0.3.5 → xarray_ms-0.3.7}/doc/source/introduction.rst

@@ -72,16 +72,5 @@ Why xarray-ms?
 * xarray-ms uses arcae_, a high-performance backend to CASA Tables implementing
   a subset of python-casacore_'s interface.
 * Some limited support for irregular MSv2 data via padding.
-
-Work in Progress
-----------------
-
-The Measurement Set v4 specification is currently under active development.
-xarray-ms is also currently under active development and does not yet
-have feature parity with MSv4 or xradio_.
-Some measures information and many secondary datasets are not currently implemented.
-
-However, the most important parts of the MSv2 ``MAIN`` tables,
-as well as the ``ANTENNA``, ``POLARIZATON`` and ``SPECTRAL_WINDOW``
-sub-tables are implemented and should be sufficient
-for basic algorithm development.
+* Refer to the :ref:`MSv4 compliance and roadmap <compliance-and-roadmap>`
+  section for information on adherence to the specification.

xarray_ms-0.3.7/doc/source/partitioning.rst

@@ -0,0 +1,184 @@
+.. _partitioning-guide:
+
+Partitioning Guide
+==================
+
+`Measurement Set v4.0 <msv4-spec_>`_ specifies a series of datasets with
+``time``, ``baseline_id`` and ``frequency`` coordinates where
+``time`` and ``frequency`` have associated ``integration_time`` and
+``channel_width`` attributes.
+In the best case, this represents monotonic, equidistant values along
+``time`` and ``frequency`` and the standard quadratic relation between
+antennas in the case of ``baseline_id``.
+Observational data recorded directly off an interferometer and stored
+for archival purposes will commonly follow a
+``(time, baseline_id, frequency)`` ordering.
+
+The usefulness of this representation and ordering is that it is
+simple and easy for software to reason about.
+This is desirable as it simplifies our software.
+
+The challenge in converting from MSv2 to MSv4 is formulating a
+partitioning strategy to handle irregularity in an MSv2 dataset.
+
+Measurement Set v2.0 irregularity
+---------------------------------
+
+By contrast the `Measurement Set v2.0 <msv2-spec_>`_ is a tabular format that
+does not enforce any notion of regularity (although much software assumes it).
+The ``TIME`` and ``INTERVAL`` columns in the MAIN MSv2 table
+describe the midpoint in time at which a sample was measured
+and the amount of time (integration time) taken to measure the sample,
+while the ``ANTENNA1`` and ``ANTENNA2`` columns define the baseline along
+which the sample was measured.
+``TIME``, ``ANTENNA1`` and ``ANTENNA2`` are *keys* in the tabular MAIN table
+and there is no requirement that the measurements they index are ordered,
+or even form a regular ``(time, baseline_id)`` grid.
+Additionally, the ``DATA_DESC_ID`` column establishes a relation to the
+``SPECTRAL_WINDOW::CHAN_FREQ`` and ``SPECTRAL_WINDOW::CHAN_WIDTH`` columns
+representing the frequency centroid and bandwidth of the sample, respectively.
+
+The challenge that MSv2 poses to radio astronomy software in the worst case
+is that it can represent overlapped or disjoint measurements in time and frequency
+for one or more baselines.
+However, most observational data is well-behaved:
+Measurements are commonly ordered by ``TIME, ANTENNA1, ANTENNA2``
+and ``CHAN_FREQ`` commonly increases monotically with
+equidistant values (i.e. ``CHAN_WIDTH`` values are uniform) but this cannot
+always be assumed.
+Any regularity in an MSv2 MS is achieved through convention rather
+than enforcement.
+
+
+Choosing a partitioning strategy
+--------------------------------
+
+By default, MSv2 measurements are partitioned by ``DATA_DESC_ID``,
+``OBSERVATION_ID``, ``PROCESSOR_ID`` and the
+``STATE::OBS_MODE`` (via ``STATE_ID``) columns.
+
+.. autodata:: xarray_ms.backend.msv2.structure.DEFAULT_PARTITION_COLUMNS
+
+For example, it follows from the previous section that,
+in order to achieve regularity in frequency, *partition*
+MSv2 measurements by the ``DATA_DESC_ID`` column.
+
+Partitioning always uses these columns, but additional columns can be
+selected if finer grained partitioning is required:
+
+.. autodata:: xarray_ms.backend.msv2.structure.VALID_PARTITION_COLUMNS
+
+Note that ``OBS_MODE`` and ``SUB_SCAN_NUMBER`` are columns in the ``STATE``
+subtable, while ``SOURCE_ID`` is a column of the ``FIELD`` subtable.
+Partitioning on these columns is achieved by joining on the ``STATE_ID``
+and ``FIELD_ID`` columns, respectively.
+
+
+Within these partitions, measurements are sorted by
+``TIME``, ``ANTENNA1`` and ``ANTENNA2``
+to form a grid.
+
+.. _time-partitioning:
+
+Partitioning in time
+++++++++++++++++++++
+
+Compared to frequency, achieving regularity in time requires more thought
+as it depends on identifying partitions of MSv2 where data:
+
+1. contains monotically increasing ``TIME`` (after ordering).
+2. is dumped with a uniform ``INTERVAL``.
+3. ideally contains no gaps: i.e. ``(TIME - INTERVAL)[1:] == (TIME + INTERVAL)[:-1]``.
+
+For example, ``OBS_MODE`` specifying ``STATE::OBS_MODE`` via ``STATE_ID``
+is a good default partitioner, as it represents a shift in the
+interferometer's mode of operation: It identifies when
+the interferometer is e.g. slewing/observing a calibrator/observing a target.
+
+Other valid partitioning columns are:
+
+- ``FIELD_ID``: Observing a field for a period of time.
+- ``SOURCE_ID``: Observing a source within a field for a period of time.
+- ``SCAN_NUMBER``: A coarse, logical number (i.e. scan) associated with the data.
+- ``SUB_SCAN_NUMBER``: A finer, logical number (i.e. scan) associated with the data.
+  This specifies ``STATE::SUB_SCAN_NUMBER`` (via ``STATE_ID``).
+- ``STATE_ID``: The state of an interferometer.
+
+as these columns frequently identify measurement groupings where
+the interferometer is consistently dumping.
+
+.. code-block:: python
+
+    import xarray_ms
+    import xarray
+
+    # Also partition by SCAN_NUMBER and FIELD_ID
+    dt = xarray.open_datatree(ms, partition_schema=["SCAN_NUMBER", "FIELD_ID"])
+
+.. _missing-baselines:
+
+Missing Baselines
+-----------------
+
+Baselines can be missing for distinct ``TIME`` values.
+This can occur when Measurement Sets are passed through the
+CASA ``split`` task with ``keepflags=False`` set, for instance.
+
+Having all baselines present can be useful
+for simplifying calibration algorithms and cases where
+auto-correlations are requested, but none are present in the data.
+
+``xarray-ms`` will impute these missing data points with default values
+(``nan`` in the case of data, ``1`` in the case of flags).
+
+Irregular Grid Warnings
+-----------------------
+
+Given the specified partitioning schema, ``xarray-ms`` will partition
+the MSv2 by the supplied columns and attempt to establish a regular
+``(time, baseline_id, frequency)`` grid.
+If this is not possible, three classes of warning can be issued,
+related to each of the three dimensions.
+
+:class:`~xarray_ms.errors.IrregularTimeGridWarning`
++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+This warning is raised when it is impossible
+to identify a unique ``INTERVAL`` value for a partition.
+This is required to assign a single ``integration_time``
+attribute to the ``time`` coordinate.
+
+The above check is relaxed slightly by excluding the last time
+in the partition (to handle averaged data) and by allowing
+a degree of jitter in the ``INTERVAL`` column.
+
+Generally, this happens if the requested partitioning schema
+does not satisfy the criteria described in :ref:`time-partitioning`.
+The solution is to experiment with other partitioning columns.
+
+Should the user wish to continue with this case,
+``xarray-ms`` sets ``integration_time=nan``
+and adds ``(time, baseline_id)``-shaped,
+``TIME`` and ``INTEGRATION_TIME`` columns.
+Downstream applications should account for this.
+
+:class:`~xarray_ms.errors.IrregularChannelGridWarning`
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+This warning is raised when it is impossible to identify a unique
+``CHAN_WIDTH`` value for the partition.
+This is required to assign a single ``channel_width``
+attribute to the ``frequency`` coordinate.
+
+Should the user wish to continue with this
+case ``xarray-ms`` sets ``channel_width=nan``
+and adds ``(frequency,)``-shaped ``CHANNEL_WIDTH`` columns.
+Downstream application should account for this.
+
+:class:`~xarray_ms.errors.IrregularBaselineGridWarning`
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+
+This warning is raised when baselines were missing for a
+particular timestep.
+This is a relatively benign warning as ``xarray-ms`` will
+impute missing values (See :ref:`missing-baselines`).

xarray_ms-0.3.7/doc/source/roadmap.rst

@@ -0,0 +1,69 @@
+.. _compliance-and-roadmap:
+
+Measurement Set v4 Compliance
+=============================
+
+xarray-ms fully implements the loading of correlated data from
+MSv2 datasets into the Measurement Set v4.0 specification.
+This covers the MSv2 ``MAIN`` table, as well as the
+``DATA_DESCRIPTION``, ``SPECTRAL_WINDOW``, ``POLARIZATION``,
+``FEED``, ``OBSERVATION``, ``STATE`` and ``PROCESSOR`` subtables
+whose synthesis is presented in correlated data datasets
+within an xarray DataTree.
+
+Care has been taken to convert measures information from MSv2 into
+MSv4 metadata attributes, where appropriate.
+
+In particular, it loads the MSv2 dataset present in the
+`Measurement Set v4 test suite <msv4-test-suite_>`_ except for:
+
+- ALMA Measurement Sets which sometimes do not correctly link
+  the ANTENNNA and MAIN table via the FEED table.
+  This will need to be addressed heuristically.
+- Single-dish Measurement Sets.
+  This is not difficult as it involves loading in
+  ``MAIN::FLOAT_DATA`` into the ``SPECTRUM`` variable and
+  renaming ``FIELD_PHASE_CENTER_DIRECTION`` to
+  ``FIELD_REFERENCE_CENTER_DIRECTION`` in the
+  ``field_and_source_xds`` dataset.
+
+MSv4 specifies a set of optional datasets, of which the following are implemented:
+
+- antenna_xds
+- field_and_source_xds (required components)
+
+The following optional datasets are not yet implemented:
+
+- field_and_source_ephemeris_xds
+- pointing_xds
+- system_calibration_xds
+- gain_curve_xds
+- phase_calibration_xds
+- weather_xds
+- phased_array_xds
+
+Roadmap
+-------
+
+The existing coverage of the specification arguably represents a Pareto distribution of the required data for writing Radio Astronomy software in an MSv4 paradigm, but we aim to address the remaining cases as follows in order of priority:
+
+- phased_array_xds
+- pointing_xds
+
+as this will more fully support LOFAR and SKA-LOW. The following datasets are probably required for VLBI:
+
+- system_calibration_xds
+- weather_xds
+
+while the following are arguably required for calibration and other software that will need to be developed
+for the MSv4 paradigm:
+
+- gain_curve_xds
+- phase_calibration_xds
+- field_and_source_ephemeris_xds
+- single dish systems
+
+This is a rough strategy and doesn't need to be set in stone.
+Please reach out or contribute PR's if you have specific requirements.
+
+.. _msv4-test-suite: https://github.com/ratt-ru/xarray-ms/blob/main/tests/msv4_test_corpus/test_msv_corpus.py

{xarray_ms-0.3.5 → xarray_ms-0.3.7}/doc/source/tutorial.rst

@@ -3,7 +3,7 @@ Tutorial
 
 The `Measurement Set v2.0 <msv2-spec_>`_ is a tabular format that
 includes notions of regularity or, the shape of the data, in the MAIN table.
-This is accomplished through the ``DATA_DESC_ID`` column which defines the
+This is achieved through the ``DATA_DESC_ID`` column which defines the
 Spectral Window and Polarisation Configuration associated with each row:
 the shape of the visibility in each row of the ``DATA`` column can
 vary per-row.
@@ -16,13 +16,13 @@ or group MSv2 rows by the same shape and configuration.
 In xarray-ms, this is accomplished by specifying a ``partition_schema``
 when opening a Measurement Set.
 Different columns may be used to define the partition.
-See :ref:`partitioning-schema` for more information.
+See :ref:`partitioning-guide` for more information.
 
 Opening a Measurement Set
 -------------------------
 
 As xarray-ms implements an `xarray backend <xarray_backend_>`_,
-it is possible to use the :func:`xarray.backends.api.open_datatree` function
+it is possible to use the :func:`xarray.open_datatree` function
 to open multiple partitions of a Measurement Set.
 
 .. ipython:: python
@@ -50,7 +50,7 @@ to open multiple partitions of a Measurement Set.
 Selecting a subset of the data
 ++++++++++++++++++++++++++++++
 
-By default, :func:`~xarray.backends.api.open_datatree` will return a datatree
+By default, :func:`~xarray.open_datatree` will return a datatree
 with a lazy view over the data.
 xarray has extensive functionality for
 `indexing and selecting data <xarray_indexing_and_selecting_>`_.

{xarray_ms-0.3.5 → xarray_ms-0.3.7}/pyproject.toml

@@ -1,14 +1,14 @@
 [project]
 name = "xarray-ms"
-version = "0.3.5"
+version = "0.3.7"
 description = "xarray MSv4 views over MSv2 Measurement Sets"
 authors = [{name = "Simon Perkins", email = "simon.perkins@gmail.com"}]
 readme = "README.rst"
 requires-python = ">=3.10"
 dependencies = [
-    "xarray>=2025.0",
+    "xarray>=2025.0, < 2025.9.1",
     "cacheout>=0.16.0",
-    "arcae>=0.3.2",
+    "arcae>=0.3.2, < 0.4.0",
     "typing-extensions>=4.12.2",
 ]
 
@@ -26,6 +26,7 @@ dev = [
 ]
 doc = [
     "sphinx>=8.0.2",
+    "sphinxcontrib-spelling",
     "pygments>=2.18.0",
     "sphinx-copybutton>=0.5.2",
     "pydata-sphinx-theme>=0.15.4",
@@ -53,7 +54,7 @@ extend-select = ["I"]
 # github_url = "https://github.com/<user or organization>/<project>/"
 
 [tool.tbump.version]
-current = "0.3.5"
+current = "0.3.7"
 
 # Example of a semver regexp.
 # Make sure this matches current_version before

{xarray_ms-0.3.5 → xarray_ms-0.3.7}/tests/test_zarr_roundtrip.py

@@ -1,18 +1,21 @@
+import xarray
 import xarray.testing as xt
-from xarray.backends.api import open_dataset, open_datatree
 
 
 def test_dataset_roundtrip(simmed_ms, tmp_path):
-  ds = open_dataset(simmed_ms)
+  ds = xarray.open_dataset(simmed_ms)
   zarr_path = tmp_path / "test_dataset.zarr"
   ds.to_zarr(zarr_path, compute=True, consolidated=True)
-  ds2 = open_dataset(zarr_path)
+  ds2 = xarray.open_dataset(zarr_path)
   xt.assert_identical(ds, ds2)
 
 
 def test_datatree_roundtrip(simmed_ms, tmp_path):
-  dt = open_datatree(simmed_ms)
+  dt = xarray.open_datatree(simmed_ms)
   zarr_path = tmp_path / "test_datatree.zarr"
   dt.to_zarr(zarr_path, compute=True, consolidated=True)
-  dt2 = open_datatree(zarr_path)
+  # TODO Remove forcing of engine once
+  # https://github.com/pydata/xarray/issues/10808
+  # is resolved
+  dt2 = xarray.open_datatree(zarr_path, engine="zarr")
   xt.assert_identical(dt, dt2)

{xarray_ms-0.3.5 → xarray_ms-0.3.7}/xarray_ms/backend/msv2/entrypoint.py

@@ -225,6 +225,7 @@ class MSv2EntryPoint(BackendEntrypoint):
   ]
   description = "Opens v2 CASA Measurement Sets in Xarray"
   url = "https://xarray-ms.readthedocs.io/"
+  supports_groups = True
 
   def guess_can_open(
     self, filename_or_obj: str | os.PathLike[Any] | BufferedIOBase | AbstractDataStore
@@ -266,6 +267,7 @@ class MSv2EntryPoint(BackendEntrypoint):
       drop_variables: Variables to drop from the dataset.
       partition_schema: The columns to use for partitioning the Measurement set.
         Defaults to :code:`{DEFAULT_PARTITION_COLUMNS}`.
+        See :ref:`partitioning-guide` for more further information.
       partition_key: A key corresponding to an individual partition.
         For example :code:`(('DATA_DESC_ID', 0), ('FIELD_ID', 0))`.
         If :code:`None`, the first partition will be opened.
@@ -345,6 +347,7 @@ class MSv2EntryPoint(BackendEntrypoint):
       drop_variables: Variables to drop from the dataset.
       partition_schema: The columns to use for partitioning the Measurement set.
         Defaults to :code:`{DEFAULT_PARTITION_COLUMNS}`.
+        See :ref:`partitioning-guide` for more further information.
       auto_corrs: Include/Exclude auto-correlations.
       ninstances: The number of Measurement Set instances to open for parallel I/O.
       epoch: A string uniquely identifying this Dataset.

{xarray_ms-0.3.5 → xarray_ms-0.3.7}/xarray_ms/backend/msv2/factories/correlated.py

@@ -77,6 +77,8 @@ MSV4_to_MSV2_COLUMN_SCHEMAS = {
 
 FIXED_DIMENSION_SIZES = {"uvw_label": 3}
 
+PARTITIONING_LINK = "https://xarray-ms.readthedocs.io/en/latest/partitioning.html"
+
 
 class CorrelatedFactory(DatasetFactory):
   """Factory class for generating the main correlated dataset
@@ -309,7 +311,8 @@ class CorrelatedFactory(DatasetFactory):
         f"in the case of data variables "
         f"and flags will be set for these cases. "
         f"This situation is benign, especially if auto-corelations "
-        f"have been requested on a dataset without them.",
+        f"have been requested on a dataset without them. "
+        f"See {PARTITIONING_LINK}",
         IrregularBaselineGridWarning,
       )
 
@@ -399,7 +402,8 @@ class CorrelatedFactory(DatasetFactory):
         f"time.attrs['integration_time'] will be set to 'nan' and "
         f"(time, baseline_id) shaped TIME and INTEGRATION_TIME columns "
         f"will be added. "
-        f"{'They contain nans in missing rows.' if missing_rows else ''}",
+        f"{'They contain nans in missing rows. ' if missing_rows else ''}"
+        f"See {PARTITIONING_LINK}",
         IrregularTimeGridWarning,
       )
       time_attrs["integration_time"]["data"] = np.nan
@@ -447,7 +451,8 @@ class CorrelatedFactory(DatasetFactory):
         f"found in partition {self._partition_key}. "
         f"MSv4 cannot strictly represent this case and so "
         f"frequency.attrs['channel_width'] will be set to 'nan' and "
-        f"a (frequency,) shaped CHANNEL_WIDTH column will be added.",
+        f"a (frequency,) shaped CHANNEL_WIDTH column will be added. "
+        f"See {PARTITIONING_LINK}",
         IrregularChannelGridWarning,
       )
       freq_attrs["channel_width"]["data"] = np.nan

{xarray_ms-0.3.5 → xarray_ms-0.3.7}/xarray_ms/errors.py

@@ -2,17 +2,17 @@ class IrregularGridWarning(UserWarning):
   """Base Warning for irregular grids"""
 
 
-class IrregularTimeGridWarning(UserWarning):
+class IrregularTimeGridWarning(IrregularGridWarning):
   """Warning raised when the intervals associated
   with each timestep are not homogenous"""
 
 
-class IrregularBaselineGridWarning(UserWarning):
+class IrregularBaselineGridWarning(IrregularGridWarning):
   """Warning raised when missing baselines are
   present in the Measurement Set"""
 
 
-class IrregularChannelGridWarning(UserWarning):
+class IrregularChannelGridWarning(IrregularGridWarning):
   """Warning raised when an irregular channel grid
   is encountered"""
 

{xarray_ms-0.3.5 → xarray_ms-0.3.7}/xarray_ms/testing/simulator.py

@@ -290,11 +290,13 @@ class MSStructureSimulator:
         (nchan,) = chan_freq.shape
         index = (np.array([r]),)
         chan_width = np.full(nchan, (chan_freq[-1] - chan_freq[0]) / nchan)
+        ref_freq = chan_freq[0] + chan_freq[-1] / 2
         T.putcol("NUM_CHAN", np.array([nchan]), index=index)
         T.putcol("CHAN_FREQ", chan_freq[None, :], index=index)
         T.putcol("CHAN_WIDTH", chan_width[None, :], index=index)
         T.putcol("RESOLUTION", chan_freq[None, :], index=index)
         T.putcol("EFFECTIVE_BW", chan_width[None, :], index=index)
+        T.putcol("REF_FREQUENCY", ref_freq[None], index=index)
 
     # Partially populate the POLARIZATION table
     with Table.from_filename(f"{output_ms}::POLARIZATION", **kw) as T:

xarray_ms-0.3.5/doc/source/api.rst

@@ -1,54 +0,0 @@
-API
-===
-
-Opening Measurement Sets
-------------------------
-
-The standard :func:`xarray.backends.api.open_dataset` and
-:func:`xarray.backends.api.open_datatree` methods should
-be used to open either a :class:`~xarray.Dataset` or a
-:class:`~xarray.DataTree`.
-
-.. code-block:: python
-
-    >>> dataset = xarray.open_dataset(
-                    "/data/data.ms",
-                    partition_schema=["DATA_DESC_ID", "FIELD_ID"])
-    >>> datatree = xarray.backends.api.open_datatree(
-                    "/data/data.ms",
-                    partition_schema=["DATA_DESC_ID", "FIELD_ID"])
-
-These methods defer to the relevant methods on the
-`Entrypoint Class <entrypoint-class_>`_.
-Consult the method signatures for information on extra
-arguments that can be passed.
-
-
-.. _entrypoint-class:
-
-Entrypoint Class
-----------------
-
-Entrypoint class for the MSv2 backend.
-
-.. autoclass:: xarray_ms.backend.msv2.entrypoint.MSv2EntryPoint
-    :members: open_dataset, open_datatree
-
-.. _partitioning-schema:
-
-Partioning Schema
------------------
-
-The default partitioning schema contains the following columns:
-
-.. autodata:: xarray_ms.backend.msv2.structure.DEFAULT_PARTITION_COLUMNS
-
-Partitioning always uses these columns, but additional columns can be
-selected if finer grained partitioning is required:
-
-.. autodata:: xarray_ms.backend.msv2.structure.VALID_PARTITION_COLUMNS
-
-Note that ``OBS_MODE`` and ``SUB_SCAN_NUMBER`` are columns in the ``STATE``
-subtable, while ``SOURCE_ID`` is a column of the ``FIELD`` subtable.
-Partitioning on these columns is achieved by joining on the ``STATE_ID``
-and ``FIELD_ID`` columns, respectively.