Compile dosxyz_show on Ubuntu (10.04, 14.04)

I was surprised to find that this program does't come compiled with BEAM (or other EGSnrc packages) nor does it come packaged using the autotools suite.  Well, we can easily make up for this by compiling it the old fashioned way.  Sadly, whatever functionality autotools would normally provide, we must now provide ourselves.  So get ready and relax, this won't be too painful.

Before this will work, you must have installed EGSnrc (this is where the source for dosxyz_show is found).  Go to the source for dosxyz_show, found in

cd $HEN_HOUSE/omega/progs/dosxyz_show/

The only files present here are the Makefile (which holds the details needed by the compiler) and the .c file (which holds the code to be compiled).  Like every good linux user, I tried running this on the command line as soon as I saw the Makefile:

make

If everything were fine, this should work and then you are done installing dosxyz_show.  Unfortunately for me, the following error chain was produced (I removed many lines from this output because it was too long!):

gcc -O2  -I/usr/X11R6/include  -o /home/xxxxxx/HEN_HOUSE/bin/i686-pc-linux-gnu-/dosxyz_show -L/usr/X11R6/lib  dosxyz_show.c -lXm -lXt -lX11 -lmdosxyz_show.c:46:22: error: Xm/XmAll.h: No such file or directorydosxyz_show.c:101: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘NoName_status’dosxyz_show.c:109: error...

Looking at the first error:

Xm/XmAll.h: No such file or directory

It is clear that a library is missing.  So I went to the NRC site for dosxyz_show and found that I needed to add the Motif libraries.  The documentation recommended installing LessTif, an open-source equivalent.  In fact, it is not equivalent (which can be validated by looking through the files in the package... some includes we will need are missing at least).  A google search for the file name revealed a file listing for the package libmotif-dev.  So we install that, naively assuming that it's the correct package:

sudo apt-get install libmotif-dev

I also noticed that the default paths in the Makefile were not appropriate for Ubuntu.  In particular, we see this in the Makefile:

X11_include = -I/usr/X11R6/include
# On our system, Motif include files are in /usr/X11R6/include/Xm =>
# we don't need a separate -I for Motif. If this is different on your
# system, adjust accordingly.
Motif_include =
X11_libdir = -L/usr/X11R6/lib
# On our system, the Motif library is /usr/X11R6/lib =>
# we don't need a separate -L for Motif. If this is different on your
# system, adjust accordingly.
Motif_libdir =

Searching for the directories listed above reveals that they do not exist.  OK, lets set the paths correctly. Use these settings instead:

X11_include = -I/usr/include/X11
# On our system, Motif include files are in /usr/X11R6/include/Xm =>
# we don't need a separate -I for Motif. If this is different on your
# system, adjust accordingly.
Motif_include =
X11_libdir = -L/usr/lib/X11
# On our system, the Motif library is /usr/X11R6/lib =>
# we don't need a separate -L for Motif. If this is different on your
# system, adjust accordingly.
Motif_libdir =

Now we compile again

make

If you're using Ubuntu 14.04, that may have been sufficient. However, I sometimes get the following error:

In file included from /usr/include/Xm/XmAll.h:33:0,
                 from dosxyz_show.c:34:
/usr/include/Xm/Xm.h:59:27: fatal error: X11/Intrinsic.h: No such file or directory
 #include <X11/Intrinsic.h>

Which can be solved by installing libxt-dev:

sudo apt-get install libxt-dev

make 

If you've added the environment variables suggested during the EGS install, the path to the executable should already be in your path (check this by trying to auto-complete dosxyz_show on the shell).

If you're using Ubuntu 10.04, you should end up with a new error!  Progress!

gcc -O2  -I/usr/X11R6/include  -o /home/xxxxxxx/HEN_HOUSE/bin/i686-pc-linux-gnu-/dosxyz_show -L/usr/X11R6/lib  dosxyz_show.c -lXm -lXt -lX11 -lmIn file included from /usr/include/Xm/XmAll.h:46,                 from dosxyz_show.c:46:/usr/include/Xm/Xm.h:59:34: error: X11/extensions/Print.h: No such file or directoryIn file included from /usr/include/Xm/XmAll.h:46,                 from dosxyz_show.c:46:/usr/include/Xm/Xm.h:827: error: expected specifier-qualifier-list before ‘XPContext’In file included from /usr/include/Xm/XmAll.h:86,                 from dosxyz_show.c:46:/usr/include/Xm/Print.h:46...

Identifying the first error:

X11/extensions/Print.h: No such file or directory

it is clear that my package installation didn't fully do the trick.  Another google search for the error revealed that I can search for the packages containing a certain file using apt-file.  So we set that up and look for our file (it may take a minute or so to update the apt-file index):

sudo apt-get install apt-file
sudo apt-file update
apt-file search X11/extensions/Print.h
x11proto-print-dev: usr/include/X11/extensions/Print.h

The search reveals that the file is in the x11proto-print-dev package.  We install it:

sudo apt-get install x11proto-print-dev

and we try to build again, with complete success (nevermind all the warnings about fscanf):

gcc -O2  -I/usr/include/X11  -o /home/xbaker/staging/beamnrc/HEN_HOUSE/bin/i686-pc-linux-gnu-/dosxyz_show -L/usr/lib/X11  dosxyz_show.c -lXm -lXt -lX11 -lmdosxyz_show.c: In function ‘get_data’:dosxyz_show.c:1280: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result...

The binary executable produced by the compilation process must be made executable, and then you can run it:

cd $HEN_HOUSE/omega/progs/dosxyz_show 

chmod u+x dosxyz_show

./dosxyz_show <EGSPHANT> <3DDOSE>

Done!

Ensuring vmc++ has the standard library

