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?

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?

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?

I use MAUS 0.9.2

Basically, I do
global_event->get_tracks();
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
"transverse":{
"transverse_mode":"twiss",
"beta_x":1000.,
"alpha_x":0.,
"emittance_x":1., # 4d emittance
"beta_y":8000.,
"alpha_y":0.5,
"emittance_y":1.,
},
"longitudinal":{"longitudinal_mode":"sawtooth_time",
"momentum_variable":"p",
"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
}]
}

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?

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.