Message: Problem with Nuclear Secondaries from Muon Capture Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

Question Problem with Nuclear Secondaries from Muon Capture 

Forum: Hadronic Processes
Date: 03 Aug, 2009
From: Kevin Lynch <Kevin Lynch>

I am having a problem understanding how to use the G4MuonMinusCaptureAtRest process, similar to an issue from a few years back that was unfortunately never answered: http://hypernews.slac.stanford.edu:5090/HyperNews/geant4/get/phys-list/287.html

Following information in the forum and in the examples, I add the capture process to my muon physics list:

  G4VProcess* mucap = new G4MuonMinusCaptureAtRest;
  pmanager -> AddRestProcess(mucap);

When the secondaries list of the process includes a nucleus, (it doesn't seem to matter what type!), the CPU becomes pegged at 100%, and memory use grows until the process is killed for eating the entire memory of the machine. If I set /tracking/verbose 2, I see the following in the output:

    :----- List of 2ndaries - #SpawnInStep= 18(Rest=18,Along= 0,Post= 0), #Spawn
Total= 18 ---------------
    :      0 fm      0 fm  -11.3 cm   4.14 MeV     alpha
snipped
    :      0 fm      0 fm  -11.3 cm   1.28 MeV     gamma
    :      0 fm      0 fm  -11.3 cm   1.38 MeV Ne22[0.0]
    :      0 fm      0 fm  -11.3 cm     12 eV      gamma
snipped

The output for that nucleus displays the problem:

********************************************************************************
*************************
* G4Track Information:   Particle = Ne22[0.0],   Track ID = 7,   Parent ID = 1
********************************************************************************
*************************

Step#      X         Y         Z        KineE    dEStep   StepLeng  TrakLeng    
Volume     Process
    0      0 fm      0 fm  -11.3 cm   1.38 MeV     0 eV      0 fm      0 fm     
 housing    initStep
    1      0 fm      0 fm  -11.3 cm   1.38 MeV     0 eV 5.83e+288 pc 5.83e+288 p
c      housing   UserLimit
    2      0 fm      0 fm  -11.3 cm   1.38 MeV     0 eV 5.83e+288 pc    inf pc  
    housing   UserLimit
    3      0 fm      0 fm  -11.3 cm   1.38 MeV     0 eV 5.83e+288 pc    inf pc  
    housing   UserLimit

The last line of which continues forever.

The interesting thing to me is that this is the output of the advanced optical physics example LXe, although my code produces the same garbage (Mg26 from Al, in my case).

I'm guessing that I've left something out ... following the examples, I only define the following particles:

  G4MuonMinus::MuonMinusDefinition();
  G4NeutrinoMu::NeutrinoMuDefinition();
  G4MuonPlus::MuonPlusDefinition();
  G4AntiNeutrinoMu::AntiNeutrinoMuDefinition();

  G4Electron::ElectronDefinition();
  G4NeutrinoE::NeutrinoEDefinition();
  G4Positron::PositronDefinition();
  G4AntiNeutrinoE::AntiNeutrinoEDefinition();

  G4Gamma::GammaDefinition();

Is the issue that I'm not defining all the possible secondaries? Or could I be doing something else wrong? Is there (blaphemy!) a bug in the implementation of the capture process?

I'm using 4.9.2.p1 compiled with gcc 4.3.6 on a few different x86_64 Linux systems. Any pointers you can give me would be greatly appreciated...

Inline Depth:
 1 1
 All All
Outline Depth:
 1 1
 2 2
 All All
Add message: (add)

1 Idea: Re: Problem with Nuclear Secondaries from Muon Capture   (Vladimir Ivanchenko - 03 Aug, 2009)
(_ None: Re: Problem with Nuclear Secondaries from Muon Capture   (Kevin Lynch - 03 Aug, 2009)
(_ Idea: Re: Problem with Nuclear Secondaries from Muon Capture   (Vladimir Ivanchenko - 09 Aug, 2009)
 Add Message Add Message
to: "Problem with Nuclear Secondaries from Muon Capture"

 Subscribe Subscribe

This site runs SLAC HyperNews version 1.11-slac-98, derived from the original HyperNews


[ Geant 4 Home | Geant 4 HyperNews | Search | Request New Forum | Feedback ]