There are numerous missing bits and bobs when running make install, but a smoking gun is can be seen in the non-functioning of genie-config due to a missing dependence on a makefile

genie_3_00_06:build_genie-git $ echo $PATH
/opt/genie/git/bin:/opt/genie/3_00_06/bin:/opt/lhapdf/5.9.1/bin:/opt/root/v6-24-06/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
genie_3_00_06:build_genie-git $ echo $GENIE
/opt/genie/git
genie_3_00_06:build_genie-git $ which genie-config
/opt/genie/git/bin/genie-config
genie_3_00_06:build_genie-git $ genie-config
/opt/genie/git/bin/genie-config: line 8: /opt/genie/git/src/make/Make.config_no_paths: No such file or directory
genie_3_00_06:build_genie-git $ ls $GENIE
bin  include  lib

In my container image builds I apply some manual fixes, that might be useful as a starting point:

# Install some things that the GENIE install script forget.
RUN cp /opt/Generator-src/VERSION ${GENIE}/
RUN cp -r /opt/Generator-src/config ${GENIE}/
RUN mkdir -p ${GENIE}/data/
RUN cp -r /opt/Generator-src/data/evgen ${GENIE}/data/

RUN mkdir -p ${GENIE}/src/make/
RUN cp /opt/Generator-src/src/make/Make.config_no_paths \
                      ${GENIE}/src/make/

There is a bit of inconsistency when it comes to Fermi constant, Weimberg Angle and W boson mass. Specifically, the weimber angle is a common parameter (hence variable) while Fermi Constant and W boson mass are all hard coded. Everything should be a parameter. Possible solution could be the creation of a EWConstants Algorithm that takes care of those constants that are related.

Need to move COHElasticPXSec from Coherent/EventGen to Coherent/XSection

I've been working on the MC files generated for the DUNE TDR purpose (based on GENIE v2.12.00), especially the nutau flavour. A classification of these events based on the tau decay is natural. More specifically I’m looking into the rho resonance decay.
In the CAFANA ntuples of the generated files, the intermediate rho wasn’t recorded, so I select them using the rho decay products : pi- pi0. I found the branching ratio of this decay mode to be equal to 22.40%, while from the PDG we expect 25.49% (the pi- pi0 nutau decay mode has almost 100% of the time a rho resonance). I’m using a sample of N=173309 nutauCC events, so that the expected statistical stand. dev. of this process should be (saying p = 25.49%) : sigma = sqrt ( N*p(1-p) ) = 181 events, which represents about 0.1% of BR.

I was surprised not to recover the PDG expectation BR. I made a crosscheck on other tau decay modes : the 3pions decay mode is in agreement with the pdg numbers (9.44%, expected 9.31%). Same thing for the leptonic decays (e and mu), and
for the tau—>pi- nutau decay (11.36%, expected 10.82%), though a bit less convincing.

An unrequested coding style suggestion for your consideration:

Please do not import symbols in the global namespace from a header: this sets a ::string symbol in every program that includes your header, and in every program where any included header includes this one directly or indirectly.

If you don't like prefixing each string with std::, you can still import the symbol from within genie namespace, so that the effect is limited in scope.
This restriction also does not apply to source code (e.g. .cxx files), but rather only to headers.

Hi all, there is a problem about the evaluation of energy thresholds for some interactions. Specifically this was discovered in the implementation of the "contact formalism" by @afropapp13 and @nwright38 .
The threshold of some processes like Quasi Elastic requires the initial state nucleon momentum to be a time like-Lorentz vector as the minimum energy is evaluated in its rest reference frame. In the case where interactions allow an off-shell initial state nucleon this is not always true, as a result the probe energy becomes a nan, the comparisons with the threshold is always false and the event is rejected as it goes "below threshold".
Relevant code is here https://github.com/GENIE-MC/Generator/blob/master/src/Framework/Interaction/KPhaseSpace.cxx#L276

Changing this is easy from the point of the code: we just need to make the comparisons of the energy in a different reference frame. Any will do.
Yet, changing this might have a considerable impact on a number of models and people should be informed. Soon We'll post a proposed solution so that it could be discussed.

Reported by @Igor144 in GENIE docdb 297.

