Project

General

Profile

Actions

Sim-Development #1261

open

Problems with transport of multiple different nuclear fragments in GEANT4

Added by Oleg Golosov over 3 years ago. Updated over 1 year ago.

Status:
Assigned
Priority:
Normal
Assignee:
Target version:
-
Start date:
04/02/2019
Due date:
12/20/2019 (over 2 years late)
% Done:

20%

Estimated time:
10.00 h
Spent time:

Description

Running transport macro with CbmUnigenGenerator and GEANT4 often ends up in a crash.
Most probably it comes from some limitation on maximum amount on additionally registered particles in GEANT4.
In CbmUnigenGenerator all the nuclei found in particular file with model output are registered using FairRunSim::AddNewIon(FairIon*) method.
Half of files containing 1000 events fail on this step supposedly because of the large number of registered ions (~300).
Example log is attached.

The interesting thing is that the same files are transported properly with GEANT3.

How could we overcome this limitation?


Files

transport.log.gz (41.8 KB) transport.log.gz Oleg Golosov, 04/02/2019 06:15 PM
transport_successful.log.gz (138 KB) transport_successful.log.gz Oleg Golosov, 04/02/2019 06:42 PM
Actions #1

Updated by Oleg Golosov over 3 years ago

UPDATE: most probably I was wrong concerning the origin of the problem.

There are files containing ~500 different nuclei and successfully transported (log attached) so there must be some other cause for the crash.

Actions #2

Updated by Volker Friese over 3 years ago

  • Tracker changed from Bug to Sim-Development
  • Project changed from CbmRoot to Simulation
  • Status changed from New to Assigned
  • Target version changed from APR19 to OCT19
  • Estimated time set to 10.00 h

I will not be able to debug this in time for APR19. I set it to the agenda for the next release.

Actions #3

Updated by Florian Uhlig about 3 years ago

  • Assignee changed from Volker Friese to Oleg Golosov

Oleg could you please provide input files such that I can test it myself.

Actions #4

Updated by Florian Uhlig about 3 years ago

  • % Done changed from 0 to 20

Forget ma last comment. I found the file myself when I looked in the log file. The location was slightly different but I hope it is the correct file.

/lustre/nyx/cbm/users/ogolosov/mc/generators/dcmqgsm_abotvina/auau/pbeam12agev/mbias/root/dcmqgsm_4.root

As first steep I did a simulation using Geant3 which worked without problems. Changing to Geant4 as transport engine worked for me also without problems.
The only difference between your test and my test were probably different Geant4 version. I used FairSoft jun19p1 which contains Geant4 10.5.1 whereas you used FairSoft may18 which comes with Geant4 10.4.1,

Could you please try to run the simulations using FairSoft jun19p1. Maybe the problem was meanwhile solved in Geant4.

Actions #5

Updated by Oleg Golosov about 3 years ago

  • Assignee changed from Oleg Golosov to Volker Friese

Dear Florian,

Transition to newer Geant4 version did not help.
Apparently this has been the model problem.
Last week we received an update from the author of DCMQGSM-SMM which excluded from the model formation of exotic nuclei with A=20 and Z~1-2.
I generated model files with the new code and the problem with Geant4 seems to have disappeared.
The files that caused the crash did not contain such nuclei but maybe the fix affected another part of the modeling process excluding some other exotica unrecognized by Geant4.

According to logs, the crash was produced after registering a nucleus with pdg=1000090190. So one would think either this nucleus or the next one with pdg=1000090200 to be faulty (the numbers are extracted from an ordered map). But both of them are still present in the files after fix.

So meanwhile the problem is not present, but I suppose for the future there should be some way to check for nuclei not existing from Geant's point of view so that their presence in one event would not crash the whole job.

Actions #6

Updated by Volker Friese almost 3 years ago

  • Due date set to 12/20/2019
  • Target version changed from OCT19 to APR20
  • Parent task set to #1398

Target OCT19 missed.

Actions #7

Updated by Volker Friese over 2 years ago

  • Target version changed from APR20 to APR21
  • Parent task deleted (#1398)

Since it is not an urgent problem, target APR20 is removed.

Actions #8

Updated by Volker Friese over 1 year ago

  • Target version deleted (APR21)
Actions

Also available in: Atom PDF