I recently grasped the concept of two-step simulations and realised how valuable it could be for my project. I aim to simulate a moving X-ray tube in a CT scanner by modelling multiple angles, for radiation protection purposes. Initially, I was concerned about needing many primaries for each angle (simulation) to capture rare events. However, with two-step simulations, I can simulate the x-ray tube once with many primaries and then reuse the phase-space file for subsequent angles.
My question is: how can I modify the phase-space file so that the beam position and direction align with the tube’s rotation at each step, if even possible? Additionally, how does uncertainty propagate from the first to the second step?
I found some insights in this topic, but it does not cover altering the source’s initial position and direction.
Suppose the isocentre is at (x,y,z)=(−100,0,0), and I simulate the configuration shown in the Flair file to generate the phase space file. For a subsequenet simulation, how can I rotate the beam to aim, for instance, from (0,0,100), representing a clockwise 90° rotation about the y-axis? While I understand how to rotate the geometry through cards, what specific parameters in the source routine need to be adjusted (assuming that the changes are made there)? Additionally, what quantity should be scored to generate the phase space file?
If possible, could you please make amendments to my file to achieve this setup and provide guidance on what was changed so I can better understand the process?
Thank you for your question. If I understand your simulation correctly, you want to repeat the effect of your source on a sample from different angles.
For simpler cases where the user source routine is not needed, the card SPECSOUR is useful to define several simple sources from different positions and angles. In your case, this is not possible since the cards SOURCE (for the source routine) and SPECSOUR can not be active at the same time.
One way to solve this could be to modify the input phase-space file such that it repeats the particles N times, where N is the number of angles you want to use. In each iteration, the positions and angles of the particles would be corrected accordingly, and the weight W of each particle would be set as W/N.
Instead of performing the angle variations within a single simulation, I am more inclined to run a series of “sub-simulations” for each angle. In my case, moving the source would also require rotating the geometry, as the CT scanner’s gantry needs to be adjusted accordingly. I would then accumulate the results from each simulation.
While I am familiar with how to handle geometry rotation using cards, I am less certain about modifying the source position and angle in the input phase-space file. Would it be possible for you to modify the respective phase-space file from the attached flair file to achieve the approach I outlined above (i.e., the 90° clockwise rotation)? If so, I would greatly appreciate it if you could guide me through the steps you take.
Aiming to solve your question, I propose here an approach that uses as reference the example file included in your 2-step simulation post. The main differences are the following:
This simulation has two fully independent steps, with two input files. The step 1 emulates and scores the photon spectrum in the output of the X-ray tube, while step 2 focuses on the interaction of the X rays on the detector.
In the step 1 file, for simplicity, the whole geometry can be placed such that the detector centre is in (0,0,0). Besides, a new ‘OUTPUT’ region shall be defined where the photon fluence shall be scored. To my understanding, this should be placed inside the COLLIM hole.
As in the example, the step 1 file requires the USERDUMP card, together with the mgdraw user routine. You only need to adjust the region numbers:
IF (JTRACK .EQ. 7) THEN !Particle code for photon
IF (MREG .EQ. 3 .AND. NEWREG .EQ. 2) THEN !Region number for TARGET and VOID
!Particle ID, momentum, coordinate-x, -y, -z, direction-x,
! -y, -z, weight
WRITE(90,*) JTRACK, PTRACK, XSCO, YSCO, ZSCO, CXTRCK,
& CYTRCK, CZTRCK, WTRACK
END IF
END IF
The step 2 file shall contain only the detailed detector geometry, together with the scoring cards you may want to use. As in the example, the SOURCE card is needed to enable the user source routine, which will use the output file of first stage.
A way to simplify the effect of changing the beam angle in the user routine is to rotate the detector, instead of rotating the beam. This can be parametrised with a single number since the detector is placed in (0,0,0) and can be simply done with the ROT-DEFI card and start_transform directive. If you use USRBIN/EVENTBIN scorings, these need to be rotated as well with the card ROTPRBIN.
At the end, you have to combine the results with the proper normalisation. Last but not least, note that the two steps could be merged in a simple input file, as it is done in the example.
I hope this is clear enough. Please let me know if the approach makes sense to you and should you need further support to implement it.
This issue has been on my mind over the past few days, and after much consideration, I realised that, unfortunately, I will still need to simulate the electron beam for each run. In my final simulation, it will be essential to determine whether there is any electron leakage across the entire scanner. As a result, the concept of a two-step simulation does not really apply here, as I would still need to score electrons in each run (I am aware that the simulations will require a significant amount of time to complete this way).
That said, the information you provided will certainly be useful for my future work, so do not think that your time was wasted by answering this post. I am always eager to explore new methods of implementation, and I will for sure revisit your suggestions when the time is right. I must say, your explanation was incredibly clear and easy to follow, which I greatly appreciate!
