src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2023-10-11T10:06:06+02:00https://gitlab.psi.ch/OPAL/src/-/issues/788PyOpal cmake option2023-10-11T10:06:06+02:00ext-calvo_ppedro.calvo@ciemat.esPyOpal cmake optionThe `BUILD_OPAL_PYTHON` flag must be added as a compile option to be available from CMake settingsThe `BUILD_OPAL_PYTHON` flag must be added as a compile option to be available from CMake settings2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/766RF Cavity, Global Offset and Debugging2023-08-22T10:13:18+02:00ext-rogers_cRF Cavity, Global Offset and DebuggingCouple more things to add into PyOpal - Variable Frequency RF Cavity, Global Offset and a couple more minor bug fixesCouple more things to add into PyOpal - Variable Frequency RF Cavity, Global Offset and a couple more minor bug fixes2023.1ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/758Quality of life improvements to PyOpal2023-05-05T12:02:53+02:00ext-rogers_cQuality of life improvements to PyOpalFollowing on from #745
Couple of extra "usability" features:
* It should be possible to pass multiple arguments to a "setup" function for PyOpal objects
* If an argument is passed that is not recognised, PyOpal should throw an error. A...Following on from #745
Couple of extra "usability" features:
* It should be possible to pass multiple arguments to a "setup" function for PyOpal objects
* If an argument is passed that is not recognised, PyOpal should throw an error. At the moment PyOpal quietly ignores unrecognised arguments - technically, this is consistent with "normal" python but it is not very nice
* It should be possible to define something as a required argument; if it is undefined, and user tries to use the class in anger (e.g. call to get_field_value) then PyOpal should throw an error.
* It should be possible to make PyOpal run silently (i.e. suppress output) or send output to a file. Bonus points if we can send PyOpal output to sys.stdout!
* In PyOpal/PyCore/Globals.cpp there is a hard coded constant for --processes (3). This should be user defined.2023.1ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/745PyOPAL - FFA lattice2023-04-20T16:54:05+02:00ext-rogers_cPyOPAL - FFA lattice### Summary
Implement supporting code to model our current FFA lattice in PyOPAL. That means writing API for following elements:
- ScalingFFAMagnet and EndFieldModels
- DumpEMFields
- LocalCartesianOffset (other offsets?)
- Probe
- Mult...### Summary
Implement supporting code to model our current FFA lattice in PyOPAL. That means writing API for following elements:
- ScalingFFAMagnet and EndFieldModels
- DumpEMFields
- LocalCartesianOffset (other offsets?)
- Probe
- MultipoleT
- VariableRFCavity and TimeDependence plugin
- General consideration of stability/etc
Maybe some other things I forgot.
Also (of course)
- Code
- Test
I will do Documentation in a separate feature when I am more happy with the whole framework.2023.1ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/624PyOpal - build system2022-09-14T11:43:03+02:00ext-rogers_cPyOpal - build system### Summary
Build system and a couple of simple examples for opal<->python API
I would like to merge in my current working tree, by way of debugging all of the build system stuff for pyopal. At the moment I have working code that will ...### Summary
Build system and a couple of simple examples for opal<->python API
I would like to merge in my current working tree, by way of debugging all of the build system stuff for pyopal. At the moment I have working code that will allow users to link against python and build C/python libraries. I have implemented a couple of examples:
* Access to a few polynomial routines
* Access to the OpalRing for field lookups
Obviously not full implementation of #516 but an opportunity to get a bit of feedback on the interface for building libraries/etc.
~"Feature request"2022.1ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/660OpalElement wrapper2022-07-18T10:20:11+02:00ext-rogers_cOpalElement wrapperI had a go at doing an OpalElement wrapper:
https://gitlab.psi.ch/ext-rogers_c/src/-/blob/master/src/PyOpal/PyElement.h
https://gitlab.psi.ch/ext-rogers_c/src/-/blob/master/src/PyOpal/PyElement.cpp
I implement an OpalVerticalFFAMagnet...I had a go at doing an OpalElement wrapper:
https://gitlab.psi.ch/ext-rogers_c/src/-/blob/master/src/PyOpal/PyElement.h
https://gitlab.psi.ch/ext-rogers_c/src/-/blob/master/src/PyOpal/PyElement.cpp
I implement an OpalVerticalFFAMagnet wrapper here:
https://gitlab.psi.ch/ext-rogers_c/src/-/blob/master/src/PyOpal/PyVerticalFFAMagnet.h
https://gitlab.psi.ch/ext-rogers_c/src/-/blob/master/src/PyOpal/PyVerticalFFAMagnet.cpp
and here is a script that builds a OpalVerticalFFAMagnet in python and plots the field. Not a proper test yet, more like a proof that it "works".
https://gitlab.psi.ch/ext-rogers_c/src/-/blob/master/tests/opal_src/PyOpal/test_vertical_ffa_magnet.py
This is related to #516 and dependent on #624. I don't want to try to make a merge branch until #624 is merged so I just link to my dev fork instead. It can only cause mayhem if I start sticking this stuff in #624 branch or try to make a new branch that is dependent on the #624 branch!2022.1ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/516pyopal - specification2022-07-18T10:19:57+02:00ext-rogers_cpyopal - specification### Summary
Specification for pyopal
[2020-04-20_PyOpal.docx](/uploads/7deccec6c3c38595bfcbe9cae0b4b05c/2020-04-20_PyOpal.docx)### Summary
Specification for pyopal
[2020-04-20_PyOpal.docx](/uploads/7deccec6c3c38595bfcbe9cae0b4b05c/2020-04-20_PyOpal.docx)2022.1ext-rogers_cext-rogers_c