Skip to content

Conversation

ekapadi
Copy link
Contributor

@ekapadi ekapadi commented Oct 29, 2024

Description of work

Mantid's interpretation of the NeXus format uses multiple root-level "NX_class: NXentry" groups to store multiple workspaces in a single NeXus HDF5 file. By using additional root-level groups, such as "NX_class: NXcollection", metadata about a group of workspaces may be stored. In addition, the NeXus format itself allows other, non-NeXus information to be stored in an HDF5 file, provided it avoids collisions with the NeXus naming system. In combination, all of this led to the requirement solved by the current PR, which allows LoadNexusProcessed to function correctly in the presence of other root-level non-NXentry and non-NeXus groups.

Summary of work

This commit includes the following changes:

  • When LoadNexusProcessed is determining the number of workspaces in a NeXus HDF5 file, it now counts the number of root-level "NX_class: NXentry" groups. Previously, it counted the number of root-level groups, assuming all were of "NX_class: NXentry".

EWM ref:

EWM#7148

To test:

A new unit test has been added to test these changes: LoadNexusProcessedTest::test_load_workspace_group_other_root_groups.

In order to verify these changes "by hand" it's recommended to take a look at the contents of the test-input file: build/ExternalData/Testing/Data/UnitTest/WorkspaceGroup_other_groups.nxs using the h5dump tool. In addition to including twelve workspaces (, as NX_class: NXentry "mantid_workspace_nn" groups), this file adds a root-level NX_class: NXcollection "metadata" group, and another root-level non-NeXus group. Following the form of the new unit test, verify that LoadNexusProcessed loads this file as a group workspace, and successfully ignores the other root-level groups in the file.


Reviewer

Please comment on the points listed below (full description).
Your comments will be used as part of the gatekeeper process, so please comment clearly on what you have checked during your review. If changes are made to the PR during the review process then your final comment will be the most important for gatekeepers. In this comment you should make it clear why any earlier review is still valid, or confirm that all requested changes have been addressed.

Code Review

  • Is the code of an acceptable quality?
  • Does the code conform to the coding standards?
  • Are the unit tests small and test the class in isolation?
  • If there is GUI work does it follow the GUI standards?
  • If there are changes in the release notes then do they describe the changes appropriately?
  • Do the release notes conform to the release notes guide?

Functional Tests

  • Do changes function as described? Add comments below that describe the tests performed?
  • Do the changes handle unexpected situations, e.g. bad input?
  • Has the relevant (user and developer) documentation been added/updated?

Does everything look good? Mark the review as Approve. A member of @mantidproject/gatekeepers will take care of it.

Gatekeeper

If you need to request changes to a PR then please add a comment and set the review status to "Request changes". This will stop the PR from showing up in the list for other gatekeepers.

@sf1919
Copy link
Contributor

sf1919 commented Oct 30, 2024

Please can you add a milestone to this PR? If you can add labels too that would be good.

@ekapadi ekapadi added this to the Release 6.12 milestone Oct 30, 2024
@ekapadi ekapadi added Framework Issues and pull requests related to components in the Framework ORNL Team Issues and pull requests managed by the ORNL development team labels Oct 30, 2024
@walshmm walshmm self-requested a review November 5, 2024 18:13
@walshmm
Copy link
Contributor

walshmm commented Nov 5, 2024

Building too much longer than verifying 😅

Code Review

Functional

  • Do changes function as described? Add comments below that describe the tests

Grep of the test file listing the 12 expected workspaces
image

And a sample of the newly added metadata:
image

all Root level groups can be see here:
image
where there are the two additional groups that are not workspaces.

  • Do the changes handle unexpected situations, e.g. bad
  • Has the relevant (user and developer) documentation been added/updated?

@walshmm
Copy link
Contributor

walshmm commented Nov 5, 2024

The test written does confirm that in the presence of these other groups it will function and load the file.

walshmm
walshmm previously approved these changes Nov 5, 2024
Copy link
Contributor

@walshmm walshmm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved, please find a gatekeeper!

Mantid's interpretation of the NeXus format uses multiple root-level "NX_class: NXentry" groups to store multiple workspaces in a single NeXus HDF5 file.  By using additional root-level groups, such as "NX_class: NXcollection", metadata about a group of workspaces may be stored.  In addition, the NeXus format itself allows other, non-NeXus information to be stored in an HDF5 file, provided it avoids collisions with the NeXus naming system.  In combination, all of this led to the requirement solved by the current PR, which allows `LoadNexusProcessed` to function correctly in the presence of other root-level non-NXentry and non-NeXus groups.

This commit includes the following changes:

  * When `LoadNexusProcessed` is determining the number of workspaces in a NeXus HDF5 file, it now counts the number of root-level "NX_class: NXentry" groups.  Previously, it counted the number of root-level groups, assuming all were of "NX_class: NXentry".
@ekapadi ekapadi force-pushed the EWM7148_LoadNexusProcessed_root_groups-main branch from 2eb2588 to 0c2cfdf Compare November 7, 2024 16:14
@peterfpeterson peterfpeterson merged commit 87b579b into main Nov 7, 2024
10 checks passed
@peterfpeterson peterfpeterson deleted the EWM7148_LoadNexusProcessed_root_groups-main branch November 7, 2024 18:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Framework Issues and pull requests related to components in the Framework ORNL Team Issues and pull requests managed by the ORNL development team

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants