src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2023-04-05T09:08:35+02:00https://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/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/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/752replace deprecated sprintf2023-03-31T14:16:36+02:00gsellreplace deprecated sprintf2023.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/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/749More geometries for cyclotron elements2023-01-27T17:57:31+01:00snuverink_jjochem.snuverink@psi.chMore geometries for cyclotron elementsFrom @zhang_h: It would be better if the collimators in forms other than a rectangular could also be defined in OPAL_cycl. The collimators in Ring or Injector2 or COMET could be in forms of a trapezoid, a triangle, a circle, and an ellipse.From @zhang_h: It would be better if the collimators in forms other than a rectangular could also be defined in OPAL_cycl. The collimators in Ring or Injector2 or COMET could be in forms of a trapezoid, a triangle, a circle, and an ellipse.https://gitlab.psi.ch/OPAL/src/-/issues/748Improve error message for using protected keywords2023-03-31T14:12:22+02:00snuverink_jjochem.snuverink@psi.chImprove error message for using protected keywordsReported by @zhang_h:
An input like:
```
ring: Cyclotron, TYPE="RING", ...;
```
will generate an error:
```
Error>
Error> *** User error detected by function "OpalData::define()"
Error> You cannot replace the object "RING".
Error...Reported by @zhang_h:
An input like:
```
ring: Cyclotron, TYPE="RING", ...;
```
will generate an error:
```
Error>
Error> *** User error detected by function "OpalData::define()"
Error> You cannot replace the object "RING".
Error> You cannot replace the object "RING".
```
This is because `ring` is a protected keyword and can't be used as an object name. However, from the user perspective this seems not very clear.
The error message comes from OpalData.cpp:
```c++
if (oldObject->isBuiltin() || ! oldObject->canReplaceBy(newObject)) {
throw OpalException("OpalData::define()",
"You cannot replace the object \"" + name + "\".");
} else {
```
I propose to make a distinction between the two cases and change it to:
```c++
if (oldObject->isBuiltin()) {
throw OpalException("OpalData::define()",
"The keyword \"" + name + "\" is protected and can't be used to name an object.");
else if (! oldObject->canReplaceBy(newObject)) {
throw OpalException("OpalData::define()",
"You cannot replace the already defined object \"" + name + "\".");
} // else not needed
```
Also it might be good not to have "name" in uppercase letters if the user writes it in lowercase, but I couldn't quickly find out where this happens.2023.1snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/747OPAL hangs when running FFA in parallel2022-11-08T12:25:32+01:00ext-rogers_cOPAL hangs when running FFA in parallel### Summary
OPAL hangs when running FFA in parallel
### Possible fixes
`Ring::apply` has a call to `lossDS_m->save();` which in turn calls `ippl::allreduce`. This is a type of MPI reduce. At the same time, `ParallelCyclotronTracker::d...### Summary
OPAL hangs when running FFA in parallel
### Possible fixes
`Ring::apply` has a call to `lossDS_m->save();` which in turn calls `ippl::allreduce`. This is a type of MPI reduce. At the same time, `ParallelCyclotronTracker::deleteParticle` calls `allreduce(flagNeedUpdate, 1, std::logical_or<bool>());`. So the procs can never align and we get a hang.
Fix is to call `lossDS_m->save()` in the Ring::finalise method, which seems to be the approach taken by `Cyclotron`.2023.1ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/746Use smart pointers for elements2022-11-05T23:09:24+01:00krausUse smart pointers for elements2023.1krauskraushttps://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/744Use smart pointers for fieldmaps2022-11-08T09:18:57+01:00krausUse smart pointers for fieldmaps2023.1krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/743Compilation fails2022-10-19T15:13:27+02:00ext-calvo_ppedro.calvo@ciemat.esCompilation failsAfter OPAL/src!602, OPAL compilation fails. The format of the new version is invalid (see [link](http://amas.web.psi.ch/opal/master/output/2022-10-19_10-49.txt))After OPAL/src!602, OPAL compilation fails. The format of the new version is invalid (see [link](http://amas.web.psi.ch/opal/master/output/2022-10-19_10-49.txt))gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/742change version in master to 2022.2-dev2022-10-19T15:11:24+02:00gsellchange version in master to 2022.2-dev2022.2gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/741change version strings for 2022.12022-10-14T13:53:10+02:00gsellchange version strings for 2022.12022.1gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/740Release version 2022.12023-03-30T16:12:12+02:00gsellRelease version 2022.1**source code**
* [x] review the file `src/addToDoxygenMainPage.h` (list of Authors)
* [x] create issue "Release version YEAR.N"
* [x] create branch OPAL-YEAR.N
* [x] create issue and MR with target branch YEAR.N
* [x] ...**source code**
* [x] review the file `src/addToDoxygenMainPage.h` (list of Authors)
* [x] create issue "Release version YEAR.N"
* [x] create branch OPAL-YEAR.N
* [x] create issue and MR with target branch YEAR.N
* [x] update version string in CMakeLists.txt and Doxyfile to YEAR.N
* [x] wait for approval and merge
* [x] tag version OPAL-YEAR.N.0 on branch OPAL-YEAR.N
* [x] create MR with target branch master
* [x] update version string in CMakeLists.txt and Doxyfile to YEAR.N+1-dev
* [x] wait for approval and merge
**binaries**
* [x] upload source tar-ball to <br>
`/afs/psi.ch/project/amas/webhosting/Downloads/OPAL/src/OPAL-YEAR.N.0.tar.xz`
* [x] binary for Linux
* [x] compile on opalrunner with build-recipes <br>
Note:
* [x] upload Linux binary package to <br>
`/afs/psi.ch/project/amas/webhosting/Downloads/OPAL/package/OPAL-YEAR.N.0-1-x86_64-linux.tar.xz`
* [x] tested by other developers
* [x] binary for macOS x86_64
* [x] compile with Clang on macOS with Intel CPU and current OS/Xcode
* [x] upload macOS binary package to <br>
`/afs/psi.ch/project/amas/webhosting/Downloads/OPAL/package/OPAL-YEAR.N.0-1-x86_64-macos.tar.xz`
* [x] tested by other developers
* [x] binary for macOS M1
* [x] compile with Clang on macOS with M1 CPU and current OS/Xcode
* [x] upload macOS binary package to <br>
`/afs/psi.ch/project/amas/webhosting/Downloads/OPAL/package/OPAL-YEAR.N.0-1-arm-macos.tar.xz`
* [x] tested by other developers
**regression-tests**
* [x] create new branch YEAR.N
* [x] setup the regression-tests to run the new version on opalrunner.psi.ch
**manual/documentation**
* [x] setup a new branch for the new version of the manual
* [x] fix version, branches and links in `Manual.attributes`
* [x] clone repository into <br>
`/afs/psi.ch/project/amas/webhosting/opal/Documentation/YEAR.N` <br>
and checkout new branch: <br>
`git clone https://gitlab.psi.ch/OPAL/documentation/manual.git YEAR.N && cd YEAR.N && git checkout OPAL-YEAR.N`
* [x] add links to the binaries in the wiki
* [x] update https://gitlab.psi.ch/OPAL/src/wikis/For-Developers/Compile-OPAL
* [x] compile the change log/release notes and publish it in the wiki: https://gitlab.psi.ch/OPAL/src/wikis/ReleaseNotes
* [x] build Doxygen documentation
* [x] update https://gitlab.psi.ch/OPAL/src/wikis/home
**tracker**
* [x] new milestone for `OPAL x.(y+1)`
* [x] update labels and milestones in issues
**varia**
* [x] PSI module
* [x] write e-mail to mailing list2022.1gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/739fixes for compilation on macOS2022-09-30T22:11:38+02:00gsellfixes for compilation on macOS2022.1gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/738Fix some uninitialized variables2022-09-21T15:16:30+02:00muralikrishnanFix some uninitialized variablesSome of the newly added quantities such as temperature, DebyeLength and plasma parameter in the stat file were uninitialized. Since during emission we do not compute them this may cause an issue.Some of the newly added quantities such as temperature, DebyeLength and plasma parameter in the stat file were uninitialized. Since during emission we do not compute them this may cause an issue.2022.1muralikrishnanmuralikrishnanhttps://gitlab.psi.ch/OPAL/src/-/issues/737P3M solver2022-09-23T12:59:37+02:00muralikrishnanP3M solver### Summary
Complete the P3M solver initiated by Benjamin Ulmer in his Master's thesis so that it can be used in
scenarios where collisions might be important.### Summary
Complete the P3M solver initiated by Benjamin Ulmer in his Master's thesis so that it can be used in
scenarios where collisions might be important.2022.1muralikrishnanmuralikrishnanhttps://gitlab.psi.ch/OPAL/src/-/issues/736Trimcoil implementation bug2023-02-13T15:50:53+01: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.
### What is the current *bug* behavior?
The trim c...### 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.
### What is the current *bug* behavior?
The trim coils do not work anymore.
### What is the expected *correct* behavior?
Trim coils working as normal.
### Possible fixes
The bug was introduced in 77c975dcca3b99cf195cbf020d5039f8be745646, specifically in line
https://gitlab.psi.ch/OPAL/src/-/blob/160558d02705876d15775fe7527227a142bc2088/src/Classic/AbsBeamline/Cyclotron.cpp#L101
the order of the arguments is wrong, see also https://gitlab.psi.ch/OPAL/src/-/blob/0601ed262da6cd29690abff38053c900f9bafacc/src/Classic/TrimCoils/TrimCoil.cpp#L432022.1snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.ch