![]() |
![]() |
------------------- Most error messages are written on output unit LUNERR (usually 15), interspersed with lines giving the number of random number generator calls identical to those printed on standard output. (This file has generally extension .err). Each error message begins with the name of the routine in which it is originated. Some messages, however (especially if fatal) are printed on standard output. Many error messages (often somewhat cryptic) are printed only for debugging or information purposes and should be of concern to the user unless there is a large number of them: for instance when one of the hadronic event generators fails to conserve some quantity within the strict limits imposed. Examples: Eventq: charge/baryon conservation failure with Nucrin 5 4 11 10 Eventv: ekin+am < pla,ij,igreyt 4.93747684 4.94905223 14 1 The following type of message is also not important, and is especially frequent in runs with photonuclear reactions activated: *** Umfnst: eexany,eexdel,eexmin,amepar,enenew,np,ikpmx,eexnew,eexmax 0. 0.002 0.004319 1.11498839 1.09082268 2 0 0. 0.0171591096 Another type of informative message, indicating that a step counter has been reset because it was approaching the upper limit for an integer, is the following: *** Emfgeo: Ncoun 2000000000 Generally, messages issued by the geometry routines are more important. However, fatal ones are written to standard output, for instance: EXIT BEING CALLED FROM G1, NEXT REGION NOT FOUND In such cases, it is recommended to run the geometry debugger (see command GEOEND) to find and correct the error. The following one indicates a real problem if repeated more than a few times: GEOFAR, TXYZ: 1. -0.0721463599 -0.409276348 -0.909553612 Nfrom, Nreg, X, Y, Z 1001 3 -0.108787724 -1.26878781 8.78769155 Geofar: Particle in region 3 (cell # 0) in position 1.000000000E+00 0.000000000E+00 1.000000000E+00 is now causing trouble, requesting a step of 6.258867675E-07 cm to direction -2.285059979E-01 -9.412338141E-01 2.487245789E-01, error count: 0 [...skipped...] Particle index 3 total energy 5.189748600E-04 GeV Nsurf 0 We succeeded in saving the particle: current region is n. 2 (cell # 0) As it can be seen, the program has some difficulty to track a particle in a certain direction, and it tries to fix the problem by "nudging" the particle by a small amount, in case the problem is due to a rounding error near a boundary. If the message appears often, it is recommended to run the geometry debugger centering around the position reported in order to find if there is an error in the geometry description. Other geometry errors concern particles with direction cosines not properly normalised. This happens often with user routines where the user has forgotten to check that the sum of the squares be = 1.0D0 IN DOUBLE PRECISION. For instance, the following message is generally caused by an inaccurate MAGFLD user routine: MAGNEW, TXYZ: ...[sum of the squares]... U,V,V: ...[3 cosines]... A similar message may be issued by the tracking routine GEOFAR: GEOFAR, TXYZ: ...[sum of the squares]... U,V,V: ...[3 cosines]... Nfrom, Nreg, X, Y, Z' ...[calling code, region number, particle position]... Another geometry error message is the following: **************************************** GEOMETRY SEARCH ARRAY FULL **************************************** This message indicates that insufficient memory has been allocated for the "contiguity list" (list of zones contiguous to each zone). This is not an actual error, but it is suggested that the user could optimise computer time by increasing the values of the NAZ variable in the geometry region specifications. ========================================================================