Multiplicity FAQ for the Phobos Physics Working Group

Robin Verdier, 1-Dec-1998

Steve Manly asked me to give a status presentation for the multiplicity reconstruction package during the Dec. 4 phone conference. I agreed to do that if he would provide a list of questions. He did, and here it is, slightly modified, with answers. Some things may not work yet exactly as I describe them; please let me know of instances.

Q1. What is the minimal set of classes required to run the package?

Q2. What input files are required?

Q3. What is output from a run?

Q4. What is the simplest way to do a multiplicity reconstruction and view the results?

Q5. What is the reconstruction algorithm in a nutshell?

Q6. What is the function of each part of the package?

Q7. Where is a production version available, and with what data files does it work?

Q8. What user hooks are available for custom modifications?

Q9. Where is the user guide? Is it up-to-date?

Q10. What are the physics strengths and weaknesses? What would you worry about if someone wanted to publish these results?

Q11. What work is ongoing on the package, and what is planned for the future?

Q12. What data files will be required for further development of the multiplicity reconstruction?

Q1. What is the minimal set of classes required to run the package?

A. The classes are listed below in the answer to Q6. They are all in a standard Phat release, in the $PHATHOME/phatmul subdirectories. Since classes reference classes reference classes, it's probably unwise to try to create a minimal set of libraries. Our use of shared libraries means that an executable image will be as small as possible.

Q2. What input files are required?

Until real data is available, you will need a file containing output from the Phobos Monte Carlo. Two formats are available. Files with extension .apx are in ASCII format; in addition to geometry, they contain for each pad the summed energies from all tracks that traversed it. Each file can contain many events. Files with extension .root contain the same information as the .apx files, but stored in a standard object-oriented ROOT format that is ten times faster to read and whose energy depositions are, so far as we know, identical in format with the files we will get in actual running. Some .root files contain only data for spectrometer sensors and are therefore not useful for multiplicity reconstruction. If a .apx file but no .root file is available for your studies, you can create a .root file from a .apx file by executing the macro $PHATHOME/phatmul/apxtoroot.C.

Steve Manly is building a catalog of available data files at

http://phobos-srv.lns.mit.edu/Detectors/Computing/Datafiles/DataDocProposal/mcdata.htm

Note that you must type it all one [too-?] long line. You can find new format files created by Andrzej Olszewski in

/data04/phobos/olszewsk/exports/pre-mdc2 on abacus.mit.edu and /home/phobos/PHOBOS-data/pre-mdc2/root/full on nighthawk.chm.bnl.gov

The files are

cvr_all_containers.root

cv0_all_containers.root

iv0_all_containers.root

Q3. What is output from a reconstruction run?

In normal use, you display TGraphErrors or TH2F (2-d histos) that TPhMul methods create for you on request. You can also access the raw and reconstructed data directly using class methods in order to examine it in formatted listings or to use it for trying different reconstruction algorithms. In the near future, you will be able to stream the TPhPadMap data containers to and from private files.

Q4. What is the simplest way to do a multiplicity reconstruction and view the results?

