Open jllanfranchi opened 7 years ago
Selecting the non-neutrino data is clunky at the moment - they can only be directly select from the data object (i.e. data_object['muons']
) and there's also a lot of copy-paste code to deal with the different particle types (e.g. in the __init__
). One way to make this more generic is using a NuFlavInt*
class which incorporates muons, noise, etc. We could also add a function in which you can select the type of particle to iterate on, something like data_object.iterate(particle_type)
, which makes selecting the particle more generic and hopefully the code too can be more generalised using this.
I'm not sure I grasp the scope of this and whether it's still important :thinking:
@ShiveshM has developed a very useful successor to the
Events
object in theData
object (see $PISA/pisa/core/events.py, same file for both classes). This allows for "dynamically" combining flavints together (might still be some work to get weights right) and also generalizes simply to noise and mouons (and presumably other things we can throw at it).He has also made this a shared object that can be used by all stages in his pipeline, eliminating redundancy and ensuring consistency in the events that are used by each stage. This is a behavior we should replicate in all the stages.
Data
toEvents
, replacing theEvents
object. (That name seems more general, sincedata
is a very specific thing, whileEvents
can include noise, muons, background, MC, etc., etc. and data.events[flav][int]
)... which just has a veneer of 2-level indexing but this doesn't generalize well at all now)NuFlavInt*
work with muons, noise, (background), ... etc.; OR create a higher-level parser (or class?) that can deal with the various categories of things we might have in our data.There are probably many other issues to consider, so feel free to add any you can think of.