The file, detector.pilot, contains input information for grisudet.c. A line with no asterisk is a comment line. The comments in the file make it self-explanatory (hopefully). Should you wish to use a pilot file with a different name, just place the filename on the cherenkf command line; the default for no command-line filename is detector.pilot.

New records in the following pilot file specify the vbf output parameters. A full description of the revised SOURC record is at the end of this file.

                   --- GRISUDET SIMULATION PILOT ---
January 2007

This file is used to specify the i/o files and operating conditions for the
 grisudet code contained within the GrISU simulation package.
Any line not starting with a '*' is a comment.

A 5-character flag preceeds input data with only one such flag per line


-If the log-book file name is not provided, a log-book file will not be
 produced. Conditions specified before specification of a logbook will
not appear in the log book.
-If the array configuration file name is not provided, the program will
stop. If more than one of each are provided, 
only the last instance of each will be used.

LOGBK: The log-book file name.
ARRAY: The telescope array configuration file, in Config/Files
CHERP: A Cherenkov Photon file; default- standard input
OUTPU: The output file name; There is no default, you may
       use stdout as the output file name for standard output
OPTIC: When this record is used, the electronics response is not
       simulated and individual photon information is written to the specified
       file.  Used to test the optics model and produce point-spread functions.
KUMAC: The file specified by this command will be a kumac procedure which
       generates a graphical description of the array configuration.
PEOUT: Output dump of individual pe's, no electronics

 ARRAY  ./Config/Files/whipple_sgarface.cfg
* ARRAY  ./Config/Files/veritas2tel.cfg
default for CHERP (if no asterisk) is now "standard input"
*  CHERP  ./Data/MCPhotons/photon.cph
*  OUTPU  ./Data/Raw/photon.rec
*  LOGBK  ./Dump/grisudet.log
   OPTIC  ./Data/TestOptics/star.opt
  KUMAC   ./Dump/photon.kumac
   PEOUT  ./Dump/pe.out

 filename for list of thrown energies (in TeV); default no file
* ENOUT  ./Data/Raw/photon.eng

--------- vbf file specifications ------------------
VBFOF <vbf output file>, default: no vbf output file
* VBFOF  ./Data/Raw/photon.vbf

You may choose to include the pedestals in the output vbf file or
in a separate file specified in the VBFPF record.
VBFPF <output file>, default: include peds in vbf output file.
* VBFPF filename

You must set the start time for the events written to the vbf file
VBFST <string1> <string2> <string3> in format as shown in the next line
* VBFST 2006-11-28   02:00:00.000000000   GPS 

vbf eventtime parameters
meandatarate(Hz) = mean data rate for the showers written to the vbf file
vbf_ped_flag     = 0, no pedestals sent to vbf files
ped_time_interval(sec), integer time interval(sec) between pedestal files,
VBFTM <meandatarate(Hz)> <vbf_ped_flag> <ped_time_interval(sec)>
* VBFTM 2.0 1 1

simulator    = name of simulator
vbfrunnumber = vbf run number for vbf file
observatory_height_meters = observatory height above sea level
if observatory_height_meters < 0.0, then use observatory height
from cherenkov "H" line (new in this release). You can thus use
cherenkov files that do not have the "H" line.
VBFPR <simulator> <vbfrunnumber> <observatory_height_meters>
* VBFPR duke 400 -1.0


Number of Cherenkov events (NBREV) to be simulated (0 implies no
limitation) and number of times to cycle through (normally 1) a given
Unless you are familar with the details of the code, you should always
cycle through only 1 time!!!!! Additional cycles only use those photons
that struck the telescope during the first cycle!!!!!
* NBREV 0 1

random number seed: negative integer
* RANDM -82966

Number of QADCpedestal records followed by the number of FADC pedestal

