Implementation of full ray-tracing event processing

[jgalan]

The implementation baseline will be defined at pipeline/axionGenerator.rml. For the moment, the opticsBench.rml ray tracer to test optics implementations have been implemented at the present PR.

Simply, test the processing using

restManager --c opticsBench.rml

Some variables that can be modified are REST_DEV, REST_YAW, REST_PITCH, REST_NEVENTS in order to produce different datasets systematically.

One could then do:

export REST_YAW=0.01
restManager --c opticsBench.rml

in order to generate a file where the optics was deviated by 0.01 degrees in the yaw axis.

There is also an additional RML containing a TRestAnalysisPlot definition that can be used together with the previous generated ROOT file to produce few systematic plots.

restManager --c opticsPlots.rml --f file_generated.root

It will produce the following figure:

List of changes at this PR:

• Added new TRestAxionEventProcess::TRestEventProcess encapsulation to add capability to processes to rotate or translate a ray-tracing component. Metadata members inside this class added to keep information of rotation/translation parameters. TRestAxionEventProcess::BeginOfEventProcess and TRestAxionEventProcess::EndOfEventProcess have been implemented to produce rotation and translation of the particular component. The relevant metadata members are:

  • fYaw and fPitch angles measured in the default radians unit.
  • fCenter giving a physical position to the helioscope component defined by each process.

• TRestAxionGeneratorProcess has been re-impemented to connect with TRestAxionSolarFlux.

  • It will also accept to define different generator types, the default is solarFlux, but if defined as flat it will just launch particles parallel to the z-axis, and spread on the area defined by fTargetRadius. The energy values in the flat case are distributed in the range (fMinEnergy,fMaxEnergy).

• TRestAxionDeviationProcess new process added to allow including an intermediate additional random deviation to the particle. It can be combined with flat distribution to produce an artificial angular distribution.

• TRestAxionTransportProcess new process added to move the particle to a given z-position following the direction of the particle at the present state.

• TRestAxionFieldPropagationProcess has been implemented. It extracts the effective BSquared field and coherence length.

• TRestAxionMagneticField::GetTransversalFieldComponent bug fixed and method added for validation at magneticField.py.

• TRestAxionEvent added methods RotateXZ and RotateZX to be used by TRestAxionEventProcess to produce component rotation.

• TRestAxionEvent data members fBSquared and fLCoherence have been added, and fGammaProbability has been removed (not yet clear which members will be finally kept).

• Fully impemented opticsBench.rml ray-tracer description to be operative.

• Implemented opticsPlots.rml to produce plots with the files produced using opticsBench.rml.

[ruzarmen]

Hi Javi, this looks real good!!
I have one doubt though ... i don't quite understand the fact that the focal plane has the spot centered at 0,0
In principle, if the optics is tilted with fYaw=0.1deg then the spot should have moved ~13.1 mm in the focal plane.
It seems like if the focal plane moves synchronous with the optic which it is correct. We should be aware though that the focal plane and the detector plane are not the same.
I think we should consider two cases:

1. Source Off-Axis ... which corresponds with what is shown
2. Sorce In-Axis but optic with Pitch or Yaw. In this case I think we probably need to remove the second rotation.

[jgalan]

Hola Javi, esto tiene muy buena pinta. Me queda la duda de por qué la imagen del plano focal tiene el spot centrado en 0,0 En principio la imagen debería aparecer con un offset de 17.5 mm respecto a yaw=0 arcsec en el plano del detector.

Parece como si el plano focal se desplaza al unísono con la óptica que es lo que en realidad sucede. Aquí lo que tenemos que tener cuidado es que el plano focal y el plano del detector son distintos una vez aplicamos yaw o pitch. Creo que para representar todo en el plano del detector nos hace falta una rotación más.

Hi Jaime, I have updated opticsPlot.rml so that it includes 2-additional plots showing the spot profile in 1-dimension. I also added the stats box, where we see the average shift/offset of the spot to be -0.2112mm, for 2.4 arcmin.

How do you get the relation between the Yaw angle and the expected offset?

We need to discuss about it, but what I am doing is to get the spot at Z=7500mm, not sure what additional rotation would be required.

So, what I call here focal is Z=7500mm (the distance to the center of the optics). This is defined at opticsBench.rml, where it says:

        <!-- Moving to Z=7500 -->
        <addProcess type="TRestAxionTransportProcess" name="ToFocalPoint" zPosition="7500"/>
        <addProcess type="TRestAxionAnalysisProcess" name="focal">
            <observable name="posX"/>
            <observable name="posY"/>
        </addProcess>

As you see, this will generate two observables at the analysis tree, focal_posX and focal_posY that are the ones I am representing on those plots.

[jgalan]

Ok, I just added a new parameter inside TRestAxionOpticsProcess, named fOpticalAxis that allows to define if the particle will be described respect to the optical axis or to the universal axis.

In other words, if opticalAxis=true then the "detector" will have been displaced to the optical axis, being the spot centered at (0,0).

If opticalAxis=false then the particle will be described respect to the universal axis, the detector then should be shifted/placed at the proper (x,y,z) position to be able to find the spot.

Here it is an image when opticalAxis=false:

[ruzarmen]

Perfect!

[jovoy]

Maybe make the pitch angle REST_PITCH and the event number REST_NEVENT changeable like described in the beginning of the description.