Change ldmx-sw to be able to read MG5 inputs

[tvami]

Is your feature request related to a problem? Please describe.

We moved the LHE production to MG5 in LDMX-Software/dark-brem-lib-gen#19

Describe the solution you'd like

Now next step is to change ldmx-sw to be able to read those LHE files

Describe alternatives you've considered

Keep using MG4 files

Additional context

Follow-up to #1520

[tomeichlersmith]

I generated a MG5 library using v5.0 of dark-brem-lib-gen.

dbgen use latest
mkdir scratch
dbgen work scratch/
dbgen run --run 1 --max_energy 8.0 --apmass 0.01

The library generated has the correct structure. One directory with the LHE files within it.
The LHE files do have events in them. I am now guessing that the parsing library I wrote initially in G4DarkBreM does not support some additional LHE tags that are inserted by MG5.

Then I ran the config from the signal validation sample.

denv init ldmx/pro:v4.2.0
# copy ldmx-sw/.github/validation_samples/signal/config.py to this directory
# set p.maxEvents = 10 and p.run = 1
denv fire config.py

which replicates the issue from the CI.

[ ParallelWorld ] 0 debug: Adding : sp_hcal_front_back_PV to parallel world.
[ ParallelWorld ] 0 debug: Adding : sp_hcal_top_bot_PV to parallel world.
[ ParallelWorld ] 0 debug: Adding : sp_hcal_left_right_PV to parallel world.
Unrecognized Exception: BadConf : Unable to find any library entries at 'dblibgen/electron_tungsten_MaxE_8.0_MinE_4.0_RelEStep_0.1_UndecayedAP_mA_0.01_run_1'
  The library is either a single CSV file or a directory of LHE files.
  Any individual file can be compressed with `gzip`.
  This means the valid extensions are '.lhe', '.lhe.gz', '.csv', and '.csv.gz'

Luckily for me, past Tom figured that library parsing would be annoying and wrote the g4db-extract-library program which uses the LHE library parser from G4DarkBreM to extract the necessary components and then writes a CSV that is loadable by G4DarkBreM. Using this command runs successfully but produces an empty CSV.

[tomeichlersmith]

I'm guessing the LHE parser, which made some assumptions about the input LHE files, had those assumptions broken when we switched to MG5.

[tomeichlersmith]

Found it. The new MG model uses the PDG ID 1023 for the dark photon but we assume the PDG ID here is 622. There are two solutions:

1. Update our code here to look for PDG 1023 in the LHE rather than PDG 622.
2. Update dark-brem-lib-gen to use 622 for the dark photon PDG.

I prefer option (1) since the PDG 1023 conforms with the PDG ID numbering standards and I know where to fix it.

ldmx-sw/SimCore/src/SimCore/APrimePhysics.cxx

Line 111 in 45ee57d

model.getParameter<int>("aprime_lhe_id", 622),

And actually, the aprime_lhe_id is a configurable part of our dark brem model, so technically resolving this issue doesn't require changing any of the C++! (Although, I think it would be a good idea to make the parameter default be the number produced by our default library generator.)

Adding

mySim.dark_brem.model.aprime_lhe_id = 1023

to the config then allows it to run normally! 🎉

[tvami]

That's what I guessed to in #1520

And I agree option 1) is to go.
However the nuclei and past interaction electron ids (611) also need to change. That might need c++ change

[tomeichlersmith]

The nuclei IDs are ignored when parsing in G4DarkBreM. We just look for the target Z by scanning the file for the line with Znuc in it. I don't remember seeing a 611 milling around.

Certainly, if we want our Geant4 PDG IDs to match the IDs in the LHE, then we need more C++ changes. Specifically, in how we define the G4APrime. The only place in ldmx-sw where we care about the nuclei ID is in the LHE Primary Generator.

ldmx-sw/SimCore/src/SimCore/Generators/LHEPrimaryGenerator.cxx

Lines 53 to 57 in 45ee57d

	if (particle->getIDUP() == -623) { /* Tungsten ion */
	G4ParticleDefinition* tungstenIonDef =
	G4IonTable::GetIonTable()->GetIon(74, 184, 0.);
	if (tungstenIonDef != nullptr) {
	primary->SetParticleDefinition(tungstenIonDef);

But I think this fix is only necessary because the nuclei was not conforming to the PDG ID standards. I think Geant4 will be able to deduce the correct nuclei from these IDs (untested).