Moses

Introduction

The Moses software is a C++ framework for developing new HEP models according to which events can be generated using Pythia8. Moses is built as a set of interfaces to some known tools like Pythia8, HepPDT, LHAPDF, FastJet and ROOT.

This software was developed during an MCnet 4-months project in UCL (UK), It was further developed in Tel Aviv University and in Sheffield University. This release (1.<y>.<z>) is a proof-of-concept version and it includes a certain Kaluza-Klein (KK) model of extra dimensions was implemented. For this model, events consisting of exited KK states of the SM Z⁰ and photon can be generated.

This software requires ROOT, LHAPDF, HepPDT, FastJet and Pythia8 to be installed.
More details about the implemented KK process can be found in arXiv:1004.1649v1 [hep-ex]

Contacts

• Noam Hod:
  • noam.com@gmail.com
  • noam.hod@cern.ch
• Mark Sutton:
  
  • sutt@mail.desy.de
  • sutt@cern.ch

Download

The source code can be viewed at The Moses svn repository or downloaded from The Moses download area for the latest version.

Installation

To prepare,
Make sure to have LHAPDF, ROOT, HepPDT, FastJet and Pythia8 installed (Pythia8 should be configured with --enabled-shared). Make sure that the scripts root-config, lhapdf-config and fastjet-config are in your PATH (located in the bin directories of these packages). Copy the full paths to HepPDT and Pythia8 base directories, these paths will need to be specified during configuration.

To configure and build Moses,
wget http://www.hepforge.org/archive/moses/moses-<x>.<y>.<z>.tgz
tar -zxvf moses-<x>.<y>.<z>.tgz
cd moses-<x>.<y>.<z>
source configure.sh --heppdtpath=/path/to/heppdt --pythia8path=/path/to/pythia8
make

To clean the installation of compiled objects,
make clean

To complete purge of transient files, and to unset all the exported variables,
make cleanall

To unset all the exported variables,
source configure.sh --unsetall

Usage

On every logon, some variables must be set for runtime or for re-make,
source ./config.sh

To run,
All the executables go in the bin/execs directory and they can be ran directly from there,
ls -lrt bin/execs
$MOSESSYS/bin/executable_name

There's a special helper script for handling with running and re-making the various executables,
./helper --ls
./helper --run=usageExample_BuildProcess
(or --run=usageExample_LHAPDF or --run=usageExample_HepPDT)

To see all the helper script options,
./helper --help

The output

All the output is, essentially, either flat files (.dat etc), or .root files (trees or canvases) or .eps files.

All the executables output go by default to, data/
where this is determined automatically by the variable, $MOSESDATA/ = $MOSESSYS/data/ = /full/path/to/data/
This can be overridden by re-exporting this variable
mkdir /your/path/to/the/new/datadir
export MOSESDATA=/your/path/to/the/new/datadir
Possibly, include the last line in the end of the config.sh script.

To see the data in its default location,
ls -lrt data/
or,
ls -lrt $MOSESDATA/
for a general, user defined, location

The Moses software structure

In general, the basic structure is very simple so it can be very easy to either run the examples and to allow further personal development on top of the existing structure. The common area (under the moses-<x>.<y>.<z>/examples) contains common code so it can be linked against any package (also under the examples directory). Each package (one directory) should correspond to a single model. In other words, a single hard process with the specific related tasks to be executed (except for the tasks that can be thought of as common to several packages). The user can copy code from these two areas for his own needs, add new libraries or add new packages just like it is done in the examples directory. For a detailed picture of the Moses software structure, see figure 1. The compilation flow is organized from the lowest level (core) to the highest level (models), so when standing in one location which contains a Makefile and executing make, everything that is at higher levels will also compile if changed. The moses-<x>.<y>.<z>/make.mk and moses-<x>.<y>.<z>/examples/common/commonmake.mk files contain global definitions at different levels to avoid rewriting these definition in each of the other Makefiles. Thus, either one or two of theses files have to be included in every Makefile depending on the context. Note that there can be many tasks placed under each model directory. That includes oriented plugins and/or main programs like MC-programs (pythia8-mains, pythia8-plugins), theoretical-analysis programs, data-analysis programs etc. Therefore, there are some places where one can find specific higher levels than the ones sketched in figure 1. In particular there are analysis directories that encapsulate several analysis tasks, some of which presented in this paper.