Closed jovoy closed 8 months ago
Interesting to note that this only works when you move targetPosition and TRestAxionFieldPropagationProcess by the same value in x- and y-direction. Need to update commentary on that.
If the whole BabyIAXO setup is moved with this target position and analysis position but the sun stays at the same point:
The first real loss of signal can be seen at a displacement of 3e9 km which is a lot but also makes sense regarding the sun has a radius of 7e5 km. So maybe I would have already expected a loss of signal at 7e5 km? Not that this is relevant for the 80 cm by which we move the setup in the end; I just wanted to make sure it works properly.
Hi @jovoy, if I understood correctly you are adding an offset to the generator so that the flux illuminates a non-centered region. Of course, one must be careful, moving the magnet by an offset distance would require increasing the target size so that the full magnet bore entrance is illuminated.
Just for additional info, I think this could also be achieved by moving the magnet, or perhaps I am missing something, is not the case? Moving the magnet is possible inside TRestAxionFieldPropagationProcess
using fPosition
data member inside TRestAxionEventProcess
. This would allow to create a magnet displacement. Of course, you need to move other components, such as optics and windows to mimic the generator offset.
I am not against adding the possibility for an offset inside TRestAxionGeneratorProcess, however, it would be perhaps more coherent with other parts of the code if you make TRestAxionGeneratorProcess
to inherit from TRestAxionEventProcess
, since right now it just inherits from TRestEventProcess
.
In that way you could use the TRestAxionEventProcess::fPosition,fYaw,fPitch
to translate and rotate the generator (not just translate the target position), what do you think?
As you mentioned, adding a general offset should not change too much the flux, but perhaps it would be interesting to rotate the sun respect to the target, so that we mimic the start/end of tracking, when the magnet is not anymore capable to follow the sun's core. It would be interesting to see that effect, how the Gamma flux diminishes when the sun goes off-point.
Okay, I thought TRestAxionGeneratorProcess
was already inheriting from TRestEventProcess
. Is that not what the include
at the beginning of the header does? I was wondering why this wasn't working but also would that work, if the output is directly produced in the code?
You can not only move the magnet because the target would then not be at the same position as the magnet end-bore and then you would have to make the target bigger, through which you would loose a lot of statistics. So the target has to be moved to move the magnet.
So actually rotation of the sun with respect to the experiment makes a lot bigger difference then moving them up and down with respect to each other. The rotation (what happens when the magnet is not able anymore to follow the suns core) has been done in the previous acceptance study.
Okay, I thought
TRestAxionGeneratorProcess
was already inheriting fromTRestEventProcess
. Is that not what theinclude
at the beginning of the header does? I was wondering why this wasn't working but also would that work, if the output is directly produced in the code?
Yes, it inherits from TRestEventProcess
which is the basic process template in REST, but it does not inherit from TRestAxionEventProcess
. As you see, we should change this line of code, changing TRestEventProcess
by TRestAxionEventProcess
.
Doing that would add the data members of TRestAxionEventProcess
to TRestAxionGeneratorProcess
.
So, that, you could use fPosition
, fYaw
and fPitch
in the new implementation where the target is translated. We could also rotate then the axion direction so that it is like the sun is placed somewhere else. Not sure if only translating makes sense here.
Ah okay, thanks, didn't see the difference.
You can not only move the magnet because the target would then not be at the same position as the magnet end-bore and then you would have to make the target bigger, through which you would loose a lot of statistics. So the target has to be moved to move the magnet.
Ok, but I do not understand what it is achieved if you translate both, the generator and the magnet. Actually translating the sun makes no real sense, because the extension of the sun is huge compared to the target size.
You can not only move the magnet because the target would then not be at the same position as the magnet end-bore and then you would have to make the target bigger, through which you would loose a lot of statistics. So the target has to be moved to move the magnet.
Ok, but I do not understand what it is achieved if you translate both, the generator and the magnet. Actually translating the sun makes no real sense, because the extension of the sun is huge compared to the target size.
I don't want to move the sun (generator) but only it's target which is the disc at the end of the magnet bore. It's just the small disc where the axions randomly arrive. If I don't move that and only the magnet, the whole end-bore is not illuminated anymore. In the past I have just increased the size of the target if this was an issue but now the movement of the end-bore is too big.
You can not only move the magnet because the target would then not be at the same position as the magnet end-bore and then you would have to make the target bigger, through which you would loose a lot of statistics. So the target has to be moved to move the magnet.
Ok, but I do not understand what it is achieved if you translate both, the generator and the magnet. Actually translating the sun makes no real sense, because the extension of the sun is huge compared to the target size.
I don't want to move the sun (generator) but only it's target which is the disc at the end of the magnet bore. It's just the small disc where the axions randomly arrive. If I don't move that and only the magnet, the whole end-bore is not illuminated anymore. In the past I have just increased the size of the target if this was an issue but now the movement of the end-bore is too big.
That's also why I didn't really want to use fPosition
on TRestAxionGeneratorProcess
because then I would move the sun and the target.
Ok, I understand that you rotate the magnet, then the end bore position is not centered anymore? Is it the case? It is not the end-bore at the (0,0,0)? I mean, it is not the rotation vertex? That would assure that the end-bore is always illuminated even if you do not move the target.
In any case, I don't think the changes harm any other studies. So I will approve for the time being, if you are certain about the changes, you merge them. We may re-discuss during the CM in case we find a better implementation is worth.
Ok, I understand that you rotate the magnet, then the end bore position is not centered anymore? Is it the case? It is not the end-bore at the (0,0,0)? I mean, it is not the rotation vertex? That would assure that the end-bore is always illuminated even if you do not move the target.
I mean, right now a rotation of the bore around itself results in an end bore that is not centered anymore, but since that is only millimeters it's not a problem. What I'm talking about right now is displacing the whole experiment by 80cm because the focus of BabyIAXO is between the two bores. And if the target position would stay like this, the magnet would be 80cm next to the target.
In any case, I don't think the changes harm any other studies. So I will approve for the time being, if you are certain about the changes, you merge them. We may re-discuss during the CM in case we find a better implementation is worth.
Yeah, sure, let's do that!
The helioscope might not be pointed towards the sun by one of the bores but by the middle between both bores. The bores are 1600mm apart. To not loose to much statistics by just making a bigger target, the target can, with this PR, be moved up or down, depending on which bore one wants to use.