A. Assuming that you have located a standard Phat release and have defined the necessary environment variables PHATHOME, ROOTSYS, LD_LIBRARY_PATH, PATH, and DISPLAY (see http://phobos-srv.lns \ .mit.edu/Phat/PhatDocumentation/GettingStarted.htm), you can use the macros in $PHATHOME/phatmul/macros. You also have to have a data file accessible from the computer you're runnng on. Type

phat $PHATHOME/phatmul/macros/runmul.C

and follow the prompts. They should be self-explanatory. When you are asked whether to run a setup macro, you should enter cr unless you want to make individual settings or change parameter values, in which case you should copy $PHATHOME/phatmul/macros/setmul.C to your local area, modify it, and then specify its name in answer to the prompt.

Once processing is complete (~ 2 seconds / event), you can type

.x $PHATHOME/phatmul/macros/plotmul.C

to see a standard set of plots of occupancy, energy deposited per track, dN/dEta, and secondary fractions, for the entire detector. This macro uses the methods of TPhMul to get and plot the data; you can make a personal copy and modify it to give plots that are of particular interest to you, for example, comparing the vertex detector reconstruction with that of the octagon.

MDC Production macros invoking multiplicity reconstruction can be found in $PHATHOME/phatloop.

Q5. What is the reconstruction algorithm in a nutshell?

get data (pad data only, or pad data + MC tracks and hits);

for every pad of every active sensor

get the deposited energy or convert the ADC value to energy;

convert to 300 m thickness assuming all tracks came from the found vertex;

limit energy to mean + ~ 4 s.d.;

look up global dE/track and (Total/secondary) fractions;

calculate # tracks and # primary tracks;

map (project) these quantities onto (h, f) displays.

Q6. What is the function of each part of the package?

• TPhMul: a procedural class with methods that perform the reconstruction (in particular, TPhMul::Recon) and provide access to lower-level methods of the classes it invokes (for example, TPhMul::GetGraph). The user creates an instance of TPhMul and requests all actions through its Process, Get, and Set methods; additional methods and public fields allow experts to perform diagnostic and control functions, including the creation of diagnostic histograms.

• TPhPadMap: a data container class that provides dynamic storage and coordinate mapping functions for raw and reconstructed data. Each TPhPadMap can contain a 3-dimensional array of variables; two of the dimensions are coordinates and the third indexes variables. TPhMul creates two sets of arrays of TPhPadMaps, one, called Sensor Maps, having the coordinates of sensor pads, the other, called Displays, have physical eta, phi coordinates. Each layer stores a different variable, for example, deposited energy, used phase space, global secondary fraction, reconstructed total number of tracks; other layers can store the equivalent generated values.

• TPhDept: a data container class that provides values of the global energy deposited per track determined from ancillary studies.

• TPhFsec: a data container class that provides values of the global fraction of total-to-primary tracks determined from ancillary studies.

• TPhDispDef: a data container class that manages display map definitions in the form required by TPhMul.

• TPhSensDef: a data container class that manages sensor geometry in the form required by TPhMul.

• TPhMulDisp: a procedural class that provides better access and labelling facilities for graphs.

• TPhOpts: a data and procedural class that provides access to parameter files used for automated fitting of global functions. The difficulty of this process has meant that the fits produced in this way are, so far, unsatisfactory.

Q7. Where is a production version available, and with what data files does it work?

The newest version can be checked out from the CVS repository (q.v.) and will work with new .root files, with the temporary limitations noted above, and on privately created .root files and on old .apx files. It will be tested with new .apx files when they become available. The desirable existence of a standard, well- maintained version of Phat at each computing site has apparently not yet come to pass.

Q8. What user hooks are available for custom modifications?

The out-of-date user guide on the Web and the runmul.C, setmul.C, and plotmul.C macros show how to set new values of the global functions in TPhDept and TPhFsec; the effect of changing the truncation energy limit can be studied in the same way. A future version of the global function classes will allow more flexibility in specifying the functions. Computing the function values in interpreted code is theoretically possible but probably too slow to be useful.

Q9. Where is the user guide? Is it up-to-date?

A July 1998 version is on the Phobos server in

http://phobos-srv.lns.mit.edu/Detectors/Computing/Documentation /muluser.htm.

Many interim changes have rendered it obsolete, and I hope shortly to replace it with a new version incorporating some of the information in the present document.

Q10. What are the physics strengths and weaknesses? What would you worry about if someone wanted to publish these results?

One strength of the algorithm is that it is simple, transparent, and robust, although the surrounding O-O machinery tends to conceal these aspects. Another is that each pad is treated as an independent detector, so that we don't need the whole detector to be working, as long as we know what parts are inactive.

The major weakness of the reconstruction is inescapable given the Phobos geometry: by every accepted estimate, the occupancy in the central region will be very high, and the effects of detector physics, in particular the Landau tail, and of geometry, in particular the high production of secondaries, introduce large experimental uncertainties into our single-event reconstructions. The determination of these effects and their uncertainties is the biggest task for our multiplicity reconstruction. Preliminary studies show that the "tune", or set of global functions, obtained for central events at vertex 0, works tolerably for random vertices and inclusive events. An immediate goal is the introduction of an improved integrated multiplicity calculation that is accurate enough to use as a metric for these studies. We need also to begin studies of the extent to which the average secondary fraction can be determined from data at different vertices (if it moves, it isn't physics), and checked with the insertion of additional material in the neighborhood of the beam pipe, if possible.

Our dilemma is simple: if Geant and the Event Generators are correct, we are guaranteed the reconstruction will be correct; but then why are we doing the experiment?

My biggest worry is not that we'll get the wrong answer for the multiplicity, but that we WON'T assign the experimental uncertainty and systematics correctly. We're not in the square root of N any more, Toto.

Q11. What work is ongoing on the package, and what is planned for the future?

A. My own priority order, past reacting to changes in other parts of Phat, includes

Implementing the streamer functions for TPhPadMaps, to speed up the reading of data from .root files

Making a precision fit integral

Basing the energy truncation on neighboring pad averages

Bringing the amateurish plots up to publication quality

Converting the TPhSensDef struct into a class to handle geometry modifications; so far this has not worked

Making the TPhOpts global fits robust so phi dependence can be studied more efficiently

Q12. What data files will be required for further development of the multiplicity reconstruction?

A. We will need runs for different centralities, vertex positions, and models. To begin the studies that will continue throughout the course of Phobos, and making a rough calculation of the numbers of tracks necessary to achieve 1% precision in the total multiplicity, I estimate that we'll want at least 6 central events at 9 vertex positions and 4 centralities, or a total of about 200 events, for 3 models (HIJING, HIJET, and FRITIOF, for example). Estimates for achieving this level of precision in individual parts of the detector are much higher; but it would not make sense to generate more data yet.