Skip to content
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

Make the TrueJet processor use the PIDHandler to set the ParticleIDs #132

Merged
merged 5 commits into from
Jun 24, 2024

Conversation

tmadlener
Copy link
Contributor

BEGINRELEASENOTES

  • Make the TrueJet processor use the PIDHandler to set the ParticleIDs for the different objects it creates. This sets the necessary metadata that is required, e.g. for the conversion to EDM4hep.

ENDRELEASENOTES

Fixes key4hep/k4EDM4hep2LcioConv#62

@Zehvogel can you check whether this fixes things on your end? At least from a technical level, the algorithm names might still need some tuning, but I would also be interested to see which ones are actually hit / converted.

@Zehvogel
Copy link
Contributor

Zehvogel commented May 8, 2024

Yes I will test it. It would probably also be good if someone who uses the MarlinUtil TrueJet parser can test if that still works with this change. Maybe someone at DESY? :)

@tmadlener
Copy link
Contributor Author

Thanks. In principle nothing should have changed other than that we are now writing some additional metadata as well. I will check if that is actually true.

@Zehvogel
Copy link
Contributor

Zehvogel commented May 8, 2024

This fixes running TrueJet for me. I still need to adapt my RDataframe code to work on the new direction though.
However I compared the podio-dump output after this change and before reversal of the PID collection and it looks like everything is correct. Depending on what kind of events one uses a lot of the PIDs will stay empty.

As far as I can tell *_PID_TrueJet_*_jet_n is filled for the n-th jet belonging to the initial/final colour neutral. I have no idea how this will ever reach values much greater than two... maybe @MikaelBerggren can comment if we really need 25? Also the 0'th one is never filled? The files become really crowded at the moment with all of them in there...

I attached the above-mentioned podio-dump outputs if anyone wants to take a look :)

truejet_oldpid.txt
truejet_newpid.txt

auto fafpf_mainPidId = fafpfPidHandler.addAlgorithm("TrueJet_fafpf", {});
std::array<int, 25> fafpf_pidIds{};
for (size_t i = 0; i < fafpf_pidIds.size(); ++i) {
fafpf_pidIds[i] = fafpfPidHandler.addAlgorithm("TrueJet_fafpf_jet_" + std::to_string(i), {});
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
fafpf_pidIds[i] = fafpfPidHandler.addAlgorithm("TrueJet_fafpf_jet_" + std::to_string(i), {});
fafpf_pidIds[i] = fafpfPidHandler.addAlgorithm("TrueJet_fafpf_jet_" + std::to_string(i + 1), {});

Also the 0'th one is never filled? The files become really crowded at the moment with all of them in there...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

doesn't this do the opposite? I.e. it just renames 0 to 1 but it will still never be filled?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't fix that, but I just remembered I wanted to do this, because previously the one that goes currently into the "main" PID went into 0.

auto fafpi_mainPidId = fafpiPidHandler.addAlgorithm("TrueJet_fafpi", {});
std::array<int, 25> fafpi_pidIds{};
for (size_t i = 0; i < fafpi_pidIds.size(); ++i) {
fafpi_pidIds[i] = fafpiPidHandler.addAlgorithm("TrueJet_fafpi_jet_" + std::to_string(i), {});
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
fafpi_pidIds[i] = fafpiPidHandler.addAlgorithm("TrueJet_fafpi_jet_" + std::to_string(i), {});
fafpi_pidIds[i] = fafpiPidHandler.addAlgorithm("TrueJet_fafpi_jet_" + std::to_string(i + 1), {});

@tmadlener
Copy link
Contributor Author

Also the 0'th one is never filled? The files become really crowded at the moment with all of them in there...

I am not sure if this can even be checked easily, but were these filled before?

@Zehvogel
Copy link
Contributor

Also the 0'th one is never filled? The files become really crowded at the moment with all of them in there...

I am not sure if this can even be checked easily, but were these filled before?

I think that the 0'th one was not filled was expected if you start the counting of the jets per ICN by 1. There is no ICN/FCN with no truejet belonging to it. So that one seems to be simply left over.

For the values > 2 I am not so sure. I think 3 and 4 are used relatively often (as soon as you have gluon-splitting etc.).

Leaving my area of expertise even more I would guess that a final colour neutral would by definition always result in two (true)jets while an initial colour neutral can have $2n$ (true)jets where $n$ is the number of final colour neutrals it hadronises into.

So maybe we can at least reduce the amount of fafpf PIDs to two (three including the main one)?

@tmadlener tmadlener force-pushed the truejet-pidhandler branch from feaee55 to dc83d18 Compare June 19, 2024 14:06
@tmadlener
Copy link
Contributor Author

After merging #134, we have almost halfed the number of ParticleID objects that will be visible once this has been converted to EDM4hep. For the initial state side there is no generally applicable way to do this. The number 25 has been chosen to work at ILD up to 1 TeV. At lower energies this might be smaller. I think the easiest way of dealing with this might be to simply drop the "superfluous" collections via the KeepDropSwitch and configuration (untested) along the lines of

# ...
"drop *_PID_TrueJet_fafpi_jet1?",
"drop *_PID_TrueJet_fafpi_jet2?",
# and then maybe some single digits as well if you still want to get rid of more
# or alternatively drop all of them and keep only the ones you want, might be the same number of lines

@@ -837,6 +848,12 @@ void TrueJet::processEvent( LCEvent * event ) {
// pre-PS part

LCCollectionVec* fafpi_vec = new LCCollectionVec(LCIO::RECONSTRUCTEDPARTICLE ) ;
auto fafpiPidHandler = UTIL::PIDHandler(fafpi_vec);
auto fafpi_mainPidId = fafpiPidHandler.addAlgorithm("TrueJet_fafpi", {});
std::array<int, 25> fafpi_pidIds{};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know the 25 is just the result of correctly making the 0'th pid the mainPid, but I wonder if the 26 before was correct? I would have thought that we would expect an even number here (after removal of the mainPid).

auto fafpi_mainPidId = fafpiPidHandler.addAlgorithm("TrueJet_fafpi", {});
std::array<int, 25> fafpi_pidIds{};
for (size_t i = 0; i < fafpi_pidIds.size(); ++i) {
fafpi_pidIds[i] = fafpiPidHandler.addAlgorithm("TrueJet_fafpi_jet_" + std::to_string(i), {});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we format this to left-pad with 0 to have nicer sorting in podio-dump etc.?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So basically, TrueJet_fafpi_jet_01 for example?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done. Should work until someone wants more than 99 of these ;)

@Zehvogel
Copy link
Contributor

While you are in there anyway, do you mind setting

streamlog_out(WARNING) << " processing event: " << evt->getEventNumber()

to something like MESSAGE?

@tmadlener tmadlener merged commit 34c6e80 into iLCSoft:master Jun 24, 2024
8 checks passed
@tmadlener tmadlener deleted the truejet-pidhandler branch June 24, 2024 08:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

broken conversion of lcio particle IDs that were not created using the PID handler
2 participants