Skip to content

Latest commit

 

History

History
114 lines (105 loc) · 3.9 KB

README.org

File metadata and controls

114 lines (105 loc) · 3.9 KB

traject: generate Developer Mode 2.0 trajectories

Overview

General python interface for managing trajectories and the interface with TrueBeam’s Developer Mode. Control points as used with developer mode are implemented here with python interface. The xml schema used to build the xml data structure that is used for writing the new xml control scripts.

Mechanical control points can be generated with python scripting. The trajectory object can then be written to the Developer Mode schema using this library.

Installation

Dependencies

pip install lxml matplotlib sympy

generateDS

This package is used to update the developer mode python class from the xml schema.

lxml

Library for using xml files in python

matplotlib

Used for visualization

numpy

The heavy lifting.

sympy

Symbolic math package

Virtual Environment

I develop/run this in a virtual environment. If not using, just make sure you have numpy and matplotlib available to your environment. 
mkvirtualenv -p /usr/bin/python2 traject && pip install -U pip

pip install matplotlib
pip install git+https://github.com/PySide/pyside-setup.git

Examples

As the user interface is rather sparse, a few examples of how to use the trajectory class are included

Change Schema Version

When building the Developer Mode class from a new scheam, the class can be (re-)generated using the following in the traject/traject folder: 
ln -sf ResearchBeam_HE20.xsd schema/ResearchBeam.xsd
generateDS.py --export="write" -o "developer_mode.py" -s "developer_modes_subs.py" schema/VarianResearchBeam.xsd

TODO packaging

I need to modify the setup so that the correct class is generated for the schema of interest. As I needed to modify the generated class by hand to fix some of the documentation, it may be better to have different classes generated for different versions and then select based on the version number.

After having to manually modify the class calls in the code after generating from the new schema, it may not be pragmatic to have this be generated on the fly. Probably better to have the schema class be generated and tested within the version control framework as it is now. A separate class could be used depending on the users preferred version number.