HepUtils update: Multiple Jet Collections and Cluster sequence access

[ChrisJChang]

This adds many updates to HepUtils, and allows use of multiple jet collections to be stored in the event class. It also keeps the cluster sequence alive so that it can be accessed in analyses.

The pointer to the cluster sequence can be accessed with "event->clusterseq()".

I also changed all existing use of event->jets() to use a jet collection name (using the default antikt_R04 for most analyses).

I am listing @anderkve as a reviewer.

[anderkve]

Thanks for preparing the PR @ChrisJChang! Is there a set of example YAML settings that we can include in e.g. ColliderBit_CMSSM.yaml to demonstrate the jet collections option?

[anderkve]

When testing the current ColliderBit_CMSSM.yaml on this branch, I get an error from contur:

Gambit has encountered an uncaught error during initialisation.

Check the output logs for details.
(Unless you see one or more uninitialised logger messages above, these will be in the location specified in your yaml file.)

what(): TypeError: expected bytes, numpy.float64 found

At:
  <stringsource>(15): string.from_py.__pyx_convert_string_from_py_std__in_string
  /home/anders/physics/GAMBIT/gambit_2/Backends/installed/contur/2.1.1/contur/factories/yoda_factories.py(245): root_n_errors
  /home/anders/physics/GAMBIT/gambit_2/Backends/installed/contur/2.1.1/contur/factories/yoda_factories.py(379): __init__
  /home/anders/physics/GAMBIT/gambit_2/Backends/installed/contur/2.1.1/contur/factories/yoda_factories.py(882): __get_likelihood_blocks
  /home/anders/physics/GAMBIT/gambit_2/Backends/installed/contur/2.1.1/contur/factories/yoda_factories.py(859): __init__
  /home/anders/physics/GAMBIT/gambit_2/Backends/installed/contur/2.1.1/contur/factories/depot.py(103): add_point
  /home/anders/physics/GAMBIT/gambit_2/Backends/installed/contur/2.1.1/contur/run/run_analysis.py(506): main

I'm not sure yet if this issue is specific to this branch or if this is an error that exists on master.

[anderkve]

OK, turns out the error above is an existing problem on master. I've created an issue for it here: #465

So for this PR I'll just comment out the Rivet/Contur stuff in my further test runs.

[anderkve]

Thanks for all the work on this, @agbuckley and @ChrisJChang -- looks very good to me. As discussed in the ColliderBit meeting just now, we only need two changes before this PR can be merged:

• We remove the default settings for the jet_collections options and rather force the user include at least one jet collection configuration in their YAML file

• We should go through the existing YAML files on this branch and replace the old antiktR setting with a new YAML node containing the corresponding settings for a antikt_R04 jet collection.

[anderkve]

@ChrisJChang, I can go through the YAML files and update all the settings. Will do it right away.

[anderkve]

@ChrisJChang, I guess the code below is in the wrong file? The error messages point to Py8EventConversions.hpp, which indeed seems like a more natural place for these functions to live.

gambit/ColliderBit/src/getHepMCEvent.cpp

Lines 60 to 99 in 0762388

	/// Storage of different FastJet methods
	FJNS::JetAlgorithm FJalgorithm_map(str algorithm)
	{
	FJNS::JetAlgorithm result;
	if (algorithm == "antikt") {result = FJNS::antikt_algorithm;}
	else if (algorithm == "cambridge") {result = FJNS::cambridge_algorithm;}
	else if (algorithm == "kt") {result = FJNS::kt_algorithm;}
	else if (algorithm == "genkt") {result = FJNS::genkt_algorithm;}
	else if (algorithm == "cambridge_for_passive") {result = FJNS::cambridge_for_passive_algorithm;}
	else
	{
	ColliderBit_error().raise(LOCAL_INFO, "Could not find jet algorithm in list available. Please add the missing option to the FJalgorithm_map function in Py8EventConversions.hpp.");
	}
	return result;
	}
	FJNS::Strategy FJstrategy_map(str strategy)
	{
	FJNS::Strategy result;
	if (strategy == "Best") {result = FJNS::Best;}
	else if (strategy == "NlnN") {result = FJNS::NlnN;}
	else
	{
	ColliderBit_error().raise(LOCAL_INFO, "Could not find jet strategy in list available. Please add the missing option to the FJstrategy_map function in Py8EventConversions.hpp.");
	}
	return result;
	}
	FJNS::RecombinationScheme FJRecomScheme_map(str reco_scheme)
	{
	FJNS::RecombinationScheme result;
	if (reco_scheme == "E_scheme") {result = FJNS::E_scheme;}
	else if (reco_scheme == "pt_scheme") {result = FJNS::pt_scheme;}
	else if (reco_scheme == "pt2_scheme") {result = FJNS::pt2_scheme;}
	else
	{
	ColliderBit_error().raise(LOCAL_INFO, "Could not find jet recombination scheme in list available. Please add the missing option to the FJRecomScheme_map function in Py8EventConversions.hpp.");
	}
	return result;
	}

[ChrisJChang]

* We remove the default settings for the `jet_collections` options and rather force the user include at least one jet collection configuration in their YAML file

There is also a check for the run options have the current collider settings (runOptions.hasKey(RunMC.current_collider())), and setting a default xsec veto, and flag whether to simulate parton only. This is where I put the default jet collection settings. Do you think we should remove this, so the user has to also provide the current collider as a yaml entry?

[ChrisJChang]

The error messages point to Py8EventConversions.hpp, which indeed seems like a more natural place for these functions to live.

This was where those were living originally, however having them in a header file creates multiple definition errors when these are used in multiple places. Since there is no source file associated with the Py8EventConversions, and they are not specific to Pythia8, perhaps it would make more sense to move them to ColliderBit/src/Utils.cpp

[ChrisJChang]

I removed the default settings, throwing an error if they are not present. I also moved the location of the list of available fastjet algorithms, strategies, etc to Utils.cpp.

[anderkve]

Thanks for the quick fixes, @ChrisJChang -- I agree with all the decisions above. I'll let the CI jobs run to completion (or known crash) and then merge this to master.

[anderkve]

Btw, @ChrisJChang, do happen to know why the gambit_build (ubuntu-py2) CI job suddenly has reappeared? The only mention of ubuntu-py2 I find in our repo is some commented-out code in .github/workflows/ci.yml...

[ChrisJChang]

Btw, @ChrisJChang, do happen to know why the gambit_build (ubuntu-py2) CI job suddenly has reappeared? The only mention of ubuntu-py2 I find in our repo is some commented-out code in .github/workflows/ci.yml...

Turns out that there was a branch rule that it had to pass both ubuntu and ubuntu-py2 runners on the master branch. When the ubuntu-py2 runner was removed, we should have removed that rule. I went into the GutHib settings and removed this. I can add in the Mac ones as well if we like.

[anderkve]

Thanks! That makes sense. (I hadn't looked into the branch protection stuff before.)

I'd say we just keep the Ubuntu one required for now. Then we can reassess in a future Core meeting which jobs to list as required once PR #462 is done.

[anderkve]

Merging this now. Thanks for all the work on this!