Runtime error when the energy changes

Dear experts,

I changed the energy of the source in the simulation.
When the energy is 200 and 250 MeV, it can operate normally.
XZY2022.9.23PT200.flair (3.9 KB)
XZY2022.9.23PT200.inp (4.1 KB)
XZY2022.9.14PT.flair (4.0 KB)
XZY2022.9.14PT.inp (4.1 KB)
But when it gets to 300 MeV, error occurred at runtime.
300XZY2022.9.23PT.flair (3.6 KB)
300XZY2022.9.23PT.inp (4.1 KB)
When I changed the source energy of the simulation in the other direction to 300MeV, it worked fine.
XZZ2022.9.23PT300.flair (3.9 KB)
XZZ2022.9.23PT300.inp (4.1 KB)
What is the cause of the error? How should it be solved?

Dear @Junjie_Zhang,
I think the problem is due to the fact that you’re using a BOX body, which is deprecated. I suggest you to replace it with an RPP and then rotate it using a ROT-DEFI card and then the $start_transform instruction.

Dear amario,

I replaced BOX in two ways, The first method is to cut the RPP using PLA, and the second is to rotate the RPP using ROT-DEFI, Both methods give me the Angle I want.
SY.flair (1.8 KB)
SY.inp (1.3 KB)

I have the following questions:

1.Why can BOX sometimes be used and sometimes not?

2.ROT-DEFI card rotates RPP clockwise, but why does the coordinate axis rotate counterclockwise, as the yellow and purple coordinate axes in the figure?

3.Use the same ROT-DEFI card for rotation and translation, and Use one card to rotate first, and then use another card to translate. The results of the two methods are different. Is it because in the first way, translation is according to the axis after rotation?

4.After rotating with ROT-DEFI, I can continue to use another ROT-DEFI to move, but I can’t get the center coordinate of RPP, so I can’t move it to the place I want accurately. What should I do?

Looking forward to your reply.

Dear @Junjie_Zhang,

I’ll try to answer your questions.

BOX is a deprecated type of body. It was introduced a long time ago and it is kept for backward compatibility but you should not use it. BTW, I’ve seen in your input that you are using parenthesis, those are deprecated too.

These coordinate axes are a new feature of flair 3.2 and I’m not familiar with it.

I’ll answer these two together with an example: SY.flair (2.1 KB).
In this input I defined three identical RPPs:

RPP origin     -20 20 -10 10 -50 50
RPP tra1rot2   -20 20 -10 10 -50 50
RPP rot1tra2   -20 20 -10 10 -50 50
  • The first one, “origin”, was left in the origin.
  • The second, “tra1rot2”, was first translated and then rotated.
  • The third, “rot1tra2”, was first rotated and then translated.

As rotation, I choose a simple 90 degree rotation.
As translation, I choose to move by 100 cm in x, and by 200 cm in z.

When the translation precedes the rotation the center of the object that initially was in 0,0,0 is moved in 100,0,200, then it is rotated by 90 degrees, therefore the center moves in -200,0,100.

When the rotation precedes the translation, the center of the object that initially was in 0,0,0 remains in 0,0,0 while the object is rotated, then the translation takes place and the object is moved in 100,0,200.

So, yes, the order in which rotation and translations are defined matters a lot, because the rotations are performed around the origin. Whenever you have to define a roto-translation, it is convenient to define the rotation and the translation in two separate cards, in this was it is easier to deal with them. Indeed, have a look in the example at how I implemented the roto-translation.

In this way it is also possible to control where the object is being moved. In the example, I wanted the center of the object to be located in 100,0,200, so I built the object with its center in the origin, then I rotated it (the center doesn’t move because the rotation is around the origin), and last I translated to the position where I wanted it.