src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2022-07-13T13:47:19+02:00https://gitlab.psi.ch/OPAL/src/-/issues/724Fix particle deletion by beam stripping interactions2022-07-13T13:47:19+02:00ext-calvo_ppedro.calvo@ciemat.esFix particle deletion by beam stripping interactionsThe deletion of the particles is performed differently in Opal-cycl and Opal-t. Therefore, the call to `destroyT` in beam stripping algorithm must be restricted to simulations in Opal-t. Opal-cycl remove particles from the bunch in a spe...The deletion of the particles is performed differently in Opal-cycl and Opal-t. Therefore, the call to `destroyT` in beam stripping algorithm must be restricted to simulations in Opal-t. Opal-cycl remove particles from the bunch in a specific method in `ParallelCyclotronTracker`2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/725test_field.py failing test2022-07-18T10:26:54+02:00ext-rogers_ctest_field.py failing testTest is failing:
tests/opal_src/PyOpal/PyObjects/test_field.py
Segmentation fault because Ring.cpp refPartBunch_m is set to nullptr during Ring::finalise(). The refPartBunch_m is a borrowed reference and can be left as not null.Test is failing:
tests/opal_src/PyOpal/PyObjects/test_field.py
Segmentation fault because Ring.cpp refPartBunch_m is set to nullptr during Ring::finalise(). The refPartBunch_m is a borrowed reference and can be left as not null.2022.1ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/726OPAL compilation fails2022-07-26T17:47:43+02:00ext-calvo_ppedro.calvo@ciemat.esOPAL compilation failsSince MR !579 the [compilation of OPAL](http://amas.web.psi.ch/opal/master/output/2022-07-14_10-49.txt) is failing. I am not sure if the Python configuration has been completed.Since MR !579 the [compilation of OPAL](http://amas.web.psi.ch/opal/master/output/2022-07-14_10-49.txt) is failing. I am not sure if the Python configuration has been completed.2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/727Hard coded momentum tolerance2023-08-30T10:35:27+02:00ext-rogers_cHard coded momentum tolerance### Summary
In Opal-Cycl, there is a hardcoded parameter which requires the mean beam momentum to be within 1e-2 of the reference particle momentum. This is completely inappropriate for many simulations.
### Steps to reproduce
Run a l...### Summary
In Opal-Cycl, there is a hardcoded parameter which requires the mean beam momentum to be within 1e-2 of the reference particle momentum. This is completely inappropriate for many simulations.
### Steps to reproduce
Run a lattice with PC != mean momentum of the beam
### What is the current *bug* behavior?
Opal throws an exception. This comes from line 2411 of ParallelCyclotronTracker.cpp
### What is the expected *correct* behavior?
Really, opal should not throw an exception at all. There are many use cases where the reference momentum does not want to be the same as the actual distribution. At the very least the tolerance should be soft coded.
### Relevant logs and/or screenshots
Line 2414 of src/Algorithms/ParallelCyclotronTracker.cpp
```
if (std::abs(pTotalMean - referencePtot) / pTotalMean > 1e-2) { // ROGERS BUG; 1e-2 should be user parameter
throw OpalException("ParallelCyclotronTracker::checkFileMomentum",
"The total momentum of the particle distribution\n"
"in the global reference frame: " +
std::to_string(pTotalMean) + ",\n"
"is different from the momentum given\n"
"in the \"BEAM\" command: " +
std::to_string(referencePtot) + ".\n"
"In Opal-cycl the initial distribution\n"
"is specified in the local reference frame.\n"
"When using a \"FROMFILE\" type distribution, the momentum \n"
"must be the same as the specified in the \"BEAM\" command,\n"
"which is in global reference frame.");
}
```
I guess easiest would be to add a tolerance parameter to the FROMFILE distribution type. Default to 1e-2.2023.1ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/728Error in AsymmetricEnge derivatives2022-09-14T13:27:24+02:00ext-rogers_cError in AsymmetricEnge derivativesI found a bug in the AsymmetricEnge derivatives. Should be like:
```
f(x) = E(x-x0) + E(-x-x0) - 1
f^{(2n)} = E^{(2n)}(x-x0) + E^{(2n)}(-x-x0)
f^{(2n+1)} = E^{(2n)}(x-x0) - E^{(2n)}(-x-x0)
```
but I forgot to include the higher derivat...I found a bug in the AsymmetricEnge derivatives. Should be like:
```
f(x) = E(x-x0) + E(-x-x0) - 1
f^{(2n)} = E^{(2n)}(x-x0) + E^{(2n)}(-x-x0)
f^{(2n+1)} = E^{(2n)}(x-x0) - E^{(2n)}(-x-x0)
```
but I forgot to include the higher derivatives code.2022.1ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/730OPAL (master) gives a segfault when ending2022-09-14T11:29:06+02:00ext-piot_pOPAL (master) gives a segfault when ending### Summary
The most recent master version compiles fine on fedora fc35 but it gives a segfault upon finishing
A checkout of the OPAL-2011-1 compile on the same distro works just fine.
### Steps to reproduce the failure
git check out ...### Summary
The most recent master version compiles fine on fedora fc35 but it gives a segfault upon finishing
A checkout of the OPAL-2011-1 compile on the same distro works just fine.
### Steps to reproduce the failure
git check out
git checkout master
cd ../master
CC=mpicc CXX=mpicxx cmake ../src/ -DHDF5_C_COMPILER_EXECUTABLE=/usr/lib64/openmpi/bin/h5pcc -D CMAKE_BUILD_TYPE=Release -D CMAKE_CXX_FLAGS="-Wno-error=cast-function-type -Wno-cast-function-type -Wl,--copy-dt-needed-entries"
make -j 24
cd ../example
mpirun -np 8 ../master/src/opal awaDrive_all.in
### What is the current *bug* behavior?
```
Timings{0}> WakeField........... Wall max = 0, CPU max = 0
Timings{0}> Wall avg = 0, CPU avg = 0
Timings{0}> Wall min = 0, CPU min = 0
Timings{0}>
Timings{0}> Write H5-File....... Wall max = 2.27603, CPU max = 1.23
Timings{0}> Wall avg = 2.27519, CPU avg = 1.115
Timings{0}> Wall min = 2.27071, CPU min = 1.03
Timings{0}>
Timings{0}> Write Stat.......... Wall max = 0.105094, CPU max = 0.07
Timings{0}> Wall avg = 0.0356317, CPU avg = 0.02625
Timings{0}> Wall min = 0.0245887, CPU min = 0
Timings{0}>
Timings{0}> -----------------------------------------------------------------
[localhost:356319:0:356319] Caught signal 11 (Segmentation fault: address not mapped to object at address (nil))
[localhost:356320:0:356320] Caught signal 11 (Segmentation fault: address not mapped to object at address (nil))
[localhost:356318:0:356318] Caught signal 11 (Segmentation fault: address not mapped to object at address (nil))
[localhost:356321:0:356321] Caught signal 11 (Segmentation fault: address not mapped to object at address (nil))
==== backtrace (tid: 356320) ====
0 /lib64/libucs.so.0(ucs_handle_error+0x2a4) [0x7f1d48c29864]
1 /lib64/libucs.so.0(+0x2a41d) [0x7f1d48c2d41d]
2 /lib64/libucs.so.0(+0x2a5fa) [0x7f1d48c2d5fa]
3 opal() [0xc8f6c0]
4 opal() [0x910701]
5 opal() [0x7eb18c]
6 opal() [0xb935d9]
7 opal() [0x918acf]
8 opal() [0xa1a7af]
9 opal() [0x72c16a]
10 opal() [0x72c189]
11 opal() [0x6f368a]
12 /lib64/libc.so.6(+0x57a15) [0x7f1d4d257a15]
13 /lib64/libc.so.6(on_exit+0) [0x7f1d4d257b90]
14 /lib64/libc.so.6(+0x40447) [0x7f1d4d240447]
15 /lib64/libc.so.6(__libc_start_main+0x80) [0x7f1d4d2404f0]
16 opal() [0x4abbd5]
=================================
==== backtrace (tid: 356319) ====
0 /lib64/libucs.so.0(ucs_handle_error+0x2a4) [0x7fa60d660864]
1 /lib64/libucs.so.0(+0x2a41d) [0x7fa60d66441d]
2 /lib64/libucs.so.0(+0x2a5fa) [0x7fa60d6645fa]
3 opal() [0xc8f6c0]
4 opal() [0x910701]
5 opal() [0x7eb18c]
6 opal() [0xb935d9]
7 opal() [0x918acf]
```
### What is the expected *correct* behavior?
git check out git checkout OPAL-2011-1
cd ../OPAL-2011-1
CC=mpicc CXX=mpicxx cmake ../src/ -DHDF5_C_COMPILER_EXECUTABLE=/usr/lib64/openmpi/bin/h5pcc -D CMAKE_BUILD_TYPE=Release -D CMAKE_CXX_FLAGS="-Wno-error=cast-function-type -Wno-cast-function-type -Wl,--copy-dt-needed-entries"
make -j 24
cd ../example
mpirun -np 8 ../OPAL-2011-1/src/opal awaDrive_all.in
works fine
### Relevant logs and/or screenshots
the input file I use are the AWA photoinjector; the specific version is available at https://xgitlab.cels.anl.gov/awa/awa-opal-lattices2022.1https://gitlab.psi.ch/OPAL/src/-/issues/734SDDS wake function read error2022-09-14T11:28:20+02:00adelmannSDDS wake function read errorError>
Error> *** User error detected by function "Attributes::getString()"
Error> Attribute "FNAME" is not string.
Error> Attribute "FNAME" is not string.
application called MPI_Abort(MPI_COMM_WORLD, -100) - process 0
[unset]: ...Error>
Error> *** User error detected by function "Attributes::getString()"
Error> Attribute "FNAME" is not string.
Error> Attribute "FNAME" is not string.
application called MPI_Abort(MPI_COMM_WORLD, -100) - process 0
[unset]: write_line error; fd=-1 buf=:cmd=abort exitcode=-100
wakecorr: WAKE, TYPE="LONG-SHORT-RANGE", NBIN=500, FNAME="testWake220GHz.sdds" ;2022.1https://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.chhttps://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/739fixes for compilation on macOS2022-09-30T22:11:38+02:00gsellfixes for compilation on macOS2022.1gsellgsellhttps://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/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/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/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/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/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/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/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/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/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.1gsellgsell