RE: [fluka-discuss]: coincidence scoring

From: <me_at_marychin.org>
Date: Fri, 23 May 2014 22:56:28 -0700 (PDT)

Dear Philippe,

I think detector combination is not yet implemented in the DETECT card, though
the manual foretells.

User routines -- I would first determine whether mgdraw can do the job, or do
you need stupre as well. The prior would be straight-forward. The latter would
be tricky, though this is a fortunate case since your gamma spectroscopy problem
will not involve particles beyond photon, electron and positrons (if I
understand well). Other than mgdraw and stupre, you might need some others such
as fluscw, comscw, usrout etc but these are more straightforward and less of a
worry.

I do not know how familiar you are with user routines. Here, some of my
recommendations might be redundant, but anyway, here we go...

Do you need stupre? It depends on your definition of coincidence. Here are some
different definitions:

- In PET, coincidence is defined by the 180-degree angle, the 511 keV energy and
the arrival time, which spells the inherent trouble of PET, because many photon
pairs recognised as coincident in fact do not originate from the same
annihilation event. If we detect as PET detects, we don't need stupre, because
we don't care about the relationship between particles, we care only about the
attributes they have (angle, energy, time, location, ...)

- In DETECT card, the requirement for coincidence is for the particles to have a
common primary (first-ancestor, the source particle, which I added footnote for
in my earlier message). If we detect this way, we don't need stupre either.

- But we can be even more picky. We can demand that we recognise as coincidence
the particles emerging from the same collision, we reject all other particles
even though they come from the same primary. In this case, we do need stupre.

Because:
- mgdraw concentrates on the current particle being tracked
- we should make no assumptions about the order FLUKA tracks which particle
first, as mentioned earlier, this is completely programmatic and absolutely
unphysical
- stupre provides the connection between the parent and the ejectile

Once you identify the user routine(s) you need, you might like to exercise them
by making them verbose and ridiculously loud -- insert WRITE everywhere to make
each entry and each part of the user routine greet you by reporting the values
of the variables they deals with. This would give the best feel of how the
variables get reset and changed, which is critical.

Needless to say, before production runs, extensive QA would be necessary in case
you take the stupre route.

:) mary


> On 22 May 2014 at 05:56 Philippe Velten <Philippe.Velten_at_fys.kuleuven.be>
> wrote:
>
> 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 Sat May 24 2014 - 09:10:35 CEST

This archive was generated by hypermail 2.3.0 : Sat May 24 2014 - 09:10:36 CEST