Writing BEAMnrc phase space files

We have officially broken a phase space file from BEAMnrc into smaller files which can be successfully fed into DOSEXYZ or VMC++.  The file is made up of a simple header and then a list of particle data.  The header follows this format (from http://irs.inms.nrc.ca/software/beamnrc/documentation/pirs0509/node68.html):

MODE_RW 

The file mode: it can be either 'MODE0' or 'MODE2' depending on whether ZLAST is included in the phase-space parameters. 

NPPHSP 

The total number of particles in the file. 

NPHOTPHSP 

The total number of photons in the file. 

EKMAXPHSP 

The maximum kinetic energy of the particles stored in the file. 

EKMINPHSPE 

The minimum electron kinetic energy (MeV). 

NINCPHSP 

The number of particles incident from the original (non-phase space) source used to generate the phase space file.

Then, after the header, each particle is listed using this format:

LATCH, E, X, Y, U, V, WT, (ZLAST) 

It is noted that E "is set negative if this is the first particle scored from a new primary (ie from a non-phase space source) history."  The documentation goes on:

We set E negative for the first particle scored by each new primary (non-phase space) history in order to be able to group scored quantities (energy deposited, fluence, etc) according to primary history when a phase space file is used as a source. This is necessary to account for correlations between incident particles and ensures a correct estimate of the uncertainty on the scored quantities [17]. The negative E marker is propagated to phase space files generated using a phase space source, so that, even in these second-generation files, particles can be grouped according to the original primary histories. When a negative E is read from a phase space source, the primary history counter is incremented and the particle's energy is set to |E|.

If you are using an old phase space file without negative E markers as a source, scored quantities will be grouped according to incident particle instead of primary history. BEAMnrc will output a warning that uncertainties may be underestimated because correlations between incident particles cannot be accounted for. However, we have shown that in most cases the underestimates in uncertainty caused by not taking correlations into account are not significant [17]

So the key to breaking a larger phase space into smaller phase spaces which won't crash vmc++ is ensuring that the first particle's energy is accompanied by a negative sign.  Done. 

swig: java to c++

So, I found myself trying to import a c++ library into Java using SWIG, which now broadly supports the conversion:

http://www.swig.org/tutorial.html

http://www.dabeaz.com/cgi-bin/wiki.pl?SwigFaqTutorialJavaSharedLibraryExampleOnLinux

http://www.swig.org/Doc2.0/SWIGPlus.html#SWIGPlus_nn2

My inputfile was just the headers of my c++ program (listed twice, as explained in http://mathiasirwans.blogspot.com/2007/11/experience-with-swig-cc-java.html).  In the end, I used this bash script to run the whole process (and it was completely successful):


#!/bin/sh

swigFileStem='input'
swigFileExt='swg'
javaLibrary='/usr/lib/jvm/java-6-sun-1.6.0.21'

swig -java -package com.what.ever -c++ ${swigFileStem}.${swigFileExt}
gcc -fpic -c VEGA_Classes.cpp ${swigFileStem}_wrap.cxx -I${javaLibrary}/include -I${javaLibrary}/include/linux
gcc -shared VEGA_Classes.o ${swigFileStem}_wrap.o -lstdc++ -o libvega.so


I hit only a single hitch (at the very last step, trying to run my java program):

Exception in thread "main" java.lang.UnsatisfiedLinkError: PATH/libvega.so: PATH/libvega.so: undefined symbol: _ZTVN10__cxxabiv120__si_class_type_infoE
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1803)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1728)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1028)
at main.main(main.java:3)

Adding the stdc++ library during the linking via the '-lstdc++' flag you see above fixed the whole problem, as described here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193950

Also note the presence of the '-package' tag in my input file.   The SWIG manual indicates that the value which follows this flag will appear at the top of each java file produced by SWIG.  This is MUCH faster than adding the package declaration yourself.  http://www.swig.org/Doc2.0/Java.html