CbmRoot » Simulation

Didn't we solve the issue already?

I just had a look into it. One can no longer call:

Error: Can't call FairPrimaryGenerator::SetTargetRotAngle(0.,beamRotY*TMath::Pi()/180.) in current scope mcbm_sim.C:279:

So what I can do is rotate the target position, e.g. -45 deg around the Y axis,
but I can't tell the beam that the target plane is rotated. As a result the vertices
remain in the x/y plane. An interaction can be seen in the attached screenshot.

If I remember correctly, the vertex position was OK only for small angles.

Will be picked up for OCT19.

Dear David,

your assessment is correct: the target rotation is not taken into account when creating the event vertex. In general, there is no guarantee that the generated primary vertex falls into the target volume, even if the target is perpendicular to the beam. Gaussian smearing in x and y is determined by the beam properties, not by the target extension. So, if the beam is wider than the targer size, some vertices will be outside of the target.

This functionality is implemented in FairPrimaryGenerator::MakeVertex(). To do it correctly would require to calculate entry and exit points of the beam in the target and sample the event vertex along the trajectory of the beam through the target. If the target is always a disk as we have it right now, this can be done analytically without using TGeoManager. However, it requires a derived class CbmPrimaryGenerator implementing the desired functionality which is not present in FairRoot.

This is possible, but some amount of work (estimated 10 h). I see from the current mcbm macros that the setup is defined such that the beam axis is the z axis, in contrast to the plots you show here. So, can you specify the urgency of the matter?

Dear Volker,

in mCBM the z-axis points along the center of the downstream TRD module.
The z-axis does not point along the primary beamline.

I cannot judge the impact of misplaced vertices at 25 degrees rotation angle to the primary beam.

Alternatively one could rotate the z-axis back to the z-axis and modify all subsystem geometries accordingly.
That modification would however take much longer than 10 hours, I guess.

Best regards David

I have investigated the possibilities to implement the requirement that the event vertex falls into the target volume. The findings are summarised in the attached write-up. Changes to FairRoot are required.

A pull request to FairRoot was issued today by Florian.

The functionality should now be present. It works, however, only from FairRoot v18.2.0 on.

You have either to use the CbmTransport class or use in your macro CbmEventGenerator instead of FairPrimaryGenerator. You can specify the target as before, and the beam via

CbmTransport::SetBeamPosition(Double_t x0, Double_t y0, Double_t sigmaX = -1., Double_t sigmaY = -1., Double_z zFocal = 0.)

When the sigmas are non-positive, the fixed values x0 and y0 will be used, otherwise x and y are sampled from a Gauss function. zFocal is the z coordinate of the beam focal plane (where the other parameters are defined). It is by default 0, hoping that they will manage to focus the beam on the target....

The beam angle can be set in the same way by

CbmTransport::SetBeamAngle(Double_t thetaX0, Double_t thetaY0, Double_t sigmaThetaX = -1., Double_t sigmaThetaY = -1.)

If you do not want to use the CbmTransport class, you have the same methods for CbmEventGenerator:

CbmEventGenerator::SetBeamPosition(..) and CbmEventGenerator::SetBeamAngle(..)

With FairRoot earlier than v18.2.0, the settings of the beam properties will have no effect; the beam will always be at (0,0,0) in z direction. I will introduce a corresponding warning.

Could you please test whether it works properly?

I can confirm that the vertex position in rotated targets looks good in CbmRoot Revision 14690 with fairroot_v18.2.0, see:

#4 - OK" alt="Event #4 - OK" />
#5 - OK" alt="Event #5 - OK" />

I think I fixed the event rotation according to the beam angle with r14691. David, can you please check? Maybe with a single particle in z direction:

run->AddInput(new FairParticleGenerator(2212, 1, 0., 0., 1.));

You have to show me how to visualize trajectories, then I could better debug on my own...

The event rotation was indeed buggy in rev 14690 and got fixed in rev 14691, see here:

Good! I assume the issue can be closed, then.