The short answer:

If you're getting an error like this:

./vmcpp: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

while running VMC++, then you need to add gcc-3.3 to your system, which adds the missing library file mentioned in the error.  In Ubuntu, you can fix this by adding this line to your /etc/apt/sources.list file (choose your mirror from http://packages.ubuntu.com/hardy/i386/libstdc++5/download):

deb http://ubuntu.wikimedia.org/ubuntu/ hardy main universe

and then opening synaptic, reloading, and installing the libstdc++5 package:

sudo apt-get install libstdc++5

More details

In my version of Ubuntu (10.04 lucid), the standard c++ library is the one that comes packaged with gcc-4.4. Unfortunately, the version of the VMC++ monte carlo package that I have was compiled with an older version of gcc. Here is the message I received:

 ./vmcpp: error while loading shared libraries: libvmcpp.so: cannot open shared object file: No such file or directory 

Ooops, that's actually the first error I received while running the program. That simply requires the addition of the lib files that came with the VMC++ executable (including libphsp_source.so, libsimple_source.so, libvmcpp.so) to your system's library path.  If you don't want to install them the 'correct' way, you can get away with adding their directory to the environment variable LD_LIBRARY_PATH, like this (in bash):

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:`pwd` 

Indeed, the real error I received was this:

./vmcpp: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

This required some digging.  A Google search revealed the Ubuntu repositories containing my desired package (libstdc++5).  After choosing the package (the one with /usr/lib/libstdc++.so.5 for my system) and -- on the next page -- my architecture (i386), I was guided to the download location.  I added the appropriate line to my /etc/apt/sources.list file, reloaded my synaptic, then installed the package libstdc++5.

Using dcm4che to read image data: installing JAI

This tutorial describes the installation of JAI in Ubuntu, though it should work for any flavour of linux.  Reading jpg formatted images from a dicom file is easy with dcm4che:

http://www.dcm4che.org/

To use this package to read image data from dicom files in this way:

http://forums.dcm4che.org/jiveforums/message.jspa?messageID=17102#17102
http://samucs.blogspot.com/2008/03/converting-dicom-to-jpeg-using-dcm4che.html

requires the installation of the Java Advanced Imaging (JAI) package.  Sadly, JAI is no longer being developed, so very few efforts are being made to improve accessibility to these packages.  However, nothing is easy to find anymore, as you can read from the testimonials in this thread:

http://forums.dcm4che.org/jiveforums/message.jspa?messageID=14576

Despite this, Java has a new place where the source code is being stored:

http://java.net/projects/jai-imageio

But we aren't going to compile this from source today because we have access (for now, at least) to the pre-made jars we require.  As First, download the jai-imageio build which is appropriate to your architecture from here:

http://download.java.net/media/jai-imageio/builds/release/1.1/

Since I'm using Ubuntu (10.10), I selected

jai_imageio-1_1-lib-linux-i586-jdk.bin

from the list.  I opened a terminal and (as the root user) went to the location of my java install.

sudo -i
cd /usr/lib/jvm/java-6-openjdk

At this location you should find a 'jre' directory.  Copy over the file you downloaded above into this directory and then add the witchcraft which follows (this is all BASH):

cp /home/myUsename/Downloads/jai_imageio-1_1-lib-linux-i586-jdk.bin .

chmod a+x jai_imageio-1_1-lib-linux-i586-jdk.bin

_POSIX2_VERSION=199209

export _POSIX2_VERSION

./jai_imageio-1_1-lib-linux-i586-jdk.bin

This sets the POSIX version for the compatibility of the 'tail' command used by the installer.  Don't blame me for that POSIX crap, it's because no one has updated this installer since the time when you couldn't use 'tail +5' (nowadays you have to use 'tail -5' to do the same thing).  Anyway, proceed through the installer and you should be left with these new files:



  inflating: COPYRIGHT-jai_imageio.txt
  inflating: DISTRIBUTIONREADME-jai_imageio.txt
  inflating: ENTITLEMENT-jai_imageio.txt
  inflating: LICENSE-jai_imageio.txt
  inflating: THIRDPARTYLICENSEREADME-jai_imageio.txt
  inflating: UNINSTALL-jai_imageio
  inflating: jre/lib/i386/libclib_jiio.so
  inflating: jre/lib/ext/jai_imageio.jar
  inflating: jre/lib/ext/clibwrapper_jiio.jar

All done!

3D Plotting in Java (Ubuntu with JOGL and jzy3d)

A quick google search and StackOverflow check revealed two appropriate Java packages for displaying surface plots.  One uses OpenGL, and the other does not.  Since I want maximal functionality for verifying the data visually, I'm going with the OpenGL implementation.

Originally, I tried building the library myself, but the resulting jars didn't seem to contain the correct class information (or they were broken, though the build was successful).  Some links related to this method are found below.

In ubuntu, open synaptic and install this package (as instucted in http://ubuntuforums.org/showthread.php?t=1670765):

libjogl-java

This will add two libraries to your /usr/share/java directory, namely jogl.jar and gluegen-rt.jar.  In eclipse, add these libraries to your build path, then associate the native libraries (which were also automatically installed with libjogl-java) with those jars.  I found out (from http://forum.worldwindcentral.com/archive/index.php?t-21608.html) that these libraries are stored in /usr/lib/jni.  Specify that path as the native library path in Eclipse.

Then you can add the jzy3d jar to your class and you can start drawing with the tutorials found here:

http://code.google.com/p/jzy3d/wiki/DemoCode

You'll also need the syntax for drawing the Chart objects from jzy3d in AWT/Swing containers:

http://code.google.com/p/jzy3d/wiki/EmbeddingChartInAnExistingApplication

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