Issue is connected to the energy range for the spline representing the sum of all x-section splines, computed by GMCJDriver::BootstrapXSecSplineSummation().

@Igor144 says that "If the user calculates the spline till 200 GeV then max will be equal to 220 GeV. Since there is no precalculated values in the range 200–220 GeV the method void GEVGDriver::CreateXSecSumSpline sets them equal to zero, which leads to wobble of the spline close to the right end"

There is no rotation with respect to the beam for the COH pion model developed by Luis.
Normally, I would fix it, but it touches a lot of place that are connected with the COH Gamma produciton, so I prefer not to touch it for the time being, until the COH gamma is developed.
Since there is no tune with his model in, this is not a priority, more a reminder.

The list of env variables to be recorded in the NtpMCJobEnv is incomplete given recent additions to configurations and build options.

There appears to be a memory leak in the deserialization process when events are loaded from a .ghep file. A very simple sample program will quickly exhaust the memory on any machine with a big enough input file (~1M events seems to do the trick):

// CStdLib
#include <iostream>

//ROOT
#include "TFile.h"
#include "TTree.h"

// GENIE
#include "Framework/GHEP/GHepParticle.h"
#include "Framework/Ntuple/NtpMCEventRecord.h"

int main()
{

  TFile gHEPfile("/path/to/large-file.ghep.root", "READ");
  auto gHEPtree = dynamic_cast <TTree *>( gHEPfile.Get("gtree"));

  genie::NtpMCEventRecord *mcrec = nullptr;
  gHEPtree->SetBranchAddress("gmcrec", &mcrec);

  auto nEvts = gHEPtree->GetEntries();
  std::cout << "total number of events:" << nEvts << std::endl;

  // event loop
  gHEPfile.cd();
  for (int iev = 0; iev < nEvts; iev++)
  {
    gHEPtree->GetEntry(iev);
  }

  return 0;
}

However, @sjgardiner points out that if the event loop is modified to explicitly delete the event:

...
  // event loop
  gHEPfile.cd();
  for (int iev = 0; iev < nEvts; iev++)
  {
    gHEPtree->GetEntry(iev);
    genie::EventRecord* event = mcrec->event;
    delete event;
  }
...

then all is well and there's no leak.

I'm not sure if this behavior existed in older GENIE + ROOT combinations but I've observed it in GENIE 3.00.04 + ROOT 6.12.06 and GENIE 3.00.06 + ROOT 6.16.00.

W cut is hard coded here

Which doesn't correspond to the cut used in the transition region which is retrieved at runtime from e.g. here

The new kMinQ2Limit_e is a hack aimed at improving CPU efficiency for certain comparisons against electron scattering data. However the built-in limits are not meant to cut into the allowed phase space in any importany way, but merely to protect againt infinities.

kMinQ2Limit_e was installed on the understanding that it is a stopgap and that a new method will be developed for user-specified kinematic limits to be supplied via the GENIE configuration system.

The stopgap implementation can not be what we are permanenlty left with, so the plan should be to remove kMinQ2Limit_e before the release of GENIE 3.2.0.

Working with Julia on transparency, Dytman recently discovered that we have a small problem with rho decays. The result pions never get 14 label so can't interact and therefore bias transparency badly. How to fix this is still under investigations.

DCC (Kamano, Nakamura, Lee, and Sato and others) generated a resonance+background model that works consistently for meson-nucleon, electron-nucleon, and neutrino-nucleon. They published a series of papers, here's the summary for all but neutrino: https://inspirehep.net/literature/1756287. I've been working on piN->piN, etaN, and K+Lambda for a start and Harry Lee was very helpful. I've also discussed implementation of neutrino model and Toru Sato, also helpful. This is independent of nuclear model but will full implementation will give us a consistent model for all fundamental principal and FSI interactions.

Getting various errors similar to
gNtpConv.cxx:1809:24: error: use of undeclared identifier 'flux'
int brNuGpid[flux::fNgmax]; // particle ID of each ancestor particles

The offending code needs to be placed within an #ifdef GOPT_ENABLE_GEOM_DRIVERS ... #endif

The GHepUtils NEUT mode converter returns mode 0 for diffractive events, it should return 15/-15 for CCDFR from a neutrino/anti-neutrino and 35/-35 for NCDFR.

