Update SimCore to include recent features

[EinarElen]

I am updating ldmx-sw, here are the details.

What are the issues that this addresses?

This resolves #1234

Check List

• I successfully compiled ldmx-sw with my developments

• I ran my developments and the following shows that they are successful.
  See PRs in SimCore

• I attached any sub-module related changes to this PR.

Related Sub-Module PRs

If you have developments in a submodule that you need to merge in along with these developments, please link those PRs here, otherwise just delete this section.
Note: You do not need to make a Sub-Module PR if your submodule developments are already on that repo's default branch.

• 107 increase the number of processes in the process map SimCore#109
• Allow kaon physics to be configurable at runtime by the user SimCore#108
• add option to filter by run number as well as event number SimCore#105
• get process manager from particle singleton SimCore#102
• bump G4DarkBreM to v2.0.1 SimCore#101

Of these I expect one of the SimObjects DQM plots to fail (because primary particles will be counted as "Primary" rather than "Unknown"). W.r.t. the signal simulation, I leave it to @tomeichlersmith to say if anything is expected to change

[EinarElen]

Right, so something was changed by all of this. I'm not sure why but TS and Hcal features seem to have changed but Ecal/other features have remained the same.

ecal_pn_fail.pdf

[EinarElen]

The logs are different as well so something has changed w.r.t. the simulation

Gold 
[ EcalProcessFilter ]: 10000 Brem photon produced 12 particle via biasWrapper(photonNuclear) process.
[ Simulator ] : Started 823126 events to produce 10000 events.
---- LDMXSW: Event processing complete  --------
PR 
[ EcalProcessFilter ]: 10000 Brem photon produced 36 particle via biasWrapper(photonNuclear) process.
[ Simulator ] : Started 824435 events to produce 10000 events.
---- LDMXSW: Event processing complete  --------

[EinarElen]

The first difference occurs at event 150

Gold 
[ EcalProcessFilter ]: 150 Brem photon produced 8 particle via biasWrapper(photonNuclear) process.
[ EcalProcessFilter ]: 150 Brem photon produced 10 particle via biasWrapper(photonNuclear) process.
PR 
[ EcalProcessFilter ]: 150 Brem photon produced 8 particle via biasWrapper(photonNuclear) process.
[ EcalProcessFilter ]: 150 Brem photon produced 9 particle via biasWrapper(photonNuclear) process.

So here something changed. As far as I can tell, this was the first time that there was a second PN attempt.

[EinarElen]

What fun, I can't reproduce either the gold or the PR log results on my machine....

[EinarElen]

On my machine with trunk vs PR branches for a very small ecal pn sample and using https://github.com/tomeichlersmith/root-diff/

LDMX_Events mismatched between files
== Branches with different content ==
EventHeader.timestamp_.fSec
EventHeader.timestamp_.fNanoSec
SimParticles_test.second.processType_

So this looks like what we would expect

[EinarElen]

Ok, I've confirmed that the difference comes from the introduction of the KaonPhysics, I will have to figure out what causes it.

[EinarElen]

I'm retracting my previous confirmation that the issue was caused by the kaon changes... There was an event seed mismatch between the two branches I was comparing so it doesn't tell us anything. The seed for the previous event however was the same (!?)

[EinarElen]

Found the culprit in a comment in a Geant4 header file:

// G4DecayTable.hh
// Insert a decay channel at proper position 
// (i.e. sorted by using branching ratio ) 

[EinarElen]

From the G4DecayTableMessenger, the accepted way to change the branching ratio of a process is

void G4DecayTableMessenger::SetNewValue(G4UIcommand * command,G4String newValue)
{
    if (command == brCmd) {
      //Command   /particle/property/decay/br
      G4double  br = brCmd->GetNewDoubleValue(newValue);
      if( (br<0.0) || (br>1.0) ) { 
	G4cout << "Invalid brancing ratio. Command ignored." << G4endl;
      } else {
        currentChannel->SetBR(br);
      }
    }
  }
}

This doesn't change the location of the channel, so according to G4 we should be ok in doing this as well. To be sure, here is the algorithm used to pick decay channels

while(true){
    G4double sumBR = 0.0;
    G4double r= G4UniformRand();
    // select decay channel
    for (auto channel : channels) {
      sumBR += channel->GetBR();
      if ( // Not allowed due to parent mass) { continue} 
      if (r < sumBR) return channel;
    }
  }

This should not depend on the order that the change is made. So we can use the actual Geant4 positions safely.

[EinarElen]

Hey whaddya know only the expected to fail plots failed :)

[tomeichlersmith]

The only failing plot is the expected proceess type which makes me think we should probably add more bins since the bin max right now is 12

I am going to merge the SimCore patch and make a new SimCore release to be merged in.

[tomeichlersmith]

Everything looks good here, I'm thankful the CI helped us find this very funky bug 💯

I have two house-keeping requests before I'm ready to merge.

1. Update SimCore to the v1.8.0 tag (I try to refer to the tag name in the commit message).
2. Update the SimParticle DQM to align with the increase in the number of process types. (maybe add the names to the bins as well?)

[EinarElen]

Updated process type histogram

Checked that I didn't off-by-one the bin labels, there are 1k events and 1k in the "Primary" bin :)

[tomeichlersmith]

Were you running a special/nuclear config? I'm just surprised there are so many "unknowns"

[EinarElen]

It was a very soft kaon particle gun, so most of the unknown are ionization from hadrons

[EinarElen]

But that was what made me catch the pi-inelastic mapping being wrong :)

[EinarElen]

Ok, SimCore bumped!