FAQ: Why has my N-tuple got too many entries?

• You have two NTPR banks with the same number (check ntuple.dat). It is not sufficient to disable one version.
• All the banks you are using in the NTPR do not lie on a single path in the data structure.

FAQ: Why must I use PAW to look at SNOMAN Output?

• Process an n-tuple without PAW
• Look at the Data Structure output

FAQ: Can I change the order in which processors get called?

FAQ: With the Monte Carlo, can I generate a variable number of particles?

FAQ: Is SNOlib really a library?

SNOlib is structured into about 40 SUs (Software Units) that form a simple dependency tree with lower SUs providing services to upper ones. In order that SNOlib remains flexible, so that it can grow and develop to meet the demands placed on it throughout the SNO experiment, it is essential that these SUs remain as loosely coupled as possible. In particular, the way SUs initialise, and reinitialise after titles update, is hidden from other SUs. This is done with a special control system that allows SUs to declare dependencies on other SUs and titles banks at execution time, rather than hardwiring them at compile time. Although this is far more flexible, the control system has to be able to call every SU, as it does not know, until execution time, what SUs will be active. It is this system that pulls in all the code when linking. This normally means that the executable program has dead code. For ways to remove this dead code and a more detailed discussion of SUs see chapter "Adding Code to SNOMAN" of the User Manual.

FAQ: Which version of SNOMAN do I want?

If you want the known bugs in this version fixed, also get the "post-release" directory from surf. This directory contains all the bugs that could be fixed in this version. "Could be fixed" is the rub. Some bugs, but only a few, require significant change to some part of the data structure or some other key part of Snoman. To get these bugs fixed you will have to wait for the next version. This happens rarely. The post-release directory contains .inc, .for, and .dat files. Put those files into the code or prod directory (as appropriate) and rebuild Snoman. Note that since the tar file never changes after freezing, you can keep Snoman up to date without re-downloading the .tar.gz file. Be warned though, this procedure builds a Post-Release version. It is not a good idea to use it for long production runs as it does not represent an official version of the code.

If you need the latest released version, you can get the Development Release Oxford puts this out so the entire group can write code for the next release. The purpose of this release is mostly for development, as the name suggests. If 3_01 is the current release and you want to write some code for the next release, you should almost certainly use the development release of 3_02. Oxford does not guarantee that a development release will work on all platforms.

If you want something more recent than that you could look to see if there is Update File in the standard tar directory.

FAQ: What does PCK: event too complex for packer mean?

FAQ: How can I turn off all absorption and scattering in SNOMAN?

FAQ: How are bug fixes propagated?

FAQ: How do I get the latest SNOMAN?

Applying an Update to the Last Development Release

1. If you have not already none so, get the latest Development Release.
2. Apply the latest Update File If that does not look recent enough mail n.west1@physics.oxford.ac.uk to make a new one.

Installing from Another Site

1. Create an rhost*.scr file. There are a number of these already on the $SNO_TOOLS directory e.g. rhost_surf_snoman.scr. Simply copy one of these and then edit the fields you need to change.
2. Execute the rhost*.scr in the parent shell e.g.:- source rhost_surf_snoman_dev_stable.scr
3. Execute the upgrade_snoman tool i.e.:- $SNO_TOOLS/upgrade_snoman.scr When it asks, you must say that there is no tar file. This means, of course, that the tool pulls a complete version, a file at a time, so can be rather slow.

FAQ: How are ZEBRA bank numbers chosen, and what values are valid?

• Creating a bank (MZBOOK,MZLIFT):-

  ZEBRA applies rules in the following order:-

  1. If bank is inserted into a chain, use IDN+1 of the following bank, or if that is missing used IDN+1 of previous bank.
  2. If bank is connected as vertical link -n, set IDN = +n
  3. IDN = 1
• Input via Titles bank (TZINIT):-

  Use the bank number on the *DO if supplied, otherwise apply bank creation rules.

FAQ: Why do I get two time peaks when plotting MC data with centred source?

Although there is a fixed relationship between the event generation time (word MC_JDY in the MC bank) and the time in the MCPM bank, there is NO fixed relationship to the time held in the PMT bank. Those times are relative to trigger times. The trigger depends on exactly when the summed signal rises above threshold, which is dependent on the statistical processes of photoeletron emission and collection and PMT noise. The trigger is latched to a 20nsec clock and so can have a 20nsec jitter. Consequently raw PMT times will display this jitter. The solution is to use TIME_DIFFERENCE - Time difference DQF and calculate the time difference between the time in the PMT bank and the MC bank.

FAQ: What does "ZFATAM. !!!!! Going to ZFATAL for TZINIT fails." mean?

If you see something like this:-

If you see something like:-

