The geometry of the detector is configurable via data cards documented under the geometry cards page. The available magnetic field maps are currently limited. They are listed in the status page. None are tuned for the smaller octogon, and the H-magnet field map (105) at this time (1996.11.12) has two "features": (1) the vertical gaps were not large enough, so the flux tends to jump the gap and cancel instead of remaining vertical, (2) the symmetry for the four quandrants is wrong such that the left half has the direction reversed.
The flux files generated by Lynn Miller and Stu Mufson handle the difference in the spectrum and distribution of neutrinos seen by the near and far detectors. These files are available at Fermilab. Users much set the MFLX card to 1 to access this method. They must also use MKIN 2 and set the ZREF, FREF, FFLX cards. These are documented on the non-geometry cards page.
R. Hatcher -- 1996.11.12
A1: Are the lines in your data file longer than 80 columns? The processor truncates after 80 columns.
R. Hatcher -- 1996.11.12
A2: One common problem is to accidentally overwrite things you've previously set. This mistake is further elaborated on at the beginning of the geometry cards page.
R. Hatcher -- 1996.11.12
A3: Does your problem involve attempting to set a geometry parameter using RVOL or IVOL cards? Is the volume specified using a "*" as an instance type? For example, you might wonder why the thickness of a B2PL plane is still 2cm after issuing the following cards:
RVOL 'B*PL'
RTAG 'THIC'
RVAL 4.0
The reason is that the default
instance is just that, a default, not a wildcard.
It takes effect only if the
database contains no reference to a B2PL plane's thickness;
it is sort of a value of last resort.
Because the B2PL plane is explicitly defined,
the lookup never falls
through to the B*PL entry and your change is never seen.
At some point I will enhance the code so that using the "?" character matches all instances in the database at the time that each card is parsed and modifies all the instances. This does not yet exist.
R. Hatcher -- 1996.11.12
iswit, ievent, ieotri, nrndm, nevent, ... itest
A:
These variables are found in the standard geant gcflag.inc
file. On some installations the types for these variables
are defined in the gcflag.inc itself, but on most these
are in a separate file gtflag.inc. GEANT is very
inconsistent about when types are in separate files (some includes
have them some don't). For the standard MINOS code efforts were
made to include the type declarations as necessary. To turn on
this option the user must
setenv GTINCS -DGTINCS ! HP-UX,IRIX,SUNOS,OSF1
setenv GTINCS -WF,-DGTINCS ! AIX
R. Hatcher -- 1996.11.12
#include "geant321/gckmax.inc"
By explicitly giving geant321 as a partial path
the maintainers broke our conventions for dealing with include files.
Users who wish to use the new libraries (and include files) must then ensure that the include files themselves reside in a directory labelled geant321. The user then must set both the following env variables:
setenv GEANTINCS path/geant321
setenv GEANTINCSAUX path
where path is the directory above the geant321
that holds the include files. This is done automatically at
Fermilab in the
/afs/fnal.gov/files/code/e875/sim/labyrinth/labyrinth.setup
script.
R. Hatcher -- 1996.11.12
!!!!!!!!!!!!!! W A R N I N G !!!!!!!!!!!!!
The internal data structures have been changed.
Please recompile the CDF which contains the
'Menu' definition '/XXXXX'
using the KUIPC compiler version 950303.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
A:
This means that the version of KUIP (which handles the menus and
parses the interactive command inputs) that was linked into the
program is incompatible with the data structures (normally C
code) that defined the menus.
If the program is geant (gminos_inter) then the problem is that the latest gxint.o is only compatible with CERNLIB v96a or later. You must either step back a version of GEANT or move forward a version of CERNLIB.
If the program is one of the ADAMO tools mad,
ti, tip, then it was linked with CERNLIB v96a.
As of Nov 15, 1997 the ADAMO release:
ftp:ptsun00.cern.ch/pub/adamo/install/adamo3x3.car.Z
now supports the new KUIP internal structures (and no longer
the old versions).
R. Hatcher -- 1996.11.12, 1997.11.15
ld: 0711-224 WARNING: Duplicate symbol: decomp_
A:
This message is generated because the tauola package
(used by neugen) incorporates a common block named
/DECOMP/, while a routine (unused by MINOS) in
the mathlib cernlib library shares the same name. For some
reason the AIX linker attempts to pick the routine up out
of the library at the same time it is allocating space for
the common. This appears not to cause problems.
R. Hatcher -- 1996.11.12
ld: 0711-224 WARNING: Duplicate symbol: signgam
ld: 0711-341 WARNING: Replaced XTY_CM symbol signgam requires an
alignment more strict than the alignment of the symbol that replaces it.
A:
This message seems to involve two, apparently harmless, problems.
The first, like decomp_ above, appears to be a naming
conflict. These appear to be system libraries:
??/src/bos/usr/ccs/lib/libm/lgamma.c(/usr/lib/libm.a[lgamma.o])
_qgamma.f(/usr/lib/libm.a[_qgamma.o])
The second part about XTY_CM is IBM's obscure way of saying that the two linkages to signgam had different requirements on how the object was to be aligned in memory (word, longword, quadword boundary). The linker does the right thing and takes the conservative approach so that one doesn't get an access violation.
R. Hatcher -- 1996.11.12
R. Hatcher -- 1996.11.12