Project

General

Profile

Bug #1852

Duplicate primaries in G4BL input

Added by Rogers, Chris over 5 years ago. Updated about 5 years ago.

Status:
Open
Priority:
Normal
Category:
Simulation
Target version:
Start date:
01 June 2016
Due date:
% Done:

0%

Estimated time:
Workflow:
New Issue

Description

I notice that it seems rather easy to generate duplicate primaries in G4BL input deck.

I attach a couple of sample data sets and a script that finds duplicates and prints them. Is this intentional behaviour? It seems dangerous to me...


Files

duplicate_primaries.tar.gz (6.16 MB) duplicate_primaries.tar.gz Rogers, Chris, 01 June 2016 16:21
random_seed.patch (7.62 KB) random_seed.patch Rogers, Chris, 06 June 2016 17:35
random_seed.patch_2 (12.9 KB) random_seed.patch_2 Rogers, Chris, 07 June 2016 16:46
test_simulate_beam.tar.gz (347 KB) test_simulate_beam.tar.gz Rogers, Chris, 07 June 2016 16:46
primary.log (76 KB) primary.log Mohayai, Tanaz Angelina, 07 June 2016 16:53
#1

Updated by Rajaram, Durga over 5 years ago

John -- any ideas on this?

#2

Updated by Rogers, Chris over 5 years ago

Potential patch attached. Nb: I note that most of the tests in test_mappybeamlinesimulation are failing right now. I put in a mockup CallG4bl thing which one could extend to make them pass... but did not dig too hard (too much else to dig into right now).

#3

Updated by Rogers, Chris over 5 years ago

Its not quite right... need to be able to handle multiple input random seeds (for running several input jobs)... will try again today

#4

Updated by Rogers, Chris over 5 years ago

I noticed that CallG4bl has a bug that the random_seed of generated primaries (which is used to seed geant4) is the same for every event in a given g4bl output file. It should be unique for each event. Instead of using just the g4bl random seed, I modified it to use g4bl random seed + line number (i.e. position in the g4bl file).

#5

Updated by Rogers, Chris over 5 years ago

Another issue - the json cpp -> ROOT/C++ conversion can't handle more than 32 bit integers. It is possible to fix without too much hassle. For now I only permit 32bit random seeds (note this is 2 billion random seeds allowed, which means non-zero probability of a random seed collision).

So it looks like the latest version works - attached integration test in test_simulation_beam.tar.gz (along with unit tests in the random_seed.patch_2 which was a hack of stuff in duplicate_primaries.tar.gz).

#6

Updated by Mohayai, Tanaz Angelina over 5 years ago

Hi Chris, I remember seeing similar duplicate primaries in my G4beamline input deck. This was when I was using MAUS v0.9.7; if I recall correctly, the issue was resolved when I switched to v1.4.0, which was the latest version at the time. I have also ran a recent simulation with v2.4.0 and according to the attached primary.log file (from your primary.py script), the duplicate primaries seem to be no longer present.

#7

Updated by Dobbs, Adam about 5 years ago

Chris, I have applied the patch files to one of my local branches - are you happy for it to go into the trunk?

#8

Updated by Dobbs, Adam about 5 years ago

Chris, I have applied the patch files to one of my local branches - are you happy for it to go into the trunk?

#9

Updated by Rogers, Chris about 5 years ago

Yes, certainly!

Also available in: Atom PDF