Quenching in mgdraw.f

Dear professors,

I have noticed some relative threads like Mgdraw.f, ENDRAW routing, quenching and I want to ask in detail in several aspects. I attach the default codes as followed.

``````      IF ( LQEMGD ) THEN
IF ( MTRACK .GT. 0 ) THEN
RULLL  = ZERZER
CALL QUENMG ( ICODE, MREG, RULLL, DTQUEN )
WRITE (IODRAW) ( ( SNGL (DTQUEN (I,JBK)), I = 1, MTRACK ),
&                         JBK = 1, NQEMGD )
END IF
END IF
``````
1. Is LQEMGD the flag for quenching and is it true when I activate the USERDUMP with SDUM=UDQUENCH? IF so, where do the birks constants in the USERDUMP go into and how to distinguish different constant of different material as in the card they are denoted simply as birks constant for material 1, 2 and 3?

2. How exactly does subroutine QUENMG work? I canâ€™t find its explanations in the manual. Why does it take in the variable RULLL which is initialized as zero? Why doesnâ€™t it take in DTRACK(I) instead? Because the quenching is directly related to the deposited energy. On the other hand, is DTQUEN the result of quenching energy? More specifically, what do DTQUEN(1,1) and DTQUEN(1,2) mean? Why the same energy deposition point (MTRACK = 1) could have two quenching energies?

3. Provided that I want to assign three groups of birks constants to the same material according to the particle type (as in the picture), how to do that in mgdraw.f?

Best regards,
Hechong Han

Dear Hechong @hanhechong,

Yes, the flag is true when you activate `USERDUMP` with `SDUM=UDQUENCH`. To answer your questions, let me briefly explain what is happening.

The Birks parameters for quenching are used when `QUENMG` is called: this subroutine uses the provided parameters, calculates the quenching factors, and finally stores the quenched energy in `DTQUEN`.

To better understand what is happening you can take for simplicity the local energy deposition events from `ENDRAW`. The variable `RULL` contains the â€śunquenchedâ€ť energy, while `DTQUEN(1, JBK)` will contain the quenched energy. In particular `JBK` goes from 1 up to the number of â€śmaterialsâ€ť for which you have entered the Birks parameters. Letâ€™s say that you have entered the parameters for three materials, so you have filled from `WHAT(1)` to `WHAT(6)` of the `USERDUMP` card. Then `DTQUEN(1, 1)` will have the quenched energy computed using the first set of coefficients (i.e. with `WHAT(1)` and `WHAT(2)`), `DTQUEN(1, 2)` the quenched energy computed using the second set of coefficients (i.e. with `WHAT(3)` and `WHAT(4)`), and similarly for `DTQUEN(1, 3)`. You will have to code some criteria to print the quenched energies for the region of interest and the particle kind.

In the case of continuous energy losses in the `MGDRAW` entry, the situation is similar with the only difference that now `DTQUEN(I, JBK)` has two indexes. `JBK` has the same meaning as before, while `I` goes from 1 to `MTRACK`, where `MTRACK` is the number of energy deposition events along the step (normally `MTRACK` > 1 in presence of magnetic fields).

Concerning your third question, yes I think it can be done. You can fill the `USERDUMP` card in the following way:
`USERDUMP 12.05E-3 0 6.5E-3 1.5E-6 3.705E-3 1.5E-6UDQUENCH`
In this way the first quenched energy will be for e-/e+, the second for protons and the second for alphas.

As you can see, mgdraw.f offers several possibilities, but event by event analysis can be done with FLUKA built-in scoring capabilities which are less error prone. As already advertised in other posts of the forum, I would recommend a way easier approach based on `EVENTBIN` with region scoring + `TCQUENCH`: you can add different `EVENTBIN` cards, score separately the particles you are interested in, and associate to each scoring card a different `TCQUENCH` card. All of this without writing a single line of code

Best,
Davide

Dear @dbozzato ,
Thank you for your detailed explanation! I will first carefully try your suggestions and reply to you if questions remain.
Best regards,
Hechong Han

1 Like

Dear @dbozzato ,
I have tried your EVENTBIN + TCQUENCH method to involve quenching. According to previous suggestions, I also include AUXSCORE to specify particle type. They perfectly fulfill my purpose and thank you once again!
In addition, I still want to figure out how mgdraw.f works because accurate energy deposition location could be of interest in further study.

1. As you have said, both in point energy loss and continuous energy loss, the JBK index in DTQUEN stands for the region number and the birks parameters in USERDUMP are for region 1,2 and 3, respectively. So why you conclude that â€śIn this way the first quenched energy will be for e-/e+, the second for protons and the third for alphasâ€ť? In my opinion, these parameters are for all particles in region 1,2 and 3 not only because that the parameters are sorted by region, but also because that we have not specified particle type in anywhere.
2. If point one makes sense, then where to link particle type like JTRACK and their birks parameters in mgdraw.f? Or can we simply use the EVENTBIN + TCQUENCH + AUXSCORE to do this linking and make sure different particles have their own birks parameters in the simulation and use mgdraw.f as a tool only to print out detailed information? Will that work?

Best regards,
Hechong Han

Dear @hanhechong,

from my understanding of the code and the test I have made, the card `USERDUMP` with `SDUM=UDQUENCH` has the purpose to pass Birks parameters to mgdraw.

Now, It is up to the user to establish how to use the passed parameters by customizing the mgdraw routine, that is by implementing any desired filtering (i.e. IF statements) for instance using `MREG` and/or `JTRACK`.

Concerning your second question, I think I understood what you meant but 1) I am not sure it would be possible (or if it is maybe it is not simple) 2) You would probably double the scored information unnecessarily: you would anyhow know the energy deposition events from EVENTBIN and you can check the Birks parameters actually associated to the scoring in the simulation output file

Best,
Davide

Dear @dbozzato ,
Thank you for your helpful explanation! Now I have a better understanding of quenching and finish my codes.
Best regards,
Hechong Han