Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Common code in IntegratePeaksSkew, IntegratePeaksShoeboxTOF, FindSXPeaksConvolve, IntegratePeaks1DProfile algorithms moved to a utility module #38789

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

warunawickramasingha
Copy link
Contributor

Description of work

A code refactoring was performed by extracting a bunch of common code inside a few peak integration algorithms into a common module named peakdata_utils.

Now those algorithms can import such utility code from the new module rather than importing directly from other algorithms. This PR makes sure that code inside IntegratePeaksSkew, IntegratePeaksShoeboxTOF, FindSXPeaksConvolve, and IntegratePeaks1DProfile would only contain the code specific to each algorithm and utility functions related to peak integration would be imported from the newly introduced utility module.

Fixes #36989.

Further detail of work

To test:

There should be NO functional changes in the below peak integration algorithms and they should work exactly as they did before.

  1. IntegratePeaksSkew
  2. IntegratePeaksShoeboxTOF
  3. FindSXPeaksConvolve
  4. IntegratePeaks1DProfile

A release note was added to notify about the update required in import paths in any external scripts if those utility classes are being used directly.


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.

@warunawickramasingha warunawickramasingha added Maintenance Unassigned issues to be addressed in the next maintenance period. Diffraction Issues and pull requests related to diffraction Single Crystal Issues and pull requests related to single crystal labels Feb 4, 2025
@warunawickramasingha warunawickramasingha added this to the Release 6.13 milestone Feb 4, 2025
@sf1919 sf1919 assigned Despiix and RichardWaiteSTFC and unassigned Despiix Feb 5, 2025
Copy link
Contributor

@RichardWaiteSTFC RichardWaiteSTFC left a comment

Choose a reason for hiding this comment

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

Thanks for this, really appreciate it, been on the backlog for a while!
No unit test5s required changing so that's promising!
Just a couple of suggestions:

  • I wonder whether it would be possible to have the IntegratePeaksSkew method have a PeakDataSkew class that inherits from PeakData and then has additional skew-specific methods associated with it (e.g. plot_integrated_peak) - such that only the methods common to all algorithms are in the peakdata_utils does that make sense?
  • There's some InstrumentArrayConverter tests in unit tests for IntegratePeaksSkew e.g.
    def test_array_converter_finds_adjacent_banks_to_left_for_component_array_detectors(self):

    would it be possible to move these to a unit test file for peakdata_utils?

@warunawickramasingha warunawickramasingha changed the title 36989 common code in integration algos moved to a util module Common code in IntegratePeaksSkew, IntegratePeaksShoeboxTOF, FindSXPeaksConvolve, IntegratePeaks1DProfile algorithms moved to a utility module Feb 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Diffraction Issues and pull requests related to diffraction Maintenance Unassigned issues to be addressed in the next maintenance period. Single Crystal Issues and pull requests related to single crystal
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Move common code from IntegratePEaksSkew, IntegratePeaksShoeboxTOF and FindSXPEaksConvolve to separate file
3 participants