SherpaFrag
Authors: Philip Ilten philip.james.ilten@cern.ch; Stephen Mrenna mrenna@fnal.gov; Christian T. Preuss preuss@uni-wuppertal.de
Description
This plugin provides an interface to Sherpa's cluster hadronization model. The color singlet system's produced by Pythia8 as input to the Lund fragmentation model are, instead, passed to Sherpa. The path to the pre-build Sherpa library (lib, include, etc) must be provided. Currently, instructions on how to install Sherpa are not provided. The current implementation was done for git branch rel-3-0-x on https://gitlab.com/sherpa-team/sherpa.git.
Authors
Philip Ilten philip.james.ilten@cern.ch; Stephen Mrenna mrenna@fnal.gov; Christian T. Preuss preuss@uni-wuppertal.de
Dependencies
This package is compatible with 8.316 and newer of Pythia8 and 3.0.0 and newer of Sherpa.
Configure and Build
This plugin must be configured with both Pythia8 and Sherpa.
./configure --with-pythia8=PYTHIA8_PATH --with-sherpa=SHERPA_PATH
Because the Sherpa configuration is non-standard it may be necessary to
set individual paths by hand:
--with-sherpa-include=SHERPA_BASE/<build-dir>/include/SHERPA-MC/
--with-sherpa-lib=SHERPA_BASE/<build-dir>/lib/SHERPA-MC/
A Docker container, pythia8/dev:sherpa, is also available which can be used to build and run this plugin, based on the hepstore/rivet container. The recipe for this container is defined with share/SherpaFrag/dev/sherpa.dev. The container can be run via singularity with the following command,
singularity shell docker://pythia8/dev:sherpa
or by docker with the following.
docker run -i -t -v "$PWD:$PWD" -w $PWD -u `id -u` --cap-add=SYS_PTRACE --rm pythia8/dev:sherpa bash --norc
When using this container, the configuration can be passed as follows.
./configure --with-pythia8=/hep/pythia/ --with-sherpa=/hep/sherpa/
After configuring, the plugin must be built.
make -j
Run
To run the plugin, navigate to the examples directory.
cd share/SherpaFrag/examples/
Then, make the run example.
make run
The run, with user supplied command files.
./run <threads> <events> common.cmnd lepDijet.cmnd lepAnalyses.cmnd ../tune/sherpa301.cmnd
Here if <threads> is zero, than a serial run is performed rather than a parallel run.
There are a number of command files provided.
- common.cmnd - configures the number of events to produce, whether to run RIVET analyses, and whether to run Sherpa fragmentation.
- lepAnalyses.cmnd - LEP RIVET analyses used for tuning.
- lepDijet.cmnd - produces LEP di-jet events.
- lhcDijet.cmnd - produces LHC di-jet events.
- pythiaTune.cmnd - relevant Pythia string parameters for tuning.
- sherpaTune.cmnd - relevant Sherpa cluster parameters for tuning.
Settings
There are a number of settings that can be passed to Pythia, defined by this plugin.
- SherpaFrag:settings - list of settings to pass to Sherpa, of the form {KEY1:VAL1,KEY2:VAL2,...}. Note the separation between key and value by a colon, :, an equal sign will not work. This is because in some cases Sherpa will accept both = and :, but in some use cases the = syntax is not valid.
- SherpaFrag:outdir - output directory where Sherpa output is placed.
Known Issues
When running, the following warning message may be printed.
Initialization_Handler::InitializeTheFragmentation: Fragmentation called without beam remnants, hadronization might not be possible due to missing colour partners in the beam!
Fragmentation might stall, please consider aborting manually.
WARNING in Variations::CheckConsistencyWithBeamSpectra:
The internal reweighting is only tested
for hadronic beams of (anti-)protons.
Will continue and hope for the best.
The cause of this message is understood and expected. The way that Pythia and Sherpa treat beam remnants requires that beam remnants be turned off in Sherpa, by setting BEAM_REMNANTS:false.
The destructor for the Sherpa object cannot be called in a threaded environment without causing a segmentation fault. Consequently, while the Sherpa object is allocated with new, it is never deleted which creates a known memory leak. However, this memory leak should only occur at the end of running, and does not impact the physics output.
When running the plugin in the Docker container, the following warning might be printed.
symbol lookup error: /hep/sherpa/lib/SHERPA-MC/libAhadicMain.so.0.0.0: undefined symbol: _ZN6ATOOLS15Getter_FunctionINS_18Fragmentation_BaseENS_31Fragmentation_Getter_ParametersESt4lessINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEED2Ev
This is due to an undefined symbol required in the Sherpa library and should not affect the final physics result.