Ulrich Baur, (one of) the author(s) of the original version of ZGRAD (or ZGRAD2 as he sometimes calls it - I guess there is a separate, older program that he calls ZGRAD), provided some documentation with his distribution of the program. This is also included with my distribution, as zgrad_weak.man .
On this page I hope to document some of the more nitty-gritty operational issues.
ZGRAD's not yet in CVS. So, for now, the current version of ZGRAD can be found here: zgrad.32603.tar.gz .
You'll also probably want the interface file for LesHouchesModule: user_les.F .
I've had good success compiling on several different Linux machines. You will have to change the makefile to indicate where your version of the CERN libraries are located, possibly to indicate what pdflib is called in your CERN library directory, and you may have to change the FORTRAN compiler and options. In a brief attempt, I was unsuccessful in compiling on an IRIX machine.
zgrad2 < ew_validate.in >& ew_validate.out &
It takes about 30 minutes to run on my P3 1 GHZ machine. Comparing the results from two linux machines with different versions of the CERN libraries, I see small differences in the output and in ew_validate1.hbook. I see _very_ small differences in ew_validateunwt.hbook.
If you run zgrad2 interactively it will prompt you for all of the input options. Many of them are described in zgrad_weak.man and I've annotated the validation example included in the distribution, ew_validate.in. A number of the input options, mostly from Uli's original program, open up branches of other options. So, if you explore the options you're encouraged to do it from the command line first, as the input card may require substantial modification.
For a more "real life" example you could consider 210ew301.in . It ran in about 8 hours on one node of the PDSF cluster at NERSC (something in the range of a 1 GHZ Pentium III). The results were:
We have generated 34936 2->2 events and 24612 2->3 events. Based on the cross sections: (2->2) 88.5412445 and (2->3) 151.007767 You should receive 14431 2 body and 24612 3 body events.
First, a lot of initialization type information. How various parameters are set, etc. " ***** ERROR in HBOOK2 : Not enough space in memory : ID= 28" is normal, I inherited a broken histogram 28 from Uli and never bothered to fix or remove it.
The first pass through the 2 and 3 body code uses the first user-specified NCALL1 and NCALL2. Uli has recommended at least 20,000 for each.
The 2 body code takes 5 sweeps of 2*NCALL1 each. You can see these numbers, and see the code select the 2 body maximum weight.
NSHOT = 40000 NO. SWEEPS = 5
Nucleon PDFs : CTEQ Set 5L (LO) Structure Functions
Ngroup = 4, Nset = 46
--------------------------------------------------------------------------------------
New 2->2 max weight: 7.8078557E-08
New 2->2 max weight: 1.22068997E-07
After each sweep, and after all 5, the total 2 body cross section is printed.
Also, the forward and backward components are printed at the end in
whatever approximation you've selected, along with the LO/EBA numbers.
The number of shots failing the 2 body cuts is also listed. And, a summary of the weighting information is printed.
The 3 body code makes 10 iterations of NCALL1 and 3 iterations of NCALL2 through VEGAS. The total cross section for each iteration is preinted, with error, and the maximum weight as it's selected. The 3 body cross section calculated internally by VEGAS is printed, and Uli prints the forward and backward cross sections he's calculate (Uli's and VEGAS' calculation are apparently slightly different. They should agree within errors.) A summary of the 13 iterations is printed along with unweighting information. For the 3 body calculation ther are cuts besides kinematic cuts which presumably have something to do with the details of the calculation. In the validation run something like 45% of calls fail these cuts.
For the production run it's much the same story. Here, the second set of user-specified NCALL1 and NCALL2 are used. The unweighting information printed reflects what actually shows up in the ASCII file of unweighted events, rather than just predictions. The number of unweighting attempts (events that make it as far as the unweighting code) is printed, along with the number of unweighted events, the sum of the weights of attempted events, the maximum events, the expected and actual unweighting efficiency, the number of negative weight events selected, and the number of events included more than once (because their weight was greater than the maximum weight).
At the end there's a summary of the whole process. The number of unweighted 2 and 3 body events isl isted, along with the cross sections used to set the fractions kept, and the actual number of events kept and saved to disk.
There are three histogram files created by ZGRAD (names are specified on the input card). The first contains kinematic information for the weighted events produced in the initialization (maximum-weight setting) run. The second actually has exactly the same information, and should eventually be removed from the source code. Histograms are booked in zgrad_main.f and zgrad_out1.f (grep on HBOOK). 2 body weighted (EBA, and soft and virtual corrections) histograms are filled in zgrad_dec_w2.f. 3 body (real photon) histograms are filled in zgrad_out1.f (grep on HFILL). Histograms that plot inclusive EW or QED quantities, and so have both 2 and 3 body components, are filled from each.
Histograms 1-30 were created by Uli. They have various kinematic quantities, including the forward-backward asymmetry. The labels are mostly clear, on request I have more detailed descriptions that I can make available. I added 31-38 to fill out the collection of pt and eta quantities plotted. 50-55 are histograms of the event weights.
The third histogram file has histograms of weighted events from the production phase, and of the corresponding unweighted events. So, 1-55 are the same quantities as in the first histogram file, but from the production run. 60-64 are obsolete and should be removed from the code. 101-138 are the same kinematic quantities as 1-38 (indeed I didn't even bother to give them names, please refer to the corresponding names of 1-38) but are for unweighted events. 200-213 are histograms of unweighted events, where i've calculated the kinematic quantities myself from the 4-vectors. For 101-138 I just used Uli's calculations. There were some problems with some of the kinematic variables, so I included these self-calculated plots as a cross check.
Users should feel free to add their own histograms to the 2 body, 3 body, or unweighted section. There's not a self-contained place to do so, but it should be basically straightforward to add them to the list of existing histograms.
Then, information is printed for each event, one line per event. We have, in order: the number of particles (5 or 6, two quarks, a Z/gamma, two leptons, and perhaps a photon), the weight of the event (+-1), the scale at which the pdf's are evaluted (currently the Z pole), the QED and QCD couplings used, the identity of each of the particles in the event, the status of each particle (ingoing, outgoing, propagator), the mother information for each particle, and the kinematic information for each particle (px, py, pz, E, m).
Currently, for 2 body events the quark ID isn't printed. For 3 body events a quark ID is printed, but it isn't fully accurate or respected. For 2 body events the quark flavors are selected in the LesHouchesModule interface. The quark is always chosen to come from the proton, and the anti-quark from the anti-proton. For 3 body events, half of the time (for weighted events) ZGRAD takes the quark from the pbar and the anti-quark from the proton. So, this is at least recorded in the event file. If the first quark ID has a negative sign then the anti-quark has come from the proton. Keeping this in mind, the quark flavor is selected in the LesHouchesModule interface. One important caveat: currently, the order of events in the event file outputed by ZGRAD is not random. So, to get the ratio of 2 body to 3 body events correct you'll have to use the entire file that you generate, and not a subset of it. The events to write to the file are selected randomly, but from the the total sample of available 2 and 3 body events. So, for example, if we over produced 2 body events the beginning of our event file will be loaded with 2 body events. Then, when we have all of the 2 body events needed to balance the available 3 body events, the tail of the event file will be full of 3 body events.
LesHouchesModule is stored in CVS. To compile it, make a new release, and add LesHouchesModule with, for example,
~% cvs checkout LesHouches ~% cd include; ln -s ./../LesHouches/LesHouches/ LesHouches; cd ../At the moment ZGRAD's interface isn't distributed with LesHouchesModule. So, you'll need to use ZGRAD's interface as a user-provided interface. The current version can be found here: user_les.F .
Replace the user_les.F (
You can use zgrad_LH_example.tcl as an
example tcl file. You should have
The quark flavors are assigned in the LesHouchesModule interface, rather than
by ZGRAD, and are done very crudely. The quark flavor information is available
in ZGRAD, but because of the way the calculation is done I had difficulty
extracting a specific quark flavor for each event, and attaching an appropriate
weight to it.
The LesHouches module, when run on fcdfsgi2 produces rare (approximately 1 in
20,000 events) floating point errors that cause it to crash. But, they do not
always occur so you can avoid usually rerun any given job, with the same
unweighted events, and avoid a crash.
The author of the LesHouches module says that the problem is related to
the FORTRAN compiler on fcdfsgi2 and that one should not use Les Houches there.
Out of the box, ZGRAD doesn't even compile on fcdfsgi2 (because of disagreements with the FORTRAN compiler), so I'm not complaining too loudly.
Currently, the LesHouches module has no HEPG bank, and so no event information,
in the first logical event of its output file. The first event from ZGRAD
(or any other input code to LesHouches) is sent to the second logical event
of the output file, and the last event from ZGRAD is discarded.
PYTHIA sometimes rejects ZGRAD events. In one sample 23 of 209,757 events were
rejected. Since you have to tell the LesHouches module specifically how many
events to process, rejection of events by PYTHIA will mean that you may run
out of events in your ZGRAD text file. If this happens, you will get a warning
"ERROR: Unexpected End of File." for each missing event, and should discard
the last events from the PYTHIA output.
In three body ZGRAD events the Z always has a pt kick from the photon,
as if the radiation was always initial state. I need to ask Uli about that.
zgrad.32603 just annotates the validation input file, no substantive changes.
LesGenType set "User"
and LesDatFile set to your event file from ZGRAD. LesPSModel can be set to
PYTHIA or HERWIG. LesHouchesModule seems not to detect the end of the event
file, so you'll have to specify how many events to process (which, as warned
above, should be the same as the number of unweighted events ZGRAD has output).
Caveats, Known Problems, and Features Not Yet Implemented
For now, the unweighted event generation is controlled only by the NCALL1 and
NCALL2 specified for that phase. Toward the bottom of the input card we see
lines like:
2 !number of unweighted events
0 ! autoset NCALL1 and NCALL2 for event generation? (1 yes, 0 no)
0 ! require exactly the number of events requested? (1 yes, 0 no)
300000 !NCALL1 for event generation runs
30000000 !NCALL2 for event generation runs
For now, the autoset functionality isn't working, nor is requiring exactly
the number of events requested. So both of these should be left at "0" and
the number of unweighted events requested is immaterial. I'd hoped to allow
you to request a certain number of unweighted events, allow NCALL1 and NCALL2
to be set automatically to try to get that number of events, and then make
additional passes if you want exactly the number you've requested. But, I
never got all of the details working.
Version History
zgrad.32403 was the first version made publicly available.
Adam Gibson
Last
modified: Wed Mar 26 10:28 PST 2003