src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2020-06-23T10:24:26+02:00https://gitlab.psi.ch/OPAL/src/-/issues/556missing include of Physics/Physics.h in tests/classic_src/AbsBeamline/SBend3D...2020-06-23T10:24:26+02:00gsellmissing include of Physics/Physics.h in tests/classic_src/AbsBeamline/SBend3DTest.cppOPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/546Bend without DESIGNENERGY gives infinite loop2020-07-09T10:48:48+02:00snuverink_jjochem.snuverink@psi.chBend without DESIGNENERGY gives infinite loop### Summary
Bend without DESIGNENERGY gives infinite loop
### Steps to reproduce
Define a bend without design energy
```
REAL bend_radius = 1;
REAL bend_angle = 0.1;
TLA_B : SBEND, ELEMEDGE=0.0, ANGLE = 25.0 / 180 * PI, FMAPFN = "1DP...### Summary
Bend without DESIGNENERGY gives infinite loop
### Steps to reproduce
Define a bend without design energy
```
REAL bend_radius = 1;
REAL bend_angle = 0.1;
TLA_B : SBEND, ELEMEDGE=0.0, ANGLE = 25.0 / 180 * PI, FMAPFN = "1DPROFILE1-DEFAULT", L = 2 * bend_radius * sin(bend_angle / 2.0), HAPERT = 2.2;
```
### What is the current *bug* behavior?
Infinite loop
### What is the expected *correct* behavior?
Either:
* Throw exception at parsing
* Track through with design energy zero
* Set design energy to initial energy of the beam
### Relevant logs and/or screenshots
```
OPAL[2]> Phase space dump frequency 1000 and statistics dump frequency 1 w.r.t. the time step.
SBend [2]> ======================================================================
SBend [2]> ===== TLA_B ==========================================================
SBend [2]> ======================================================================
SBend [2]> TLA_B using file 1DPROFILE1-DEFAULT (1D Profile type 1)
Warning> Warning: bend design energy is zero. Treating as drift.
^C
Program received signal SIGINT, Interrupt.
0x00000000008f10ee in Bend2D::calculateRefTrajectory(double&, double&) () at /home/scratch/OPAL/OPAL-fork/OPAL-src/ippl/src/PETE/PETE.h:800
800 PETE_DefineBinary(operator*, (a * b), OpMultipply)
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.212.el6.x86_64 infinipath-psm-3.0.1-115.1015_open.2.el6.x86_64 libnl-1.1.4-2.el6.x86_64 nss-pam-ldapd-0.7.5-20.el6_6.3.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) bt
#0 0x00000000008f10ee in Bend2D::calculateRefTrajectory(double&, double&) () at /home/scratch/OPAL/OPAL-fork/OPAL-src/ippl/src/PETE/PETE.h:800
#1 0x00000000008f2a4b in Bend2D::initialise(PartBunchBase<double, 3u>*, double&, double&) ()
at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/Classic/AbsBeamline/Bend2D.cpp:209
#2 0x000000000088ef8c in void OpalBeamline::visit<SBend>(SBend const&, BeamlineVisitor&, PartBunchBase<double, 3u>*) ()
at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/Elements/OpalBeamline.h:107
#3 0x000000000087a7ee in ParallelTTracker::visitBeamline(Beamline const&) ()
```
### Cause
In `Bend2D::calculateRefTrajectory` and `RBend3D::trackRefParticleThrough` the stepSize is defined as follows:
```c++
const double stepSize = betaGamma / gamma * Physics::c * dt;
```
without `designenergy_m` = 0, `betaGamma` = `gamma` = 0.
Here a minimal step size could be set.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.ch2020-07-24https://gitlab.psi.ch/OPAL/src/-/issues/545Bend2D does not take particle charge into account2020-07-17T10:10:50+02:00snuverink_jjochem.snuverink@psi.chBend2D does not take particle charge into account### Summary
A `RBEND` or `SBEND` element does not take the particle charge into account.
This was discovered by Finn O'Shea, and posted to the OPAL mailing list.
### Steps to reproduce
Define two beams and a bend:
```
BEAM1: BEAM, P...### Summary
A `RBEND` or `SBEND` element does not take the particle charge into account.
This was discovered by Finn O'Shea, and posted to the OPAL mailing list.
### Steps to reproduce
Define two beams and a bend:
```
BEAM1: BEAM, PARTICLE=PROTON, PC=P0, NPART=1000, BCURRENT=2.0e-03, BFREQ=50, CHARGE=1;
BEAM2: BEAM, PARTICLE=ALPHA, PC=P0, NPART=1000, BCURRENT=2.0e-03, BFREQ=50, CHARGE=2, MASS=3.7274;
REAL switch_angle = 0.1;
REAL design_energy = 0.05;
SBEND, ANGLE = switch_angle,
FMAPFN = "1DPROFILE1-DEFAULT",
ELEMEDGE = 2.664,
DESIGNENERGY = design_energy,
L = 2 * switch_radius * sin(switch_angle / 2.0),
E1 = 0, E2 = 0, // make a "true" sector magnet
```
### What is the current *bug* behavior?
Same bend magnet strength for each beam.
### What is the expected *correct* behavior?
Different bending strength, reduced by a factor 2 for BEAM2.
### Relevant logs and/or screenshots
```c++
void Bend2D::setBendStrength() {
// Estimate bend field magnitude.
double mass = RefPartBunch_m->getM();
double gamma = designEnergy_m / mass + 1.0;
double betaGamma = sqrt(pow(gamma, 2.0) - 1.0);
double charge = RefPartBunch_m->getQ();
fieldAmplitude_m = ((charge / std::abs(charge)) * betaGamma * mass /
(Physics::c * designRadius_m));
```
This formula does only take the sign of the charge into account. It is repeated in `findIdealBendParameters`
### Possible fixes
The formulas should be adjusted such that the charge is taken into account properly. The following methods should be fixed:
* setBendStrength
* findIdealBendParameters
Possibly also:
* findBendStrength
* estimateFieldAdjustmentStepOPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/544Charge per macroparticle wrong for multicharged particles?2020-05-25T17:18:40+02:00snuverink_jjochem.snuverink@psi.chCharge per macroparticle wrong for multicharged particles?### Summary
The charge per macroparticle seems wrongly calculated in case of OPAL-T.
This was discovered by Finn O'Shea, and posted to the OPAL mailing list.
### Steps to reproduce
```
BEAM1: BEAM, PARTICLE=PROTON, PC=P0, NPART=1000,...### Summary
The charge per macroparticle seems wrongly calculated in case of OPAL-T.
This was discovered by Finn O'Shea, and posted to the OPAL mailing list.
### Steps to reproduce
```
BEAM1: BEAM, PARTICLE=PROTON, PC=P0, NPART=1000, BCURRENT=2.0e-03, BFREQ=50, CHARGE=1;
BEAM2: BEAM, PARTICLE=ALPHA, PC=P0, NPART=1000, BCURRENT=2.0e-03, BFREQ=50, CHARGE=2, MASS=3.7274;
```
### What is the current *bug* behavior?
BEAM1:
```
OPAL> * ************** B U N C H *********************************************************
OPAL> * NP = 1000
OPAL> * Qtot = 39.500 [pC] Qi = 39.500 [fC]
```
BEAM2:
```
OPAL> * ************** B U N C H *********************************************************
OPAL> * NP = 1000
OPAL> * Qtot = 79.000 [pC] Qi = 79.000 [fC]
```
### What is the expected *correct* behavior?
These two beams are expected to have the same charge per bunch and macroparticle (since `BCURRENT` and `FREQ` are constant).
### Relevant logs and/or screenshots
In TrackRun::setDistributionParallelT():
```c++
// Return charge per macroparticle.
return beam->getCharge() * beam->getCurrent() / (beam->getFrequency()*1.0e6) / numberOfParticles;
```
### Possible fixes
The factor `beam->getCharge()` should not be present in the formula. This is correctly calculated for OPAL-Cycl. Ideally the formula should be refactored to a separate function to reduce code duplication.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/542SAAMG: Wrong results with elliptic geometry2020-07-13T15:33:13+02:00frey_mSAAMG: Wrong results with elliptic geometry### Summary
The SAAMG solver with elliptic geometry yields wrong results. It behaves like a simulation without space-charge.
[SAAMG-FODO.in](/uploads/e9067345a2ef0e6684e4d8cc3a018696/SAAMG-FODO.in)
### Steps to reproduce
Run the atta...### Summary
The SAAMG solver with elliptic geometry yields wrong results. It behaves like a simulation without space-charge.
[SAAMG-FODO.in](/uploads/e9067345a2ef0e6684e4d8cc3a018696/SAAMG-FODO.in)
### Steps to reproduce
Run the attached file with either `INTERPL=CONSTANT` or `INTERPL=LINEAR`.
### What is the current *bug* behavior?
The simulation behaves as if space-charge is switched off (`FSTYPE = NONE`).
OPAL 2.4.0frey_mfrey_m2020-07-24https://gitlab.psi.ch/OPAL/src/-/issues/541SAAMG crashes after 1000 steps2020-05-19T19:31:56+02:00frey_mSAAMG crashes after 1000 stepsThe SAAMG solver crashes after 1000 steps since the matrices are deleted in `deletePtr` and the boolean `isMatrixFilled_m` is not reset.The SAAMG solver crashes after 1000 steps since the matrices are deleted in `deletePtr` and the boolean `isMatrixFilled_m` is not reset.OPAL 2.4.0frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/531including `cmath` required on macOS2020-04-30T13:29:10+02:00gsellincluding `cmath` required on macOS### Summary
On macOS we have to include `cmath` in several files otherwise compilation fails
### Steps to reproduce
Compile on macOS with current Xcode
### Relevant logs and/or screenshots
```
/Users/gsell/src/OPAL/src/src/Classic/...### Summary
On macOS we have to include `cmath` in several files otherwise compilation fails
### Steps to reproduce
Compile on macOS with current Xcode
### Relevant logs and/or screenshots
```
/Users/gsell/src/OPAL/src/src/Classic/Filters/RelativeFFTLowPass.cpp:28:12: error: call to 'abs' is ambiguous
if(std::abs(LD[i]) > max_four_coef) {
^~~~~~~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/stdlib.h:132:6: note:
candidate function
int abs(int) __pure2;
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/stdlib.h:110:44: note:
candidate function
inline _LIBCPP_INLINE_VISIBILITY long abs( long __x) _NOEXCEPT {return labs(__x);}
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/stdlib.h:112:44: note:
candidate function
inline _LIBCPP_INLINE_VISIBILITY long long abs(long long __x) _NOEXCEPT {return llabs(__x);}
(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
include `cmath`
(If you can, link to the line of code that might be responsible for the problem)OPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/527runtime error on macOS: uncaught exception of type Teuchos::Exceptions::Inval...2020-07-06T13:48:05+02:00gsellruntime error on macOS: uncaught exception of type Teuchos::Exceptions::InvalidParameterType### Summary
Spiral inflector simulation crashes with uncaught exception (see below) on macOS. On Linux this error does **not** occur!
### Steps to reproduce
Run Daniel spiral inflector simulation
### Relevant logs and/or screenshots...### Summary
Spiral inflector simulation crashes with uncaught exception (see below) on macOS. On Linux this error does **not** occur!
### Steps to reproduce
Run Daniel spiral inflector simulation
### Relevant logs and/or screenshots
```
OPAL> * --------------------------------- Start tracking ------------------------------------ *
libc++abi.dylib: terminating with uncaught exception of type Teuchos::Exceptions::InvalidParameterType: Error! An attempt was made to access parameter "Nullspace" of type "Teuchos::RCP<Xpetra::MultiVector<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> > >"
in the parameter (sub)list "ANONYMOUS->user data"
using the incorrect type "Teuchos::RCP<Tpetra::MultiVector<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace>, false> >"!
```OPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/526Runtime error on macOS: reduction MPI_SUM is not defined on MPI_INTEGER2020-04-29T09:51:03+02:00gsellRuntime error on macOS: reduction MPI_SUM is not defined on MPI_INTEGER### Summary
Runtime error on macOS: reduction MPI_SUM is not defined on MPI_INTEGER
### Steps to reproduce
Run spiral inflector simulation
### What is the current *bug* behavior?
run-time error
### Relevant logs and/or screenshots
...### Summary
Runtime error on macOS: reduction MPI_SUM is not defined on MPI_INTEGER
### Steps to reproduce
Run spiral inflector simulation
### What is the current *bug* behavior?
run-time error
### Relevant logs and/or screenshots
```
OPAL> * --------------------------------- Start tracking ------------------------------------ *
[Nimloth:21640] *** An error occurred in MPI_Scan: the reduction operation MPI_SUM is not defined on the MPI_INTEGER datatype
[Nimloth:21640] *** reported by process [922615809,0]
[Nimloth:21640] *** on communicator MPI_COMM_WORLD
[Nimloth:21640] *** MPI_ERR_OP: invalid reduce operation
[Nimloth:21640] *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
[Nimloth:21640] *** and potentially your MPI job)
```
### Possible fixes
`MPI_INTEGER` is a type for Fortran, use `MPI_INT` instead.OPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/524Distribution Unit Tests failing2020-05-27T09:44:41+02:00snuverink_jjochem.snuverink@psi.chDistribution Unit Tests failing### Summary
The distribution unit tests are failing. See also http://amas.web.psi.ch/opal/unitTests/master/results_2020-04-25.xml
### Steps to reproduce
compile OPAL with `BUILD_UNIT_TESTS`
```
./tests/opal_unit_tests --gtest_filter=...### Summary
The distribution unit tests are failing. See also http://amas.web.psi.ch/opal/unitTests/master/results_2020-04-25.xml
### Steps to reproduce
compile OPAL with `BUILD_UNIT_TESTS`
```
./tests/opal_unit_tests --gtest_filter=Binomial*
./tests/opal_unit_tests --gtest_filter=Gauss*
```
### What is the current *bug* behavior?
Segmentation fault
### What is the expected *correct* behavior?
Successful test
### Relevant logs and/or screenshots
```
Ippl> CommMPI: Parent process waiting for children ...
Ippl> CommMPI: Initialization complete.
Note: Google Test filter = Gauss*
[==========] Running 3 tests from 2 test suites.
[----------] Global test environment set-up.
[----------] 2 tests from GaussTest
[ RUN ] GaussTest.FullSigmaTest1
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00007fff92fdfa8d in __dynamic_cast ()
(gdb) bt
#0 0x00007fff92fdfa8d in __dynamic_cast ()
#1 0x0000000100567089 in Attributes::setString (attr=@0x105808a00, val=@0x7fff5fbfee80) at /Users/jsnuverink/Documents/OPAL/fork/src/src/Attributes/Attributes.cpp:363
#2 0x0000000100013301 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__is_long () at /opt/local/libexec/llvm-9.0/include/c++/v1/string:37
#3 0x0000000100013301 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::~basic_string () at /Users/jsnuverink/Documents/OPAL/fork/src/tests/opal_src/Distribution/GaussTest.cpp:2137
#4 0x0000000100013301 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::~basic_string () at /opt/local/libexec/llvm-9.0/include/c++/v1/string:2133
#5 0x0000000100013301 in GaussTest_FullSigmaTest1_Test::TestBody () at /Users/jsnuverink/Documents/OPAL/fork/src/tests/opal_src/Distribution/GaussTest.cpp:37
#6 0x0000000100b7ef03 in testing::internal::HandleSehExceptionsInMethodIfSupported<testing::TestSuite, void> () at gtest.cc:2433
#7 0x0000000100b63757 in testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void> (object=0x104600c80, method=not implemented: member type in c_val_print
) at gtest.cc:2469
#8 0x0000000100b23932 in testing::Test::Run (this=0x104600c80) at gtest.cc:2508
#9 0x0000000100b2533a in testing::TestInfo::Run (this=0x104414330) at gtest.cc:2684
#10 0x0000000100b263af in testing::TestSuite::Run (this=0x1044144a0) at gtest.cc:2816
#11 0x0000000100b3efe9 in testing::internal::UnitTestImpl::RunAllTests (this=0x104412ff0) at gtest.cc:5338
#12 0x0000000100b7fe73 in testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> (object=0x104412ff0, method=not implemented: member type in c_val_print
) at gtest.cc:2433
#13 0x0000000100b65bd7 in testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> (object=0x104412ff0, method=not implemented: member type in c_val_print
) at gtest.cc:2469
#14 0x0000000100b3e902 in testing::UnitTest::Run (this=0x100d863a0) at gtest.cc:4925
#15 0x0000000100003502 in RUN_ALL_TESTS () at /opt/local/include/gtest/gtest.h:2473
```
### Possible fixes
The Distribution attribute `TYPE` has been changed in !341 to uppercase. All setString methods should be changed in setUpperCaseString.
```
Attributes::setString(dist.itsAttr[Attrib::Distribution::TYPE], "GAUSS");
```
to
```
Attributes::setUpperCaseString(dist.itsAttr[Attrib::Distribution::TYPE], "GAUSS");
```OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/514Fix error message in MGPoissonSolver2020-05-08T13:50:00+02:00frey_mFix error message in MGPoissonSolverThe following discussion from !327 should be addressed:
- [ ] @snuverink_j started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/327#note_20154):
> This message seems completely wrong. Can you fix it (or resolve by ...The following discussion from !327 should be addressed:
- [ ] @snuverink_j started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/327#note_20154):
> This message seems completely wrong. Can you fix it (or resolve by opening a new issue?)
```cpp
throw OpalException("ArbitraryDomain::compute",
"The class ArbitraryDomain only works with parallelization\n"
"in z-direction.\n"
"Please set PARFFTX=FALSE, PARFFTY=FALSE, PARFFTT=TRUE in \n"
"the definition of the field solver in the input file.\n");
```OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/513Improving reading of pressure data2020-07-06T11:54:52+02:00ext-calvo_ppedro.calvo@ciemat.esImproving reading of pressure dataThe pressure data from field map include holes from components as part of the geometry. To skip the LogicalError when particles hit with boundaries of the geometry (with pressure value null), the `checkPressure` function has been improvedThe pressure data from field map include holes from components as part of the geometry. To skip the LogicalError when particles hit with boundaries of the geometry (with pressure value null), the `checkPressure` function has been improvedOPAL 2.4.0ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/512compiler errors in tests/ippl_src with clang92021-01-13T22:09:20+01:00snuverink_jjochem.snuverink@psi.chcompiler errors in tests/ippl_src with clang9### Summary
Compiler errors with clang with `BUILD_OPAL_UNIT_TESTS=ON`
### Steps to reproduce
```
-- The C compiler identification is Clang 9.0.1
-- The CXX compiler identification is Clang 9.0.1
-- Check for working C compiler: /opt/...### Summary
Compiler errors with clang with `BUILD_OPAL_UNIT_TESTS=ON`
### Steps to reproduce
```
-- The C compiler identification is Clang 9.0.1
-- The CXX compiler identification is Clang 9.0.1
-- Check for working C compiler: /opt/local/bin/mpicc-mpich-clang90
```
### Relevant logs and/or screenshots
```
src/tests/ippl_src/Field/Field.cpp:1205:57: error: using integer absolute
value function 'abs' when argument is of floating point type [-Werror,-Wabsolute-value]
Vektor<unsigned,D3> N(static_cast<unsigned> (ceil( (abs(boxMin[0])+boxMax[0])/h[0])),
^
src/tests/ippl_src/Field/Field.cpp:1205:57: note: use function 'std::abs'
instead
```OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/511Link error if OpenMP is enabled2020-04-16T15:42:52+02:00gsellLink error if OpenMP is enabled### Summary
The linker reports undefined symbols if OpenMP is enabled.
### Steps to reproduce
```
cmake -DENABLE_OPENMP=TRUE ...
```
### What is the current *bug* behavior?
```
libOPAL.a(EnvelopeBunch.cpp.o): En la función `Envelo...### Summary
The linker reports undefined symbols if OpenMP is enabled.
### Steps to reproduce
```
cmake -DENABLE_OPENMP=TRUE ...
```
### What is the current *bug* behavior?
```
libOPAL.a(EnvelopeBunch.cpp.o): En la función `EnvelopeBunch::calcI() [clone ._omp_fn.0]':
EnvelopeBunch.cpp:(.text+0x82): referencia a `omp_get_num_threads' sin definir
EnvelopeBunch.cpp:(.text+0x89): referencia a `omp_get_thread_num' sin definir
libOPAL.a(EnvelopeBunch.cpp.o): En la función `EnvelopeBunch::calcI()':
EnvelopeBunch.cpp:(.text+0x9451): referencia a `GOMP_parallel' sin definir
../ippl/src/libippl.a(CommMPI.cpp.o): En la función `CommMPI::CommMPI(int&, char**&, int, bool, ompi_communicator_t*)':
CommMPI.cpp:(.text+0xf40): referencia a `omp_get_max_threads' sin definir
collect2: error: ld devolvió el estado de salida 1
make[2]: *** [src/CMakeFiles/opal.dir/build.make:117: src/opal] Error 1
make[1]: *** [CMakeFiles/Makefile2:738: src/CMakeFiles/opal.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
```
### Possible fixes
Set `-fopenmp` as a linker option.OPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/510compiler errors in ippl/test with clang92020-04-17T09:43:25+02:00snuverink_jjochem.snuverink@psi.chcompiler errors in ippl/test with clang9### Summary
Reported by @adelmann.
Compiler errors with clang with `ENABLE_IPPLTESTS=ON`
### Steps to reproduce
```
-- The C compiler identification is Clang 9.0.1
-- The CXX compiler identification is Clang 9.0.1
-- Check for worki...### Summary
Reported by @adelmann.
Compiler errors with clang with `ENABLE_IPPLTESTS=ON`
### Steps to reproduce
```
-- The C compiler identification is Clang 9.0.1
-- The CXX compiler identification is Clang 9.0.1
-- Check for working C compiler: /opt/local/bin/mpicc-mpich-clang90
```
### Relevant logs and/or screenshots
```
clang: error: optimization flag '-fno-tree-vrp'
```
```
ippl/test/particle/p3m3d.cpp:170:72: error: implicit instantiation of
undefined template 'ApplyField<double>'
HPB.for_each(RadiusCondition<double, Dim>(interaction_radius), ApplyField<double>(-1,interaction_radius));
```
```
ippl/test/particle/ChargedParticleFactory.hpp:564:73: error: unused
parameter 'extend_l' [-Werror,-Wunused-parameter]
void createParticleDistributionEquiPart(Particles & P, Vektor<double,3> extend_l, Vektor<double,3> extend_r...
```
### Possible fixes
* remove the `-fno-tree-vrp` flag
* comment out function parameters
* reorder code to avoid undefined template errorOPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/509OrbitThreader::computeMaximalImplicitDrift not yielding correct results2020-07-22T09:47:42+02:00krausOrbitThreader::computeMaximalImplicitDrift not yielding correct results### Summary
The method OrbitThreader::computeMaximalImplicitDrift doesn't yield correct results if elements are placed in 3D in the input file.
### Steps to reproduce
Download and unpack the attached [tar file](/uploads/b1fb3a7ed314c...### Summary
The method OrbitThreader::computeMaximalImplicitDrift doesn't yield correct results if elements are placed in 3D in the input file.
### Steps to reproduce
Download and unpack the attached [tar file](/uploads/b1fb3a7ed314c1a6d3141f6a4fa53646/3dplacedElement.tgz) and then run it with the current master version of OPAL.
### What is the current *bug* behavior?
The rotated quadrupole in the beam line is neglected in the output of the orbit threader and stops tracking after the second element.
### What is the expected *correct* behavior?
OPAL should track the beam through all elements.
### Relevant logs and/or screenshots
### Possible fixes
Track with a single particle until it leaves the bounding box which encloses all elements.
(If you can, link to the line of code that might be responsible for the problem)OPAL 2.4.0krauskraus2020-07-24https://gitlab.psi.ch/OPAL/src/-/issues/494Orbit threader throws an exception when TRACKBACK = TRUE and traveling wave s...2020-06-20T13:33:16+02:00krausOrbit threader throws an exception when TRACKBACK = TRUE and traveling wave structure present### Summary
When tracking the bunch back in time through a traveling wave structure then an exception is thrown in the method `TravelingWave::trackOnAxisParticle` which is used in the OrbitThreader.
### Steps to reproduce
Set `TRACK...### Summary
When tracking the bunch back in time through a traveling wave structure then an exception is thrown in the method `TravelingWave::trackOnAxisParticle` which is used in the OrbitThreader.
### Steps to reproduce
Set `TRACKBACK = TRUE` and add a traveling wave to the beamline.
### What is the current *bug* behavior?
Throws an exception.
### What is the expected *correct* behavior?
It should track the bunch back in time through a TWS.
### Possible fixes
Don't override the method of the base class RFCavity.OPAL 2.4.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/493Template directory not found when path contains spaces2020-03-31T17:10:45+02:00bellotti_rTemplate directory not found when path contains spacesFor OPAL sampler runs, the template file is not found when the path contains spaces. This could be easily solved by adding quotes `"` around the template directory path.For OPAL sampler runs, the template file is not found when the path contains spaces. This could be easily solved by adding quotes `"` around the template directory path.OPAL 2.4.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/490BEAM without particles specified crashes2020-07-06T08:44:02+02:00snuverink_jjochem.snuverink@psi.chBEAM without particles specified crashes### Summary
When the `BEAM` command has no particles (`NPARTS`) specified, OPAL crashes.
### Steps to reproduce
[drift-noparts.in](/uploads/a9848fe46eceb6059924d5971f621442/drift-noparts.in)
### What is the current *bug* behavior?
C...### Summary
When the `BEAM` command has no particles (`NPARTS`) specified, OPAL crashes.
### Steps to reproduce
[drift-noparts.in](/uploads/a9848fe46eceb6059924d5971f621442/drift-noparts.in)
### What is the current *bug* behavior?
Crash.
### What is the expected *correct* behavior?
Exit with error that no particles are specified.
### Relevant logs and/or screenshots
traceback:
```
Program received signal SIGSEGV, Segmentation fault.
Distribution::createOpalT(PartBunchBase<double, 3u>*, unsigned long&) ()
at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/Distribution/Distribution.cpp:2820
2820 double maxTOrZ = *longIt;
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.212.el6.x86_64 infinipath-psm-3.0.1-115.1015_open.2.el6.x86_64 libnl-1.1.4-2.el6.x86_64 nss-pam-ldapd-0.7.5-20.el6_6.3.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) bt
#0 Distribution::createOpalT(PartBunchBase<double, 3u>*, unsigned long&) ()
at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/Distribution/Distribution.cpp:2820
#1 0x0000000000885814 in TrackRun::setDistributionParallelT(Beam*) ()
at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/Classic/Algorithms/PartBunchBase.hpp:254
#2 0x000000000088861f in TrackRun::setupTTracker() () at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/Track/TrackRun.cpp:505
#3 0x000000000088914c in TrackRun::execute() () at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/Track/TrackRun.cpp:197
#4 0x00000000006ea0aa in OpalParser::execute(Object*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const () at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/OpalParser/OpalParser.cpp:139
#5 0x00000000006ee452 in OpalParser::parseAction(Statement&) const ()
at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/OpalParser/OpalParser.cpp:172
#6 0x00000000006edcf3 in OpalParser::parse(Statement&) const ()
at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/OpalParser/OpalParser.cpp:90
#7 0x00000000006e9d4c in OpalParser::run() const ()
at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/OpalParser/OpalParser.cpp:607
#8 0x000000000088276a in TrackCmd::execute() () at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/Track/TrackCmd.cpp:212
#9 0x00000000006ea0aa in OpalParser::execute(Object*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const () at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/OpalParser/OpalParser.cpp:139
#10 0x00000000006ee452 in OpalParser::parseAction(Statement&) const ()
at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/OpalParser/OpalParser.cpp:172
#11 0x00000000006edcf3 in OpalParser::parse(Statement&) const ()
at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/OpalParser/OpalParser.cpp:90
#12 0x00000000006e9d4c in OpalParser::run() const ()
at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/OpalParser/OpalParser.cpp:607
#13 0x00000000006eeb90 in OpalParser::run(TokenStream*) const ()
at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/OpalParser/OpalParser.cpp:632
#14 0x0000000000642812 in main () at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/Main.cpp:360
```
### Possible fixes
The method that crashes, takes the first entry without checking its size:
https://gitlab.psi.ch/OPAL/src/blob/master/src/Distribution/Distribution.cpp#L2817
```cpp
double Distribution::getMaxTOrZ() {
std::vector<double>::iterator longIt = tOrZDist_m.begin();
double maxTOrZ = *longIt;
```
This should be fixed. But in addition, it would be good to catch this when parsing, and OPAL can exit with an exception.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/489clang compiler warnings in unit tests2020-03-18T21:09:58+01:00snuverink_jjochem.snuverink@psi.chclang compiler warnings in unit testsThere are some clang (9.0.1) compiler warnings (-Wunused, -Wuninitialized) in the unit tests.There are some clang (9.0.1) compiler warnings (-Wunused, -Wuninitialized) in the unit tests.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.ch