Bxdraw routine for counting protons and heavy ions

Dear Fluka experts,
I have yet another question for you. :sweat_smile: First of all, thank you for your constant support, I really appreciate it!

I am trying to assess the importance of a specific region (sensitive area) in my setup by measuring how many particles (primarily protons) are produced inside it and will reach the closest region ‘PADC’ . I need to do this under two conditions: with and without an adjacent region that acts as a converter, producing recoil protons from neutrons.

To achieve this, I wrote a BXDRAW routine where I consider only particles moving from region 6 to 7 while excluding those that pass from 5 to 6. My approach is:

  1. I first store NCASE for particles moving from 5 to 6.
  2. Then, I consider particles going from 6 to 7 only if their NCASE is different from the previously stored value.

Does this approach make sense, or is there a more straightforward way to obtain the same information?

Additionally, I encountered the error:
Index ‘-7’ of dimension 1 of array ‘am’ below lower bound of -6

From an old forum post, I understand that this is related to the production of alpha particles or other heavy ions in my simulation. However, I am actually interested in these particles, but I’m unsure how to modify my routine to properly handle these "exceptions”. When considering all particles, I have not only NCASE but also NPHEAV…

Lastly, I am having trouble getting the GEON2R subroutine to work within my routine. Could there be a specific subroutine that I need to include for it to function properly?

Thanks in advance for your precious help!

converter_importance.f (13.7 KB)
04022025_.flair (3.3 KB)
04022025_.inp (7.3 KB)

Dear Antonella,

if I understand FLUKA internals correctly, NCASE is the number of the current primary particle, so all secondaries/tertiaries of this primary will be excluded if ANY of them went from 5 to 6.

If you want a per particle check, you can use LLOUSE, a user defined flag for the current particle. You can check the crossing 5-6 and set LLOUSE = 1, then check crossing 6-7 and count it only if LLOUSE is not 1. The advantage of this approach is that the particle carries the information, no bookkeeping required.

Best regards
Roman

Dear Roman,

Thanks for your quick reply!

I really appreciate the clarification about the ‘NCASE’ variable - I had thought it referred to the total number of particles, not just the primary ones.

If I also want to include ions with JTRACK < -6, will the approach you suggested still work?
And I guess I should add an IF statement between the particle position check and the WRITE operation to properly distinguish between heavy ions and lighter particles, as well as the information they carry that I need to save, like in the picture below:

Thanks a lot for your help!
Cheers,
Antonella

Dear Antonella,

the LLOUSE approach works for any particle as long as it doesn’t change identity.
Based on the description of your problem, I was suggesting something like

         IF (jtrack == 1 .OR. jtrack .LT. -6 ) THEN
         ! or other particles
            IF (mreg == 5 .AND. newreg == 6 ) THEN
                LLOUSE = 1
            ELSE IF (mreg == 6 .AND. newreg == 7 .AND. LLOUSE .NE. 1) THEN
                counter_det_padc = counter_det_padc + 1
                WRITE(50) jtrack, 
     &                    (etrack - am(jtrack)), 
     &                    xsco, ysco, zsco, cxtrck, cytrck, cztrck
            END IF
         END IF

of course with the option to save more info if needed otherwise.

In the case of heavy ions it depends on how you want to treat fission/fragmentation products. If you don’t care whether the parent passed from 5 to 6, it works straight up. If you want to exclude them depending on the parent history, you will have to inherit the LLOUSE flag, which seems possible (see here, “STUPRF”), but I have unfortunately no experience myself. The description suggests you just have to include a copy of stuprf.f in your executable, but maybe some expert can elaborate here…

In terms of your GEON2R problem, I cannot try it without all user files, but you might want to clean up the variable definition (first_run, counters saved before definition) and maybe try the Fortran 77 convention

INTEGER converter, detector, padc
SAVE converter, detector, padc