Figure 1.2 -- Correlation (left) and resolution (right) in phi between the reconstructed and generated tracks.

 

 

 

Figure 1.3 -- Correlation (left) and resolution (right) in 1/pT between the reconstructed and generated tracks.

 

 

 

What is the reason for not using double precision for mWeights? All other floating
point event-wise variables are double. Is the array expected to be very large and
the use of float to conserve disk space?

The thinking was to save space.  However, weights should only be one or few words per event, so switched to double.

The user is expected to inherit their event from this class (or one of
StarGenPPEvent, ...etc) but none of the methods except Clear() are virtual.

StarGenEvent is intended to record the minimal set of properties which are common across diverse event generators.  It also establishes part of the interface with the Monte Carlo, e.g. the decision to stack particles for simultion and the order in which they should be stacked.  This should not be overridden by the developer.

Is it possible to create events with different particle classes (inheriting from
StarGenParticle)? I ask because there are some particle-wise quantities that for
example make sense in a DIS event but not in a hadronic event. These would be
convenient to have access to in the particle record. Or is the intention that any
more complicated particle-wise quantities should always be computed by the end
user when analysing the simulated events?

The intent is to keep the particle class as minimal as possible.  ID, kinematics, mother/daughter relationships and generator bookkeeping.  If we need to store additional particle-wise information, we should do this in a parallel data structure.  Perhaps an array of an "attribute" class.

• Is the omission of a leading “m” to field names a deliberate omission, to make
  TTree::Draw() statements simpler?

  Yes

• Accessor/setter methods are absent.

  Intentional.  This is really more of a "struct" than a "class" here.

• Comments describing the last few fields would be useful (and make comments
  Doxygen style).

  Comments doxigenated

• Add comment lines noting use of the default copy constructor/assignment
  operator.

• What is the distinction between process and subprocess?

  Depends on the event generator, and should be specified by the developer.  In pythia 6, I set
  process = pysubs.msel and subprocess = pypars.msti(1)  (a.k.a. the ISUB corresponding to the exact
  parton+parton interaction involved.)

StarGenerator ? Names StarGenerator and StarPrimaryGenerator suppose they have the same functionality but is not the case.
StarPrimaryGenerator is maker. All others
    I proposed to split  Maker in name and to move 000README and HOWTO* there.

pdg() returns the TParticlePDG information from TDatabasePDG. There is a
StarParticleData class with modified entries - should it not return it from here to be
STAR-specific?

I have modified StarPrimaryMaker (and other places in the framework where appropriate) to use StarParticleData.

OOC, why can there only be one primary generator? ...

We need a single maker to be in charge of pushing tracks out to the GEANT stack.  This is it.

If a developer wants to have a generator which is a tree of generators, this can be achieved.  StarGenerator is really a maker, so one can add makers to it, and iterate over them.  So there's no functionality lost by making StarPrimaryMaker a singleton.

We don't use the singleton patten here because that violates the spirit of the Maker/Chain approach, whereby makers are available to other makers in the chain through a call to GetMaker("/path/to/maker").

I believe the ROOT folks recommend using TTree::Branch() not TTree::Branch().
http://root.cern.ch/phpBB3/viewtopic.php?f=10&t=10142

Fixed, and request made to ROOT team to fix their documentation (class reference) for TTree.

Init() returns the result of StMaker::Init(), but potential problems in Init() itself (e.g.
failure to open output file) are not handled.

kStWarn will be returned on file open failure.

Make() and Finish() should presumably call/return StMaker::Make() and
StMaker::Finish(), assuming the other operations in those methods are successful.

No.  StMaker::Make() would loop over all sub makers and call Make() on them, as well as other bookkeeping tasks.  This is not needed.  Likewise with Finish().

In Finalize(), printing an error and returning kStFatal may be more useful than
assert().

Error returned.

StarGenerator ? Names StarGenerator and StarPrimaryGenerator suppose they have the same functionality but is not the case.
StarPrimaryGenerator is maker. All others
    I proposed to split  Maker in name and to move 000README and HOWTO* there.

