I just realized the treshold/cut-off is applied on the trigger, not on the detector signal! Sorry for the error.
That is of course better, but ideally I would also need an energy selection on each individual trigger/detector as mentioned in my previous message.
Cheers,
Philippe
________________________________
From: me_at_marychin.org [me_at_marychin.org]
Sent: Wednesday, May 21, 2014 07:51
To: Philippe Velten; fluka-discuss_at_fluka.org
Subject: Re: [fluka-discuss]: coincidence scoring
Dear Philippe,
Assuming I understood your question well, the DETECT card can do the job. The trigger is triggered by energy deposition, in the trigger region(s), by *any particle belonging to the same parent source* (re: footnote), regardless of whether trigger signal occurs before or after energy deposition in the detector region(s).
As a test to convince ourselves we can send a photon through two successive regions. To ensure no backscatter we can have a dense material for the first region, and set regional transport cutoffs in the second region to a value exceeding the beam energy. In the DETECT card if we then set the first region as the detector, and the second region as the trigger, energy will be deposited in the detector first, signal will be triggered in the trigger region later. We'll find that DETECT happily recognises the energy deposition in the detector. The numbers reported by DETECT output (fort.17) can be verified against the energy deposition table in .out (can be located by text-searching for 'Feeder', or 'Events by Region' under fless).
We can also test the corollary: swapping the detector region and the trigger region would still produce DETECT output which is consistent with .out.
As you mentioned we can of course use user routines. Note though the different interpretations of before-after: before-after in terms of wall-clock and also in terms of upstream-downstream of a radiation cascade; before-after in terms of FLUKA tracking which particle first and which particle emerges from the stack first (which is entirely programmatic, absolutely unphysical). With user routines we would need to set a trigger flag, whose lifetime and validity need to be considered in terms of the order FLUKA tracks progenies and the order progenies get pushed and popped out of the stack. Propagation of flags through progenies should be done via ISPUSR, otherwise as far as I can imagine the mess would be unsurmountable.
Footnote: *Any particle belonging to the same parent source* is defined in the DETECT section of FLUKA's manual as:
"primary particle and its descendants, i.e. between two successive calls to the FEEDER subroutine (case of an incident beam) or to a user-written SOURCE<
http://www.fluka.org/fluka.php?id=man_onl&sub=71> subroutine (case of an extended source, or of a source read from a collision file or sampled from a distribution)"
In the nomenclature of fellow Monte Carlo house-brands, this is commonly referred to as, "progenies belonging to the same history".
:) mary
> On 19 May 2014 at 09:05 Philippe Velten <Philippe.Velten_at_fys.kuleuven.be> wrote:
>
>
> Dear FLUKA experts,
>
> I would need some advanced coincidence scoring capabilities to simulate a beta-gamma spectroscopy setup.
> More precisely, I would like to score energy deposition in one detector (beta signal in the beta detector) at the condition that a delayed gamma ray is detected in an other detector (e.g. a energy deposition with a 2 sided energy selection).
> I don't think this kind of feature is possible with the available DETECT card and its coincidence capabilities but please correct me if I am wrong.
> It seems that currently the designated "trigger" must arrive BEFORE the "detector" signal. In my case, I could switch my trigger and signal, e.g. consider that the beta signal is the trigger and the gamma signal is the detector and this way I would get a coincidence count, but then no beta spectrum...
>
> I guess I could use the mgdraw routines to build a custom scoring from scratch but I would like to use built-in scoring and data processing capabilities of FLUKA as much as possible.
> So please could you tell me if there is a way to implement such coincidence capabilities with minimal addition?
>
> A possibility would be a routine called at the end of each event (usreou.f for example) but with access to the energy deposited in the volumes designated as "detector" and "trigger" with the DETECT card and with the possibility to assign null weight to some of those scoring under some conditions.
> In my case, give a null weight to the energy deposition in the beta detector if the energy deposited in the gamma detector doesn't corresponds to the the gamma ray energy.
>
> Best regards,
> Philippe
>
>
Received on Thu May 22 2014 - 16:03:37 CEST