src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2022-02-04T16:05:23+01:00https://gitlab.psi.ch/OPAL/src/-/issues/680Remove interactive mode, replace it with additional help option.2022-02-04T16:05:23+01:00krausRemove interactive mode, replace it with additional help option.The interactive mode is presumably not used by anyone. I propose therefore to remove it and add instead an option to print the help for commands on the command line.
Additionally I noticed that Opal crashes while printing the help messa...The interactive mode is presumably not used by anyone. I propose therefore to remove it and add instead an option to print the help for commands on the command line.
Additionally I noticed that Opal crashes while printing the help messages. The reason is that the type names `predefined string`, `upper case string` and `upper case string array` are longer than 16 characters. However the user doesn't have to know what these types represent, they are simply strings and string arrays respectively.2022.1krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/257GA interface is appending new generation output to new json file, rather than...2019-07-04T17:15:48+02:00ext-edelen_aGA interface is appending new generation output to new json file, rather than having one generation output per json fileaccording to the input file:
```
INITIALPOPULATION=100,
MAXGENERATIONS=2,
NUM_MASTERS=1,
NUM_COWORKERS=8,
SIMTMPDIR="tmp",
TEMPLATEDIR="tmpl",
FIELDMAPDIR="fieldm...according to the input file:
```
INITIALPOPULATION=100,
MAXGENERATIONS=2,
NUM_MASTERS=1,
NUM_COWORKERS=8,
SIMTMPDIR="tmp",
TEMPLATEDIR="tmpl",
FIELDMAPDIR="fieldmaps",
NUM_IND_GEN=100,
GENE_MUTATION_PROBABILITY=0.8,
MUTATION_PROBABILITY=0.8,
RECOMBINATION_PROBABILITY=0.2;
```
It seems like this should be 200 samples (100 in population x 2 generations)
However, using mldb to convert to pk reports 300 samples:
```
OPAL ML Database Generator
Found 2 json files.
Write ML-Database 1nCGA-small-test.pk
xDim = 6 -> ['G0', 'G1', 'K0', 'K1', 'PH0', 'PH1']
yDim = 7 -> ['DE', 'EMITS', 'EMITX', 'EMITY', 'RMSS', 'RMSX', 'RMSY']
generations = 2
Data points = 300
```
Looking at the json files:
- 1_1nCGA_0.json has 100 individuals
- 2_1nCGA_0.json has 200 individuals
And if we compare the first individual in each case, they are both the same:
```
"G0": 63.7949,
"G1": 17.5757,
"K0": 474.876,
"K1": 185.284,
"PH0": -8.94274,
"PH1": -2.44182
```
So it looks like new data is just being appended to the new json file in subsequent generations rather than creating a new file for each generation with only that generation's data in it.snuverink_jjochem.snuverink@psi.chkraussnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/795Regression test broken: string constant duplicated2023-12-11T09:18:24+01:00ext-calvo_ppedro.calvo@ciemat.esRegression test broken: string constant duplicatedAfter merging !648 all the regression tests are broken (see [link](http://amas.web.psi.ch/opal/master/output/2023-12-01_21-49.txt)).
A string constant has been created for an attribute of OutputPlane that overwrites the name of an eleme...After merging !648 all the regression tests are broken (see [link](http://amas.web.psi.ch/opal/master/output/2023-12-01_21-49.txt)).
A string constant has been created for an attribute of OutputPlane that overwrites the name of an element. Therefore, all simulations are broken. The addition of this string constant is not necessary and should be deleted.ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/792OPAL Monitor Memory Usage2023-11-29T17:22:02+01:00adelmannOPAL Monitor Memory Usage### Summary
(Summarize the bug encountered concisely)
One thing I ran into recently is an out-of-memory issue when I run it with many "monitor" elements. What seems to be happening is that the memory allocated while saving the particles...### Summary
(Summarize the bug encountered concisely)
One thing I ran into recently is an out-of-memory issue when I run it with many "monitor" elements. What seems to be happening is that the memory allocated while saving the particles to disk doesn't get freed after the file is output. In my case, I was using 2 million particles and I could see the memory usage rise by 200MB as the first monitor output is saved to disk and then rise by another 200MB at the second and so on. Since I was producing video-like output with 48 monitors, it didn't take long to exceed our cluster's 4GB per core limit.
### Steps to reproduce
Run simulation with 2E6 particles and 48 monitors
### What is the current *bug* behavior?
out of memory
### What is the expected *correct* behavior?
no out of memory
### Relevant logs and/or screenshots
I did some digging in the source code and on line 367 in `src/Classic/Structure/LossDataSink.cpp` I saw that the vectors storing particle information in the monitor objects do get cleared. Reading online, though (since I'm not a C++ expert) I saw some people saying this might not free memory (https://stackoverflow.com/questions/13944886/is-stdvector-memory-freed-upon-a-clear). I implemented their suggestion, ie the following code to replace all of the clear methods.
### Possible fixes
std::vector<OpalParticle>().swap(particles_m);
std::vector<size_t>().swap(turnNumber_m);
std::vector<size_t>().swap(bunchNumber_m);
std::vector<double>().swap(spos_m);
std::vector<double>().swap(refTime_m);
std::vector<Vector_t>().swap(RefPartR_m);
std::vector<Vector_t>().swap(RefPartP_m);
std::vector<h5_int64_t>().swap(globalTrackStep_m);2023.1adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/789Compile error2023-10-16T13:16:21+02:00ext-rogers_cCompile error### Summary
The main branch fails to compile with the error
```
n file included from /usr/include/c++/11/cassert:44,
from /home/cr67/Software/install/include/boost/numeric/ublas/detail/config.hpp:16,
f...### Summary
The main branch fails to compile with the error
```
n file included from /usr/include/c++/11/cassert:44,
from /home/cr67/Software/install/include/boost/numeric/ublas/detail/config.hpp:16,
from /home/cr67/Software/install/include/boost/numeric/ublas/exception.hpp:19,
from /home/cr67/Software/install/include/boost/numeric/ublas/storage.hpp:26,
from /home/cr67/Software/install/include/boost/numeric/ublas/vector.hpp:21,
from /home/cr67/Software/install/include/boost/numeric/ublas/matrix.hpp:18,
from /home/cr67/Software/OPAL/opal_src_3/src/Algorithms/BoostMatrix.h:21,
from /home/cr67/Software/OPAL/opal_src_3/src/Classic/Algorithms/CoordinateSystemTrafo.h:4,
from /home/cr67/Software/OPAL/opal_src_3/src/Classic/AbsBeamline/ElementBase.h:67,
from /home/cr67/Software/OPAL/opal_src_3/src/AbstractObjects/Element.h:34,
from /home/cr67/Software/OPAL/opal_src_3/src/AbstractObjects/BeamSequence.h:21,
from /home/cr67/Software/OPAL/opal_src_3/src/AbstractObjects/BeamSequence.cpp:19:
/home/cr67/Software/OPAL/opal_src_3/src/Algorithms/BoostMatrix.h: In instantiation of ‘T prod_boost_vector(const boost::numeric::ublas::matrix<double>&, const T&) [with T = Vektor<double, 3>]’:
/home/cr67/Software/OPAL/opal_src_3/src/Classic/Algorithms/CoordinateSystemTrafo.h:78:29: required from here
/home/cr67/Software/OPAL/opal_src_3/src/Algorithms/BoostMatrix.h:28:19: error: ‘const class Vektor<double, 3>’ has no member named ‘size’; did you mean ‘Size’?
28 | assert(vector.size() == 3);
| ~~~~~~~^~~~
```
This arises because the compiler is expecting a method like ``Vektor::size()`` which does not exist. I note that Vektor::Size does appear to exist, but note the upper case.
Not that it should matter, but:
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
### Steps to reproduce
Build the master2023.1https://gitlab.psi.ch/OPAL/src/-/issues/782Single-particle simulation gets stuck2023-09-07T08:41:49+02:00ext-calvo_ppedro.calvo@ciemat.esSingle-particle simulation gets stuck### Summary
The simulation hangs when try to run single-particle simulation in parallel.
### Steps to reproduce
Run RingCyclotronSingleParticle regression test
```
mpirun -np 4 RingCyclotronSingleParticle.in
```
### What is the cur...### Summary
The simulation hangs when try to run single-particle simulation in parallel.
### Steps to reproduce
Run RingCyclotronSingleParticle regression test
```
mpirun -np 4 RingCyclotronSingleParticle.in
```
### What is the current *bug* behavior?
The reduce function of IPPL called in `Distribution::printDist` fails.
### What is the expected *correct* behavior?
There is an exception in `ParallelCyclotronTracker::initializeTracking_m` to avoid it, but the simulation gets stuck before entering the tracker.
### Possible fixes
A feasible solution is introduced a check between the number of particles in the distribution and the number of nodes before that, in `Distribution::checkParticleNumber`2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/781Segmentation fault running Opal-cycl with boundary geometry2023-09-13T11:20:37+02:00ext-calvo_ppedro.calvo@ciemat.esSegmentation fault running Opal-cycl with boundary geometryI've got an unexpected segmentation fault running Opal-Cycl simulations.
```
[aceler15:459721] *** Process received signal ***
[aceler15:459721] Signal: Segmentation fault (11)
[aceler15:459721] Associated errno: Unknown error 21871 (21...I've got an unexpected segmentation fault running Opal-Cycl simulations.
```
[aceler15:459721] *** Process received signal ***
[aceler15:459721] Signal: Segmentation fault (11)
[aceler15:459721] Associated errno: Unknown error 21871 (21871)
[aceler15:459721] Signal code: (-1210805744)
[aceler15:459721] Failing at address: 0x25c
[aceler15:459721] [ 0] /usr/lib64/libc.so.6(+0x4eb50)[0x7f5ab1a7fb50]
[aceler15:459721] [ 1] opal(+0xecc644)[0x556f23eb8644]
[aceler15:459721] [ 2] opal(+0x9c528a)[0x556f239b128a]
[aceler15:459721] [ 3] opal(+0x75b576)[0x556f23747576]
[aceler15:459721] [ 4] opal(+0x75b899)[0x556f23747899]
[aceler15:459721] [ 5] opal(+0x718d6a)[0x556f23704d6a]
[aceler15:459721] [ 6] /usr/lib64/libc.so.6(+0x5126c)[0x7f5ab1a8226c]
[aceler15:459721] [ 7] /usr/lib64/libc.so.6(on_exit+0x0)[0x7f5ab1a823a0]
[aceler15:459721] [ 8] /usr/lib64/libc.so.6(__libc_start_main+0xec)[0x7f5ab1a6bd8c]
[aceler15:459721] [ 9] opal(+0x5243ae)[0x556f235103ae]
[aceler15:459721] *** End of error message ***
--------------------------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--------------------------------------------------------------------------
```
I attach the input files needed to reproduce the issue:
[tracking.in](/uploads/a84549a3f0c0e72fc2528edade1b1001/tracking.in)
[particulas_1E4.dat](/uploads/b398ed9242251cb467a9f440ac6ac824/particulas_1E4.dat)
[Geom_holeTargetLine.h5](/uploads/84d6c6c15d316fc0228fd3b04affaa1a/Geom_holeTargetLine.h5)
[Gap_18ene19.h5part](https://gitlab.psi.ch/OPAL/src/uploads/e46d8e040ba6dd3d973d458949a71b47/Gap_18ene19.h5part)
[Vacio_18ene19_2mm.h5part](https://gitlab.psi.ch/OPAL/src/uploads/cf9c48fc479e96e4491f6f687e946154/Vacio_18ene19_2mm.h5part)
[BField_real_4T_2.dat](https://gitlab.psi.ch/OPAL/src/uploads/f9567783d8a24a17dbb5a36c6c30bef8/BField_real_4T_2.dat)
Curiously, the simulation finalizes properly… (see [tracking.out](/uploads/8bdb58dbba9b08d6b50f6642e1ea9be4/tracking.out))2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/780Regression tests broken2023-09-29T12:25:17+02:00ext-calvo_ppedro.calvo@ciemat.esRegression tests brokenBeamLine-1, BeamLine-2 and PROSCAN-1 regression tests [are broken](http://amas.web.psi.ch/opal/regressionTests/master/results_2023-08-24_21-49.xml) since f1081e540647eef178c4350fd97b82d45e814cdcBeamLine-1, BeamLine-2 and PROSCAN-1 regression tests [are broken](http://amas.web.psi.ch/opal/regressionTests/master/results_2023-08-24_21-49.xml) since f1081e540647eef178c4350fd97b82d45e814cdc2023.1sadr_msadr_mhttps://gitlab.psi.ch/OPAL/src/-/issues/779No lbal output file with ENABLE_AMR2023-09-25T16:06:46+02:00ext-calvo_ppedro.calvo@ciemat.esNo lbal output file with ENABLE_AMR`.lbal` output file is not written when OPAL is compiled with `ENABLE_AMR=TRUE`
`LBalWriter::write(PartBunchBase<double, 3>* beam)` has to be declared upper in SDDSWriter class`.lbal` output file is not written when OPAL is compiled with `ENABLE_AMR=TRUE`
`LBalWriter::write(PartBunchBase<double, 3>* beam)` has to be declared upper in SDDSWriter class2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/778RFkick bug with MTS integrator2023-09-04T11:52:38+02:00ext-calvo_ppedro.calvo@ciemat.esRFkick bug with MTS integratorWorking on #773 I have found that there is an error produced by a wrongly implemented unit change. So up, ParallelCyclotronTracker works internally in ns, therefore, several unit changes are necessary throughout the code.
`ParallelCyclo...Working on #773 I have found that there is an error produced by a wrongly implemented unit change. So up, ParallelCyclotronTracker works internally in ns, therefore, several unit changes are necessary throughout the code.
`ParallelCyclotronTracker::RFkick` method has as input variables `t` and `dt` in ns, as they are subsequently transformed to s in `RFCavity::getMomentaKick`. However, `ParallelCyclotronTracker::push` used with MTS integrator calculates `dt1` in s, and is not changed to ns before calling `RFkick`, so the results are not corrected.
This error affects the RingCyclotronMTS regression tests (OPAL/regression-tests#116).2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/775Masks2023-08-30T09:34:47+02:00adelmannMasksThe issue appears to be that when I use certain masks elements, I see bleed through in a particular region. A detailed description of the problem, including reproducer can be found
[here](https://psilists.ethz.ch/sympa/arc/opal/2023-07/...The issue appears to be that when I use certain masks elements, I see bleed through in a particular region. A detailed description of the problem, including reproducer can be found
[here](https://psilists.ethz.ch/sympa/arc/opal/2023-07/msg00021.html)2023.1adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/774VFFA-1 regression test fails2023-09-14T08:40:39+02:00ext-calvo_ppedro.calvo@ciemat.esVFFA-1 regression test failsVFFA-1 test fails since commit bfc9b5f226219494303f162371c6cc36cdabc10cVFFA-1 test fails since commit bfc9b5f226219494303f162371c6cc36cdabc10c2023.1https://gitlab.psi.ch/OPAL/src/-/issues/771use 0.0 instead of epsilon in division by zero check2023-08-17T15:45:04+02:00gselluse 0.0 instead of epsilon in division by zero checkThe division by zero test introduced in !626 should not use a epsilon but 0.0.The division by zero test introduced in !626 should not use a epsilon but 0.0.2023.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/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/767Problem in Command DUMPEMFIELDS and DUMPFIELDS2023-08-22T10:12:45+02:00ext-rogers_cProblem in Command DUMPEMFIELDS and DUMPFIELDS### Summary
By email from Dou Gouliang
>>>
When I use the command "DUMPFIELDS" and "DUMPEMFIELDS" , the opal_2.4 shows the error (annex 1):
```
Error> *** Error:
Error> Internal OPAL error:
Error> Assertion 'idx.i < num_gridpx_m - 1' ...### Summary
By email from Dou Gouliang
>>>
When I use the command "DUMPFIELDS" and "DUMPEMFIELDS" , the opal_2.4 shows the error (annex 1):
```
Error> *** Error:
Error> Internal OPAL error:
Error> Assertion 'idx.i < num_gridpx_m - 1' failed.
Error> idx.i = 118, num_gridpx_m - 1 = 118.000000
Error> in
Error> /afs/psi.ch/user/g/gsell/private/src/OPAL/src/src/Classic/Fields/FM3DH5BlockBase.h, line 163
```
I have checked my inputfile ,and there is no wrong experssion. The detailed experssion is :
```
DUMPEMFIELDS, COORDINATE_SYSTEM = Cartesian, X_START= -0.8, X_STEPS=1601, DX= 0.001, Y_START=-0.25, Y_STEPS=501, DY= 0.001, Z_START=-0.02, Z_STEPS=41, DZ=0.001, T_START=0,T_STEPS=1, DT=0.1 ,FILE_NAME="FIELDEM-MAPXYZ.dat";
```
When I try to split the original output area of X into two parts, opal can output the corresponding two parts normally. First change X_STEPS to 117, and then change X_START and X_STEPS to -0.215 and 204.
And I re-ran another cyclotron simulation and got the same error, except idx.i changed to 14 .
>>>
and later
>>>
I ran it again in a newer version of OPAL(opal-2022.01) and found the same errors. In particular, I used OPAL-2022.01 as a Linux binary package from the official website.
>>>
lattice in attached zip...
[input_file.zip](/uploads/0c4926991866db21e66977b22b9e06c7/input_file.zip)2023.1ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/763ascii2h5block error reading data2023-08-24T11:15:06+02:00ext-calvo_ppedro.calvo@ciemat.esascii2h5block error reading data### Summary
I've got the following error running ascii2h5block tool
```
[proc 0] E: H5Block3dWriteVector3dFieldFloat64: Write to dataset '/Step#0/Block/Efield/0' failed.
```
In addition, the loop to save the results in the h5part for...### Summary
I've got the following error running ascii2h5block tool
```
[proc 0] E: H5Block3dWriteVector3dFieldFloat64: Write to dataset '/Step#0/Block/Efield/0' failed.
```
In addition, the loop to save the results in the h5part format is not necessary, since the input files should already be sorted in the correct format. Therefore, it is sufficient to read the data directly
An enhancement can be included to ensure that the number of data in the fields matches the grid specified in the input header.
### Possible fixes
`H5Block3dSetView` has to be adapted to each field, separately for E-field and H-field.2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/756Wrong class member2023-08-23T10:00:55+02:00ext-calvo_ppedro.calvo@ciemat.esWrong class memberOPAL compilation [fails](http://amas.web.psi.ch/opal/master/output/2023-04-05_10-49.txt). The bug was introduced in OPAL/src!613. I get the following error compiling with SAAMG solver
```
error: ‘class Tpetra::Map<>’ has no member named...OPAL compilation [fails](http://amas.web.psi.ch/opal/master/output/2023-04-05_10-49.txt). The bug was introduced in OPAL/src!613. I get the following error compiling with SAAMG solver
```
error: ‘class Tpetra::Map<>’ has no member named ‘getLocalNumElements’
```2023.1https://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.ch