Reconstruction of 207Bi internal conversion electrons

[macolino]

Hi, when I simulate 207Bi events Falaise does not manage to reconstruct properly the internal conversion electron tracks since they are emitted with delay with respect to the decay. What do you sugges to solve this issue ? It would be nice to have the possibility to set this feature in the pipeline. Thanks, regards CM

[cherylepatrick]

@macolino - I'm curious what it does - does it reconstruct the hits as delayed? And does it cluster them but just fail to fit them to a track? I ask because I know that Lauren had to change the default pipeline settings for tracking and clustering delayed hits in order to reconstruct alphas. According to her talk last week, she added TPC.processing_delayed_hits : boolean = true to her reconstruction config file to get the clustering and line.guess.fit_delayed_clusters : boolean = true to get the tracking. So if you don't have those, it might be worth trying it again with them to see if it helps.

[pguzowski]

I have talked about this in #25

Also these aren't really delayed (they would have an associated calo hit), they would be the prompt part of another triggered event. But first we need the digitization/trigger simulation to be implemented in software, to treat this properly.

[drbenmorgan]

This is a reconstruction task so assigning to coordinators of the WG to handle directly or find volunteers.

[fmauger]

Next Bayeux release (3.3) will provide a wrapper generator, namely "genbb::time_slicer_generator" which will be able to split a Bi207 primary decay in two parts:

• the "prompt" event with only prompt particles emitted before a time threshold set by the user
• the "delayed" event with only particles emitted "after' the time threshold

A typical config will look like this:

###############################
# The original Bi207+Pb207m decay from Decay0:
[name="Bi207" type="genbb::wdecay0"]
#@config Bi-207 decay 
decay_type      : string  = "background"
decay_isotope   : string  = "Bi207+Pb207m"

#############################################
# Splitted Bi207+Pb207m decay with time slicing roughly compatible with SuperNEMO 
# trigger system for simulated Bi-207 based calibration runs:
[name="calibBi207" type="genbb::time_slicer_generator"]
#@config Bi-207 decay with time slicing
logging.priority : string = "debug"
generator      : string  = "Bi207"
time_threshold : real as time = 400 ns
time_cut       : real as time = 5 s
mode           : string = "both_events"
record_original_event_id : boolean = true

Such a generator will fake two "independant" events built from one single decay and confined in different time windows. This mechanism emulates the behaviour of a hardware trigger which naturally splits decay cascade using some specific time constant. The new class is available in some Bayeux's devel branch and we will to make a try with Carla ASAP. Once validated, Falaise will be able to use it, with a small add-on in its lists of supported primary event generators. This will enable to play with the Bi207 generator while the trigger/digitization model is not available yet. I also have checked that this new class works with Bi214-Po214 and splits BiPo cascades in sequences of some prompt 'e-gammas' events followed by delayed "lonely alpha" events.

[pfranchini]

I'm curious what it does - does it reconstruct the hits as delayed? And does it cluster them but just fail to fit them to a track? I ask because I know that Lauren had to change the default pipeline settings for tracking and clustering delayed hits in order to reconstruct alphas. According to her talk last week, she added TPC.processing_delayed_hits : boolean = true to her reconstruction config file to get the clustering and line.guess.fit_delayed_clusters : boolean = true to get the tracking. So if you don't have those, it might be worth trying it again with them to see if it helps.

In current official-2.0.0_changed.conf they are both true by default, but still the delayed electrons are neither clustered nor reconstructed. The time window is 13 us and their delay goes up to more than 1 second.

[cherylepatrick]

Did you do Francois' thing? What were your time threshold and time cut?

[pfranchini]

Was using the normal generator, trying now to understand how to use the new (1 year ago!) time_slicer_generator.

[cherylepatrick]

Don't know if it will help, but it is worth a try!

[pfranchini]

@fmauger Where should I put the configuration file you have suggested? Does not work in share/Falaise-4.0.1/resources/genbb/CalibrationSources.conf.

[fmauger]

I have checked that share/Falaise-4.0.1/resources/genbb/CalibrationSources.conf should be the right place to add it:

# Splitted Bi207+Pb207m decay with time slicing roughly compatible
# with SuperNEMO trigger system for simulated Bi-207 based calibration runs:
[name="calibBi207" type="genbb::time_slicer_generator"]
  #@config Bi-207 decay with time slicing;group=calibration
  logging.priority : string = "debug"
  generator      : string  = "Bi207"
  time_threshold : real as time = 400 ns
  time_cut       : real as time = 5 s
  mode           : string = "both_events"
  record_original_event_id : boolean = true

I guess you should also add the following line in the GenBB.csv file to make this new generator available from the variant system:

calibBi207 : Bi-207 decay with time slicing : Calibration : 

Then make a try...

In other words: 1 - The CalibrationSources.conf file defines the generator 2 - The GenBB.csv publishes/registers it in Falaise's variant interface

frc

[pfranchini]

I was forgetting about GenBB.csv so now it produces some results: thanks. Still I do not see any delayed event being reconstructed. Should I expect to see one event with the characteristic X-rays from the electron capture and the following one with the eventual internal conversion electron(s)? Should the threshold be O(100ms) and the time_cut few seconds?

[emchauve]

I did a quick test, the time slicer looks to work (splitting into 2 separated events). After generation of 1E5 events, I have a significant fraction of events with a delay greater than 5 seconds, so I recommand the following configuration for the time cut : time_cut : real as time = 100 s

However electrons track are still NOT reconstructed because the time of the primary event (in case of delay) does contains the time shift, which is then propagated into the time of calorimeter and tracker step hit (so we have an event with delay hits and no prompt hits!).

After some investigation, I found the origin of the problem : a typo + instead of - in the time slicer generator of genbb!! I just made the pull request on Bayeux : https://github.com/BxCppDev/Bayeux/pull/58

Bi207 electrons are reconstructed after this fix on my side. Once this is merge, please give a try Paolo to confirm so, then we could close finally this issue!

[drbenmorgan]

After some investigation, I found the origin of the problem : a typo + instead of - in the time slicer generator of genbb!! I just made the pull request on Bayeux : BxCppDev/Bayeux#58

Bi207 electrons are reconstructed after this fix on my side. Once this is merge, please give a try Paolo to confirm so, then we could close finally this issue!

Great! Could you request a new patch release of Bayeux (3.4.2) with that incorporated, then we can make that the required minimum version. If it'll be in a new major/minor release that'll be fine too, just might require a little more testing.

[pfranchini]

Hi @emchauve thanks for that, I was not brave enough to look into Bayeux. Will test it once merged and produce some private MC for Miroslav's analysis for a first pass and comparison with Carla's MC (which used the t=0 delay if I understood correctly).

[pfranchini]

After some investigation, I found the origin of the problem : a typo + instead of - in the time slicer generator of genbb!! I just made the pull request on Bayeux : BxCppDev/Bayeux#58 Bi207 electrons are reconstructed after this fix on my side. Once this is merge, please give a try Paolo to confirm so, then we could close finally this issue!

Great! Could you request a new patch release of Bayeux (3.4.2) with that incorporated, then we can make that the required minimum version. If it'll be in a new major/minor release that'll be fine too, just might require a little more testing.

Hi, I see that this is has been merged since Bayeux 3.4.2 (which is currently at 3.4.3). I think I have tested this before with a local patch but let me do it again before closing the issue.

[fmauger]

@Manu : high-statistics MC runs to check everything is fine.