FAQ: Why doesn't the Monte Carlo data structure have electron and gamma tracks?

FAQ: How do I run the uncalibrator?

test_ucl_mconly.cmd just uses the MC times and charges directly. This is the simplest and most robust approach. The processor list is:-

test_ucl_cal.cmd uncalibrates and then calibrates the MC times and charges in a single pass. The processor list is:-

test_ucl_zdab.cmd uncalibrates the MC times and charges and then generates a zdab file. test_zdab_cal.cmd reads in and calibrates this zdab file. The processor lists are:-

These command files should be tested and understood before trying to use the uncalibrator for any analysis. The limitations of the uncalibrator are discussed below.

First, here are some general comments on other command file settings:-

• $intial_date
  This should be set to a date when there are both valid ECA and PCA constants otherwise the calibrator and uncalibrator will not work. For example:- $initial_date 20000101 12000000
• $use_ref_cal_consts
  In principle this command could be used to do a UCL and CAL for any date. I suspect that in practice there are not reference versions of all the banks needed for the MC.
• $old_eca and titles cal_const1_mc.dat
  No Need! You are free to use ancient versions of the ECA if you like but more up to date versions should work just as well - if not better. If you do use old ECA constants then make sure you use old PCA ones as well:- set bank tcal 1 word 10 to 1 set bank tcal 1 word 11 to 1
• $calibration_mode ?? a.k.a. set bank TCAL 1 word 4 to ??
  This only affects the calibration of the times and charges and not their uncalibration. The reason is simple. The MC always produces times in ns and charges in pe, it is not capable of anything else. The output of the uncalibrator is always ADC counts because the output is used to fill zdabs. The uncalibrator therefore always uncalibrates in mode 44 regardless of the setting of the calibration mode. The calibrator then calibrates the raw ADC counts produced by the uncalibrator to the extent specified by the calibration mode (??).
• set bank TCAL 1 word 2 to ?
  Word 2 of the TCAL bank has nothing to do with uncalibration. This word specifies whether the times used by the trigger simulation (t_wobble_walk) are walked or not. The time in the PMT bank is filled with t_wobble_only, correctly leaving the addition of the walk to the uncalibrator.

Sadly the uncalibrator is not trouble free. There are two problems:-

The most serious problem with the uncalibrator is that the MC doesn't produce a time spectrum that looks like the calibrated time spectrum of real data, it therefore has trouble doing the calibration backwards. The real spanner in the works is provided by the ECA. The eca time calibration maps between ADC counts, in the range 0-4095, and time in ns, in the range x-y. When uncalibrating, if the time (after the PCA uncalibration) is not in the range x-y it cannot be mapped to an ADC value. In this way the MC times get truncated at one end.

Another problem is the lack of a place in the zdab structure to indicate that the uncalibrator could not uncalibrate a charge or time due to the lack of calibration constants or that it was outside the range x-y. Currently if the uncalibrator fails due to a lack of calibration constants then it produces -9999 for the charge or time, this is then converted to 0 because all the output must be in the range 0-4095 if it is to be stored in the zdab. To first order this is not a problem, events happen on a particular dates and times and so if there are no constants to uncalibrate with then there will be no constants to calibrate with and the attempt to calibrate 0 ADC counts will mostly result in -9999. There are some catches though. Firstly if the user looks at the raw ADC count spectrum it contains a surprising number of zeros. Secondly if the uncalibrator failed due to the lack of PCA constants and the user only requests an ECA calibration then they will get the ECA calibration for zero ADC counts rather than -9999. A third, but rather unlikely, problem could occur. The ECA time calibration can produce calibrated times for some ADC ranges but not others. If 0 ADC counts does have a calibrated time but the uncalibration of the MC time failed then this will result in a spurious time for that PMT.

Fixes to these problems are, not doubt, possible and volunteers are welcome.

FAQ: Why is Database backward compatibilty so important?

1. The same information is now scattered over multiple banks.

2. If the new code is to be able to process old data, either it has to be able to load multiple banks or the old database data has to be reformatted into new banks.

1. Stick to a simple format of two parts:-
   1. A fixed length header. It should have some spare slots for future use. If a list follows record:-
      1. The start address of the list
      2. The length of a row
      3. The number of rows

   2. A list consisting of a fixed length row none or more times. The row should have some spare slots for future use.

2. Make changes only by adding new data, never by redefining existing entries.

FAQ: What is the difference between the Px banks and the PMT?

  update_px_from_pmt:  Create/Update Px banks from PMT bank chain
  update_pmt_pf:       Update PF word of PMT bank chain.

One of my good intentions that never materialised was going to be to rewrite all the code that used the "long skinny" to use the "short fat" and erased all evidence of the former.

Basically, it's best to pretend the "long skinny" form doesn't exist.