Reported by Xianguo Lu [email protected], and his student Qiyu Yan [email protected]

They report that gevgen and gevgen_atmo generates different output for same flux input.

Gevgen and gevgen_atmo.pdf

While debugging something with Stephen Dolan, we realised it would be nice to have the seed used to generate a file to be stored in the ghep file. No idea how at the moment, but if someone has ideas, I'm happy to attempt it.

The creation of GVersion.h is faulted.
the piece of code if ($git_revision ne "-1" ) { $git_differences = git diff HEAD; if($? == 0) { print GVRS "/* \n"; print GVRS " * git differences at compile time: \n"; print GVRS "$git_differences"; print GVRS "*/ \n\n"; } }
from src/scripts/setup/genie-write-gversion - line 84 is creating a file which can potentially not compile if the changes involves the character */ Afro just experienced this.
I suggest to remove these lines. We have git to keep track of the changes, no point in having this in an header.
@sjgardiner you had a look at this code recently. Is it ok?

This was reported primarily by Chris Backhouse, with help from Chris Marshall and Luke Pickering.

When right now, we use Spline::LoadFromTTree to get splines from text files (via Spline::LoadFromASCIIFile).

This uses TTree::Draw() to fill arrays then deletes htemp using FindObject(). This does not work if TH1::AddDirectory(false) has ever been called outside GENIE (which I believe art does).

There's a bunch of easy ways to fix this - including stopping building the spline using TTree::Draw at all, or manually deleting the TTree's histogram (I think doing this with delete TTree::GetHistogram() is safe? But it might not be).

In GENIE v2, this method gets called a lot of times (potentially per event?) by the DUNE Caf code when it's calling CalcWeight() for resonance - I don't think this should be called that much, but that's another issue we'll fix outside GENIE.

I'd like to ask to the GENIE developers if it possible to include splines for Tungsten in the set of pre-generated splines - i.e. those that can be found here: http://scisoft.fnal.gov/scisoft/packages/genie_xsec/

For Tungsten, the relevant isotopes to add are

182W --> 1000821820
183W --> 1000821830
184W --> 1000821840
186W --> 1000821860

Hello,

I was just intalling GENIE on my computer and I wanted to try if everything were installed properly so I tried generating some basic events. I did not put in any specific cross section files. However I kept getting the error :

1569297196 WARN XSecSplLst : [s] <SplineExists (110)> : No splines for tune G18_02a_00_000 were found!

And it went into a sort of infinite loop where it keeps repeating the same error. So I wanted to ask please if that is an error coming from the fact I did not specify any cross section spline or if it is a problem coming from the installation.

Thank you very much!

While debugging the dark neutrino code we did a check on our units conversion constants.
One thing we noticed is that the speed of light in our environment can be derived from our units in this way

double speed_of_light = units::second/units::meter; // this gives us the speed of light in m/s

that gives as a result 299802761.341 which is 0.0034 % faster than... you know... light!
It is a very small discrepancy, but we might want to be aware of this just in case.

There was a pull request about the Coulomb corrections used in the QE generation. The pull request was number #5 . We open this issue to not forget the topic.

While developing a decayer for Dark neutrinos, I noticed that there is an unsafe behaviour. The function IsHandled is not called by the UnstableParticleDecayer so if we need to implement a new decayer in a safe way, we need to change also the IsHandled function of previous existing decayers.
I would not normally complain, but because the IsHandled function has to be written anyway and it is required from the interface, we might already use it and make it safe.

I can probably come up with a clean solution by today if necessary

When GENIE is linked against root without Minuit2 built in, running specific model will fail due to

When the step back operation is executed the code creates a copy of the event record:

For some reason this creates a segfault:

===========================================================
#7  TIter::TIter (dir=true, col=0x0, this=<synthetic pointer>) at GHepRecord.cxx:907
#8  genie::GHepRecord::Copy (this=0x5277720, record=...) at GHepRecord.cxx:907
#9  0x00007f004853ce06 in genie::EventGenerator::ProcessEventRecord (this=0x4505f60, event_rec=0x5277720) at EventGenerator.cxx:171
#10 0x00007f0048562ca3 in genie::GEVGDriver::GenerateEvent (this=this
entry=0x48f4770, nu4p=...) at GEVGDriver.cxx:286
#11 0x00007f004856f6c1 in genie::GMCJDriver::GenerateEventKinematics (this=0x4e66ab0) at GMCJDriver.cxx:1234
#12 0x00007f004856fc46 in genie::GMCJDriver::GenerateEvent1Try (this=0x4e66ab0) at GMCJDriver.cxx:1004
#13 0x00007f0048570fdc in genie::GMCJDriver::GenerateEvent (this=this
entry=0x4e66ab0) at GMCJDriver.cxx:826
#14 0x0000000000410cc8 in GenerateEventsUsingFluxOrTgtMix () at gEvGen.cxx:382
#15 0x000000000040663f in main (argc=<optimized out>, argv=<optimized out>) at gEvGen.cxx:234
===========================================================

which is related to the invalidation of iterators.
I don't know anything more, but I'm investigating.

gntpc does not know of CEvNS and when events are passed through this conversion the code dies because of the assert in line 621.
Dedicated flags should be added to the code and new branches added to the gst.

Dear Genie developers,

I am trying to build a software package put together by my colleague. I have successfully built the package however it segfaults when I run it. The software is built using genie and the stack trace appears to point to some conflict in the way these libraries are being used. I have attached the complete stack trace to this issue. log.txt

versions
ROOT: 6.12.06
genie: 2.12.10
GEANT4: 4.10.01.p03

Linux version 3.10.0-862.14.4.el7.x86_64 (gcc version 4.8.5 20150623
(Red Hat 4.8.5-28) Centos7

The software that I am using is here: https://github.com/patha325/NewSaRoMaN/tree/master/B4c however it requires several items of third party software in order to run so I have not been able to put together a minimal working example. The offending piece of code is here: path/to/NewSaRoMaN/B4c/src/B4PrimaryGeneratorAction.cc at line 112.

I am unsure how to diagnose the error in this segfault though it appears to come from a conflict during running when passing the tuple format NtpMCEventRecord between ROOT and genie. If you could offer any insight or pointers that I could investigate it would be greatly appreciated.

Please let me know if there is any more information that I can add that would help diagose this issue.

Thank you for all of your help,
John Nugent

We might have dropped the ROOT 5 dependency, but our Makefiles are still supporting it.

Specifically we have

Can we clean this file.
Also we need to update the make file of comparisons as well. I'll open a dedicated issue there

Hi @GENIE-MC
I'm interested in collaborating with this project by delivering a series of logotype options that fits this project for the best!

If interested let me know so we can get started!

Cheers!

Cubic interpolation in CacheBranchFx produces wiggly distributions that occassionaly can skew kinematic distributions or increase generation inefficiency.

The issue was found by @Igor144 and described in GENIE docdb 297.

Replacing TSpline3 with ROOT::Math::Interpolator resolves it.

Running GENIE with the default tune and configurations on the tagged version 3.2.2 with the following command:

gevgen -n 10000 -e 3.0 -p 11 -t 1000060120 --cross-sections ../splines/carbon12_spline_EMPlusMEC_G18_02a_00_000.xml --event-generator-list EM

Eventually hits an assertion that fails in the Pythia6 hadronization. (This does not happen if I switch to Pythia8)

The relevant messages and the stack trace are shown below

1673649526 NOTICE PythiaHad : [n] <PythiaBaseHadro2019.cxx::MakeQuarkDiquarkAssignments (97)> : Making leading quark / remnant di-quark assignments
1673649526 NOTICE PythiaHad : [n] <PythiaBaseHadro2019.cxx::MakeQuarkDiquarkAssignments (116)> : Hit nucleon pdgc = 2112, W = 2.48038
1673649526 NOTICE PythiaHad : [n] <PythiaBaseHadro2019.cxx::MakeQuarkDiquarkAssignments (118)> : Selected hit quark pdgc = 1[sea]
1673649526 NOTICE Pythia6Had : [n] <Pythia6Hadro2019.cxx::Hadronize (84)> : Running PYTHIA6 hadronizer
1673649526 NOTICE Pythia6Had : [n] <Pythia6Hadro2019.cxx::Hadronize (90)> : Fragmentation: q = 1, qq = 2103, W = 2.48038
gevgen: Pythia6Hadro2019.cxx:108: virtual bool genie::Pythia6Hadro2019::Hadronize(genie::GHepRecord*) const: Assertion 'np>0' failed.

Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=140737223285760) at ./nptl/pthread_kill.c:44
44      ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737223285760) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=140737223285760) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=140737223285760, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3  0x00007ffff3dc9476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0x00007ffff3daf7f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x00007ffff3daf71b in __assert_fail_base (fmt=0x7ffff3f64150 "%s%s%s:%u: %s%sAssertion '%s' failed.\n%n", assertion=0x7ffff48c4694 "np>0", file=0x7ffff48c61cf "Pythia6Hadro2019.cxx", line=108, function=<optimized out>)
    at ./assert/assert.c:92
