Identify Peaks in Region

[Owen Arnold]

Recent profiler analysis relating to #7217 shows that the process of zooming to a peak location is very expensive. The processing is done in the GUI thread, and always results in every peak widget being interacted with. The solution does not scale well when there are > 1000 peaks. Profiler results are indicating that the widget update() call is the largest contribution to the execution times. It is not apparent how the individual update calls could be optimized. A better solution may be to simply focus the problem so that fewer update calls are required.

The problem could be well handled in a parallel fashion. It would be much better if we could throw additional resources at the problem of finding which peaks intesect a given region. We could do this with n-threads in Mantid, which should be much quicker than the current route.

Plan is to generate a new algorithm called PeaksInRegion, which will take a peaks workspace, the coodinates system for a region (Q_lab, HKL, Q_sample), and a set of coordinates. It will return the indexes of those peaks found to intesect with the region.

[Owen Arnold]

BenchMark. First Pass of performance tests (single threaded). Processing 4000 peaks in 0.052 of a second.

<?xml version="1.0" encoding="UTF-8" ?> 
 <testsuite name="CrystalTest" tests="1" errors="0" failures="0" package="CrystalTest" time="0.053">
 <testcase classname="CrystalTest.PeaksInRegionTestPerformance" name="testPerformance" line="257" time="0.052" totalTime="0.053" CPUFraction="1">
 <measurement>
  <name>CPUFraction</name> 
  <value>1</value> 
  </measurement>
  </testcase>
  </testsuite>

[Owen Arnold]

refs #7233. First implementation with tests.

Changeset: 2b040b24b3cf254f11373c0e485ef511845659b7

[Owen Arnold]

Process peaks in an OpenMP loop. Now proccesses 4000 peaks in 0.044 of a second

  <?xml version="1.0" encoding="UTF-8" ?> 
 <testsuite name="CrystalTest" tests="1" errors="0" failures="0" package="CrystalTest" time="0.045">
 <testcase classname="CrystalTest.PeaksInRegionTestPerformance" name="testPerformance" line="257" time="0.044" totalTime="0.045" CPUFraction="1">
 <measurement>
  <name>CPUFraction</name> 
  <value>1</value> 
  </measurement>
  </testcase>
  </testsuite>

[Owen Arnold]

4000 peaks 
Single threaded = 0.052 
Multi threaded = 0.044 
Fractional time multithreaded = 0.846
 
10000 peaks 
Single threaded = 0.084s 
Multi threaded = 0.110s 
Fractional time multithreaded = 0.764

40000 peaks 
Single threaded = 0.404 
Multi threaded = 0.345
Fractional time multithreaded = 0.850

[Owen Arnold]

refs #7233. Multithreaded peak intersection search

Changeset: 44f840c6e39bf2f82bf1d1fc134434194ec89104

[Owen Arnold]

refs #7233. Check sphere-plane intersection.

Changeset: 83637b50467904665adf6de9564db39d961b977b

[Owen Arnold]

refs #7233. Fix calculation error.

Changeset: 4d57b6d774235846f6689aaf2fc567717acc7390

[Owen Arnold]

refs #7233. Add progress reporting.

Changeset: 2c555032f27bb3dc163cdf946fab71c820130257

[Owen Arnold]

Tester:

Load the MANDI peaks file attached to #7217. Then run the following on that peaks file:

PeaksInRegion(InputWorkspace='peaks',CoordinateFrame='Q (lab frame)',Extents='-1,1,-1,1,2,4',OutputWorkspace='peaks_in_region')

Open up the peaks file and the output table workspace file side by side in ManidPlot. You should be able to see why each peak has been accepted/rejected as part of that region defined by the extents.

Also set the CheckExtents flag to true and modify the PeaksRadius parameter. You should be able to include additional peaks into the region by extending the radius parameter.

Also check that the unit tests run, because these provide extensive test coverage of the various usage scenarios.

[Stuart Campbell]

This ticket has been transferred to github issue ​8079