HDGeant4 Meeting, June 30, 2020

From GlueXWiki
Revision as of 16:23, 30 June 2020 by Marki (Talk | contribs) (added minutes)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

HDGeant4 Meeting
Tuesday, June 30, 2020
3:00 pm EDT
BlueJeans: 968 592 007


  1. Announcement: New version set with upgrade to Geant4: version_4.21.3.xml
  2. Review of minutes from the last meeting (all)
  3. Issues on GitHub
  4. Pull Requests on GitHub
  5. Action Item Review


Present: Alex Austregesilo, Sean Dobbs, Colin Gleason, Mark Ito (chair), Igal Jaegle, Richard Jones, Simon Taylor, Nilanga Wickramaarachchi

There is a recording of this meeting on the BlueJeans site. Use your JLab credentials to get access.

Announcement: Version Set with Upgraded Geant4

A new version set with upgrade to Geant4: version_4.21.3.xml was released today. Mark described it and attendant caveats. This led to a discussion of upgrading compilers.

  • We did not go further with Geant4 versions because of limitations with the CentOS7 native compiler.
  • Similar issues may arise with ROOT.
  • There are three options to address the issue:
    1. Do nothing and accept the limitations imposed by the default GCC 4.8.5 compiler
    2. Require users to use a container for all software-dependent functions where the container has a non-CentOS7-default version of the compiler installed.
    3. Require users to implement advanced compilers on their systems either by
      1. using a system like Software Collections
      2. or installing more modern compiler versions natively

There are various use cases that may (or may not) need support going forward, e.g., farm user at JLab, developer on a private desktop or laptop machine, maintainer of a university cluster, etc.

We will have to return to this discussion at some point.

Review of minutes from the last Meeting

We went over the minutes from June 16 without extensive comment.

Issues on GitHub

We reviewed the issues.

Energy deposition in TOF mismatch in data & MC #159

Sean cross-posted this issue from the halld_sim repository to hdgeant4.

BCAL reconstructed energy sometimes broken on startup: multicore only #143

Richard reported progress on non-reproducible BCAL energy results when running hdgeant4 with multiple threads. He has discovered a pathology with the "division" technique of Geant4 to create multiple sensitive detector channels. HDGeant4 uses this feature ubiquitously, not only in the BCAL but also in the CDC, FCAL, TOF, etc. The implementation of divisions turns to be manifestly non-thread-safe. Another technique, the Geant4 "replica" feature, does have thread safety built in and Richard has followed that code as a model for how to implement thread safety for divisions.

In the process, Richard identified a separate issue where results from one events depend on details of how processing proceed with previous events, an effect he is calling hysteresis. This leads to non-reproducibility in repeated execution of the code starting with the same random number seeds each time. He believes the problem lies in the code to do charged particle propagation through magnetic fields.

He concludes that all results to date of multi-threaded running of HDGeant4 are suspect. Luckily, the running we have been doing on the OSG has always been single-threaded.

Pull Requests on GitHub

We looked over the pull requests. Igal submitted changes to simulate the lead tungstate insert for FCAL2. He based his changes on work done by Simon. Simon explained that, in terms of material, the insert is implemented as a single block, but sub-divided to give individual read-out channels following the scheme used in the FCAL. The pull request has been merged.

Action Item Review

  1. Continue work on the BCAL multi-threading problem (Richard)
  2. Structure a discussion on advanced compiler versions (Mark)
  3. Try out the bcal_nolight_heavy_rtj branch. (Colin)
  4. Merge issues #93 and #111 (Mark)