LHE MadGraph reweighting implementation into DelphesPythia8_EDM4HEP.

[TomDingley]

BEGINRELEASENOTES

• Add lhefWeights event-weights vector read from MadGraph reweighted LHE files, stored in output root file in _EventHeader_weights for DelphesPythia8_EDM4HEP executable.

ENDRELEASENOTES

[tmadlener]

There seem to be some merge conflicts, could you try and resolve them?

[andresailer]

And could you rephrase your opening post into release notes and other text so that the release notes look more like what we have in https://github.com/key4hep/k4SimDelphes/blob/main/doc/ReleaseNotes.md

Thanks!

[TomDingley]

Hi both, thanks for the comments. I've tried to resolve the conflicts (apologies, my original repo is by now slightly outdated). Hope this worked. I'll change the release notes now to be in-line with previous iterations.

[tmadlener]

The actual changes look sensible to me. There are a few unnecessary format / whitespace changes (that I assume pre-commit will also complain). Could you remove those and also keep the naming convention for member variables?

[TomDingley]

And could you rephrase your opening post into release notes and other text so that the release notes look more like what we have in https://github.com/key4hep/k4SimDelphes/blob/main/doc/ReleaseNotes.md

Thanks!

Hi - opening post should now be of the correct format to be included in the release notes. Thanks for the pointer :)

[tmadlener]

Does the LHE weights branch also carry the names for the different weights? If yes, we should try to also preserve those into the metadata of the EDM4hep file that we produce.

That would require reading in the weight names from the LHE files and then probably storing them internally in the DelphesEDM4hepConverter to retrieve them on the first event, and put them into a the metadata podio::Frame with the correct key. The key would be edm4hep::labels::EventWeightsNames (defined in <edm4hep/Constants.h>.

[TomDingley]

Hi both, apologies for the delay in getting back to this.
Just committing changes for pre-commit to pass.

At the moment Delphes stores the weight ID as an integer, so it's not much more instructive than just storing the vector of weights. We could perhaps change this implementation to also check for strings and then store these?

[tmadlener]

Can we get the weight names from the LHE event somehow before it goes through Delphes via Pythia? Maybe it would then be possible to match weight ids and names again. Otherwise we would have to find some way to get the weight names through. I think otherwise interpreting these weights down the line will become very hard.

[TomDingley]

Hi, apologies for the delayed response - I just got back from a short holiday.

I have an implementation working that reads the weights using a new function in DelphesPythia8Common and is called within DelphesPythia8Reader. Then stored eventually in the branch GPStringKeys under EventWeightNames. Let me know what you think, it's perhaps a tad messier than required at the moment.

[tmadlener]

Very nice. This is in principle pretty much the solution, I had in mind. I am wondering whether we need to re-open the LHE file again to get to the weight names, or whether we would be able to re-use some of the Pythia8 functionality.

If I read the documentation correctly, it should be possible to obtain it via

const auto& weightNames = m_pythia->info.weightNameVector();

I think that it should be possible to call that after m_pythia->init() and I would assume (or hope) that this also works for weights read from LHEF files. That would make it possible to remove the std::vector<std::string> getWeightNames(const std::string&) free function again and we would not have to bother with maintaining the reading of the LHEF files since Pythia already does everything for us.

[tmadlener]

Suggested change

	frame.putParameter<std::vector<std::string>>(edm4hep::labels::EventWeightsNames, weightNames);
	frame.putParameter(edm4hep::labels::EventWeightsNames, weightNames);

It's not strictly necessary in this case to explicitly spell out which template function you want to call as the compiler will figure it out from the arguments in any case.