rest-for-physics / axionlib

A library to define all the ingredients required for basic axion-photon raytracing in axion helioscopes. Solar axion flux generation routines, optics response, magnetic field definition, and likelihood sensitivity calculations.
3 stars 2 forks source link

Change Axion generator Target Position #87

Closed jovoy closed 8 months ago

jovoy commented 8 months ago

jovoy Ok: 15 Powered by Pull Request Badge

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.

jovoy commented 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.

jovoy commented 8 months ago

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.

jgalan commented 8 months ago

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.

https://github.com/rest-for-physics/axionlib/blob/068fb4530f8aabfcc702c179a290a38bdfeca48c/inc/TRestAxionEventProcess.h#L33

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?

jgalan commented 8 months ago

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.

jovoy commented 8 months ago

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?

jovoy commented 8 months ago

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.

jovoy commented 8 months ago

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.

jgalan commented 8 months ago

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?

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.

https://github.com/rest-for-physics/axionlib/blob/068fb4530f8aabfcc702c179a290a38bdfeca48c/inc/TRestAxionGeneratorProcess.h#L32

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.

jovoy commented 8 months ago

Ah okay, thanks, didn't see the difference.

jgalan commented 8 months ago

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.

jovoy commented 8 months ago

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.

jovoy commented 8 months ago

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.

jgalan commented 8 months ago

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.

jgalan commented 8 months ago

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.

jovoy commented 8 months ago

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.

jovoy commented 8 months ago

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!