pyopal - specification

Summary

Specification for pyopal

2020-04-20_PyOpal.docx

added Feature request label

@OPAL following our discussion yesterday I had a go at making a functional specification, attached. There are a few things I wasn't sure about (highlighted in yellow) and some discussion (italicised).

In order to make editing easy, pease use the shared link:

pyOPAL doc shared on Dropbox

When done editing we can update the file on the gitlab

@ext-rogers_c : Thanks for the document. I added a few comments in the Dropbox document.

But maybe the following can be discussed here, you wrote no support for OPAL-Cycl. But I think as long as OPAL-cycl is not merged with OPAL-T, I think it is important to support OPAL-Cycl as well. Same for OPAL-map by the way. Depending on the chosen solution, I don't think it will be much additional work.

@ext-rogers_c we (@frey_m) used pybind11 to wrap with minimal manual effort (writing etc) a OO-Library. Are you aware of pybind11?

@snuverink_j: Support for OPAL-Cycl: why don't I put it in as an extension? Best to get something working, for people to look at (and criticise). If it turns out not to be much extra work, then should turn around Opal-Cycl/Map quite quickly.

@adelmann: from the pybind11 docs https://github.com/pybind/pybind11

tiny self-contained version of Boost.Python ... thanks to some of the new C++11 language features ... dramatically simpler binding code in many common situations

It does sound good (although it means supporting another library). I will have a go at implementing something.

@ext-rogers_c: okay, sure one probably wants to start with a few commands and use cases anyway, that's fine.

But I think the final final version is not complete without OPAL-Cycl and OPAL-Map support. Since if we have that working, then also the MadX parser stuff can become deprecated and later removed. Once you have something for OPAL-T, I am happy to help out with the OPAL-Cycl and OPAL-Map parts.

@adelmann looking at pybind11 - I made a small test module here: https://gitlab.psi.ch/ext-rogers_c/src/blob/master/src/PyOpal/PyBindField.cpp compare to the Boost::Python module: https://gitlab.psi.ch/ext-rogers_c/src/blob/master/src/PyOpal/PyBoostField.cpp and they look pretty similar.

• The documentation for Boost::Python was better (in pybind11 I had to fish around on stackexchange for 30 minutes finding how to do a python tuple, and in the end guessed the answer).
• My guess is Boost::Python will be more stable/better supported as it is part of a big package.
• The overhead is probably a bit bigger for Boost::Python support because it has to link against system python - which means passing some command line arguments to the bjam stuff and less portability. pybind11 is a "headers only" package.
• I didn't look at class implementation.

Shrug...

I tend to lean towards Boost::Python

I would also use Boost:Python since we already depend on Boost (as @ext-rogers_c also pointed out during the OPAL webinar). We used pybind11 since it is a more lightweight package.

Okay, here is another version of the file:

2020-04-28_PyOpal-v2.docx

Let me know if you have any further comments.

I think this is a great proposal!

mentioned in issue runOPAL#14

@ext-rogers_c thanks again for spearheading this.
What's the next step? Is there anything I can do to help?
Will a pyopal repo be started here under OPAL?

mentioned in issue #624 (closed)

marked this issue as related to #624 (closed)

During the Dev workshop (June 2021) we developed a job list:

OpalElements, including unit tests and unit documentation:

1. Template wrapper for OpalElement
2. Implementation for each of the relevant OpalElements i.e. one for SBEND, one for RBEND, etc.

Global wrappers, including unit tests and unit documentation:

0. Add subdirectories to src/PyOpal ** src/PyOpal/Subdirectory/PyModule.h,cpp should be reflected on python side like import pyopal.subdirectory.module
1. Track (and Run), including interface to OPAL-T, OPAL-MAP, OPAL-CYCL
2. Distribution
3. Solver
4. Option
5. Line

Sweep for missing things

Integration/system tests

Integration/system documentation

changed weight to 4

mentioned in issue #660 (closed)

mentioned in issue #227

marked this issue as related to #660 (closed)

added PyOPAL label