From: Giuseppe Battistoni (Giuseppe.Battistoni@mi.infn.it)
Date: Tue Jul 24 2007 - 17:25:09 CEST
I can confirm that there is no way at present to inhibit in FLUKA
a given decay channel.
There could be tricky ways however to help. Let us take your case:
you can use GDECAY sdum for LAM-BIAS and make the decay lenght much
shorter so to increase the number of pion decays.
At the same time, using for instance the DISCARD command,
you can discard the transport of muon and muon-neutrino.
At that point the products of the ordinary decay of pion are thrown away
and you are left with the rare case: pi+ --> e+ nue (B.R. 1.23 10**-4)
If you make the decay length short enough you have some hope to select
a good number of these decays which will be correctly reweigheted in
the ordinary FLUKA scoring (but you have to be careful because there
is also pi+ --> mu+ numu gamma with B.R. 2 10**-4)
Giuseppe
On Tue, 17 Jul 2007, Joseph Comfort wrote:
> Does the user have access to the branching ratios of particle decay? In
> fact, how many branches are included for a particle and what are the BRs
> built into the program? I am looking at pi->e nu and pi->mu nu (with mu
> decay). The e branch is about 10^4 slower than the mu branch. To study
> it in detail, I want to shut off the pi->mu nu branch. How can I do that?
>
> On another matter, I am not entirely sure of the behavior of the GDECAY
> option of the LAM-BIAS card. The writeup indicates that one can only
> make the decay length shorter. But to inhibit the decay of certain
> particles, for special studies, one would like to make it longer. I
> tried this in an application some time ago, and it seemed to to have the
> right effect, but maybe the results were wrong. Alternatively, one
> could use the 'blank' option for decay times. If the 'reduction' is
> done by a number much less than 1, the times can be increased. The
> running time is certainly increased, even very substantially (but why?),
> but I'm not sure the effect is what I want.
>
> Some guidance and clarifications would be appreciated.
>
> Thank you
> Joe Comfort
>
This archive was generated by hypermail 2.1.6 : Tue Jul 24 2007 - 17:44:04 CEST