Merged
Conversation
A number of keys into the ME event header information
mapping is defined. This is to ensure that code will
use the same keys when ever information is set.
Additional, non-predefined keys, are still possible.
This makes it much more robust when we ask for specific
MC information from the event header, such as
- cross-section(s)
- weight(s)
- Heavy-ion "geometry" parameters
- Npart in projectile and target
- Ncoll in various views
- Overall
- Hard
- wounded-nucleon on nucleon
- nucleon on wounded-nucleon
- wounded on wounded
- Parton distribution function parameters
This is crucial for building a HepMC event structure which
can be passed on to say for example Rivet analyses.
The generator has been changed so that it exports _all_ relevant and available information from Pythia to the MC event header, including heavy-ion "geometry" parameters. In particular, the information is stored in an HepMC compatible way for later user by f.ex. Rivet. Note, the current code counts up the number of collisions by it self. However, the authors of Pythia have another way of doing that. The code is now there to do it the same way as the Pythia authors, but is currenly disabled. We should decide which is the appropriate way to count Ncoll. I would recommend to follow how the Pythia authors do it.
This change does two things:
**Full header**
_All_ information available in the HepMC event header is
propagated to the MC event header information map. This
includes
- Heavy-ion "geometry" parameters (b,Ncoll,Npart,...)
- Cross-section(s)
- Weight(s)
- PDF information
- and other attributes defined
This is so that we can build a full HepMC event structure later -
for example to pass to Rivet analyses
** External program **
The functionality of the generatator is expanded so that it may
spawn an event generator program, say `eg`.
- The generator opens a FIFO
- The generator then executes the program `eg` in the background
- The `eg` program is assumed to write HepMC event records on
standard output, which is then redirected to the FIFO
- The generator reads events from the FIFO
For this to work, a number of conditions _must_ be met by the
`eg` program:
- It _must_ write events in the HepMC event format
- It _must_ write the HepMC event records to standard output
- It _cannot_ write anything else but the HepMC event record to
standard output
- It _must_ accept the command line option `-n NEVENTS` to
set the number of events to generate.
If a particular `eg` program does not meet these requirements, then
a simple shell script can be defined to wrap the `eg` appropriately.
For example, the CRMC program `crmc` _can_ write HepMC events to
standard output, but it will also dump other stuff there. Thus,
we can provide the script
#!/bin/sh
crmc $@ -o hepmc3 -f /dev/stdout | \
sed -n 's/^\(HepMC::\|[EAUWVP] \)/\1/p'
which simply filters the output of `crmc`. Another EG program
may not accept the `-n EVENTS` command line option, but rather has
the command line option `--nevents`, so then we would do something
like
#!/bin/sh
cmdline="eg-program -o /dev/stdout "
while test $# -gt 0 ; do
case x$1 in
x-n) cmdline="$cmdline -n $2"; shift ;;
*) cmdline="$cmdline $1" ;;
esac
shift
done
$cmdline
The command line to run is specified as
--configKeyValues "HepMC.progCmd=<program and options>"
and can include not only the program name but also other
options to the program. For example
--configKeyValues "HepMC.progCmd=crmc -m 5 -i 20800820 -I 20800820"
for Pb-Pb collisions with Hijing.
With this change, we can use _any_ event generator which is capable to
write out its event records in the HepMC format.
The generator `GeneratorTParticle` will read in particles
from a `TChain` containing a branch with a `TClonesArray` of
`TParticle` objects.
The generator can operate in two modes
- Data is read from a file(s)
- Data is read from a file being generated by a child
program
The first mode is selected by
-g tparticle --configKeyValues "TParticle.fileNames=foo.root,bar.root"
The second mode is selected by
-g tparticle --configKeyValues "TParticle.progCmd=<program and options>"
For this latter mode, see also recent commit to `GeneratorHepMC`
Above `<program and options>` specifiy a program to spawn in the
background which will write to a specified file (temporary file).
Suppose the program is called `eg`, then the following _must_ be
possible
eg -n NEVENTS -o OUTPUT_FILENAME
That is, `eg` _must_ accept the option `-n` to set the number of
events to produce, and the option `-o` to set the output file name
(a ROOT file).
The name of the `TTree` object in the file(s) can be set with
--configKeyValues "TParticle.treeName=<name>"
(defaults to `T`), and similar for the branch that contains the
`TClonesArray` of `TParticle`
--configKeyValues "TParticle.branchName=<name>"
(defaults to `Particles`).
The generator `GeneratorTParticle` _does not_ import any header
information into the simulation event record. Some proper
convention could be decided upon, e.g., one that tracks the
HepMC event record format.
Please consider the following formatting changes to AliceO2Group#11913
Please consider the following formatting changes to AliceO2Group#11913
The classes `GeneratorHepMC` and `GeneratorTParticle` is refactored to derive from the (second) base class `GeneratorFileOrCmd`. `GeneratorFileOrCmd` provides common infrastructure to specify - File(s) to read events from (ROOT files in case of `GeneratorTParticle`, and HepMC files in case of `GeneratorHepMC`), _or_ - Which commmand to execute and with which options. It also provides infrastructure to make unique temporary names, a FIFO to read from (child program writes to), and so on. These are all configured through configuration keys prefixed by `FileOrCmd.`. Other changes include - `GeneratorHepMC` will open _any_ file that HepMC supports - ASCII, compressed ASCII, HEPEVT, etc. - Through the use of `GeneratorFileOrCmd` the command line option flags for specifying seed (default: `-s`), number of events (default `-n`), largest impact parameter (defautl: `-b`), output (default: `>`), and so on can be configured via configuration key values - `GeneratorHepMC` and `GeneratorTParticle` are passed the `GeneratorFileOrCmdParam` as well as specific `GeneratorHepMCParam` and `GeneratorTParticleParam`, respectively, objects by `GeneratorFactor` and sets the internal parameters accordingly. This hides the specifics of the parameters from `GeneratorFactory`.
…nd makes life so much more difficult than it needs to be for very little gain
- Forgot to change key for test in `run/CMakeLists.txt` - `crmc.sh` uses `-o hepmc` instead of `-o hepmc3` to accomodate older installation of CRMC with `aliBuild`.
cholmcc
force-pushed
the
cholmcc_aod_to_hepmc
branch
from
494110c to
fd03db0
Compare
…o cholmcc_aod_to_hepmc
Added braces around single-statement branching constructs (sigh)
I'm not sure why
if (foo)
bar
is considered less clear than
if (foo) {
bar
}
The latter adds superflous spaces and braces and obscures the code. Of
course, one _sometimes_ should disambiguate, like in
if (foo)
if (bar)
baz
else
gnus
but it is really only needed in those cases, and only because humans
read it. The compiler knows what to do.
Contributor
Author
|
|
Collaborator
|
Error while checking build/O2/fullCI for c62aa7e at 2023-10-23 15:30: Full log here. |
Contributor
Author
|
Failures of The problem is that Apache MacOSX defines Apache like which wont work. Perhaps a work-around is to introduce the lines in the appropriate header of the ALICE Funny thing is that it only shows up when ROOT tries to AcLIC a script, which would indicate that ROOT's AcLIC includes headers implicitly - specifically the In any case, these two failures are false negatives |
Collaborator
|
Error while checking build/O2/fullCI for 750baee at 2023-10-28 22:44: Full log here. |
Contributor
Author
|
Hi all, Any news on this? Thanks. |
Contributor
Author
|
Hi all, Please advice as to what to do next. Thanks. Yours, |
Contributor
Author
|
I just resynced this branch against Please advice as to the next steps. Thank you. Yours, |
pzhristov
approved these changes
Nov 10, 2023
Contributor
|
The errors in the CI are not related to this PR, we can merge it. |
Member
|
The errors in the CI are actually related. ;-) This PR exposed some arrow header to cling, which is not actually able to digest it, due to some injected system header. Fixed by #12248. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The class
o2::eventgen::AODToHepMCconverts events stored in AODtables to
HepMC3::GenEventobjects. The objects are kept in-memoryso that clients (e.g., a future
o2::analysis::RivetWrapperor similar)can pick up that event structure and process it.
The converter class will convert
o2::aod::McCollisionsando2::aod::McParticlesinformation, as well as auxiliary information ino2::aod::HepMCXSections,o2::aod::HepMC::PdfInfos, ando2::aod::HeavIons.The built
HepMC3::GenEventdata structures can optionally be stored ondisk in HepMC3 ASCII files.
The application
o2-aod-mc-to-hepmcuses this converter class toconvert AOD files to HepMC files.
Note that the converter only depends on
Framework/AnalysisDataFormats.hand not any other AOD information.Compilation of
Generators/src/AODToHepMC.cxxis contingent on HepMC3being found at configure time.
The code is heavily documented and commented.