The issue pointed out by hiro is indeed a problem, so quite a while back I
started to remedy this by
getting rid of hard-wired numbers for individual detectors, and reduce the
problem for each detector or
component defined to have a starting rotmatrix number defined in urotm.inc
e.g.
integer rotm_inel_base
parameter (rotm_inel_base = 70)
and then in the code where it is used ONLY access rotation matrices via
symbolic counting
ie. call gsrotm(rotm_inel_base+1,....)
and use as call gspos('MODU',1,...,rotm_inel_base+1,'ONLY')
as example.
This way one only has to look into urotm.inc to check block allocations.
Please note that one should
try to keep the base numbers as low as possible since the allocation via
zebra reserve space from 0 - highest rotations number defined.
This mechanism is NOT implemented for all detectors so one can run into the
problems given by Hiro.
------------------------------------------------------
Flemming Videbaek
Physics Department
Brookhaven National Laboratory
tlf: 631-344-4106
fax 631-344-1334
e-mail: videbaek@bnl.gov
> Rotation matrix numbers for inelastic counters have been changed
> since I get the warning when I try to use it. (I did not notice this when
> I put those couters in brag.) In anycase, it is fixed. It is very hard
> to tell which rotain matrix number is unused from the code. I guess only
> way to tell is to run brag and check it by protm command.
>
> Hiro
>
This archive was generated by hypermail 2b30 : Fri Sep 13 2002 - 12:11:17 EDT