src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2023-08-15T16:30:31+02:00https://gitlab.psi.ch/OPAL/src/-/issues/769remove deprecated Tpetra::StaticProfil2023-08-15T16:30:31+02:00gsellremove deprecated Tpetra::StaticProfil2023.1gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/770linking problems with boost::phoenix2023-08-14T12:34:54+02:00gselllinking problems with boost::phoenixDue to a bug in Boost 1.81.0 and newer we get linking related to boost::phoenix:
```
../optimizer/liboptp.a(expression.cpp.o):(.bss+0x0): multiple definition of `boost::phoenix::placeholders::uarg10'
libOPAL.a(matheval.cpp.o):(.bss+0x0):...Due to a bug in Boost 1.81.0 and newer we get linking related to boost::phoenix:
```
../optimizer/liboptp.a(expression.cpp.o):(.bss+0x0): multiple definition of `boost::phoenix::placeholders::uarg10'
libOPAL.a(matheval.cpp.o):(.bss+0x0): first defined here
```2023.1gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/686Use a library that provides dimensional analysis and unit/quantity manipulation.2023-07-24T11:02:38+02:00krausUse a library that provides dimensional analysis and unit/quantity manipulation.Once we switch to c++20 then we should use [this library](https://github.com/mpusz/units) to make unit convertions safe. Ideally we also provide units for the parser such that the user can provide quantities in different units than meter...Once we switch to c++20 then we should use [this library](https://github.com/mpusz/units) to make unit convertions safe. Ideally we also provide units for the parser such that the user can provide quantities in different units than meter, seconds etc.
See also [here](https://mpusz.github.io/units/introduction.html) and [here](https://www.youtube.com/watch?v=7dExYGSOJzo).https://gitlab.psi.ch/OPAL/src/-/issues/750Trimcoil implementation bug2023-07-24T11:00:49+02:00snuverink_jjochem.snuverink@psi.chTrimcoil implementation bug### Summary
In #276 and !53 a trim coil range in the azimuthal direction was introduced. However, this was not properly tested and it contained a bug, that was discovered by @zhang_h. This was partly fixed in #736 / !598, but not comple...### Summary
In #276 and !53 a trim coil range in the azimuthal direction was introduced. However, this was not properly tested and it contained a bug, that was discovered by @zhang_h. This was partly fixed in #736 / !598, but not completely tested.
### What is the current *bug* behavior?
The trim coils do not work anymore without `PHIMIN` and `PHIMAX` specified.
### What is the expected *correct* behavior?
Trim coils working as normal.
### Possible fixes
The bug was introduced in 77c975dcca3b99cf195cbf020d5039f8be745646, especially the default value of `PHIMAX` was not specified (https://gitlab.psi.ch/OPAL/src/-/commit/77c975dcca3b99cf195cbf020d5039f8be745646#fa26d1e4b267fcc893fcd886f40d73b50d62cdef_46_56) and the `TrimCoil::setAzimuth` method was not so well implemented (https://gitlab.psi.ch/OPAL/src/-/commit/77c975dcca3b99cf195cbf020d5039f8be745646#c96f8a350e29295ac068d6a60d9a39c1972d72e6_16_28).2023.1snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/768testing2023-07-18T10:47:51+02:00sadr_mtesting### Summary
(Summarize the bug encountered concisely)
### Steps to reproduce
(How one can reproduce the issue - this is very important)
### What is the current *bug* behavior?
(What actually happens)
### What is the expected *co...### Summary
(Summarize the bug encountered concisely)
### Steps to reproduce
(How one can reproduce the issue - this is very important)
### What is the current *bug* behavior?
(What actually happens)
### What is the expected *correct* behavior?
(What you should see instead)
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's very hard to read otherwise.)
### Possible fixes
(If you can, link to the line of code that might be responsible for the problem)2023.1https://gitlab.psi.ch/OPAL/src/-/issues/655Remove real variable P02023-05-16T14:46:42+02:00krausRemove real variable P0The attribute `PC` of the `BEAM` command gets `P0` as default value. `P0` is defined to create a `1 GeV` beam. If a user forgets to set the energy of the beam then Opal should throw an exception. Using a default value here results in unn...The attribute `PC` of the `BEAM` command gets `P0` as default value. `P0` is defined to create a `1 GeV` beam. If a user forgets to set the energy of the beam then Opal should throw an exception. Using a default value here results in unnecessary mistakes. When `PC` doens't have default value then we can also remove `P0` which is created in a rather strange way.OPAL 2021.1krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/764RingDefinition - Beam rotation and Momentum Tolerance2023-05-16T12:15:30+02:00ext-rogers_cRingDefinition - Beam rotation and Momentum Tolerance### Summary
I would like to be able to introduce an arbitrary rotation to beams in RingDefinition, independent of the azimuthal angle at which the ring is injected. At the moment, transverse "kicks" are enabled by `BEAM_PRINIT` but this...### Summary
I would like to be able to introduce an arbitrary rotation to beams in RingDefinition, independent of the azimuthal angle at which the ring is injected. At the moment, transverse "kicks" are enabled by `BEAM_PRINIT` but this does not permit full rotation through 360 degrees.
My use case:
We decided at a recent meeting that for consistency with the ring layout on the ground in the ring we are designing, the ring should start at "12 o'clock" and proceed in a clockwise direction. OPAL-Cycl mode currently supports element placements in clockwise or anticlockwise direction but beam can only proceed in an anti-clockwise direction.2023.1ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/759Check attributes of the cyclotron element2023-05-12T09:45:53+02:00ext-calvo_ppedro.calvo@ciemat.esCheck attributes of the cyclotron elementSome attributes of the cyclotron element must be verified for correct assignment. For example, `MINR` cannot be negative and the initial position of the reference particle (`RINIT` and `ZINIT`) must be defined within the range of the mac...Some attributes of the cyclotron element must be verified for correct assignment. For example, `MINR` cannot be negative and the initial position of the reference particle (`RINIT` and `ZINIT`) must be defined within the range of the machine.2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/762RFCavity: unify units internally2023-05-09T10:21:56+02:00ext-calvo_ppedro.calvo@ciemat.esRFCavity: unify units internallyAccording to #357, all elements should use the same units internally to eliminate unnecessary conversions and less error-prone. Unit conversion should be done for input parameters upon reading the variables.According to #357, all elements should use the same units internally to eliminate unnecessary conversions and less error-prone. Unit conversion should be done for input parameters upon reading the variables.2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/760gmsgALL should be common across all objects2023-05-09T09:50:46+02:00ext-rogers_cgmsgALL should be common across all objectsAt the moment a "gmsgALL" is implemented independently by each object. Verbose output can be controlled by command line options like --info but would be nice to control at OPTION level as is done by gmsg. Propose implementing a gmsgALL i...At the moment a "gmsgALL" is implemented independently by each object. Verbose output can be controlled by command line options like --info but would be nice to control at OPTION level as is done by gmsg. Propose implementing a gmsgALL in the same way as gmsg is done.
Task:
* Add gmsgALL to Main.cpp, test/Main.cpp, PyOpal/PyCore/Globals.cpp
* Edit relevant classes to use extern gmsgALL2023.1ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/761Remove duplicate function to check integers2023-05-09T08:03:32+02:00ext-calvo_ppedro.calvo@ciemat.esRemove duplicate function to check integersDumpFields and DumpEMFields have repeated methods to check if an input variable is an integer. A new method could be created to avoid duplication in Util namespaceDumpFields and DumpEMFields have repeated methods to check if an input variable is an integer. A new method could be created to avoid duplication in Util namespace2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://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/482File header for OPAL source proposal2023-04-19T13:20:01+02:00snuverink_jjochem.snuverink@psi.chFile header for OPAL source proposalThe following discussion from !294 should be addressed:
- @gsell started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/294#note_18341): (+4 comments)
> @snuverink\_j @ext\-rogers\_c
> Ok, maybe we have to chang...The following discussion from !294 should be addressed:
- @gsell started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/294#note_18341): (+4 comments)
> @snuverink\_j @ext\-rogers\_c
> Ok, maybe we have to change/extend the file header for OPAL source files according the recommendations in https://www.gnu.org/licenses/gpl-howto.html. What do you think about the following proposal:
> ```
> //
> // Brief description
> //
> // Copyright (c) YYYY, Notice mentioning University, Institute, Lab or Author
> //
> // Optional: related work, e.g. title of PhD or Master thesis
> //
> // This file is part of OPAL.
> //
> // OPAL is free software: you can redistribute it and/or modify
> // it under the terms of the GNU General Public License as published by
> // the Free Software Foundation, either version 3 of the License, or
> // (at your option) any later version.
> //
> // You should have received a copy of the GNU General Public License
> // along with OPAL. If not, see <https://www.gnu.org/licenses/>.
> //
> ```
> For PSI employees the copyright notice would be:
> ```
> // Copyright (c) YYYY1[, YYYY2...], Paul Scherrer Institut, Villigen PSI, Switzerland
> // All rights reserved.
> ```
> For a PhD or Master student something like:
> ```
> // Copyright (c) YYYY1[, YYYY2...], Firstname Lastname, University
> // All rights reserved
> ```
> My proposal for the header of the file `MapAnalyser.h` would be something like:
> ```
> //
> // Class: MapAnalyser
> // Organizes the function for a linear map analysis from
> // ThickTracker.
> // Transfer map -> tunes, symplecticity and stability
> // Sigma Matrix -> (not projected) beam emittance
> //
> // This class is in an unfinished state.
> // For some dicussion see https://gitlab.psi.ch/OPAL/src/issues/464
> // Some cleanup was done in https://gitlab.psi.ch/OPAL/src/merge_requests/294
> //
> // Copyright (c) 2017, Philippe Ganz, ETH Zürich
> // All rights reserved
> //
> // Implemented as part of the Master thesis
> // "s-based maps from TPS & Lie-Series applied to Proton-Therapy Gantries"
> //
> // This file is part of OPAL.
> //
> // OPAL is free software: you can redistribute it and/or modify
> // it under the terms of the GNU General Public License as published by
> // the Free Software Foundation, either version 3 of the License, or
> // (at your option) any later version.
> //
> // You should have received a copy of the GNU General Public License
> // along with OPAL. If not, see <https://www.gnu.org/licenses/>.
> //
> ```
Tasks:
* [x] Extend the list of student files (@frey\_m)
* [x] Adapt source files from students
* [x] Strongly modified classes (e.g. `PartBunchBase` and `RK4`) (as pointed out in #501) (fixed with !380)
* [x] OPAL-map and Matched distribution (!308)
* [x] Fix .cpp files with same file header as header files (!355)
* [x] Beam stripping physics (see https://gitlab.psi.ch/OPAL/src/merge_requests/328)
* [x] Optimiser (see https://gitlab.psi.ch/OPAL/src/merge_requests/323),
* [x] SAAMG solver (see https://gitlab.psi.ch/OPAL/src/merge_requests/324)
* [x] Fix: SAAMG originally developed in MSc thesis not PhD (see comment https://gitlab.psi.ch/OPAL/src/merge_requests/327#note_20157) (!369)
* [x] ~~envelope tracker (Yves Ineichen ?)~~ **Edit:** This solver got removed (see !343).
* [x] @frey\_m see #501
* [x] ~~all DKS stuff is @locans\_u's work~~ **Edit:** DKS got removed (see #523)
* [x] all P3M files are part of [Benjamin Ulmer's work](http://amas.web.psi.ch/people/aadelmann/ETH-Accel-Lecture-1/projectscompleted/cse/thesisBUlmer.pdf) (see https://gitlab.psi.ch/OPAL/src/merge_requests/325)
* [x] Cyclotron work by Jianjun Yang (!356)
* [x] Update wiki on code styleOPAL 2.4.0snuverink_jjochem.snuverink@psi.chgsellfrey_msnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/757Zero field should create a warning2023-04-12T10:58:36+02:00adelmannZero field should create a warning### Summary
In case a zero field is read in, a warning should be issued.
Such almost zero fields make sense however one field component must be non zero.
The attached example shows the zero field and the fixed zero field.
[zero-field-...### Summary
In case a zero field is read in, a warning should be issued.
Such almost zero fields make sense however one field component must be non zero.
The attached example shows the zero field and the fixed zero field.
[zero-field-example.zip](/uploads/334c29c62cd2efbaff2e81f244885022/zero-field-example.zip)2023.1adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/754boost::filesystem::extension() is deprecated in new boost versions2023-04-05T09:50:50+02:00gsellboost::filesystem::extension() is deprecated in new boost versions2023.1gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/755Tpetra CsrMatrix::getNodeNumElements() is deprecated2023-04-05T09:08:35+02:00gsellTpetra CsrMatrix::getNodeNumElements() is deprecated2023.1gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/753fix assigned but unused variable warnings2023-04-05T09:08:00+02:00gsellfix assigned but unused variable warningsWith Clang 14 on macOS 13.3 and Xcode 14.3 we get several warning about variables assigned but not used. In some cases the value is used only if some debug output is enabled.With Clang 14 on macOS 13.3 and Xcode 14.3 we get several warning about variables assigned but not used. In some cases the value is used only if some debug output is enabled.2023.1gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/751Cyclotron out of range field lookup2023-03-31T14:48:00+02:00snuverink_jjochem.snuverink@psi.chCyclotron out of range field lookup### Summary
The magnetic field lookup can be out of range resulting in an segmentation fault.
### Steps to reproduce
One way to reproduce this is to have a trim coil with a very large `BMAX`, e.g.:
```
tc15: TRIMCOIL, TYPE="PSI-PHASE...### Summary
The magnetic field lookup can be out of range resulting in an segmentation fault.
### Steps to reproduce
One way to reproduce this is to have a trim coil with a very large `BMAX`, e.g.:
```
tc15: TRIMCOIL, TYPE="PSI-PHASE", RMIN = 3000, RMAX = 4560.073, BMAX=100.0025264327051118017, COEFNUM = {-0.0312020990404, 0.0227946756108, -0.00354827255973}, COEFDENOM = {14.7460286849, -16.9186605846, 7.61516943548, -1.53074181639, 0.11384470123};
psi_ring: Cyclotron, TYPE="RING", CYHARMON=6, PHIINIT=0.0, PRINIT=pr0, RINIT=r0 , SYMMETRY=8.0, RFFREQ=frequency, FMAPFN="./s03av.nar", FMLOWE=0.072, FMHIGHE=0.595,
TRIMCOIL={tc15};
```
### What is the current *bug* behavior?
segmentation fault:
```
OPAL> * ---------------------- Start tracking ---------------------------------- *
/afs/psi.ch/sys/psi.x86_64_slp6/Programming/gcc/10.3.0/include/c++/10.3.0/bits/stl_vector.h:1045: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = double; _Alloc = std::allocator<double>; std::vector<_Tp, _Alloc>::reference = double&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed.
Thread 1 "opal" received signal SIGABRT, Aborted.
0x00007ffff43a2aff in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: yum debuginfo-install bzip2-libs-1.0.6-26.el8.x86_64 glibc-2.28-211.el8.x86_64 zlib-1.2.11-21.el8_7.x86_64
(gdb) bt
#0 0x00007ffff43a2aff in raise () from /lib64/libc.so.6
#1 0x00007ffff4375ea5 in abort () from /lib64/libc.so.6
#2 0x00000000004c60c2 in std::__replacement_assert (
__file=__file@entry=0xce5908 "/afs/psi.ch/sys/psi.x86_64_slp6/Programming/gcc/10.3.0/include/c++/10.3.0/bits/stl_vector.h", __line=__line@entry=1045,
__function=__function@entry=0xce77d8 "std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = double; _Alloc = std::allocator<double>; std::vector<_Tp, _Alloc>::reference ="..., __condition=__condition@entry=0xce5e98 "__builtin_expect(__n < this->size(), true)")
at /afs/psi.ch/sys/psi.x86_64_slp6/Programming/gcc/10.3.0/include/c++/10.3.0/x86_64-pc-linux-gnu/bits/c++config.h:461
#3 0x00000000007785c0 in std::vector<double, std::allocator<double> >::operator[] (__n=19210, this=0x1999428)
at /home/snuverink_j/OPAL/src/src/Classic/AbsBeamline/Cyclotron.cpp:767
#4 Cyclotron::interpolate (this=this@entry=0x1998fd0, rad=@0x7fffffff6ac8: 4.7088452431449133,
tet_rad=@0x7fffffff6ad0: 0.1981665351710836, brint=@0x7fffffff6ad8: 0, btint=@0x7fffffff6ae0: 0,
bzint=@0x7fffffff6ae8: 0) at /home/snuverink_j/OPAL/src/src/Classic/AbsBeamline/Cyclotron.cpp:750
#5 0x000000000077887b in Cyclotron::apply (this=0x1998fd0, R=..., t=@0x7fffffff6f38: 6000.00000001014, E=..., B=...)
at /home/snuverink_j/OPAL/src/src/Classic/AbsBeamline/Cyclotron.cpp:454
#6 0x0000000000775b38 in Cyclotron::apply (this=0x1998fd0, id=@0x7fffffff70d8: 1, t=@0x7fffffff6f38: 6000.00000001014,
E=..., B=...) at /home/snuverink_j/OPAL/src/src/Classic/AbsBeamline/Cyclotron.cpp:409
#7 0x00000000006d2154 in ParallelCyclotronTracker::computeExternalFields_m (this=this@entry=0x1996380,
i=@0x7fffffff70d8: 1, t=<optimized out>, Efield=..., Bfield=...)
at /home/snuverink_j/OPAL/src/src/Algorithms/ParallelCyclotronTracker.cpp:3417
#8 0x00000000006d21bf in ParallelCyclotronTracker::getFieldsAtPoint (this=0x1996380, t=<optimized out>,
Pindex=@0x7fffffff70d8: 1, Efield=..., Bfield=...)
at /home/snuverink_j/OPAL/src/src/Algorithms/ParallelCyclotronTracker.cpp:1463
#9 0x00000000006ebe66 in std::function<bool (double const&, unsigned long const&, Vektor<double, 3u>&, Vektor<double, 3u>&)>::operator()(double const&, unsigned long const&, Vektor<double, 3u>&, Vektor<double, 3u>&) const (__args#3=...,
__args#2=..., __args#1=@0x7fffffff70d8: 1, __args#0=@0x7fffffff6da8: 6.9533465388994597e-310, this=<optimized out>)
at /afs/psi.ch/sys/psi.x86_64_slp6/Programming/gcc/10.3.0/include/c++/10.3.0/bits/std_function.h:248
#10 RK4<std::function<bool (double const&, unsigned long const&, Vektor<double, 3u>&, Vektor<double, 3u>&)>>::derivate_m(PartBunchBase<double, 3u>*, double*, double const&, double*, unsigned long const&) const (this=this@entry=0x193f8f0,
bunch=bunch@entry=0x193c500, y=y@entry=0x7fffffff7030, t=@0x7fffffff6f38: 6000.00000001014,
yp=yp@entry=0x7fffffff7000, i=@0x7fffffff70d8: 1) at /home/snuverink_j/OPAL/src/src/Steppers/RK4.hpp:108
#11 0x00000000006ec366 in RK4<std::function<bool (double const&, unsigned long const&, Vektor<double, 3u>&, Vektor<double, 3u>&)>>::doAdvance_m(PartBunchBase<double, 3u>*, unsigned long const&, double const&, double) const (this=0x193f8f0,
bunch=0x193c500, i=@0x7fffffff70d8: 1, t=@0x7fffffff7168: 5999.9341888880599, dt=0.065811122079631468)
at /home/snuverink_j/OPAL/src/src/Steppers/RK4.hpp:70
#12 0x00000000006d2a51 in Stepper<std::function<bool (double const&, unsigned long const&, Vektor<double, 3u>&, Vektor<double, 3u>&)>>::advance(PartBunchBase<double, 3u>*, unsigned long const&, double const&, double) const (
dt=0.065811122079631468, t=@0x7fffffff7168: 5999.9341888880599, i=@0x7fffffff70d8: 1, bunch=0x193c500,
this=<optimized out>) at /home/snuverink_j/OPAL/src/src/Algorithms/ParallelCyclotronTracker.cpp:3046
#13 ParallelCyclotronTracker::seoMode_m (this=this@entry=0x1996380, t=@0x7fffffff7168: 5999.9341888880599,
dt=0.065811122079631468, Ttime=..., Tdeltr=..., Tdeltz=..., TturnNumber=...)
at /home/snuverink_j/OPAL/src/src/Algorithms/ParallelCyclotronTracker.cpp:3046
#14 0x00000000006e21dd in ParallelCyclotronTracker::GenericTracker (this=0x1996380)
at /home/snuverink_j/OPAL/src/src/Algorithms/ParallelCyclotronTracker.cpp:1429
#15 0x00000000006e2765 in ParallelCyclotronTracker::execute (this=0x1996380)
at /home/snuverink_j/OPAL/src/src/Algorithms/ParallelCyclotronTracker.cpp:1238
#16 0x00000000006b2651 in TrackRun::execute (this=0x193e6c0) at /home/snuverink_j/OPAL/src/src/Track/TrackRun.cpp:245
#17 0x000000000053531b in OpalParser::execute (this=this@entry=0x193bb50, object=object@entry=0x193e6c0, name=...)
at /home/snuverink_j/OPAL/src/src/OpalParser/OpalParser.cpp:140
#18 0x0000000000538d29 in OpalParser::parseAction (this=0x193bb50, stat=...)
at /home/snuverink_j/OPAL/src/src/OpalParser/OpalParser.cpp:173
#19 0x00000000005392d9 in OpalParser::parse (this=0x193bb50, stat=...)
at /home/snuverink_j/OPAL/src/src/OpalParser/OpalParser.cpp:91
#20 0x00000000005390d6 in OpalParser::run (this=0x193bb50)
at /home/snuverink_j/OPAL/src/src/OpalParser/OpalParser.cpp:608
#21 0x00000000006aaba9 in TrackCmd::execute (this=0x18947b0) at /home/snuverink_j/OPAL/src/src/Track/TrackCmd.cpp:230
#22 0x000000000053531b in OpalParser::execute (this=this@entry=0x7fffffff8490, object=object@entry=0x18947b0, name=...)
at /home/snuverink_j/OPAL/src/src/OpalParser/OpalParser.cpp:140
#23 0x0000000000538d29 in OpalParser::parseAction (this=0x7fffffff8490, stat=...)
at /home/snuverink_j/OPAL/src/src/OpalParser/OpalParser.cpp:173
#24 0x00000000005392d9 in OpalParser::parse (this=0x7fffffff8490, stat=...)
at /home/snuverink_j/OPAL/src/src/OpalParser/OpalParser.cpp:91
#25 0x00000000005390d6 in OpalParser::run (this=0x7fffffff8490)
at /home/snuverink_j/OPAL/src/src/OpalParser/OpalParser.cpp:608
#26 0x0000000000535800 in OpalParser::run (this=this@entry=0x7fffffff8490, is=is@entry=0x1890ad0)
at /home/snuverink_j/OPAL/src/src/OpalParser/OpalParser.cpp:633
#27 0x00000000004b3843 in opalMain (argc=<optimized out>, argv=<optimized out>)
at /home/snuverink_j/OPAL/src/src/Main.cpp:364
#28 0x00007ffff438ed85 in __libc_start_main () from /lib64/libc.so.6
#29 0x00000000004af24e in _start () at /home/snuverink_j/OPAL/src/src/Main.cpp:131
```
### What is the expected *correct* behavior?
not crash and ignore the field. the particle will be cleaned up afterwards.
### Possible fixes
https://gitlab.psi.ch/OPAL/src/-/blob/master/src/Classic/AbsBeamline/Cyclotron.cpp#L747:
```cpp
if (fieldType_m != BFieldType::FFABF) {
/*
For FFA this does not work
*/
r1t1 = it + ntetS * ir - 1;
r1t2 = r1t1 + 1;
r2t1 = r1t1 + ntetS;
r2t2 = r2t1 + 1 ;
} else {
/*
With this we have B-field AND this is far more
intuitive for me ....
*/
r1t1 = idx(ir, it);
r2t1 = idx(ir + 1, it);
r1t2 = idx(ir, it + 1);
r2t2 = idx(ir + 1, it + 1);
}
if ((it >= 0) && (ir >= 0) && (it < Bfield_m.ntetS_m) && (ir < Bfield_m.nrad_m)) {
// lookup and apply field
```
The range check should rather be `ir + 1 < Bfield_m.nrad_m`2023.1snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/752replace deprecated sprintf2023-03-31T14:16:36+02:00gsellreplace deprecated sprintf2023.1gsellgsell