Why does it inherit from StMaker? The user is prevented from calling Make(), and
a maker than canʼt make seems like and odd design.

The inheritence from StMaker is to leverage all of the other facilities of the maker class, e.g. hierarchical data structure, list of sub makers over which we can iterate, etc...

Make mm and cm private/protected (are they even used?).

They should be used by developers in order to specify the units used by the concrete event generators, so that the simulation package recieves events with the correct spacial dimensions.

If impact parameter is heavy-ion specific, why is SetImpact() in the base class?

It is there to define a consistent method across all heavy ion generators.

Why is StarPrimaryGenerator a friend of StarGenerator? What private information
is being accessed? All I saw looking through StarPrimaryGenerator was use of
public StarGenerator methods.

StarGenerator::mId should only be assigned by the primary generator.

StarPrimaryGenerator - in StarPrimaryGenerator::Init() it is supposed that all makers from GetMakeList() are inherited from StarGenerator. If this is not true then you are looking for seg. fault. You need to use dynamical cast.

Resolved.

StarGenParticle ? Why do you need to duplicate TMCParticle.h ?

TMCParticle is an emulation of the LUJETS/PYJETS particle record.  TParticle would be a better choice over TMCParticle, but it would still lack bookeeping information needed to keep track of (a) which event generator created the particle, (b) the unique ID of the particle in the event generator's record, (c) the unique ID of the particle in the aggregated event record and (d) the position of the particle on the starsim event stack (--> id truth).

Additionally, we layout the memory structure such that we can easily add the data to the g2t table for backwards compatability with the current framework.

Enumerations are added which specify the status of the particle, so that developers can follow a consistent standard.  A method is also established to determine whether the particle should be sent out to GEANT for simulation.

The documentation here is very good. One thing to add would be whether array
indices are in the range [0, N) or [1, N].

Done. 

Why is StarPrimaryGenerator a friend of StarGenerator? What private information
is being accessed?

get_hepevt_address() is accessed by StarPrimaryGenerator to add the particle to the g2t tables.

SetId() could be inlined.

SetId() now looks up the particle in the StarParticleData class and sets mass accordingly.

What is the reason for inheriting from TObjectSet? Is that where the particles
added to the list are deleted?

Permits us to add StarParticleData to the primary maker so that it is browsable and accessible to makers through the normal chain mechanism.  (Low priority: We should eliminate the singleton pattern here in favor of this access method).

sInstance doesnʼt follow naming convention.

True.  I prefer to singleout the singleton instance with this convention.

My anti-macro-bias strikes again...

Noted.  Function implemented.

I donʼt understand PopPrimaryForTracking()...

This class follows the Alice implementation of the VMC particle stack.  I think they chose the name poorly, because it doesn't really "pop" anything from a stack.  But we're stuck with the name of the method.

StarRandom - Why do you to remap ROOT's TRandom generators to StarRandom ?

I would like to ensure that there is a sinlge-source for random numbers in simulations.  There was some discussion in yesterday's (9/6) VMC meeting about providing a single source RNG, but allowing different seeds (or algos) on a per-maker basis.

I would make _Random a nested class of StarRandom and move the forward
declaration inside the class (no need to expose its existence to the user).

Is use of the common random generator encouraged for users? Does the rest of
the package expect it, or is it just there for convenience in case users want it?

Yes.  This is a matter of being able to (a) reproduce results for a given seed, and (b) replace poor-quality FORtran-era random number generators with more robust modern RNGs (higher periodicity, and better randomization).

StRoot/St_geant_Maker/St_geant_Maker.cxx 
      remove all xgeometry. All other modifications are o.k.

Keep flat structure of packages, i.e. remove level StarGeneratorPool which generate extra complexity.

I need justification for StarDb/Generators, StarDb/Pythia8

Round 2

Conclusion:  The new framework has similar performance to the old framework in terms of matching tracks from the event record to reconstructed tracks via ID trutrh.