mx-bluesky 1.2.0__tar.gz → 1.4.1__tar.gz

{mx_bluesky-1.2.0 → mx_bluesky-1.4.1}/.copier-answers.yml

@@ -1,9 +1,11 @@
 # Changes here will be overwritten by Copier
-_commit: 2.2.0
+_commit: 2.5.0
 _src_path: gh:DiamondLightSource/python-copier-template
 author_email: dominic.oram@diamond.ac.uk
 author_name: Dominic Oram
+component_lifecycle: production
 component_owner: group:data-acquisition
+component_type: library
 description: Bluesky tools for MX Beamlines at DLS
 distribution_name: mx-bluesky
 docker: true

{mx_bluesky-1.2.0 → mx_bluesky-1.4.1}/.devcontainer/Dockerfile

@@ -3,7 +3,7 @@
 # The devcontainer should use the build target and run as root with podman
 # or docker with user namespaces.
 #
-FROM python:3.11 AS build
+FROM python:3.12 AS build
 
 ARG PIP_OPTIONS
 

{mx_bluesky-1.2.0 → mx_bluesky-1.4.1}/.github/CONTRIBUTING.md

@@ -54,4 +54,4 @@ It is recommended that developers use a [vscode devcontainer](https://code.visua
 
 This project was created using the [Diamond Light Source Copier Template](https://github.com/DiamondLightSource/python-copier-template) for Python projects.
 
-For more information on common tasks like setting up a developer environment, running the tests, and setting a pre-commit hook, see the template's [How-to guides](https://diamondlightsource.github.io/python-copier-template/2.2.0/how-to.html).
+For more information on common tasks like setting up a developer environment, running the tests, and setting a pre-commit hook, see the template's [How-to guides](https://diamondlightsource.github.io/python-copier-template/2.5.0/how-to.html).

{mx_bluesky-1.2.0 → mx_bluesky-1.4.1}/.github/pages/make_switcher.py

@@ -1,3 +1,5 @@
+"""Make switcher.json to allow docs to switch between different versions."""
+
 import json
 import logging
 from argparse import ArgumentParser
@@ -6,6 +8,7 @@ from subprocess import CalledProcessError, check_output
 
 
 def report_output(stdout: bytes, label: str) -> list[str]:
+    """Print and return something received frm stdout."""
     ret = stdout.decode().strip().split("\n")
     print(f"{label}: {ret}")
     return ret
@@ -52,14 +55,12 @@ def get_versions(ref: str, add: str | None) -> list[str]:
     return versions
 
 
-def write_json(path: Path, repository: str, versions: str):
+def write_json(path: Path, repository: str, versions: list[str]):
+    """Write the JSON switcher to path."""
     org, repo_name = repository.split("/")
-    pages_url = f"https://{org}.github.io"
-    if repo_name != f"{org}.github.io":
-        # Only add the repo name if it isn't the source for the org pages site
-        pages_url += f"/{repo_name}"
     struct = [
-        {"version": version, "url": f"{pages_url}/{version}/"} for version in versions
+        {"version": version, "url": f"https://{org}.github.io/{repo_name}/{version}/"}
+        for version in versions
     ]
     text = json.dumps(struct, indent=2)
     print(f"JSON switcher:\n{text}")
@@ -67,6 +68,7 @@ def write_json(path: Path, repository: str, versions: str):
 
 
 def main(args=None):
+    """Parse args and write switcher."""
     parser = ArgumentParser(
         description="Make a versions.json file from gh-pages directories"
     )

{mx_bluesky-1.2.0 → mx_bluesky-1.4.1}/.github/workflows/_container.yml

@@ -30,12 +30,8 @@ jobs:
           DOCKER_BUILD_RECORD_UPLOAD: false
         with:
           context: .
-          # Need load and tags so we can test it below
+          file: Dockerfile.release
           load: true
-          tags: tag_for_testing
-
-      - name: Test cli works in cached runtime image
-        run: docker run --rm tag_for_testing --version
 
       - name: Create tags for publishing image
         id: meta

{mx_bluesky-1.2.0 → mx_bluesky-1.4.1}/.github/workflows/_pypi.yml

@@ -15,3 +15,5 @@ jobs:
 
       - name: Publish to PyPI using trusted publishing
         uses: pypa/gh-action-pypi-publish@release/v1
+        with:
+          attestations: false

{mx_bluesky-1.2.0 → mx_bluesky-1.4.1}/.github/workflows/_release.yml

@@ -23,7 +23,7 @@ jobs:
       - name: Create GitHub Release
         # We pin to the SHA, not the tag, for security reasons.
         # https://docs.github.com/en/actions/learn-github-actions/security-hardening-for-github-actions#using-third-party-actions
-        uses: softprops/action-gh-release@c062e08bd532815e2082a85e87e3ef29c3e6d191 # v2.0.8
+        uses: softprops/action-gh-release@e7a8f85e1c67a31e6ed99a94b41bd0b71bbee6b8 # v2.0.9
         with:
           prerelease: ${{ contains(github.ref_name, 'a') || contains(github.ref_name, 'b') || contains(github.ref_name, 'rc') }}
           files: "*"

{mx_bluesky-1.2.0 → mx_bluesky-1.4.1}/.github/workflows/ci.yml

@@ -21,7 +21,7 @@ jobs:
     strategy:
       matrix:
         runs-on: ["ubuntu-latest"] # can add windows-latest, macos-latest
-        python-version: ["3.11"] # , "3.12"] # add 3.12 when p4p #145 is fixed
+        python-version: ["3.11", "3.12"]
       fail-fast: false
     uses: ./.github/workflows/_test.yml
     with:

{mx_bluesky-1.2.0 → mx_bluesky-1.4.1}/.gitignore

@@ -80,6 +80,7 @@ instance/
 
 # Sphinx documentation
 docs/_build/
+docs/_api
 
 # PyBuilder
 target/

{mx_bluesky-1.2.0 → mx_bluesky-1.4.1}/.pre-commit-config.yaml

@@ -26,6 +26,14 @@ repos:
         types: [python]
         require_serial: true
 
+      - id: import-contracts
+        name: Ensure import directionality
+        pass_filenames: false
+        language: system
+        entry: lint-imports
+        types: [python]
+        require_serial: false
+
   # Type checking
   - repo: https://github.com/pre-commit/mirrors-mypy
     rev: v1.4.1

mx_bluesky-1.4.1/.vscode/mxb-with-core-dependencies.code-workspace

@@ -0,0 +1,23 @@
+// To use this you should obviously have these all in the parent directory
+{
+	"folders": [
+		{
+			"path": ".."
+		},
+		{
+			"path": "../../dodal"
+		},
+		{
+			"path": "../../bluesky"
+		},
+		{
+			"path": "../../ophyd"
+		},
+		{
+			"path": "../../ophyd-async"
+		}
+	],
+	"settings": {
+		"terminal.integrated.gpuAcceleration": "off"
+	}
+}

{mx_bluesky-1.2.0 → mx_bluesky-1.4.1}/Dockerfile

@@ -1,11 +1,14 @@
 # The devcontainer should use the developer target and run as root with podman
 # or docker with user namespaces.
-ARG PYTHON_VERSION=3.11
+ARG PYTHON_VERSION=3.12
 FROM python:${PYTHON_VERSION} AS developer
 
 # Add any system dependencies for the developer/build environment here
 RUN apt-get update && apt-get install -y --no-install-recommends \
     graphviz \
+    ffmpeg \
+    libsm6 \
+    libxext6 \
     && rm -rf /var/lib/apt/lists/*
 
 # Set up a virtual environment and put it in PATH

{mx_bluesky-1.2.0 → mx_bluesky-1.4.1}/Dockerfile.release

@@ -33,6 +33,6 @@ RUN git restore .
 RUN rm src/mx_bluesky/_version.py
 RUN pip install --no-cache-dir --no-compile --no-deps -e .
 
-ENTRYPOINT /app/hyperion/utility_scripts/docker/entrypoint.sh
+ENTRYPOINT ["/app/hyperion/utility_scripts/docker/entrypoint.sh"]
 
 EXPOSE 5005

{mx_bluesky-1.2.0 → mx_bluesky-1.4.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: mx-bluesky
-Version: 1.2.0
+Version: 1.4.1
 Summary: Bluesky tools for MX Beamlines at DLS
 Author-email: Dominic Oram <dominic.oram@diamond.ac.uk>
 License:                                  Apache License
@@ -226,6 +226,7 @@ Requires-Dist: opencv-python
 Requires-Dist: opentelemetry-distro
 Requires-Dist: opentelemetry-exporter-otlp
 Requires-Dist: pydantic
+Requires-Dist: pydantic-extra-types
 Requires-Dist: pyepics
 Requires-Dist: pyzmq
 Requires-Dist: requests
@@ -236,14 +237,15 @@ Requires-Dist: matplotlib
 Requires-Dist: blueapi>=0.5.0
 Requires-Dist: daq-config-server>=0.1.1
 Requires-Dist: ophyd==1.9.0
-Requires-Dist: ophyd-async>=0.3a5
+Requires-Dist: ophyd-async>=0.8a5
 Requires-Dist: bluesky>=1.13.0a4
-Requires-Dist: dls-dodal==1.33.0
+Requires-Dist: dls-dodal==1.36.2
 Provides-Extra: dev
 Requires-Dist: black; extra == "dev"
 Requires-Dist: build; extra == "dev"
 Requires-Dist: diff-cover; extra == "dev"
 Requires-Dist: GitPython; extra == "dev"
+Requires-Dist: import-linter; extra == "dev"
 Requires-Dist: ipython; extra == "dev"
 Requires-Dist: mypy; extra == "dev"
 Requires-Dist: myst-parser; extra == "dev"

mx_bluesky-1.4.1/docs/_api.rst

@@ -0,0 +1,16 @@
+:orphan:
+
+..
+   This page is not included in the TOC tree, but must exist so that the
+   autosummary pages are generated for mx_bluesky and all its
+   subpackages
+
+API
+===
+
+.. autosummary::
+    :toctree: _api
+    :template: custom-module-template.rst
+    :recursive:
+
+    mx_bluesky

mx_bluesky-1.4.1/docs/_templates/custom-module-template.rst

@@ -0,0 +1,37 @@
+{{ ('``' + fullname + '``') | underline }}
+
+{%- set filtered_members = [] %}
+{%- for item in members %}
+    {%- if item in functions + classes + exceptions + attributes %}
+        {% set _ = filtered_members.append(item) %}
+    {%- endif %}
+{%- endfor %}
+
+.. automodule:: {{ fullname }}
+    :members:
+
+    {% block modules %}
+    {% if modules %}
+    .. rubric:: Submodules
+
+    .. autosummary::
+        :toctree:
+        :template: custom-module-template.rst
+        :recursive:
+    {% for item in modules %}
+        {{ item }}
+    {%- endfor %}
+    {% endif %}
+    {% endblock %}
+
+    {% block members %}
+    {% if filtered_members %}
+    .. rubric:: Members
+
+    .. autosummary::
+        :nosignatures:
+    {% for item in filtered_members %}
+        {{ item }}
+    {%- endfor %}
+    {% endif %}
+    {% endblock %}

{mx_bluesky-1.2.0 → mx_bluesky-1.4.1}/docs/conf.py

@@ -1,8 +1,9 @@
-# Configuration file for the Sphinx documentation builder.
-#
-# This file only contains a selection of the most common options. For a full
-# list see the documentation:
-# https://www.sphinx-doc.org/en/master/usage/configuration.html
+"""Configuration file for the Sphinx documentation builder.
+
+This file only contains a selection of the most common options. For a full
+list see the documentation:
+https://www.sphinx-doc.org/en/master/usage/configuration.html
+"""
 
 import sys
 from pathlib import Path
@@ -32,6 +33,8 @@ else:
 extensions = [
     # Use this for generating API docs
     "sphinx.ext.autodoc",
+    # and making summary tables at the top of API docs
+    "sphinx.ext.autosummary",
     # This can parse google style docstrings
     "sphinx.ext.napoleon",
     # For linking to external sphinx documentation
@@ -93,6 +96,12 @@ autodoc_member_order = "bysource"
 # Don't inherit docstrings from baseclasses
 autodoc_inherit_docstrings = False
 
+# Document only what is in __all__
+autosummary_ignore_module_all = False
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ["_templates"]
+
 # Output graphviz directive produced images in a scalable format
 graphviz_output_format = "svg"
 
@@ -127,6 +136,7 @@ rst_epilog = """
 .. _black: https://github.com/psf/black
 .. _mypy: http://mypy-lang.org/
 .. _pre-commit: https://pre-commit.com/
+.. _ruff: https://github.com/astral-sh/ruff
 """
 
 # Ignore localhost links for periodic check that links in docs are valid

{mx_bluesky-1.2.0 → mx_bluesky-1.4.1}/docs/developer/general/explanations/decisions/0003-python-version-support.rst

@@ -1,4 +1,4 @@
-1. Python version support
+3. Python version support
 =========================
 
 Date: 2024-08-22

mx_bluesky-1.4.1/docs/developer/general/how-to/deploy-a-release.rst

@@ -0,0 +1,57 @@
+Deploy a New Release
+====================
+
+**Remember to discuss any new deployments with the appropriate beamline scientist.**
+
+The ``utility_scripts/deploy/deploy_mx_bluesky.py`` script will deploy the latest mx-bluesky version to a specified beamline. Deployments live in ``/dls_sw/ixx/software/bluesky/mx-bluesky_vX.X.X``. To do a new deployment you should run the deploy script from your mx-bluesky dev environment with e.g.
+If you have just created a new release, you may need to run git fetch --tags to get the newest release.
+
+.. code:: console
+
+    python ./utility_scripts/deploy/deploy_mx_bluesky.py i24
+
+
+If you want to test the script for a specific beamline you can run:
+
+.. code:: console
+
+    python ./deploy/deploy_mx_bluesky.py i03 --dev
+
+
+which will create the beamline deployment of the new release in ``/scratch/30day_tmp/mx-bluesky_release_test``.
+
+
+.. note::
+
+    When deploying on I24, the edm screens for serial crystallography will be deployed automatically along with the mx-bluesky release.
+
+
+The script has a few additional optional arguments, which can be viewed with:
+
+.. code:: console
+
+    python ./deploy/deploy_mx_bluesky.py -h
+
+
+For building and deploying a Docker image please see :doc:`../../hyperion/deploying-hyperion`.
+
+
+.. note::
+
+    On i03 the installation will succeed with error messages due to RedHat7 versions of a dependency being unavailable.
+    This results in the installation being incomplete, thus requiring the following post-installation steps:
+
+    First, on a RedHat8 workstation, run
+
+    .. code:: console
+
+        . ./.venv/bin/activate
+        pip install confluent-kafka
+
+    Then, on the control machine, run
+
+    .. code:: console
+
+        . ./.venv/bin/activate
+        pip install -e .
+        pip install -e ../dodal

mx_bluesky-1.4.1/docs/developer/general/how-to/dev-ops/dev-ops.rst

@@ -0,0 +1,8 @@
+Dev-Ops guides
+==============================
+
+.. toctree::
+    :maxdepth: 1
+    :glob:
+
+    ./*

{mx_bluesky-1.2.0/docs/developer/general/how-to → mx_bluesky-1.4.1/docs/developer/general/how-to/dev-ops}/lint.rst

@@ -1,7 +1,7 @@
 Run linting using pre-commit
 ============================
 
-Code linting is handled by black_, ruff run under pre-commit_.
+Code linting is handled by ruff_, run under pre-commit_.
 
 Running pre-commit
 ------------------
@@ -18,15 +18,15 @@ commit`` on just the files that have changed::
 Fixing issues
 -------------
 
-If black reports an issue you can tell it to reformat all the files in the
+If ruff reports an issue you can attempt to automatically reformat all the files in the
 repository::
 
-    $ black .
+    $ ruff check --fix .
 
 If you get any ruff issues you will have to fix those manually.
 
 VSCode support
 --------------
 
-The ``.vscode/settings.json`` will run black and isort formatters as well as
-flake8 checking on save. Issues will be highlighted in the editor window.
+The ``.vscode/settings.json`` will run linters and formatters 
+on save. Issues will be highlighted in the editor window.

{mx_bluesky-1.2.0/docs/developer/general/how-to → mx_bluesky-1.4.1/docs/developer/general/how-to/dev-ops}/run-tests.rst

@@ -4,7 +4,7 @@ Run the tests using pytest
 Testing is done with pytest_. It will find functions in the project that `look
 like tests`_, and run them to check for errors. You can run it with::
 
-    $ tox -e pytest
+    $ tox -e tests
 
 It will also report coverage to the commandline and to ``cov.xml``.
 

{mx_bluesky-1.2.0 → mx_bluesky-1.4.1}/docs/developer/general/index.rst

@@ -12,7 +12,7 @@ Documentation is split into four categories, and each is also accessible from li
             :caption: Tutorials
             :maxdepth: 1
 
-            tutorials/dev-install
+            tutorials/profile-tests
 
         +++
 
@@ -26,13 +26,9 @@ Documentation is split into four categories, and each is also accessible from li
 
             how-to/get-started
             how-to/contribute
-            how-to/build-docs
-            how-to/run-tests
-            how-to/static-analysis
-            how-to/lint
-            how-to/update-tools
             how-to/create-a-release
             how-to/deploy-a-release
+            how-to/dev-ops/dev-ops
 
         +++
 

{mx_bluesky-1.2.0 → mx_bluesky-1.4.1}/docs/developer/general/reference/standards.rst

@@ -15,7 +15,7 @@ The code in this repository conforms to standards set by the following tools:
 
 .. seealso::
 
-    How-to guides `../how-to/lint` and `../how-to/static-analysis`
+    How-to guides `../how-to/dev-ops/lint`
 
 .. _documentation_standards:
 
@@ -60,4 +60,4 @@ Docs follow the underlining convention::
 
 .. seealso::
 
-    How-to guide `../how-to/build-docs`
+    How-to guide `../how-to/dev-ops/build-docs`

mx_bluesky-1.4.1/docs/developer/general/tutorials/profile-tests.rst

@@ -0,0 +1,84 @@
+Unit test performance
+=====================
+
+Ideally we want to keep the run-time of the unit tests down so that they are quick for developers to run locally. 
+Preferably they should run in under a minute.
+
+General Guidelines
+------------------
+
+Where a unit test waits for some event to happen, ``wait`` on the group to complete rather than adding a fixed 
+``sleep``.
+
+If testing a timeout, ensure that the timeout constant is either configurable or appropriately ``patch`` ed to a short 
+value e.g. 
+0.1s
+
+How to profile the unit tests
+-----------------------------
+
+Sometimes tests can exhibit slowdowns for unknown reasons, in order to diagnose the cause it can be useful to profile
+the test code.
+
+The simplest way to find slow tests is to run ``pytest`` with the ``--durations`` option in order to find the slowest
+tests.
+
+e.g.
+
+.. code-block:: bash
+
+    pytest -m "not (s03 or dlstbx)" --durations=10
+
+in order to find the top 10 slowest tests
+
+You can then often step through in the debugger to find lines which execute slowly.
+
+
+More detailed profiling
+------------------------
+
+Occasionally this is not sufficient. In which case more detailed profiling is necessary
+
+Generating profiler output
+--------------------------
+
+You can install ``pytest-profiling`` to run the tests and generate profiling output
+
+e.g.
+
+.. code-block:: bash
+
+    pip install pytest-profiling
+    pytest --profile tests/unit_tests/hyperion/external_interaction/test_write_rotation_nexus.py::test_given_detector_bit_depth_changes_then_vds_datatype_as_expected
+
+
+The output of this is quite brief but it will generate more detailed ``.prof`` files in the ``prof`` directory
+
+To browse these files you need something useful. Snakeviz is a tool that can be used to browse the output:
+
+.. code-block:: bash
+
+    cd prof
+    pip install snakeviz
+    snakeviz combined.prof
+
+An alternative tool is py-spy.
+
+e.g.
+
+.. code-block:: bash
+
+    pip install py-spy
+    py-spy record -o profile.svg -- pytest -s tests/unit_tests/hyperion/experiment_plans/test_robot_load_then_centre.py::test_given_no_energy_supplied_when_robot_load_then_centre_current_energy_set_on_eiger
+
+This will generator an interactive SVG flamechart that can be opened in a browser to see hot methods.
+
+Alternatively something like
+
+.. code-block:: bash
+
+    py-spy top -- pytest -s tests/unit_tests/hyperion/experiment_plans/test_robot_load_then_centre.py::test_given_no_energy_supplied_when_robot_load_then_centre_current_energy_set_on_eiger
+
+to view a ``top`` -like updating view of where time is being spent. You will probably need to temporarily annotate the 
+test with
+``@pytest.mark.parametrize`` in order to make the tests loop sufficient times in order to observe.

{mx_bluesky-1.2.0 → mx_bluesky-1.4.1}/docs/developer/hyperion/deploying-hyperion.rst

@@ -1,11 +1,11 @@
 Building a deployable Docker image
 ==================================
 
-Release builds of container images should be built by the github CI on release, ad-hoc builds can be performed via 
+Release builds of container images should be built by the github CI on release, ad-hoc builds can be performed via
 manual invocation of the Publish Docker Image workflow.
 
 Development builds of container images can be made by running the ``utility_scripts/build_docker_image.sh`` script.
-By default it will both build and push the image unless you specify ``--no-build`` or ``--no-push``. To push an image 
+By default it will both build and push the image unless you specify ``--no-build`` or ``--no-push``. To push an image
 you will first need to create a GH personal access token and then log in with podman as described below.
 
 Pushing the docker image
@@ -79,16 +79,16 @@ Then create and deploy the helm release
 
     ./utility_scripts/deploy/deploy_hyperion_to_k8s.sh --beamline=<beamline> --checkout-to-prod hyperion
 
-This will run the ``deploy_hyperion.py`` script to deploy the latest hyperion to ``/dls_sw``.
+This will run the ``deploy_mx_bluesky.py`` script to deploy the latest hyperion to ``/dls_sw``.
 You will be prompted to log into the beamline cluster, then it will create a helm release "hyperion".
-The source folders will be mounted as bind mounts to allow the pod to pick up changes in production. 
+The source folders will be mounted as bind mounts to allow the pod to pick up changes in production.
 For production these are expected to be in the normal place defined in ``values.yaml``.
 
 Development deployment
 ~~~~~~~~~~~~~~~~~~~~~~
 
-From a development ``hyperion`` workspace, either with a release image or using a development image built with the 
-script 
+From a development ``hyperion`` workspace, either with a release image or using a development image built with the
+script
 above, you install a dev deployment to the cluster you are currently logged into with ``kubectl``:
 
 ::
@@ -96,12 +96,12 @@ above, you install a dev deployment to the cluster you are currently logged into
     ./utility_scripts/deploy/deploy_hyperion_to_k8s.sh --dev --beamline=<beamline> --repository=<your image repo> hyperion-test
 
 
-The dev deployment bind-mounts the current ``hyperion`` workspace and ``../dodal`` into the container so that you can 
-run against your own development code. **Clusters do not allow bind mounts from arbitrary directories so 
+The dev deployment bind-mounts the current ``hyperion`` workspace and ``../dodal`` into the container so that you can
+run against your own development code. **Clusters do not allow bind mounts from arbitrary directories so
 your workspace will have to be in a permitted directory such as your home directory.**
 
-By default the script will log into the ``argus`` cluster, if you want to deploy to an alternate cluster, 
-log in with ``kubectl set-context --current --namespace=<NAMESPACE>`` and then specify ``--no-login`` when running the 
+By default the script will log into the ``argus`` cluster, if you want to deploy to an alternate cluster,
+log in with ``kubectl set-context --current --namespace=<NAMESPACE>`` and then specify ``--no-login`` when running the
 script
 
 Please note, the deployment script is intended to be run from a checked-out matching version of the git repository.

{mx_bluesky-1.2.0 → mx_bluesky-1.4.1}/docs/developer/hyperion/index.rst

@@ -1,7 +1,7 @@
-General MX-Bluesky Developer Guide
+Hyperion Developer Guide
 ==================================
 
-Documentation is split into four categories, and each is also accessible from links in the side-bar.
+Documentation specific for the Hyperion module within MX-Bluesky
 
 .. grid:: 2
     :gutter: 2

{mx_bluesky-1.2.0 → mx_bluesky-1.4.1}/docs/developer/hyperion/reference/param_hierarchy.puml

@@ -31,7 +31,7 @@ package Experiments {
     class RobotLoadAndEnergyChange
     class RobotLoadThenCentre
     class SpecifiedGridScan
-    class ThreeDGridScan
+    class HyperionThreeDGridScan
 }
 
 class HyperionParameters
@@ -66,9 +66,9 @@ RobotLoadThenCentre *-- RobotLoadAndEnergyChange
 RobotLoadThenCentre *-- PinTipCentreThenXrayCentre
 GridCommon <|-- SpecifiedGridScan
 WithScan <|-- SpecifiedGridScan
-SpecifiedGridScan <|-- ThreeDGridScan
-SplitScan <|-- ThreeDGridScan
-WithOptionalEnergyChange <|-- ThreeDGridScan
+SpecifiedGridScan <|-- HyperionThreeDGridScan
+SplitScan <|-- HyperionThreeDGridScan
+WithOptionalEnergyChange <|-- HyperionThreeDGridScan
 WithOavCentring <|-- GridCommon
 WithScan <|-- RotationScan
 RotationScanPerSweep <|-- RotationScan