-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement T3 r-z helix chi2 cuts #92
Implement T3 r-z helix chi2 cuts #92
Conversation
please update the target branch to CMSSW_14_1_0_pre3_LST_X_LSTCore_realfiles_batch1_devel |
… into CMSSW_14_1_0_pre3_LST_X_LSTCore_realfiles_T3_rzchi2_final
/run all |
@bucket420 I added you so you can use the CI. If you leave another comment it should work |
/run all |
The PR was built and ran successfully in standalone mode. Here are some of the comparison plots. The full set of validation and comparison plots can be found here. Here is a timing comparison:
|
There was a problem while building and running with CMSSW. The logs can be found here. |
This is probably because the devel branch has not been updated to 14_2_0_pre1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a general comment, it would be great if the calculations applied here would be harmonized with the ones applied for T5: the logic is the same but it is applied in a different order. Even better, would it make sense to put some of the code here in functions and apply those, both here and in the T5 calculations, to simplify the code and make it clearer. It would also expose potential bugs and/or omissions in the different implementations.
Just to understand the future of this PR, do you intend to put things in functions and reuse them for the different objects? My request seems to become even more relevant in light of #97 (comment). |
Yes, I do plan to refactor the code so that we can reuse functions for different objects. Just wondering if I should put the common functions in a new file or somewhere else? Also, would it be better to make a separate PR for that? Or should I keep working on this PR? |
Keep working on this PR would be fine for me. |
/run all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the updates, @bucket420! I think the majority of the comments have been dealt with. There are a few small follow-ups on still unresolved discussions.
By the way, I see that the syntax tests fail. Have you tried running scram b -j 12 code-checks >& c.log && scram b -j 12 code-format >& f.log
and commit the proposed changes?
@ariostas will that work or there are issues with code checks?
/run all |
The PR was built and ran successfully in standalone mode. Here are some of the comparison plots. The full set of validation and comparison plots can be found here. Here is a timing comparison:
|
The PR was built and ran successfully with CMSSW. Here are some plots. OOTB All TracksThe full set of validation and comparison plots can be found here. |
I've run the command and committed the suggested change, but the static checks still failed |
/run checks |
I took the liberty to try and fix the formatting issues. My hypothesis is that you were working on an older CMSSW version and the formatting changes were not compatible with the ones in Other than that, the PR seems to be ok from my side. I left a comment about having a presentation linked as documentation, and let's agree that this be added to the PR description, so that it doesn't block the merge. |
… into CMSSW_14_1_0_pre3_LST_X_LSTCore_realfiles_T3_rzchi2_final
/run checks |
Well, I failed. Pinging @ariostas again, for any ideas on the source of the issue. |
I think that my question/comment about variable naming was clarified |
yes, CI is further ahead than this topic and target branch (we are missing batch6 (and 5?) in the devel branch) |
Ok, then I propose that we merge even with the static checks not passed. Unless there is any disagreement, I will merge the PR as is at the end of my day (~4h). |
I merged PRs in devel recently after checking explicitly in the code check logs that the part to be modified was not modified by the PR |
Indeed, this is the case. As you may have noticed in my last commits, I ended up chasing differences in the |
7a2c422
into
CMSSW_14_1_0_pre3_LST_X_LSTCore_realfiles_batch1_devel
@@ -238,8 +238,7 @@ namespace cxxopts { | |||
class Option_syntax_exception : public OptionParseException { | |||
public: | |||
Option_syntax_exception(const std::string& text) | |||
: OptionParseException("Argument " + LQUOTE + text + RQUOTE + " starts with a - but has incorrect syntax") { | |||
} | |||
: OptionParseException(u8"Argument " + LQUOTE + text + RQUOTE + u8" starts with a - but has incorrect syntax") {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@VourMa
it looks like this broke the standalone in devel
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like it, even though I am not sure why this change was proposed by the checks. Anyways, trying to fix the checks was a bigger failure that initially thought, sorry about that.
Let me make a standalone PR to fix that.
Summary:
This PR implements T3 r-z helix chi2 cuts, which replace the current linear approximation method. 2 MDs are used to build a helical trajectory, and the remaining MD is used to calculate the chi2. The T3s are divided into 25 regions according to the positions of the MDs, and the cuts are selected based on the ROC curves in each regions.
To get optimal performance, the linear cuts are kept for regions 9, 20-24, the middle MD is used to calculate the helix chi2 for regions 5 and 19, and the last MD is used to calculate the helix chi2 for all other regions.
Performance:
Link to slides.