Bug #1602

Tracker charge hypothesis not carried forward by Kalman

Added by Greis, Jan over 9 years ago. Updated almost 9 years ago.

Target version:
Start date:
05 January 2015
Due date:
% Done:


Estimated time:
New Issue


It seems like the charge hypothesis for all trackpoints coming out is 0.


Updated by Hunt, Christopher over 9 years ago

I didn't think the SciFiTrackPoint data class had a method for returning the charge of the track. So I would assume you meant the containing class, SciFiTrack, which has the charge() method.

Can you say what version of MAUS you are using, as I don't see this error in my local development branch?


Updated by Dobbs, Adam over 9 years ago

SciFiTrack is indeed where it should be stored. However, last time I looked, kalman did not seem to set this value correctly (even though pat rec does). Chris H, have you seen it working with both charge signs?


Updated by Hunt, Christopher over 9 years ago

Positive Muons seem to be working fine. I just tried a run with negatives and it gave me +1. Need to check that I analysed the correct datafile.

I'll look into this, this afternoon.

However I haven't seen a charge of zero reported. You weren't looking at straight tracks by any chance Jan?


Updated by Greis, Jan over 9 years ago

I use MAUS 0.9.2

Basically, I do
and then get_charge() on that and it consistently returns 0.
I use the same beam Celeste uses for her PID:

beam = {
"particle_generator":"counter", # routine for generating empty primaries
"random_seed":1, # random seed for beam generation; controls also how the MC # seeds are generated
"definitions":[ {
"reference":simulation_reference_particle, # reference particle
"random_seed_algorithm":"incrementing_random", # algorithm for seeding MC
"n_particles_per_spill":1, # probability of generating a particle
"emittance_x":1., # 4d emittance
"sigma_p":25., # RMS total momentum
"t_start":-1.e6, # start time of sawtooth
"t_end":+1.e6}, # end time of sawtooth
"coupling":{"coupling_mode":"none"} # no dispersion


Updated by Hunt, Christopher over 9 years ago

I understand now. I'm not so familiar with the global data structures. From a scifi point of view everything is initialised to +1 in Kalman, implying its not being properly copied up the chain.

After a quick look it seems that the ImportSciFiRecon class, forgets to set the charge of the GlobalTrack object, and only sets it in the GlobalTrackPoint objects.

If this is indeed the case its a one line fix. I think that puts the ball in your court Adam?


Updated by Dobbs, Adam over 9 years ago

Perhaps... where does that class live? Is it part of Global? If so, a Global person should push the fix to the merge branch, and then I will include it in the next release.


Updated by Dobbs, Adam almost 9 years ago

  • Assignee changed from Adey, David to Hunt, Christopher

Chris, is this issue relevant any longer or can I close? Thanks...

Also available in: Atom PDF