Writing a sort code

Creating and editing a sort code

Your first move in creating a new sort code will be to set the trigger section to a value appropriate for the experiment you are analysing. For Eurogam format data (that is Megha or Demon format) you should then initialise the adc map.

Sort code sections

Comment section

Everything up to the first line in the file that starts *trigger is ignored and so may be used to place a comment at the top of the sort code.

Trigger section

On the line after a line reading *trigger, there should be a number which indicates the number of the highest ADC channel (signal) in use in this experiment. If in doubt overestimate. For most formats and most experiments a value of 128 will suffice, but for Megha format a value of 768 should be used.

One dimensional spectrum list

After the line reading *oned there should be a list of one dimensional spectra. Each line in this section should be either a simple spectrum definition of the form

	number name size
      

or a group definition in either of these forms

	number..number nameandnumber size
	number..number,step nameandnumber size
      

Examples of simple definitions are:

	56  multiplicity   17
	365 etot         4096
	515 erel1-3      1024
      

Examples of group definitions are:

	41..44	 spec5 	 128
	61..67,2 siga1	4096
	62..68,2 sigb1	4096
      

which are equivalent to the following simple definitions:

	41	spec5	 128
	42	spec6	 128
	43	spec7	 128
	44	spec8	 128
	61	siga1	4096
	62	sigb1	4096
	63	siga2	4096
	64	sigb2	4096
	65	siga3	4096
	66	sigb3	4096
	67	siga4	4096
	68	sigb4	4096
      

Note that spectrum names are limited to 12 characters and that there is a limit to the highest spectrum number that can be used (800 at the time of writing).

Comments can be placed in this section. On any line in this section anything after a hash (#) is ignored. Also blank lines are ignored. This allows you to do things like:

	# Raw spectra
	1..128     adc1 4096
	# E and P plots
	129..159,2 e1   4096
	130..160,2 p1   4096
	# Miscellaneous
	161        esum  512      # e1 + e2
	162        prec  512      # momentum of recoil
	163        erec  512      # energy of recoil
	164        etot  512      # no prizes for guessing
      

Two dimensional spectrum list

After the line reading *twod there should be a list of two dimensional spectra. This section has the same format as the one dimensional spectrum section. The size parameter for 2d spectra refers to the size in both the X and Y direction, that is, all 2d spectra are square.

Note that the limit on the number of 2d spectra is lower than the limit on the number of oned spectra (400 at the time of writing), and also note that 2d spectra are very memory hungry. You should normally use 2d spectra no bigger than 128x128 which use 64kB each. 256x256 spectra should be used sparingly, they are 256kB each. The limit on the size of the 2d spectra has been set at 512x512 which use 1MB each. If the total memory use of the program exceeds the amount of real memory the computer it's running on has (real memory not virtual memory) then performance will be affected. In practice, serious performance problems could start 10-20MB before this limit. Even away from this limit, the more memory the spectra use, the slower the sort code will run (due to processor caching effects). You can find out how much real memory your computer has by typing:

	grep mem /var/adm/messages*
      

or by running the program top.

If a 2d spectrum name begins with the letter w then it is deemed to be a window. Accidentally starting the name of an ordinary 2d spectrum with a w could cause problems.

Variables list

After the line reading *vars there should be a list of variables. The format is the same as for the one dimensional spectrum list except that the size parameter is replaced by a floating point number giving the default value of that variable.

At the time of writing there is a limit of 500 variables.

Sort code

After the line reading *sort comes the actual sort code. Everything from here to the end of the file is passed to the appropriate compiler as is. This section is described in more detail on a separate page.

Example codes

Global variables and library routines

Compiling a sort code

Makesort command

      makesort sort_code_filename [options]
    

debug

This option compiles the sort code with the -g option enabling debuggers to be used on it. The resultant code runs considerably more slowly.

check

This option tells makesort not to compile the code, but instead to run ftnchek (FORTRAN codes) or lint (C code) to try and find some errors. Note that this option only works well on simple sort codes where the entire code is in one file.

-o sortname

This alters the name of the sort program. Makesort will output the compile code into a file called sortname and put the spectra and variable lists into sortname.spec. The default name is sunsort_proc.

-xC

This option informs makesort that the sort code is written in C, the default is FORTRAN.

-xS spec_file

This option tells makesort that the *oned, *twod and *vars sections are in a separate file. The main sort code should only contain comment, trigger and *sort sections.

Other options

Any options that aren't recognised are stuck on the end of the compiler command line.