This project is mirrored from Pull mirroring updated .
  1. 30 Sep, 2020 1 commit
    • Danny Hindson's avatar
      Revert MatrixWorkspace::isHistogramData API to original form · b0e14e06
      Danny Hindson authored
      Based on review comments, revert the isHistogramData method to its
      original form without any parameters to avoid encouraging creation
      of matrix workspaces containing histograms with mix of xModes
      Create private function instead that allows a specific histogram to
      be checked
  2. 29 Sep, 2020 3 commits
    • Danny Hindson's avatar
      Resolve unused argument compiler warning · 0545e4f8
      Danny Hindson authored
    • Danny Hindson's avatar
      Expose new optional parameter to python · 7c5d08e0
      Danny Hindson authored
    • Danny Hindson's avatar
      Fix access violation in MonteCarloAbsorption · 9918c93b
      Danny Hindson authored
      The unit test suite MonteCarloAbsorptionTest has occasionally been failing
      with an access violation on Jenkins. I've been able to track this down to
      the test Lambda_StepSize_Two_Linear_Interpolation which was failing
      I can reproduce this locally by modifying the test to repeat 1000 times
      and it eventually fails. Although the access violation occurs in a couple
      of different places:
      a) the y() or e() vector in the 0th histogram is sometimes empty once the
      MonteCarloAbsorption algorithm completes which causes some of the test asserts
      to fall over because they assume y(0).front() or e(0).front
      b) sometimes the code in MonteCarloAbsorption itself has an access violation
      when yIndexOfX returns an index out of range of the histogram
      Both problems happen in the multi-threaded code in MonteCarloAbsorption and
      it seems to be the interaction between the call to MatrixWorkspace::yIndexOfX
      and the code that updates a histogram with interpolated results via
      MatrixWorkspace::setHistogram. Something in these two functions isn't threadsafe
      I found that yIndexOfX calls IsHistogramData() which checks the 0th
      histogram in the workspcae even if the MonteCarloAbsorption code is
      processing the 1st, 2nd etc workspace
      I think if the 0th histogram is in the process of being updated by another
      thread then yIndexOfX can fail or else the setHistogram call fails.
      I have done two changes:
      - only call yIndexOfX once (there was a redundant 2nd call)
      - I have modified yIndexOfX so it takes an additional histogram index parameter.
      This allows me to keep each MonteCarloAbsorption thread interacting with a
      single histogram only. I have defaulted the new parameter to zero so other
      code behaves as before
  3. 28 Sep, 2020 14 commits
  4. 25 Sep, 2020 18 commits
  5. 24 Sep, 2020 4 commits