This project is mirrored from Pull mirroring updated .
  1. 26 Jan, 2021 2 commits
  2. 08 Dec, 2020 4 commits
  3. 07 Dec, 2020 2 commits
  4. 16 Nov, 2020 1 commit
  5. 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
  6. 29 Sep, 2020 1 commit
    • 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
  7. 07 Apr, 2020 1 commit
    • Giovanni Di Siena's avatar
      Replace boost::shared with std::shared · 11994bc3
      Giovanni Di Siena authored and Gigg, Martyn Anthony's avatar Gigg, Martyn Anthony committed
      In places other substitutions have been made, e.g
      Clang does not yet specialize std::shared_ptr for T[]. Vector
      has been used instead. The operator[] methods were incorrectly
      marked const but returning a non-const reference - this has been fixed.
      Refs #25842
  8. 20 Mar, 2020 1 commit
  9. 10 Mar, 2020 4 commits
  10. 09 Mar, 2020 4 commits
  11. 05 Mar, 2020 2 commits
  12. 18 Nov, 2019 1 commit
  13. 23 Sep, 2019 1 commit
  14. 19 Aug, 2019 1 commit
  15. 18 Jul, 2019 1 commit
    • Dan Nixon's avatar
      Implement grouped parallel event insertion · a0af5e6b
      Dan Nixon authored
      This is based on the prototype derived from the meeting at the DMSC last December.
      The workflow is as follows:
        - Pool all events received from the Kafka stream into a single buffer
        - When the buffer is to be flushed (i.e. events populated in the EventWorkspace):
          - Parallel sort the event buffer by the detector ID/workspace index
          - Determine group boundaries
          - Parallel insert events into EventWorkspace
      Also included is the optimisation of using a spec to ID mapping based on
      a vector rather than map.
      This provides better performance during the initial event buffering
      (where this lookup is made).
      Initial benchamrking shows 25M events is a intermediate buffer threshold
      for LOKI (9 banks) at 10^7 events per second.
      This manages to maintain well over 14Hz pulse rate (with no post
  16. 08 Jul, 2019 1 commit
  17. 20 Jun, 2019 1 commit
  18. 17 Jun, 2019 2 commits
  19. 15 May, 2019 2 commits
  20. 30 Apr, 2019 1 commit
  21. 19 Mar, 2019 1 commit
  22. 26 Feb, 2019 2 commits
  23. 01 Feb, 2019 1 commit
  24. 21 Jan, 2019 1 commit
  25. 18 Jan, 2019 1 commit