Customising the user environment

To create an environment to generate the type of events wanted, in the detector wanted, the default files need to be modified. The event-generator needs to be chosen, and the analysis of the seen events must be done. Histograms should be filled, and a specific detector should be described. To do this, one needs to make changes to a few selected routines, all collected in the user program, and to a few input-files.

Step 1 :

Create Your user program.

Modify your private program to Your needs. The example sgvuser.F95 contains the subroutines that You must decide how they should look. So, now edit Your user program, adding functionality following the instructions in chapter 4 .

For routines that You WANT to change, just fill in the code in the right place. Of course, You must NOT change the routine name nor the parameter list. Then find the line “#if (defined(DEFAULT))” at the beginning of the routine, and remove it. Then also remove the matching “#endif” after the END statement of the program-unit (subroutine or function). The modified routine will now be included in the executable program, instead of the default version on the SGV libraries.

One can tidy up the user program once the selections are done: If a routine in the sample file already does what You want it to, You can just delete it from the file, because that code is in the SGV libraries. Eg. if You find that it is OK that all tracks in the acceptance of the detector are also seen (ie. no additional inefficiencies are considered), You can delete the entire routine ZDEFFI from the program.

For modifications to the event-generator interface, please refer to chapter 4.1.7

Step 2 :

Create the executable program.

Just as in step 1 in chapter 3.2 .

Step 3 :

Do the assignments of input and output files.

Just as in step 2 in chapter 3.2 .

Step 4 :

Modify or create input files.

Steering file (unit 17, default name sgv.steer)

This is the file You will be modifying repeatedly, to change number of events generated, beam-energy, process generated etc. The example files, reproduced in appendix A shows all the steerings defined in for each the event-generators that SGV is shipped with, and their default values.

Note that You can add Your own steerings by following the examples in sgvuser.F95.

Geometry description file(s) (unit 51, default name sgv_geo.inp)

The example geometry files represents the DELPHI detector at LEP and the proposed ILD detector, see appendix B . Refer to chapter 6 bellow how to interpret and modify this file for Your needs. We suggest You initially do not modify it, only to do so once all other aspects of the program (event-generator, analysis code,...) has been found to work correctly.

It is possible to have more than one detector description in a single run, which is useful for detector development, since it gives the possibility to compare detector designs event by event (or even track by track). In this case, use unit 52 and 53 for the second and third geometries.

root-file (unit 99, default name sgv.root)

In appendix C an example of a macro to create an empty root file is given. Modify this file to make whatever histograms You need, and then execute the same way as in step 3 in chapter 3.2 .

The histograms are filled in the user-code, like this.

     CALL Rfill(1d1(1),varib1,1.0)
     CALL Rfill(id1(2),varib2,1.0)

to fill histogram the first 1D histogram with the value of 'varib1', the scond with that of 'varib2'.

NOTE for ntuple-users : The same method works if You want to use row-wise n-tuples. It does, however, NOT work with column-wise ntuples. If You want to use these, You must create them yourself within SGV. The root-file will still be opened and closed correctly by SGV (assuming the standard logical name/soft-link is used to point to it), so it is only the creation of the structure of the ntuple You must take care of. A good place to do this in is ZAUINI. You must also set the steering card CWN to TRUE in the steering-file.

Be warned, however, that both types of n-tuples produces disk I/O during the execution of the program. Histograms, on the other hand, are memory-resident, and I/O occurs only at the end-of-run. Because SGV is a fast program, such excessive disk I/O might seriously compromise the real-time performance (ie. Your computer might be doing only I/O, and no thinking...). This problem will be worse, the faster the CPU is, and, since CPU:s gets faster and faster every year, while I/O speed doesn't develop much, worse next year than this year ...

It is also possible to choose to have no root file at all connected, by setting the steering-card USE_HISTOS to false. The opening and closing of the root files normaly done by SGV will then be bypassed.

Other files

Of course, You can make Your own assignments as well, by simply editing your copy of sgvass.sh, doing any modification You might need.