Dear Mary,
thank you very much for your answer.
Actually I had performed a check which is very similar to what you suggested (swapping the trigger and detector) and I thought I have seen the signal disappeared.... But it seems I did something wrong because after a new check I can confirm that this part is working fine.
But still I need some more advanced features and again I don't think that the DETECT can achieve that... but please tell me if I am wrong again! :)
Here are the features I would need:
-validation of the beta signal in the deltaE-E telescope (a thin plastic scintillator followed by a thick one):
coincidence between deltaE signal with an energy threshold (betas deposit around 400keV in this detector) and E signal (threshold >650keV to get a total energy deposition >1MeV and thus avoid accidental coincidences from low energy background )
-energy selection for the trigger: the beta signal needs to be in coincidence with a delayed gamma ray so I need an energy selection around the position of the ray.
As far as I understand, the DETECT card allows only one threshold for the total detector signal (=sum of energy deposited in volumes set as detectors) and not on individual detector, neither on the trigger...
If that is indeed the case, I would be willing to write my own routines but I would appreciate some advice and orientation to do that efficiently.
Cheers and thanks,
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 - 15:37:39 CEST