Apps‎ > ‎


The X-Windows Virtual Simulator
[ runs on Linux, Windows & MacOSX ]


  • Sherouse G and Chaney E, The Portable Virtual Simulator, Int. J. Radiat. Oncol. Biol. Phys.21(2):475-482 (1991)
  • Sherouse G, Bourland D, Reynolds K, McMurry H, Mitchell T, and Chaney E, Virtual Simulation in the Clinical Setting: Some Practical Considerations, Int. J. Radiat. Oncol. Biol. Phys.19(4):1059-1065 (1990b)
  • Sherouse G, Mosher C, Novins K, Rosenman J, Chaney E, Virtual Simulation: Concept and Implementation, The Use of Computers in Radiation Therapy, Proceedings of the Ninth International Conference, Elsevier Science Publishers, North Holland, 433-436, (1987).
  • Mosher C, Sherouse G, Mills P, Novins K, Pizer S, Rosenman J, and Chaney E, The Virtual Simulator, Proceedings of the 1986 Workshop on Interactive Computer Graphics, Assoc. for Comp. Machinery (ACM), New York, 37-42, (1987).
  • Rosenman J, Sailer S, Sherouse G, Chaney E, and Tepper J, Virtual Simulation: Initial Clinical Results, Int J Radiat Oncol Biol Phys, 20(4):843-852, (1991).


This is the main flagship app to register 3D images, design beams, compute dose, and examine statistics on dose such as DVH and goal sheets.  It can call any of PLUNC's dose computation libraries.

In rigid image registration we use the mouse to slide or rotate a floating 3D image (CT, MRI, US, PET, etc) across another 3D fixed image in the background. Surprisingly, this normally takes our medical physicists 30 seconds for all both the most complex images, and incorporates knowledge of the type and extend of tumors.  YMMV since it takes some practice.

DVH and goal sheets are used for the evaluation of both the optimizer's performance and the plan's goodness.  The DVH can also used to draw the optimizer's goals, eg, to draw the minimal acceptable DVH.

A doctor can design complete treatment plans through the use of "beam normalization groups" -- groups of beams that share a prescription and a normalization point -- to implement courses, trials, competing plans or composite plans (eg, initial plus boost plans).  After a doctor has approved (digitally signed) a plan, it can be exported by a dosimetrist (via DICOM or RTP-link) to Elekta Mosaiq or other commercial R&V systems, then configured in the R&V to assign the beams to prescriptions & delivery days, and finally, to treat, but xvsim does not participate in the manual R&V work.

Dose Engines

See the Dose page for details about these dose engines:
  • libphoton is photon pencil beam: Clarkson summation with a really good Batho correction that works better than any other we've seen. People will reject Pencil Beam because of it's errors in lung-air interfaces, but it's been judged good enough to gain acceptance into clinical trials.  Codes that produce results closer to Monte Carlo exist, but are usually 100x slower. With advances in GPU implementations, these time differences are no longer significant in commercial TPSs, but can still slow an optimizer down significantly on CPU.
  • libelectron is Hogstrum's electron pencil beam Fortran code, converted to C and sped up 1000x.  The errors here can be up to 15-20% from Monte Carlo so you would not want to try to "feather" a photon and electron beam together because you cannot trust the dose at the interface.
  • Superposition Convolution Collapsed Cone for photons
  • EGS4 Monte Carlo for photons and electrons - the "silver" standard that requires that you invest significant time modeling the treatment head components in terms of vendor-confidential physical dimensions and materials.  Even a slight difference ( .1mm or 5%) in the input characteristics can render MC unusable, and there is no real-world way to know if it is correct because of the inaccuracies in measuring devices.  Still, it's the best we have.  It's errors are reduced if you run it longer; we have found about 100 CPU hours (@ 1 GHz) should produce smooth isodose curves.  Fortunately, this is really easy to distribute across processors so a 32-core machine can run for 3 hours and get a good result. [ Or use 10 32-core machines for 20 minute response time. ]


The app, when invoked directly from command line, assumes the current working directory will contain the input and output files of a single patient. It requires a planning CT image called plan_im, an anastruct named a/skin, and a directory name for writing beams.  It can accept multiple input images, each of which can have anastructs, point files & matrices listed after the -i switch for that image.

Although xvsim can be called directly by command line -- and we often do this when debugging -- we have also wrapped the command line invocation in a series of OS-specific scripts (.BAT or perl) that allow a user to invert the invocation process: launch, via a double-click, a helper app called "TPS" which helps the user choose the patient, thens call one of the "plunc" scripts to construct a command line and call xvsim with that command line.

Invoke xvsim without arguments to see it's expected switches, but I should warn you that the programmers usually leave something out; it's best to read the gi.cxx source file for a complete list.  Another way to interact with xvsim is to set environmental variables.
LATER: replace above paragraph with complete list of switches per version.