barID in trigScintDigi set to 1023

[awhitbeck]

For the upstream and downstream arrays there seems to be a problem with barID:

These numbers should never be larger than 50. I am including the configuration file that I used to generate these vents. I see this in a few dozen events out of 10k.

from LDMX.Framework import ldmxcfg
from LDMX.Detectors.makePath import makeDetectorPath
from LDMX.SimApplication import generators
from LDMX.SimApplication import examples

p=ldmxcfg.Process("sim")

p.libraries.append("libSimApplication.so")
p.libraries.append("libBiasing.so")
p.libraries.append("libEventProc.so")

mySim = ldmxcfg.Producer( 'mySim' , 'ldmx::Simulator' )
mySim.parameters[ "detector" ] = makeDetectorPath( "ldmx-det-v12" )

mpgGen = generators.multi( "mgpGen" ) # this is the line that actually creates the generator
mpgGen.parameters[ "vertex" ] = [ -27.926, 0., -700 ] # mm
mpgGen.parameters[ "nParticles" ] = 1
mpgGen.parameters[ "pdgID" ] = 11
mpgGen.parameters[ "enablePoisson" ] = True
mpgGen.parameters[ "momentum" ] = [ 380., 0., 3981.909 ] #MeV

mySim.parameters['generators'] = [ mpgGen ]

mySim.parameters["beamSpotSmear"] = [20., 80., 0.]
mySim.parameters[ "runNumber" ] = 9001
mySim.parameters[ "verboseLevel" ] = 10

p.sequence=[mySim]

from LDMX.EventProc.trigScintDigis import *
trigScintDigis.parameters["pe_per_mip"]=100.
trigScintDigisDn.parameters["pe_per_mip"]=100.
trigScintDigisTag.parameters["pe_per_mip"]=100.

p.sequence.extend([trigScintDigis,
                   trigScintDigisDn,
                   trigScintDigisTag])

from LDMX.EventProc.trackerHitKiller import trackerHitKiller
findableTrack = ldmxcfg.Producer("findable", "ldmx::FindableTrackProcessor")
p.sequence.extend([trackerHitKiller,findableTrack])

p.outputFiles=['test.root']

p.maxEvents = 10000
p.logFrequency = 1000

[tomeichlersmith]

1023 = 2^10 - 1, so I'm guessing there is an overflow somewhere inside of TrigScintID when doing some bit-shifting nonsense

[bryngemark]

yeah this to me looks like initializing to -1 and then never setting it properly

[omar-moreno]

Did anything change since we tested this last? I checked the ID's for upstream and downstream before and they were correct. It's odd that it's showing up now.

On Fri, Jun 26, 2020, 12:18 PM bryngemark notifications@github.com wrote:

yeah this to me looks like initializing to -1 and then never setting it properly

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LDMX-Software/ldmx-sw/issues/826#issuecomment-650352614, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4JMXHHB7D53C4VYKK7IDLRYTX75ANCNFSM4OJI574A .

[bryngemark]

if it's true that this doesn't happen in the tagger module but in upstream and downstream modules, i'd check specifically that the module ID gets set properly.

[awhitbeck]

I think this only happens when no particle passes through the array, but that is only based on a few anecdotal observations. There shouldn't be any cases where no particle passes through the tagger array.

[omar-moreno]

On Fri, Jun 26, 2020 at 12:28 PM Andrew Whitbeck notifications@github.com wrote:

I think this only happens when no particle passes through the array, but that is only based on a few anecdotal observations. There shouldn't be any cases where no particle passes through the tagger array.

OK, if that's the case, this makes more sense.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LDMX-Software/ldmx-sw/issues/826#issuecomment-650357160, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4JMXCVT6XAXYXYU3DUEALRYTZE5ANCNFSM4OJI574A .

[bryngemark]

Right... so these are all noise hits in that case? The barID setting for noise hits assumes that the module number has been set. I see that this happens inside the real simhit loop. So that should probably be changed to accommodate the case when a module only has noise hits.

[jmmans]

Can this issue be closed?

[bryngemark]

No fix for this has been pushed yet. I did think about it yesterday but I think only ugly (collection name parsing) solutions can be implemented until we move to processing all three modules in one single collection.

So, I'd say, can't be closed.