For accurate determination of peds/pedvars with the FADC option, use a
large noise-loop size, like 2000 or more, up to 6000 maximum
(see the SIMUL record in the configuration file) and either a large
number of samples in the pedestal event records (see the FADCS
record in the configuration file) or a large number of pedestal records
(with the NBRPR record). Multiple FADC pedestalrecords are now
independent of each other, subject to the constraint of a finite
sized noise loop.  You may create pedestal files from analysis.c
to test the accuracy of the pedvars. 

For the QADC option, use a large noise-loop size as described above. Create
a large number of pedestal events, e.g. 400, in the NBRPR record. In this
GrISU release, the maximum noise-loop size is 6000 time bins. Simarily, you
may create pedestal files for the QADC option from analysis.c. 

* NBRPR  0 1

Source characteristics(SOURC): x and y coordinates of the source in the field
of view followed by the source extention radius (all in degrees). The fourth
parameter is the latitude of the observatory in degrees. If the latitude is
set to 90 degrees the source position is given in camera corrdinates. If the
latitude is less than 90 degrees, the source position in x corresponds to an
offset in the east west direction while the y position corresponds to north
wobble North: SOURC 0.0 0.5 0.0 31.675 
wobble East : SOURC 0.5 0.0 0.0 31.675
* SOURC 0.0 0.5 0.0 90.0

Noise characteristics (NOISE): Declination and right ascention (in
degrees) of the starfield to be used for the noise estimates (Not yet
implemented) followed by the diffuse noise component in photoelectrons
per nanosecondes per square metters and per steradian.
 NOISE 0.0 0.0 0.0
* NOISE 0.0 0.0 420.0

If NUMPE is 1, output records of type N (giving number of photoelectrons
in each pixel, are produced.
if FRECP is 1, an F record will follow every R record (digital count
samples). The format of the F record is:
event_nbr,  number of telescope,  number of photoelectrons,  and fadc hi/lo_flag,
followed by fadc input in millivolts for each fadc time bin.
F records are useful in investigating the pmt pulse shape.
If NOPIX is 1, no pixel output records are printed; only S and T records
are printed. Default is 0 where pixel records are printed.

Set * USEOC 1 if you wish to use .cph files created from earlier versions
of cherenkov (before 3.0.0). Then, you may use .cph files that start
telescope numbering from 0 rather than 1 (as is the case in version 3.0.0). 
The default is 0 if the asterisk is not present.

 grid flag for facet/pixel grid search:
  GRIDF flag for facets;  GRIDP flag for pixels
    0, no grid, full facet/pixel loop as in earlier versions.
    1, make grid and use grid in facet/pixel search
    2, (for testing) made grid and write to grid file. filenames:
       facetgrid.out and pixelgridlout
    number of bins in the x and y directions for the facet/pixel
    grid search.
GRIDF/P <gridflag> <nbinsx> <nbinsy>
* GRIDF 2 15 15
* GRIDP 2 19 19


The revised SOURC record can be confusing so here's the full story.  The two wobble directions (x and y) are with respect to the following sky coordinate system:  let P denote Polaris on the celestial sphere and S represent to source location on the sphere.  Let S->P represent the arc of the great circle from S to P. Then the coordinate system has its origin at S with the y axis tangent to the S->P arc at S. The x axis is perpendicular to this y axis, along the sphere, and in a direction such that the z axis points away from the sphere for a right-handed system.  The y-axis is "wobble North" and the x-axis is "wobble East".  For a given wobble North, wobble East, and latitude, the code offsets the telescopes from the source (by "wobble North" and "wobble East") and finds the new azimuth and elevation of the telescopes. Conversly, the source appears to move in the opposite direction on the camera. The code adds the appropriate angular offsets to the incoming photons since the telescope has moved relative to the source. 

Given the above new location of the telescope, the simulation code actually keeps the telescope fixed and then moves the source in the opposite direction. These directions on the sky are used in the code output, such as for the azimuth and elevation values of the source and the telescope in the vbf output. We'll fix this in the next release. We don't expect a noticable difference since simulated showers differing by e.g. 0.5 degrees should not show noticable differencies, except possibly at large zenith angles.