TaggerVetoFilter inefficiency #1146
Assignees
Milestone
Comments
|
While working on LDMX-Software/SimCore#86, I ran into #1069 quite a lot which really made validating developments hard. Since I was already messing with the photonNuclear process, I decided to try removing the PN process entirely to see what would happen. To my surprise, after 3204 aborted attempts the event passes the filters. I'm presuming this is related to this issue. Gamma physics change to try this: void GammaPhysics::ConstructProcess() {
aParticleIterator->reset();
// Loop through all of the particles and find the "gamma".
while ((*aParticleIterator)()) {
G4ParticleDefinition *particle = aParticleIterator->value();
G4ProcessManager *pmanager = particle->GetProcessManager();
G4String particleName = particle->GetParticleName();
if (particleName == "gamma") {
// Get the process list associated with the gamma.
G4ProcessVector *vProcess = pmanager->GetProcessList();
// Search the list for the process "photoNuclear". When found,
// change the calling order so photonNuclear is called before
// EM processes. The biasing operator needs the photonNuclear
// process to be called first because the cross-section is
// needed to bias down other process.
for (int iProcess = 0; iProcess < vProcess->size(); ++iProcess) {
G4String processName = (*vProcess)[iProcess]->GetProcessName();
if (processName == "photonNuclear") {
pmanager->RemoveProcess(iProcess);
// pmanager->SetProcessOrderingToFirst((*vProcess)[iProcess],
// G4ProcessVectorDoItIndex::idxAll);
}
}
// Add the gamma -> mumu to the physics list.
pmanager->AddDiscreteProcess(&gammaConvProcess);
}
}
}With the config below: #!/bin/python
from LDMX.Framework import ldmxcfg
det = 14
run = 1
maxEvents = 5
thisPassName = "sim"
detector=f'ldmx-det-v{det}'
p = ldmxcfg.Process(thisPassName)
p.maxEvents = maxEvents
p.maxTriesPerEvent = 100000000000
#import LDMX.SimCore.photonuclear_models as pns
from LDMX.Biasing import ecal
from LDMX.DQM import dqm
from LDMX.SimCore import generators as gen
import LDMX.Ecal.EcalGeometry
import LDMX.Ecal.ecal_hardcoded_conditions
import LDMX.Hcal.HcalGeometry
import LDMX.Hcal.hcal_hardcoded_conditions
from LDMX.SimCore import simulator
from LDMX.Biasing import filters
from LDMX.Biasing import util
from LDMX.Biasing import include as includeBiasing
sim = simulator.simulator('ie')
sim.setDetector(f'ldmx-det-v{det}')
sim.generators = [gen.single_4gev_e_upstream_tagger()]
sim.beamSpotSmear = [20., 80., 0.] #mm
includeBiasing.library()
sim.actions.extend([
filters.TaggerVetoFilter(),
# Only consider events where a hard brem occurs
filters.TargetBremFilter(),
# Only consider events where a PN reaction happnes in the ECal
filters.EcalProcessFilter(),
# Tag all photo-nuclear tracks to persist them to the event.
util.TrackProcessFilter.photo_nuclear(),
util.StepPrinter()
])
p.run = run
p.outputFiles = ['PNtest.root']
p.histogramFile = 'PNtesthist.root'
p.logFrequency = 1
p.termLogLevel = 2
p.sequence = [sim, dqm.PhotoNuclearDQM()]you can reproduce the issue. So, looks like your hypothesis might be right. StepPrinter details:As a really dumb way to test that this is the issue, I went ahead and added a global (through the run manager) that was set to false at the start of each event which was set to true if we reached the relevant part of the filter and then just aborted the event in the simulator if it wasn't touched. Obviously, this isn't a solution but it does patch both this and the next events that would have failed for the same reason (at the fourth one, the step printer crashes but... that's a different issue). |
|
A simple, albeit not very elegant, solution to this is to make the TaggerVetoFilter an EVENT action as well as a STEPPING action, add a field to the event info which corresponds to whether or not we ever entered the tagger region with the primary that we set in the stepping action and then in the EndOfEventAction just checking this and aborting if it fails. I ran 1000000 such events without a PN process and it worked without issue. |
|
Interestingly, this still isn't enough to fix #1069... However, that issue seems to be unrelated, it can fail even when the PN products are present in the output :( |
This was referenced Mar 5, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
This was initially observed when studying the signal generation using this filter. What I observed through some extra debug printouts (and using the$p_z < 0$ and $z < 0$ at its end point, so I think something caused the primary electron to back-scatter. We still see a near-beam-energy total reconstructed energy in the ECal however, so particles are still reaching it.
StepPrinteruser action) was that the primary electron was not entering the target region. This did not "activate" theTargetDarkBremFilterwhich means it did not know to veto the event. The primary electron was found withInitial Hypothesis
Various small scatters bend the primary electron into the magnet which causes a much harder scatter (perhaps electron-nuclear or perhaps just a hard brem). The non-primary products of this hard scatter continue downstream into the ECal while the primary electron recoils back, avoiding the target and thus the
TargetDarkBremFilter.Additional context
#1138 (comment)
#1139
Plan
The text was updated successfully, but these errors were encountered: