PyOpal::PyRingDefinition Namespace Reference

Functions
	BOOST_PYTHON_MODULE (ring_definition)

Variables
std::string	ring_definition_docstring = std::string()
const char *	module_docstring = "ring_definition module contains the RingDefinition class"

Function Documentation

BOOST_PYTHON_MODULE()

PyOpal::PyRingDefinition::BOOST_PYTHON_MODULE

(

ring_definition

)

Definition at line 83 of file PyRingDefinition.cpp.

References PyOpal::PyOpalObjectNS::PyOpalObject< C >::addGetFieldValue(), PyOpal::Globals::Initialise(), PyOpal::PyOpalObjectNS::PyOpalObject< C >::make_element_class(), and PyOpal::ExceptionTranslation::registerExceptions().

Here is the call graph for this function:

Variable Documentation

module_docstring

const char* PyOpal::PyRingDefinition::module_docstring = "ring_definition module contains the RingDefinition class"

Definition at line 81 of file PyRingDefinition.cpp.

ring_definition_docstring

std::string PyOpal::PyRingDefinition::ring_definition_docstring = std::string()

RingDefinition handles access to the Ring object.

Placements in the Ring object are handled by RingSection. To keep the UI simple I don't give user direct access to RingSection, but provide a few convenience methods here.

General note that I am following the behaviour of Opal-T and Opal-Cyclotron which go through a "line" object for element placements. But the "Line" doesn't know about the actual position of the elements, so poor user has to do some kludge where they do field lookups and lookup position of elements from Ring, which can only be done after the "Line" setup is done (which in itself is done by Track). It's a bit intricate and arcane, would be better to access directly through Ring, but that's not what we've done.

Definition at line 79 of file PyRingDefinition.cpp.