Integration of Atlfast into Athena Framework

 

User Guide to prototype release

 

Authors: E.Richter-Was, P.Clarke, H.Phillips, P.Sherwood, R.Steward
 

 

Index

Context

Utilities used by the new Atlfast

Description of structure of prototype new Atlfast

Description of output data classes:

ReconstructedParticle
Jet
Cluster
Track
Detailed description of Algorithms (Makers):
CellMaker
ClusterMaker

DefaultReconstructedParticleMaker

Isolator

JetMaker

EventHeaderMaker

StandardNtupleMaker

How to get going:
Scripts for:
    Checking out
    Building
    Running

The jobOptions needed

Locations of output in the TES

A simple example user analysis Algorithm

Appendix: Known problems
 
 

 

Context of the project

The current versions (Fortran and C++) of ATLFAST are widely used. These are documented at ATLFAST-home-page

In brief the C++ version functions in the following way:

 
With the  ever increasing penetration of OO software into ATLAS, and in particular with the adoption od the Gaudi (now = Athena) framework, a request was made to integrate Atlfast into the framework, and at the same time re-engineer to a more OO design.

In more detail the objectives of project are:
 

  • To integrate ATLFAST++ into the Athena framework.

    •  
  • To produce a structure which as far as possible conforms to the Athena philosopy. That is to say not a simple wrapping, but a true integration into the Athena environment .

    •  
  • To re-engineer the implementation toward a full OO design

    •  
     
  • To produce a structure which is modular in order to facilitate mainenance and development, and in particular such that ATLFAST users may simply replace components according to their needs.

    •  
  • To implement a prototype with the functionality of the present ATLFAST++ by September 00

    •  
          This document is the first release of a user guide to the new Atlfast OO code which has been written as a result of this project, up to this first milestone of September-00.
     
     
     

    Utilities used by new Atlfast

     

    During the development of the new Atlfast several  "general" utilities were developed to encapsulate oft repeated code. Also several interfaces became apparent which could potentially have much wider applicability than just Atlfast.

    Since these are not Atlfast specific these have been implemented as separate prototypes, with a view to  possible discussion in a wider ATLAS context.

    These utilities are assumed and used extensively by the main Atlfast code. They are referenced briefly here. The detailed documentation is linked.
     

  • The Phi class.   This class has been furnished to encapsulate cyclic algebra in the range {-Pi,Pi]

    •  
  • IKinematic interface. It  is  clear that for a large number of analysis operations different classes such as Particles, Clusters,  Tracks.....etc need only be treated as simple kinematic quantities. In addition it proved to be exceedingly useful to define in an interface the access to several very commonly used quantities (eg. pT( ), eta( ) ). This was formalised through adoption of the IKinematic interface.
  • KinematicHelper. This collects together a few commom functions which are applied often to kinematic quantities (i.e. qunatities honouring the IKinematic interface. It was clear that these functions are not specific to Atlfast and so have been collected together ijn a helper class at least temporarily in order to make them easily  accessable to users.

    •  
  • HepMC. and McEvent????. This is the ATLAS standard interface to generator output.
  • HepMC_helper class.  Many operations connected with extracting information from the HepMC::GeneratorEvent record are collected together in this helper class.

    •  
     
  • Function objects for use with STL  generic algorithms

    •  
     

     

    Description of structure of prototype new Atlfast

     

    Following an initial appraisal of the existing C++ code it was felt that fundamental idea of "Makers" was perfectly fine and sensible and there was therefore no reason to change this aspect of the modularity. In fact it was felt that the functionality of a "Maker".matched almost perfectly to the purpose of an Athena "Algorithm". Briefly an Athena "Algorithm" is a fairly autonomous piece of code which is invoked onece per event. It may read some input objects from the event store, apply some algorithmic proccessing to them, and possibly write some resulting output objects back to the store.

    Although the idea of concept Makers was retained, the mapping between original and new has changed quite significantly. This will become clear in the detailed sections,  but to give an overview:

    1. In order to understand the factorisability of Atlfast functionality we have (for at least prototype purposes) put most distinct pieces of functionality into a distinct  Algorithm. This enforces a minimum  and well defined coupling between them, with the purpose of makeing eventual encapsulation into classes easy. For example there is at present a distinct Isolator  Algorithm.
    2. Makers are, insofar as possible, based upon functionality, not particle species. In the original code each XXX-Maker was a distinct piece of code dealing with smearing, association and isolation for species XXX. In the new code there is a single Particle-Maker which deals with smearing of all particles, a single Isolator which deals with isolation of all particles...etc.  In each case specialisation is done via composition - i.e. passing species specific tools to the algorithms at initialisation time. This has led to a significant reduction in repeated code and consequent use of commom implementation.
    3. The functions of Detector simulation, Reconstructed entity simulation and Standard Histogramming have been seperated since they are logically separate, and need to be evolved separately without unnecessary inter-dependence.
    4. The Monte-Carlo generation is handled by a completely independent package called McEvent ????html ref?????. This can be thought of as an Algorithm which is run prior to Atlfast. It provides facilities to drive various generators. The output is an McEvent object in the event store. This McEvent object itself contains  HepMC objects. HepMC is the ATLA S standard  format for generstor output. From the point of view of Atlfast is it sufficient to know that the main use made of the McEvent object is to obtain a collection of final state HepMC::Particle objects which are the primary input to several algorithms. This is somewhat different to the old code where MC generation was an integral part of Atlfast.
    The resulting list of Athena Algorithms is as follows:
     
     
    Algorithm Input object type Output object type Brief Description
    Detector simulation:
    CellMaker HepMC::Particle Cell Simulates deposition of energy in a simple flat model of the calorimeter. 
    Raw reconstructed quantities
    Cluster maker Cell Cluster Makes Clusters (="pre-jets") by summing energy of Cells in a cone 
    TrackMaker HepMC::Particle Track Makes tracks by smearing   MC truth trajectory information.
    Reconstructed entities
    DefaultReconstructed 
            ParticleMaker    		 HepMC::Particle ReconstructedParticle Makes particles by smering MC truth 4-vector information. Species is set via parameters.
    JetMaker Cluster Jet Makes jets by smearing any Clusters which are not associated to isolated electrons or photons. Includes also non-isolated muons.
    Ensemble properties
    Isolator ReconstructedParticle 
    Cell 
    Cluster    		 ReconstructedParticle Determines whether input ReconstructedParticles are isolated from Cell and Cluster energy. 
    Species is set via parameters. Outputs isolated and non-isolated lists.
    Global objects
    EventHeaderMaker everything EventHeader Calculates trigger information, missing Et...etc. outputs a single global event object.
     User example analysis
    ExampleAnalysis   any --none-- Shows user how to access Atlfast objects in TES and make some simple histograms
    Output
    StandardNtupleMaker everything Common Ntuple format For validation tests and backward compatibility
     

    The full description of each of these is given in the sections which follow.

    Further observations:
     

    Running the new Atlfast to generate data objects in the event store therefore comprises scheduling these algorithms in an appropriate order, eg: (but see later section for definitive current configuration)
        CellMaker
        TrackMaker
        ClusterMaker
        DefaultReconstructedParticleMaker  // parameters set to deal with electrons
        DefaultReconstructedParticleMaker  // parameters set to deal with photon
        DefaultReconstructedParticleMaker  // parameters set to deal with muons
        Isolator                                                  // parameters et to deal with electrons
        Isolator                                                  // parameters et to deal with photons
        Isolator                                                  // parameters et to deal with muons
        JetMaker
        EventHeaderMaker
    To schedule the example analysis algorithm then add:
        ExampleAnalysis
    To cause the output to be written in the form of the common ntuple then in addition one needs to schedule:
     
        StandardNtupleMaker
    [Note that as stated above for the prototype we purposely made almost everything an Algorithm.We briefly considered the question of sub-algorithms but immediately saw this to be not a relevant decision at this point. This is because sub-algorithms are algorithms, but with less flexibility for the user to easily replace components. It is trivial to go from algorithms -> sub-algorithms later if there is a good reason, but not vice-versa]
     
     
     
     

     

    Description of output data classes

    This section describes the output data classes intended for the user in an analysis program.  These classes are the products of Makers described briefly above and in detail in later sections. These classes define the interface between Atlfast and the user:

     ReconstructedParticle
     Jet
     Cluster
     Track
     
    General notes:

    1. In several cases it is necessary to furnish naviagation information to go from the entity to the Monte-Carlo truth particle from which it was made. At present there is NO SAFE WAY to do this. The developers of the McEvent package are aware fo the problem and will in due course provide an ATLAS-wide solution. In the meantime we have implemented this ina trivial way which is in practice safe (but not guaranteed according to the rules). Wherever this is required we have simple provided a method returning a pointer to the HepMC::Particle. The user should be aware that this will likelyt change.
    2. In some cases more general associations are required. A simple example is Clusters pointing to Cells from which it was made. A more complex example is an association between an electron and cluster which are physically near each other. This had led to a general raising of the problem which is not trivial to solve in a correct way (simply throwing in pointers is doomed in the long run). Whilst we await a proper solution, we have temporarily implemented a dumb one. Each class inherits an  AssociationManager . This contains methods for setting and retrieving Athena SmartRefs to the relevant objects. The user should be aware that this will certainly change.
    [This section does not inculde those intermediate classes which are in the event store only because this is necessarry to connect two Algorithms as these are not intended for the user. At present this is only the  Cell.class. The reader can still find out about these from the standard linked code and auto-documantation, but be warned that they are not considered to be supported Atlfast output, and may dissappear in future releases.]
     


    class   ReconstructedParticle

    Declared in :  AtlfastCode/ReconstructedParticle.h

    Declaration of collection in TES:  AtlfastCode/ReconstructedParticleCollection.h

    Brief description:

    This class represents a reconstructed particle which has been simulated from a Monte-Carlo truth particle.

    All particle species are represented by this class. Their species is differentiated by a method which gives the PDG id code.

    Its kinematic attributes are 4-momentum like and are available via the IKinematic interface.

    It has a method to acceess the MC truth particle from which it was made.

    It  has an association tracing utility to refer to any other entities which may have been asociated with it (see note above regarding the  temporary implemetation of AssociationManager).

    [Design note: A conscious decision was made that all particle species should be represented by a single class, with a simple member variable differentiating species. This is as opposed to a distinct class corresponding to each particle species.This was decided after much debate as it was felt that, apart form pdg_id, there was no fundamental difference between reconstructed particles made from smeared MC truth particles. Their attributes simply are those of a 4-momentum plus a link to the parent MC particle.

    The design philosophy has therefore been to use a common ReconstructedParticle class until a situation arises where distinct classes would be warranted. The only reason we could at present foresee within the Atlfast context is ease of dispatching (i.e. overloading methods on distinc particle class type). However the potential disadvantages seem enormous (there are then a semi-infinite number of classes to write for each and every possible particle spcies).]
     
     

    Interfaces implemented (and inheritances): 
     
    Interface name Description
    IKinematic  Deals with access to all kinematic attributes
    AssociationManager  Deals with storing and access to any associated objects (such as Clusters, Tracks). 
     
     

    Public methods intended for user: 
     
    Return type method name Description
    int pdg_id( ) PDG ID code of the particle.
    HepMC::Particle* truth( ) Returns pointer to MC truth particle from which it was made.
     

    Constructors: 
     
    Argument list Argument description Use
    () Default constructor required by Gaudi. Not meaningful for a user
    (  const int pdg_id, 
        const HepLorentzVector& vec, 
        const HepMC::Particle* progenitor  )    		 PDG id code for particle 
    4-momentum for particle 
    pointer to MC truth from which derived    		 Principle constructor to be used by user. 
     
    ( ReconstructedParticle&) Copy constructor
    (ReconstructedParticle*) Copy constructor
     

    Source code:  .h  .cxx

    Auto-generated documentation  --not done yet--
     

     
     
     

     


    class   Jet

    Declared in :  AtlfastCode/Jet.h

    Declaration of collection in TES:  AtlfastCode/JetCollection.h

    Brief description:

    This class represents a Jet.

    Its kinematic attributes are 4-momentum like and are available via the IKinematic interface.

    It  has an association tracing utility to refer to any other entities from which it has been constructed  - typically Clusters (see note above regarding the  temporary implemetation of AssociationManager).
     

    Interfaces implemented (and inheritances).
     
    Interface name Description
    IKinematic  Deals with access to all kinematic attributes
    AssociationManager Deals with storing and access to any associated objects (typically Clusters from which made). 
     

    Public methods intended for user: 
     
    Return type method  name Description
     --none--
     
     
     

    Source code:  .h  .cxx
     
    Auto-generated documentation:  --not done yet--
     
     
     

     


    class   Cluster

    Declared in :  AtlfastCode/Cluster.h

    Declaration of collection in TES:  AtlfastCode/ClusterCollection.h

    Brief description:

    This class represents a cluster of energy with a centriod at a given 3-vector position.  This information is made available by the IKinematic interface  with the constraints that eT=pT .

    The class is general and may be formed by any ClusterMakeing algorithm.

    The AssociationManager gives access to other objects from which it was made,such as Cells.
     

    Interfaces implemented (and inheritances).
     
    Interface name Description
    IKinematic  Deals with access to all kinematic attributes
    AssociationManager Deals with storing and access to any associated objects (typically Cells). 
     

    Public methods intended for user: 
     
    Return type method  name Description
     ---none----
     

    Source code:  .h  .cxx

    Auto-generated documentation:  --not done yet--
     
     
     
     

     


    class   Track

    Declared in :  AtlfastCode/Track.h

    Declaration of collection in TES:  AtlfastCode/TrackCollection.h

    Brief description:

    This class represents a track which has been simulated from a Monte-Carlo truth particle.

    Its kinematic attributes are 3-momentum like and are available via the IKinematic interface with the constriant eT=pT..

    It has a method to acceess the MC truth particle from which it was made.

    It  has an association tracing utility to refer to any other entities which may have been asociated with it (see note above regarding the  temporary implemetation of AssociationManager).
     
     

    Interfaces implemented (and inheritances).
     
    Interface name Description
    IKinematic  Deals with access to all kinematic attributes
    AssociationManager Deals with storing and access to any associated objects (typically Cells). 
     

    Public methods intended for user: 
     
    Return type method  name Description
     HepMC::Particle* truth( ) Returns pointer to MC truth particle from which it was made.
     

    Source code:  .h  .cxx

    Auto-generated documentation:  --not done yet--
     
     
     

     

    Description of CellMaker Algorithm class

    Brief definition:

    CellMaker reads Monte Carlo information form the TES and causes a calorimeter simulation of their energy deposits resulting in a collection of hit Cell entities to be written to the TES

    Input

    McEvent monte Carlo information in the TES

    Output

    Cells to the TES
     

    Source code:  .h    .cxx
     

    Long description

    The prototype design suggested that detector simulation should be factorised from simulation of reconstructed quantities. Accordingly the representation of calorimeter energy deposits (Cell class) is constructed and written to the TES by an independent CellMaker algorithm. Previously CellMaking and ClusterMaking were combined.

    We considered that as the design evolves there may be better ways to represent the calorimeter, and to answer questions about calorimeter energy deposits. Thus inside Cellmaker the Calorimeter is simulated by a Calorimeter class. The notional purpose of this is to provide an interface between an arbirtarily sophisticated calorimeter simulation and the Atlfast use of it to ask for Cells. The design has not been taken any further at present, nor has it been demonstrated that this is the best line to follow.

    The Calorimeter class follows the original ATLFAST++ model.
     

     

    The Cellmaker algorithm is then simply a wrapper which feeds the Calorimeter class particles, asks for the Cells back and writes them to the TES.

     

    User parameters

    The user can set the following parameters in jobOptions.txt. Defaults are given in []

     
     
     

    Description of ClusterMaker Algorithm class

    Brief definition:

    ClusterMaking is currently defined as a process which uses Cells from the TES and forms Clusters from them. The strategy employed is to sum all Cells in a given R-cone around an initiator. [Note: This might be more correctly called pre-jet formation as the R-cones are of jet size and therefore this algorithm does not really correspond to the normal notion of forming clusters from,say, adjacent energy deposits.]

    Input

    Cells in the TES

    Output

    Clusters to the TES
     

    Source code:  .h  .cxx
     

    Long description of strategy

     

    User parameters

    The user can set the following parameters in jobOptions.txt

     

     
     
     

    Description of DefaultReconstructedParticleMaker Algorithm class

     
     

    Brief definition:

    Reads Monte Carlo particle truth information from the TES and selects a specific particle species (set via a parameter). For each such MC truth particle it creates a ReconstructedParticle instance. The ReconstructedParticle is created with a smeared energy which can be different for different species. The ReconstructedParticles are written to the TES

    Input

    McEven MonteCarlo truth in the TES

    Output

    A collection (normally ObjectVector<ReconstructedParticle> of ReconstructedParticles written to the TES . This collection is typedefined as ReconstructedParticleCollection.

     
    Source code:  .h  .cxx
     

    Long description

    DefaultReconstructedParticleMaker is a single class which is able to create ReconstructedParticles corresponding to any particle species for which it has been configured. This is one of the major advances of the new version. All of the code which was common, but repeated in several different makers has been abstracted into one class which is configurable wherever it needs to be different for specific particle species. In fact only smearing  is different and hence this maker is configured by supplying it species specific Smearer.

    In a pure OO environment smearing would be an example of a behavioural difference given to the Algorithm by composition. It would probably be supplied through the constructor of the Algorithim. This option is not available in Athena directly however we expect the advent of tools to allow different smearers to be configured via jobOptions, and then given to this Algorithm also by jobOptions. At the time of writing this facility was not available yet and so a temporary fix up is used.

    In this release the following smearers are supplied exactly as were in ATLFAST++

    These smearers encapsulate the only part of this maker which acts in a species specific way. A user may in principle supply an arbitrarily sophisticated smearing procedure for any particle species.

     

    User parameters

    The user can set the following parameters in jobOptions.txt. defaults are given in []

    The following are neeed to configure the smearer. It is wrong to have them here, but this can only be changed when tools can be used which can be configured via jobOptions directly. Probably this will change by the next release. And temporarily also we have to set a random seed. This should disappear with the use of Athena random number services.  
     
     
     
     

    Description of Isolator Algorithm class

    Brief definition:

    Reads  ReconstructedParticles from the TES and applies an isolation test to them. Writes seperate lists of isolated and non-isolated particles back out to the TES. The present algorithm implements exactly that of ATLFAST++, and in order to do this it also reads Cells and Clusters from the TES. The isolation test is performed by summing the transverse energy in a cone around  the test particle and comparing to a threshold. It operates on a single particle species which is set via a parameter.

    Input

    Collection of ReconstructedParticles from TES
    Collection of Cells from TES
    Collection of Clusters form TES

    Output

    Collection of ReconstructedParticles to TES   (isolated particles)
    Collection of ReconstructedParticles to TES   (inon-solated particles)
     

    Source code:  .h  .cxx
     

    Long description

    Following the stated goals of the prototype the function of isolation testing has been implemented as a distinct algorithm [the purpose being to help us factorise operations in atlfast].  The Isolator algorithms class is therefore designed to be scheduled following the DefaultReconstructedParticleMaker algorithm which writes all smeared particles to the TES without itself performing any selection on isolation. Isolator reads  these smeared particles, divides them into isolated and non-isolated lists, and then writes both lists back out to the TES at  locations specified via parameters. Thus the user is most likely to be interested in the the output of Isolator rather than ReconstructedParticleMaker directly.

    Note: in order to follow ATLFAST++ exactly the cut on sum Cluster eT should be left at 0. This is because the original algorithm simply asked whether any Cluster was within the isolation cone, but did not apply any cut.

      
    User parameters

    The user can set the following parameters in jobOptions.txt. defaults are given in []

     
     
     
     
     
     

    Description of JetMaker class

    Brief definition:

    Jet maker shares its misnoma with Cluster maker, in that it is actually ClusterMaker which forms the Jets, followed by JetMaker which simply smears the energy accoring to some parameterisation. Thus the action of this algorithm is to read Clusters from the TES, smear their energy, add in any non-isolated muons, and then create a Jet which is written out.

    Input

    Collection of Clusters from TES
    Collection of Muons from TES

    Output

    Collection of Jets to TES
     

     Source code:  .h  .cxx
     

    Long description

    The JetMaker starts from Clusters in the TES. Recall that Clusters are in fact summations of energy in a jet-like cone (0.4 or 0.7) around an initiator and are therefore nearly jets anyway. The JetMaker algorithm performs the followng steps
     

    No jet -flavour tagging has been done for the prototype release purely due to time constraints.
    User parameters

    The user can set the following parameters in jobOptions.txt. defaults are given in []

    The following are neeed to configure the smearer. It is wrong to have them here, but this can only be changed when tools can be used which can be configured via jobOptions directly. Probably this will change by the next release. And temporarily also we have to set a random seed. This should disappear with the use of Athena random number services.  
     

    How to get going

    In this section we attempt to take the user step by step through the process needed to get going with the new Atlfast.

    The reader is reminded at this point that the Atlfast works on the output of any generator which has been installed in Athena and which conforms to the output format of the McEvent package. The documentation of generators is therefore no longer part of Atlfast proper. See ???? html ref to McEvent ?????. Thereofre in the following we show how to fire up an example generator, but no attempt is made to describe it or its options in detail.
     
     
     


    Scripts

    Some example scripts have been created  to demonstrate how to check out the code, build the executable, and run the job. The scripts contain a few lines where you should put in your own chosen path names corresponding to the roots where you (a) want to put the checked out the source and (b) want to build.

        checkout.sh
               This checks out  Athena ...etc, the Generators code (for Pythia ...etc), and then Atlfast.
     

        build.sh
                Performs the configure and make steps to build the job.
     
        run.sh
                Runs the job from the appropriate directory.
     
     


    Job Options

    Athena is driven by a jobOptions file.

    A job options file which will schedule a  generator  followed by all the Atlfast algorithms is available in  AtlfastFrame/share/jobOptions.txt .  This file in turn #includes AtlfastFrame/share/StandardAtlfastOptions.txt a second file which contains all of the default parameter settings. This is fairly heavily commented and the user should look at the latest version for up to date details. A brief commentary is given here.

    jobOptions.txt:
     
    AtlfastFrame/share/jobOptions.txt

    StandardAtlfastOptions.txt:

    AtlfastFrame/share/StandardAtlfastOptions.txt

    This file contains all of the parameter values to give to the instances of each Algorithm. Most of the entries are self evident after reading the description of each Algorithm given earlier in this documents.  Note that it is not an error to give parameters for Algorithms which hve not been scheduled - in this case Athena simply ignores them.
     

    The defaults set here are intended to follow those of the old ATLFAST++ as far as possible.

    The user should NOT need to edit this file, as it should be sufficinet to over-ride any parameters you wish in your own seperate file which should be included in jobOptions.txt in the same way, but following StandardAtlfastOptions.txt.
     
     
     
     
     
     


    Location of output in the TES

    All of the locations in the TES for input and output can be seen either in the default parameters for eack maker (see this document above) or by their overriden values given in the  StandardAtlfastOptions.txt  file.

    We repeat them her just for quick reference, and to show you the "general naming scheme" used for the prototype. As will all documentation however, this section may become inadvertantly out of date,  but the job options file will always give the exact values.
     

     
    Output quantitiy Object Type Collection Type Location
    Electrons: 
        Isolated 
        Non-isolated    		 ReconstructedParticle ReconstructedParticleCollection /Event/AtlfastIsolatedElectrons 
    /Event/AtlfastNonIsolatedElectrons
    Photons: 
        Isolated 
        Non-isolated 
         		 ReconstructedParticle ReconstructedParticleCollection /Event/AtlfastIsolatedPhotons 
    /Event/AtlfastNonIsolatedPhotons
    Muons: 
        Isolated 
        Non-isolated    		 ReconstructedParticle ReconstructedParticleCollection /Event/AtlfastIsolatedMuons 
    /Event/AtlfastNonIsolatedMuons
    Jets Jet JetCollection /Event/AtlfastJets
    Clusters Cluster ClusterCollection /Event/AtlfastClusters
     
     


    Example analysis Algorithm

    A very simple example analysis Algorithm has been prepared in order to show the user how to access Atlfast output from the TES and to make some simple printout and plots with it.

    This can be found in the AtlfastCode package and is called ExampleAnalysis (.h and .cxx). This Algorithm should be scheduled after all other Atlfast operations as described in a previous sub-section.

    The example code has been very heavily documented in an attempt to explain the meaning of each line.  The histogram output appears in the file specified in the jobOptions.txt file. [Note: the authors of Atlfast do not claim to yet be experts as using Athena histogram services - so expect bugs here].

     
     

    Appendix: Known problems

    build:

    - Problem in build which we dont understand. You have to copy something by hand the first time. See build.sh script for details.
     

    ClusterMaker:

    - Uses fixed cone of 0.4 for all Clusters regardless of parameter settings. Because no easy way to know barrel/ecap split yet.
     

    - A possible problem was identified in ATLFClusterMaker to do with eT weighted phi(). See PreCluster class for details. Implementation here is therefore different.
     

    StandardNtupleMaker:

    Histograms and Ntuple dont work together  Histograms have random problems with output to file.