#6  0x00007ffff3dc0e96 in __GI___assert_fail (assertion=0x7ffff48c4694 "np>0", file=0x7ffff48c61cf "Pythia6Hadro2019.cxx", line=108, function=0x7ffff48c6110 "virtual bool genie::Pythia6Hadro2019::Hadronize(genie::GHepRecord*) const")
    at ./assert/assert.c:101
#7  0x00007ffff48afb80 in genie::Pythia6Hadro2019::Hadronize (this=0x555556177f60, event=0x55555afe8e90) at Pythia6Hadro2019.cxx:108
#8  0x00007ffff48bd393 in genie::PythiaBaseHadro2019::ProcessEventRecord (this=0x555556177f60, event=0x55555afe8e90) at PythiaBaseHadro2019.cxx:78
#9  0x00007ffff4755e54 in genie::DISHadronicSystemGenerator::ProcessEventRecord (this=0x555558160ef0, evrec=0x55555afe8e90) at DISHadronicSystemGenerator.cxx:68
#10 0x00007ffff4b5a51b in gen
ie::EventGenerator::ProcessEventRecord (this=0x5555581294a0, event_rec=0x55555afe8e90) at EventGenerator.cxx:107
#11 0x00007ffff4b69c78 in genie::GEVGDriver::GenerateEvent (this=this@entry=0x7fffffffd070, nu4p=...) at GEVGDriver.cxx:286
#12 0x0000555555562960 in GenerateEventsAtFixedInitState () at gEvGen.cxx:323
#13 0x000055555555b50f in main (argc=<optimized out>, argv=<optimized out>) at gEvGen.cxx:251

Also, I have attached the spline that was used.

Julia found that this function is not implemented anywhere. Can we remove it?

With the introduction of CommonParam (and CommonDecay) NtpMCJobConfig fails to capture full state of the configuration.

Issue reported by Emircan Elikkaya and Murat Ali Guler (SHiP):

Although charm-production cross section looks correct, we have seen that charmed-meson(D+, D_s and D0) production is strongly suppressed after about 100 GeV, only lambda_C+ is produced after 100 GeV.

The issue here is that the input charm fraction tables used by the charm hadronization code go only up to 100 GeV. Since the charm fractions are nearly flat / change very weakly with energy, the proposed solution for an event with neutrino energy Enu, is to use min(Enu, 100.) when looking up that table.

gmkspl -p 12 -t 1000180400 -n 150 -e 10 -o ArXsec.xml --event-generator-list Xsec

<param_set name="Xsec">
11
genie::EventGenerator/QEL-CC
genie::EventGenerator/QEL-NC
genie::EventGenerator/RES-CC
genie::EventGenerator/RES-NC
genie::EventGenerator/DIS-CC
genie::EventGenerator/DIS-NC
genie::EventGenerator/COH-CC
genie::EventGenerator/COH-NC
genie::EventGenerator/DIS-CC-CHARM
genie::EventGenerator/QEL-CC-CHARM
genie::EventGenerator/NUE-EL
</param_set>

GENIE/support/lhapdf/GRV98lo_patched.LHgrid cannot be opened !
If you have not already done so:
Use the bin/lhapdf-getdata script to download the file.
Set the environmental variable LHAPATH to specify the directory if not as default (above).

A small issue I came across when using the gevgen_atmo script is that by default it sets the radii for the flux generation surfaces to be be 1 here:

Running gevgen --help shows various options, but not the --tune option which is new in v3. Perhaps there are more options I don't know about that don't show up...

