Dear Federico
If you define a row with 50 regions and replicate it, the usrbdx will
apply also to replicas, summing them together. In each of the 50 usrbdx
you'll get all particles crossing a column of pixels. Is this what you
need? If not:
- to get the "total" usrbdx over all 2500 pixels: add a "dummy" scoring
region in front of the detector (a thin layer of void) and score there.
- to separate all the 2500 pixels: not with usrbdx. usrbdx works by
region, keeps no track of different lattices. One should define 2500
usrbdx's, not sure that it does not hit some max dimensions (i'll check
if needed). The only structure that works "by lattice" is the USRBIN
"special" (what(1)=8). You could use this in fluence mode, with energy
as the third variable. Needs user routines, and will give the fluence
INSIDE the pixels, not at the surface
A couple of advices: independently on whether you use lattices or not,
avoid defining each pixel by a rpp. All these RPP will touch each other,
potentially giving rounding problems at boundaries: the same boundary
will be defined by two different, touching, bodies. It would be better
to define a single RPP containing everytyng and split it with planes.
This would also make the subtraction from vacuum easier, only one body!
Check your PHYSICS cards:
the PEATHRESH card, (do you need it? you are working at energy where
PEANUT is the default. ) If used one should input large values :
PHYSICS 1000. 1000. 1000. 1000. 1000. 1000. PEATHRES
If you switch on coalescence and heavy fragment evaporation you should
also switch on heavy ion transport (card IONTRANS, not IONSPLIT), and if
the energies go above 100-150 MeV/nucleon link with the RQMD generator.
The BME card is useless, and please do not set a QMDTHRESH
Hope this helps
Paola
On 08/29/2017 02:10 PM, Federico Geser wrote:
> Dear Paola
>
> Thanks for the response!
>
> Yes, I made a mistake when developing the geometry and forgot to
> subtract the container regions from the void. That's easily solvable.
>
> On the other hand, I think I will not segment the single 2x2 mm
> segments any further, I defined them that way because I'm not sure how
> to assign a USRBDX card to the copies. I thought that, assigning a
> USRBDX card to the containers was enough for FLUKA to understand that
> it should score in each of the copies. If this is no the case, then
> the only solution I see is defining a USRBDX card for each region
> (2500 USRBDX cards), thus using lattice is not an advantage in this
> case. Am I right?
>
> If I define a "master" row of 50 pixels, apply a USRBDX card to each
> pixel, and then use lattic.f to replicate the row, will the copies
> also be scored in with USRBDX?
>
> Thank you again for your attention!
>
> Regards,
>
> Federico.
>
> ------------------------------------------------------------------------
> Geser, Federico Alejandro
> Lic. in Physics
>
> Doctoral Fellowship - IFEG-CONICET
> FAMAF-UNC
>
> Office 232 - Laboratory 448
>
> http://liifamirx.famaf.unc.edu.ar/members/geser/
>
> ------------------------------------------------------------------------
>
>
> 2017-08-28 7:32 GMT-03:00 Paola Sala <paola.sala_at_mi.infn.it
> <mailto:paola.sala_at_mi.infn.it>>:
>
> Dear Federico
> the problem is in the geometry.
> The 2450 (! see later..) cells are all overlapping with the VOID
> region,
> because they are not subtracted from it. The container (lattice)
> regons
> have to be subtracted, otherwise the code cannot know wether the
> particle
> is in the VOID or in one of the lattices.
>
> Here maybe some doubt about the use of lattices. Do you plan to
> further
> segment the single 2x2mm pixel? If not, why do you need to define a
> lattice based on single simple regions? What is the advantage with
> respect
> to define 2550 regions if you have to define 2500 lattices?
>
> In your case (but maybe I do not understand well), a possible idea
> would
> be to repeat a single row, only 50 times (50 lattices). Your "base
> unit
> would be the row that you already defined. Then, one could create 50
> "container" regions having the dimensions of one row (2mmx10cm)
> positioned as the rows to be repeated, havin nothing inside, just
> containers. These will have to be subtracted from the VOID. The
> lattic.f
> would simply translate from one row to the "master" row, where the
> code is
> then able to see and select the 50 pixels.
>
> Hope this helps
> Paola
>
> > Dear FLUKA experts,
> >
> > I wrote a geometry using lattice source file, trying to define a
> detector
> > made of 50x50 regions. I defined 50 of them (only one row of the
> array)
> > that will be the elementary cell (prototypes) for each of the
> other rows.
> >
> > I would like to use the USRBDX card to count photons entering
> each of the
> > regions of the cell (such as an imaging detector) discriminating in
> > energy,
> > solid angle, or maybe both variables.
> >
> > At first, I thought that using the USRBDX card in one of the
> elementary
> > cells will be enough for FLUKA to understand that I want to
> calculate that
> > quantity in every other lattice cell related to the corresponding
> > elementary cell, but that is not true.
> >
> > The lattice card makes the correct matching of other properties, for
> > example materials, thresholds, etc, but is there any way that it
> > automatically understands USRBDX?
> >
> > Should I define a USRBDX card for each region of the cell?
> (there will be
> > 2500 USRBDX cards!)
> >
> > I attach the input, geometry and lattice source files.
> >
> > Thank you in advance!
> >
> >
> ------------------------------------------------------------------------
> > Geser, Federico Alejandro
> > Lic. in Physics
> >
> > Doctoral Fellowship - IFEG-CONICET
> > FAMAF-UNC
> >
> > Office 232 - Laboratory 448
> >
> > http://liifamirx.famaf.unc.edu.ar/members/geser/
> <http://liifamirx.famaf.unc.edu.ar/members/geser/>
> >
> >
> ------------------------------------------------------------------------
> >
>
>
> Paola Sala
> INFN Milano
> tel. Milano +39-0250317374
> tel. CERN +41-227679148
>
>
__________________________________________________________________________
You can manage unsubscription from this mailing list at
https://www.fluka.org/fluka.php?id=acc_info
Received on Wed Aug 30 2017 - 11:32:26 CEST