Project

General

Profile

Actions

Sim-Development #335

closed

Smeared vertex position is misplaced in rotated targets

Added by David Emschermann almost 7 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Start date:
07/27/2015
Due date:
% Done:

100%

Estimated time:
10.00 h
Spent time:

Description

A rotated primary beam and targed is used in the mCBM setup.
When simulating smeared vertex positions, the rotation angle
of the target is not taken into account. Some of the vertices
end up misplaced outside of the target, see attached screenshots.

To reproduce those kind of events do:

root -l mcbm_sim.C
root -l mcbm_reco.C
root -l eventDisplay.C


Files

01_rotated_target_vertex_bug.png (84.3 KB) 01_rotated_target_vertex_bug.png Event #1 - not OK David Emschermann, 07/27/2015 12:09 PM
02_rotated_target_vertex_bug.png (109 KB) 02_rotated_target_vertex_bug.png Event #2 - not OK David Emschermann, 07/27/2015 12:09 PM
03_rotated_target_vertex_bug.png (165 KB) 03_rotated_target_vertex_bug.png Event #3 - OK David Emschermann, 07/27/2015 12:09 PM
rotated_target_01.png (106 KB) rotated_target_01.png Rotated target with displaced collision vertex David Emschermann, 10/02/2015 12:39 PM
primaryvertex.pdf (128 KB) primaryvertex.pdf Volker Friese, 05/13/2019 01:14 PM
04_rotated_target_vertex_ok.png (43.1 KB) 04_rotated_target_vertex_ok.png Event #4 - OK David Emschermann, 08/05/2019 11:36 AM
05_rotated_target_vertex_ok.png (33.5 KB) 05_rotated_target_vertex_ok.png Event #5 - OK David Emschermann, 08/05/2019 11:36 AM
06_bad_event_trajectory_r14690.png (29.2 KB) 06_bad_event_trajectory_r14690.png Worng trajectory David Emschermann, 08/05/2019 01:20 PM
07_good_event_trajectory_r14691.png (19 KB) 07_good_event_trajectory_r14691.png Correct trajectory David Emschermann, 08/05/2019 01:20 PM
08_event_rotation.png (57.5 KB) 08_event_rotation.png David Emschermann, 08/05/2019 01:42 PM

Related issues

Related to CbmRoot - Bug #1314: Target is not rotated with new mcbm_transport.C macroClosedDavid Emschermann08/05/2019

Actions
Related to CbmRoot - Bug #1338: event rotation for UrQmd events from root files not workingClosedNorbert Herrmann08/30/201910/11/2019

Actions
Actions #1

Updated by Florian Uhlig almost 7 years ago

  • Assignee set to Florian Uhlig

Didn't we solve the issue already?

Actions #2

Updated by David Emschermann almost 7 years ago

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.

Actions #3

Updated by Volker Friese about 6 years ago

  • Status changed from New to Assigned
Actions #4

Updated by Volker Friese over 3 years ago

  • Tracker changed from Bug to Sim-Development
  • Project changed from CbmRoot to Simulation
  • Assignee changed from Florian Uhlig to Volker Friese
  • Target version set to OCT19
  • Estimated time changed from 2.00 h to 10.00 h

Will be picked up for OCT19.

Actions #5

Updated by Volker Friese about 3 years ago

  • Status changed from Assigned to In Progress
  • Assignee changed from Volker Friese to David Emschermann

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?

Actions #6

Updated by David Emschermann about 3 years ago

  • Assignee changed from David Emschermann to Volker Friese

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

Actions #7

Updated by Volker Friese about 3 years ago

Well, at least in macro/mcbm/mcbm_transport.C, the beam is defined in z direction, and the target is not rotated, as far as I can see.

But probably, this macro should be updated like macro/run/run_transport, using the CbmTransport class.

Actions #8

Updated by Volker Friese about 3 years ago

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.

Actions #9

Updated by Volker Friese about 3 years ago

  • % Done changed from 10 to 20

A pull request to FairRoot was issued today by Florian.

Actions #10

Updated by Volker Friese almost 3 years ago

The requested changes are available with FairRoot 18.2.0. I will now proceed with the implementation.

Actions #11

Updated by Volker Friese almost 3 years ago

  • Assignee changed from Volker Friese to David Emschermann
  • % Done changed from 20 to 80

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?

Actions #12

Updated by David Emschermann almost 3 years ago

Dear Volker,

could you please share your mcbm_mc.C macro?
I have inserted the modifications you have suggested in my macro.

Afterwards I get stuck with the following error message:

#endif  // BASE_FAIRSYSTEMINFO_H_

#undef  _BACKWARD_BACKWARD_WARNING_H

In file included from input_line_15:1:
/opt/cbm/cbmroot_trunk_latest_root6/macro/mcbm/mcbm_de.C:328:20: error: variable has incomplete type 'FairSystemInfo'
    FairSystemInfo sysInfo;
                   ^
G__FairToolsDict dictionary forward declarations' payload:7:7: note: forward declaration of 'FairSystemInfo'
class FairSystemInfo;
Actions #13

Updated by Volker Friese almost 3 years ago

I use (and maintain) macro/mcbm/mcbm_transport.C. mcbm_mc.C still uses the old scheme, without CbmTransport, and is harder to keep up-to-date.

I see that you have moved the mcbm_mc_xxx.C macros into a legacy folder. Be braver and remove them (once you find mcbm_transport.C sufficient and working).

Actions #14

Updated by David Emschermann almost 3 years ago

  • Related to Bug #1314: Target is not rotated with new mcbm_transport.C macro added
Actions #15

Updated by David Emschermann almost 3 years ago

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" />

Actions #16

Updated by David Emschermann almost 3 years ago

  • Status changed from In Progress to Resolved
  • Assignee changed from David Emschermann to Volker Friese
Actions #17

Updated by Volker Friese almost 3 years ago

Hard to tell optically, but it seems that the beam angle (event rotation) is still 0... I will check.

Actions #18

Updated by Volker Friese almost 3 years ago

  • Status changed from Resolved to In Progress
  • Assignee changed from Volker Friese to David Emschermann

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

Actions #19

Updated by David Emschermann almost 3 years ago

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

Worng trajectory

Correct trajectory

Actions #21

Updated by Volker Friese almost 3 years ago

  • Status changed from In Progress to Closed

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

Actions #22

Updated by Volker Friese almost 3 years ago

  • Related to Bug #1338: event rotation for UrQmd events from root files not working added
Actions

Also available in: Atom PDF