Functions | |
| BOOST_PYTHON_MODULE (ring_definition) | |
Variables | |
| std::string | ring_definition_docstring = std::string() |
| const char * | module_docstring |
Function Documentation
| PyOpal::PyRingDefinition::BOOST_PYTHON_MODULE | ( | ring_definition | ) |
Definition at line 83 of file PyRingDefinition.cpp.
References PyOpal::PyOpalObjectNS::PyOpalObject< C >::addGetFieldValue(), Physics::e, PyOpal::Globals::Initialise(), PyOpal::PyOpalObjectNS::PyOpalObject< C >::make_element_class(), and PyOpal::ExceptionTranslation::registerExceptions().
Variable Documentation
| const char* PyOpal::PyRingDefinition::module_docstring |
Definition at line 48 of file PyRingDefinition.cpp.
| 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 46 of file PyRingDefinition.cpp.