If GENIE is installed in a path that happens to contain the characters -l then the $GENIE/bin/genie application exits immediately with the error message:

Failed to load GENIE libraries

The problem is caused by code that parses libraries returned by genie-config --libs thinks that the directory is a library to be loaded. When it fails to load that, it exits.

The problem is caused by the line in: loadlibs.C.

TPRegexp re("-l([\\d\\w]*)");

This can be made slightly more robust by modifying the reg-ex:

TPRegexp re("^-l([\\d\\w]*)");

but I guess that this will still fail in the unlikely case that the GENIE path begins with the characters -l.

We have discovered that the DIS-related weights in v2.12.10 do not conserve total cross section. We see this when we apply, eg, the GENIE formation zone weights to an analysis that is very sensitive to DIS events (neutrino energies > 10 GeV) in the NOvA far detector. In short, if we apply absolutely no event selection in the analysis, and look at the predicted far detector true neutrino energy spectrum (with no extrapolation using the near detector), this weight moves the event rate up and down. But the formation zone should have no impact on the actual cross section, and only just impact the distributions of the final-state hadrons. We have confirmed that the average formation zone weight is not equal to 1. We have seen similar effects for other DIS knobs.

Can this be fixed in GENIE v3?

GNU GCC 7.3.0 compiler reports:

Cache.cxx: In member function ‘void genie::Cache::Save()’:
Cache.cxx:186:57: warning: enum constant in boolean context [-Wint-in-bool-context]
   keys->Write("key_list", TObject::kSingleKey&&TObject::kOverwrite);
                                                         ^~~~~~~~~~

The second argument should be a bit mask; I suppose the intention was to have TObject::kSingleKey | TObject::kOverwrite (use a single key and overwrite it as needed).
The && operator makes teh expression a boolean (1 && 2), that is equivalent to 1, that is just TObject::kSingleKey, and no overwrite.

My experiment has finally jumped from GENIE v2 to v3.
With that, our event generation broke. The story develops with GENIE complaining that

INFO Pythia6Decay : [n] <PythiaDecayer.cxx::InhibitDecay (236)> : Switching OFF ALL decay channels for particle = 4222
INFO Pythia6Decay : [n] <PythiaDecayer.cxx::InhibitDecay (236)> : Switching OFF ALL decay channels for particle = 431
FATAL GEVGDriver : [n] <GEVGDriver.cxx::CreateXSecSumSpline (455)> : You haven't loaded any splines!! 
NOTICE ReinSehgalResTF : [s] <Integrate (106)> : XSec[RES/P33(1232)/free] (Ev = 0.01 GeV) = 0 x 1E-38 cm^2
NOTICE ReinSehgalResTF : [s] <Integrate (106)> : XSec[RES/P33(1232)/free] (Ev = 0.01 GeV) = 0 x 1E-38 cm^2

then would slowly follow to list a number of interactions and energies with zero cross section (as in the last two lines of the excerpt above). Finally, some minutes later Vegas library would give merciful death to the process.
It turns out, the Pythia-related messages are there to stay, and the problem is that the cross section spline file does not contain some of the elements that our detector description includes.

My request in this issue is: the error message needs to be clearer than that. As it is, it is just misleading.

Hi! I initially found this issue in GENIE 2.12.8, but I think it is still there in the master:

in 2.12.8:

in master:

The issue causes charm events to be often rejected as unphysical when incoming neutrino direction is not oriented along LAB's z axis and leads to the incorrect charm/not charm ratio in the simulation.

A possible improvement for your consideration:

If I understand this right, this assumes that the incident particle, which the flux deposited at x4, has travelled to vtx at the speed of light. This may be problematic for massive particles (like dark matter), which might take their good time to get there. Given that the method has also p4 available, it should be possible to use the correct speed of the incident particle.

Hi, I ran into an issue building GENIE v3.0.6. I'm using:
OS: Centos Stream 8
GCC v8.5.0
ROOT v6.24.06

The issue could be fixed by adding using std::string to the headers

Running with gevgen -f flux_file.root,GARBAGE causes a segfault and not a nice user-friendly error message that the TH1 could not be found in the input file.

When doing make cleandist, GENIE decides to, to first order, delete the OS.