search

iLCSoft / MarlinReco

GNU General Public License v3.0
4 stars 40 forks source link

Add LeptonIDProcessor #114

Closed Zehvogel closed 1 year ago

Zehvogel commented 1 year ago

Here the (long awaited) draft for the LeptonIDProcessor I used for my master thesis results. There is still some cleaning up to do that I will try to get in this week.

At the moment there is still a PIDUtil.{h,cc} which will also used by my SLDIDProcessor and might be better off in MarlinUtil. I can move it there if necessary. The SLDIDProcessor still needs some more cleaning up though before I will open another PR for that one.

BEGINRELEASENOTES

ENDRELEASENOTES

Zehvogel commented 1 year ago

Thanks for the detailed feedback and the helpful suggestions Thomas!

I will cleanup PIDUtil to only include things actually needed in this PR. A lot of the functions in there will only be needed by the SLDIDProcessor and I don't know yet when I will get around to upload that one.

Regarding the weights I don't care where they live. I don't think that you want to use the same ones for a mass production, they could use some refinement. I only included them to make it easier to try out this processor. I also noticed now that they are horribly big... not sure if we should keep them in here :/

tmadlener commented 1 year ago

clicdp nightly CI is failing because it picks up the wrong LCIO. Let me try to fix that with another PR

tmadlener commented 1 year ago

115 should fix the issues with the clicdp nightlies based CI builds.

tmadlener commented 1 year ago

@Zehvogel do you want to pick up iLCSoft/LCIO#171 still for this? On the other hand the current version is slightly more backwards compatible.

Zehvogel commented 1 year ago

@tmadlener I don't have a strong preference. If you want I can make the changes now.

Zehvogel commented 1 year ago

Looks like it will not be that easy to do... getRelatedToMaxWeightAndObject returns a const LCObject* but needs non-const LCObject* as input as the underlying functions expect that. And I want to call it again with the output of the first call as input...

I had a quick look on how much of LCIO one would need to touch to have a more consistent use of const by changing getRelatedToObjects to take in a const LCObject*, but there is really no end in sight. We could also consider removing the const on the return value of getRelatedToMaxWeightAndObject etc. but I don't like that.

I can probably build a workaround using the From methods without touching LCIO again, but for now I would prefer to keep this as is and maybe change it later after someone has made LCIO const-ness a bit more consistent :)

tmadlener commented 1 year ago

I will rebase this onto the latest master then, and merge after CI has passed (at least the ones that are currently working), unless you stop me in the next few hours.