1. 06 Mar, 2019 2 commits
  2. 20 Feb, 2019 1 commit
  3. 15 Feb, 2019 3 commits
  4. 14 Feb, 2019 1 commit
  5. 12 Feb, 2019 1 commit
  6. 11 Feb, 2019 3 commits
  7. 04 Feb, 2019 1 commit
  8. 24 Jan, 2019 2 commits
    • Enrico Bothmann's avatar
      Fix YAML syntax in LHC_Tops example · 4143fa86
      Enrico Bothmann authored
      ... and remove the outdated LOOSE_METS tag, which leads to yet another
      crash. In addition, clean up the syntax in the Tops_plus_* examples.
      Lastly, remove obsolete (and possibly problematic?) semicolons after
      SCALES specifications.
      4143fa86
    • Enrico Bothmann's avatar
      Rewrite settings input using YAML · eb96f45c
      Enrico Bothmann authored
      This commit closes #10.
      
      - Replace custom configuration parsing and format with a YAML-based
        solution
      - Improve implementation of settings handling to enable features such
        as:
        - Generally only specify defaults once in the code, not scattered
          throughout with possibly different values
        - Print comprehensive report of values used for each setting at the
          end of a run
        - Warn when a setting is specified that is not used during a run (this
          is foreseen and now possible, but not implemented yet)
      
      NOTE: This is a squashed commit to keep the commit history of master
      simple. The full history of the development branch will be retained as
      10-rewrite-settings-input+commit-history in case it is needed, e.g. to
      find a (small) changeset that introduced a bug using git-bisect.
      
      A good example for new syntax is:
      Examples/V_plus_Jets/LHC_WJets/Sherpa.yaml
      
      The command line can process words using the YAML syntax, but also
      supports the old legacy syntax, at least for scalar settings.
      
      In the code, setting default settings and getting the resolved value
      for a setting can be done e.g. as follows:
      
      ```
      auto hds = Settings::GetMainSettings()["HARD_DECAYS"];
      const auto apply_br
        = hds["Apply_Branching_Ratios"].SetDefault(true).Get<bool>();
      ```
      
      Note also that Sherpa can now process several configuration files:
      `Sherpa "RUNDATA: [1.yaml, 2.yaml, ...]"`, with settings in files to the
      right taking precedence over settings in files to the left. This can be
      useful for specifying base set-ups and then deriving specialisations.
      
      A more detailed discussion of the new settings architecture is given
      in
      https://gitlab.com/sherpa-team/sherpa/wikis/The-new-Settings-implementation
      (accessing this link might require developer access to the repository).
      
      Lastly, note that physics results are guaranteed to stay the same after
      this commit. If you find that to be not true, please contact me. When
      soft physics is used, numerics sometimes causes the statistics not to be
      the same after this commit. However, I've got some patches to mitigate
      this to some degree. So in any case, contact me if you find differences
      between results generated with this commit and the preceding one.
      eb96f45c
  9. 23 Jan, 2019 1 commit
  10. 22 Jan, 2019 2 commits
  11. 21 Jan, 2019 2 commits
  12. 17 Jan, 2019 5 commits
  13. 16 Jan, 2019 1 commit
  14. 15 Jan, 2019 1 commit
  15. 09 Jan, 2019 2 commits
    • Enrico Bothmann's avatar
      Fix call to AlphaSLam with nonsensical scales · a5cc4c55
      Enrico Bothmann authored
      This fixes #102 on the caller side and is therefore preferred to the
      previous attempt to fix this in 05749814, which is a workaround in the
      wrongly called function.  This seems to be a safer solution to me.
      
      I tested this patch by printing all members of p_thresh after the
      initialization before and after the patch, and I get the exact same
      results output (except for some uninitialized members that are never
      set, i.e. the beta0 member for the AsDataSet for nf=0,1,2).
      a5cc4c55
    • Enrico Bothmann's avatar
      Revert "implemented fix to catch nan in alphaS" · ae446ca6
      Enrico Bothmann authored
      This reverts commit 05749814.
      ae446ca6
  16. 08 Jan, 2019 1 commit
  17. 07 Jan, 2019 2 commits
  18. 06 Jan, 2019 1 commit
    • Enrico Bothmann's avatar
      Fix (limited) Gaussian random number generation · de30ff96
      Enrico Bothmann authored
      ... for the primordial kT determination. The Marsaglia algorithm was
      wrongly implemented (and missed an opportunity for optimisation by not
      storing the second Gaussian random number for later use), and the
      LimitedWeight function did not rescale its hit-or-miss comparison
      function to a maximum of 1, which was extremely inefficient for low
      kTmax, where basically every kT candidate was unnecessarily rejected by
      LimitedWeight.
      
      Other changes
      ===
      
      The Gaussian random number algorithm is now implemented in Random.H and
      supersedes the previous one, which was less efficient. At that
      opportunity, I have also removed superfluous `inline` keyword uses in
      front of member function definitions.
      
      Observations in performance measurements
      ===
      
      - When running 10k events for Examples/CI/LO_Z, this will increase event
        generation speed by ~50% when using -O3. This measurement will vary
        strongly, because events with very low kTmax seem to occur only every
        few thousand events.
      
      - There is however a significant increase in Retried events from
        Hadron_Decays (before 9, after 38).
      
      Further remarks
      ===
      
      - Note that there is a chance that this fix renders previous tuning partly
        invalid.
      
      - Note that the Primordial kT generation using a Gaussian with a fixed
        width and an a-posteriori hit-or-miss Monte-Carlo that can have a
        width that is way smaller might still be very inefficient. The Gaussian
        generates a lot of large numbers before being accepted by the
        LimitedWeight. The Gaussian takes a kTmax argument but does not use it.
        This raises the question if perhaps this is not intended behaviour in
        the first place.
      de30ff96
  19. 04 Jan, 2019 3 commits
  20. 02 Jan, 2019 2 commits
    • Enrico Bothmann's avatar
      Re-use cumulative splitting sum tables · cc6873ff
      Enrico Bothmann authored
      ... improving on the implementation of the previous commit.  This makes
      the mentioned evtgen an additional 1.9(7)% faster.
      cc6873ff
    • Enrico Bothmann's avatar
      Stop using vec of vecs in Dire::GeneratePoint · 13b7a15d
      Enrico Bothmann authored
      ... which is an (LO+PS) evtgen hot-spot, even for particle-level
      production. One of the reasons has been the use of a vector of vectors
      to store cumulative sums for the winner-takes-all algorithm of the
      shower. Instead we use a large C array now. This made event generation
      for Examples/CI/LO_Z 2.6(5)% faster (when using -O3).
      13b7a15d
  21. 05 Dec, 2018 3 commits