src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2020-03-18T10:54:28+01:00https://gitlab.psi.ch/OPAL/src/-/issues/488clang compiler error: unmatched template parameter `const CenteringEnum*`2020-03-18T10:54:28+01:00snuverink_jjochem.snuverink@psi.chclang compiler error: unmatched template parameter `const CenteringEnum*`### Summary
Clang compiler errors for ippl unit test BCond.
### 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/m...### Summary
Clang compiler errors for ippl unit test BCond.
### 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
```
[ 97%] Building CXX object tests/CMakeFiles/opal_unit_tests.dir/ippl_src/Field/BCond.cpp.o
In file included from /Users/jsnuverink/Documents/OPAL/fork/src/tests/ippl_src/Field/BCond.cpp:7:
In file included from /Users/jsnuverink/Documents/OPAL/fork/src/ippl/src/FieldLayout/CenteredFieldLayout.h:127:
/Users/jsnuverink/Documents/OPAL/fork/src/ippl/src/FieldLayout/CenteredFieldLayout.hpp:313:3: error: no matching
function for call to 'centeredInitialize'
centeredInitialize(*this, mesh, p, vnodes);
^~~~~~~~~~~~~~~~~~
/Users/jsnuverink/Documents/OPAL/fork/src/tests/ippl_src/Field/BCond.cpp:411:38: note: in instantiation of member
function 'CenteredFieldLayout<2, UniformCartesian<2, double>, CartesianCentering<&CCCEnums<2, 2,
0>::vectorFace, 2, 2> >::CenteredFieldLayout' requested here
CenteredFieldLayout<Dim,M,vFace> layoutVFace(mesh);
^
/Users/jsnuverink/Documents/OPAL/fork/src/ippl/src/FieldLayout/CenteredFieldLayout.hpp:93:1: note: candidate
template ignored: substitution failure : deduced non-type template argument does not have the same type as
the corresponding template parameter ('CenteringEnum *' vs 'const CenteringEnum *')
centeredInitialize(CenteredFieldLayout<Dim,Mesh,
^
...
```
### Possible fixes
The template parameter CenteringEnum* always has a const qualifier, for example,
https://gitlab.psi.ch/OPAL/src/blob/master/ippl/src/Meshes/CartesianCentering.h#L35:
```c++
template<const CenteringEnum* CE, unsigned Dim, unsigned NComponents=1U>
class CartesianCentering
{
```
However the const qualifier seems too restrictive and I propose to remove it.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/487Clang compiler warning for IntTSC (-Wsign-compare)2020-03-20T11:54:33+01:00snuverink_jjochem.snuverink@psi.chClang compiler warning for IntTSC (-Wsign-compare)### Summary
Clang compiler warning for IntTSC (-Wsign-compare).
### 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/b...### Summary
Clang compiler warning for IntTSC (-Wsign-compare).
### 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
```
ippl/src/Particle/IntTSC.h:284:8: error: comparison of integers of
different signs: 'unsigned int' and 'int' [-Werror,-Wsign-compare]
if (p==-1) return .125*(1.-4.*dpos(i)+4.*dpos(i)*dpos(i));
~^ ~~
```
and many similar ones
### Possible fixes
The warning comes from
https://gitlab.psi.ch/OPAL/src/blob/master/ippl/src/Particle/IntTSC.h#L283
```c
auto W = [dpos](unsigned p, unsigned i) {
if (p==-1) return .125*(1.-4.*dpos(i)+4.*dpos(i)*dpos(i));
else if (p==0) return .25*(3.-4.*dpos(i)*dpos(i));
else if (p==+1) return .125*(1.+4.*dpos(i)+4.*dpos(i)*dpos(i)); };
```
`p` should be a signed integer instead of unsiged.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/485clang compiler errors for MPI_AllReduce (-Wtype-safety)2020-03-18T14:13:52+01:00snuverink_jjochem.snuverink@psi.chclang compiler errors for MPI_AllReduce (-Wtype-safety)### Summary
Clang compiler errors with MPI_AllReduce (-Wtype-safety)
### 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/lo...### Summary
Clang compiler errors with MPI_AllReduce (-Wtype-safety)
### 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
1.
```
src/Algorithms/ParallelSliceTracker.cpp:291:41: error: argument type
'bool *' doesn't match specified 'MPI' type tag that requires 'int *' [-Werror,-Wtype-safety]
MPI_Allreduce(MPI_IN_PLACE, &globalEOL_m, 1, MPI_INT, MPI_LAND, Ippl::getComm());
^~~~~~~~~~~~ ~~~~~~~
```
2.
```
src/Algorithms/bet/EnvelopeBunch.cpp:1458:33: error: argument type
'size_t *' (aka 'unsigned long *') doesn't match specified 'MPI' type tag that requires 'long *'
[-Werror,-Wtype-safety]
MPI_Allreduce(MPI_IN_PLACE, &count, 1, MPI_LONG, MPI_SUM, Ippl::getComm());
^~~~~~ ~~~~~~~~
```
3. some more similar to 2.
### Possible fixes
1.
https://gitlab.psi.ch/OPAL/src/blob/4868efe8cf31c3646c49387a293852acf215c2bb/src/Algorithms/ParallelSliceTracker.cpp#L291
```c++
MPI_Allreduce(MPI_IN_PLACE, &globalEOL_m, 1, MPI_INT, MPI_LAND, Ippl::getComm());
```
`globalEOL_m` is a boolean and this doesn't combine properly with `MPI_INT`.
Instead, the commented out line above:
```
reduce(&globalEOL_m, &globalEOL_m + 1, &globalEOL_m, OpBitwiseAndAssign());
```
compiles fine.
@kraus: there is a similar line in `ParallelTTracker.cpp`. Is that line correct in this case as well?
2.
https://gitlab.psi.ch/OPAL/src/blob/4868efe8cf31c3646c49387a293852acf215c2bb/src/Algorithms/bet/EnvelopeBunch.cpp#L1458
```c++
MPI_Allreduce(MPI_IN_PLACE, &count, 1, MPI_LONG, MPI_SUM, Ippl::getComm());
```
should rather be:
```c++
MPI_Allreduce(MPI_IN_PLACE, &count, 1, MPI_UNSIGNED_LONG, MPI_SUM, Ippl::getComm());
```OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/484clang compiler error for VerticalFFAMagnet (-Wabsolute-value)2020-03-17T10:48:05+01:00snuverink_jjochem.snuverink@psi.chclang compiler error for VerticalFFAMagnet (-Wabsolute-value)### Summary
Compiler error for VerticalFFAMagnet
### Steps to reproduce
```
Host OS System: Darwin-14.5.0
The C++ compiler identification is: AppleClang
The C++ compiler version is: 7.0.2.7000181
```
### Relevant logs and/or screensh...### Summary
Compiler error for VerticalFFAMagnet
### Steps to reproduce
```
Host OS System: Darwin-14.5.0
The C++ compiler identification is: AppleClang
The C++ compiler version is: 7.0.2.7000181
```
### Relevant logs and/or screenshots
```
src/Classic/AbsBeamline/VerticalFFAMagnet.cpp:82:9: error:
using integer absolute value function 'abs' when argument is of floating point type
[-Werror,-Wabsolute-value]
if (abs(R[0]) > halfWidth_m ||
^
/Users/jsnuverink/Documents/OPAL/fork/src/src/Classic/AbsBeamline/VerticalFFAMagnet.cpp:82:9: note:
use function 'std::abs' instead
if (abs(R[0]) > halfWidth_m ||
^~~
std::abs
```
### Possible fixes
Use `std::` namespaceOPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/483Compiler warnings from boost headers stops compilation2020-03-17T16:36:38+01:00snuverink_jjochem.snuverink@psi.chCompiler warnings from boost headers stops compilation### Summary
Warnings from boost headers result in compilation error.
### Steps to reproduce
System specifications:
```
Host OS System: Darwin-14.5.0
The C++ compiler identification is: AppleClang
The C++ compiler version is: 7.0.2.70...### Summary
Warnings from boost headers result in compilation error.
### Steps to reproduce
System specifications:
```
Host OS System: Darwin-14.5.0
The C++ compiler identification is: AppleClang
The C++ compiler version is: 7.0.2.7000181
Boost version: 1.66.0
```
### What is the current *bug* behavior?
Compiler warnings from boost files result in compilation error.
### What is the expected *correct* behavior?
Boost or dependent libraries should not trigger compiler errors.
### Relevant logs and/or screenshots
```
In file included from /Users/jsnuverink/Documents/OPAL/fork/src/src/Distribution/Distribution.cpp:10:
In file included from /Users/jsnuverink/Documents/OPAL/fork/src/src/Distribution/SigmaGenerator.h:37:
In file included from /opt/local/include/boost/numeric/ublas/matrix_sparse.hpp:16:
In file included from /opt/local/include/boost/numeric/ublas/vector_sparse.hpp:16:
/opt/local/include/boost/numeric/ublas/storage_sparse.hpp:401:35: error: unused parameter
'hint' [-Werror,-Wunused-parameter]
iterator insert (iterator hint, const value_type &p) {
^
```
### Possible fixes
Include the boost headers as system headers so that gcc and clang don't issue warnings (with `-isystem`)
In CMake this can be done with:
```cmake
include_directories (SYSTEM ${Boost_INCLUDE_DIRS})
```
As a side note it seems `include_directories` is deprecated and it is advised to use `target_include_directories` instead.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/480`VALUE` command does not print variable names2020-07-06T11:41:02+02:00snuverink_jjochem.snuverink@psi.ch`VALUE` command does not print variable names### Summary
The `VALUE` command does not print according to the example in the [manual](https://gitlab.psi.ch/OPAL/manual-master/blob/master/control.asciidoc#sec.control.value). The variable value is printed, but not its name.
### Ste...### Summary
The `VALUE` command does not print according to the example in the [manual](https://gitlab.psi.ch/OPAL/manual-master/blob/master/control.asciidoc#sec.control.value). The variable value is printed, but not its name.
### Steps to reproduce
Run the manual example
```
REAL A=4;
VALUE,VALUE=TABLE(5,#*A);
REAL P1=5;
REAL P2=7;
VALUE,VALUE={P1,P2,P1*P2-3};
```
### What is the current *bug* behavior?
Current output:
```
value: = {0,4,8,12,16}
value: = {5,7,32}
```
### What is the expected *correct* behavior?
Ideal output (also with spaces):
```
value: {0*A,1*A,2*A,3*A,4*A} = {0, 4, 8, 12, 16}
value: {P1,P2,P1*P2-3} = {5, 7, 32}
```
### Observations
After some debugging I found that this is due to the direct evaluation in the parser after which the equations that are evaluated are no longer in memory (only the variable name of the array `VALUE`). An definition (with `:=`) gives the correct output.
From the [manual](https://gitlab.psi.ch/OPAL/manual-master/blob/master/format.asciidoc):
_When the attribute value is a constant or an expression preceded by the delimiter `=` it is evaluated immediately and the result is assigned to the attribute as a constant. When the attribute value is an expression preceded by the delimiter `:=` the expression is retained and re-evaluated whenever one of its operands changes._
For example:
```
VALUE,VALUE:=TABLE(5,#*A);
```
gives:
```
value: TABLE(1:5:1,(#*A)) = {4,8,12,16,20}
```
Note that the table output is still different from the manual output.
### Possible fixes
No direct evaluation in the `VALUE` command, also with the `=` delimiter.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/477Missing include in Algorithms/bet/math/savgol.cpp2020-02-26T09:37:55+01:00snuverink_jjochem.snuverink@psi.chMissing include in Algorithms/bet/math/savgol.cppWith gcc 7.3.0 from psi modules on linux I get the compiler error:
```
src/Algorithms/bet/math/savgol.cpp:406:5: error: ‘memcpy’ was not declared in this scope
memcpy(&cIn[1], c, sizeof(double)*n);
^~~~~~
/home/scratch/OPAL/OP...With gcc 7.3.0 from psi modules on linux I get the compiler error:
```
src/Algorithms/bet/math/savgol.cpp:406:5: error: ‘memcpy’ was not declared in this scope
memcpy(&cIn[1], c, sizeof(double)*n);
^~~~~~
/home/scratch/OPAL/OPAL-fork/OPAL-src/src/Algorithms/bet/math/savgol.cpp:406:5: note: suggested alternative: ‘wmemcpy’
memcpy(&cIn[1], c, sizeof(double)*n);
^~~~~~
wmemcpy
```
This is due to a missing include `<cstring>`.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/476missing include of <algorithm> and usage of std::minmax()2020-02-25T17:26:17+01:00gsellmissing include of <algorithm> and usage of std::minmax()In `bet/profile.cpp` the header `<algorithm>` must be included. Don't now why it compiles on macOS without ...
`std::minmax()` has been removed from C++17! This should be replaced.In `bet/profile.cpp` the header `<algorithm>` must be included. Don't now why it compiles on macOS without ...
`std::minmax()` has been removed from C++17! This should be replaced.OPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/475Formula momentum conversion2021-04-23T17:10:39+02:00albajacas_aarnau.albajacas@psi.chFormula momentum conversion* [x] Add two functions to Utilities/Util
* [x] Update documentation
### Summary
I'm not sure if this is a bug, but I don't understand the formula used to convert P [eV/c] to $`\beta\gamma`$ [dimensionless] in the function [`Distribut...* [x] Add two functions to Utilities/Util
* [x] Update documentation
### Summary
I'm not sure if this is a bug, but I don't understand the formula used to convert P [eV/c] to $`\beta\gamma`$ [dimensionless] in the function [`Distribution::converteVToBetaGamma`](https://gitlab.psi.ch/OPAL/src/blob/master/src/Distribution/Distribution.cpp#L904):
```math
(\beta_x\gamma)=\sqrt{(\frac{P_x[{eV/c}]}{m_0c}+1)^2-1}.
```
If the user gives momentum in eV/c, I would imagine that the conversion should be
```math
\gamma\beta_x = \frac{P_xc}{mc^2}.
```
If it's not a bug then I think it should be better explained in the manual.OPAL 2.4.0albajacas_aarnau.albajacas@psi.chalbajacas_aarnau.albajacas@psi.ch2020-07-24https://gitlab.psi.ch/OPAL/src/-/issues/469asciih5block not working with recent H5Hut library?2020-03-02T13:48:39+01:00snuverink_jjochem.snuverink@psi.chasciih5block not working with recent H5Hut library?### Summary
The asciih5block script returns error messages and an empty (header only) file
### Steps to reproduce
```
module use unstable; module load gcc/7.3.0 mpich/3.3 hdf5/1.10.4 H5hut/2.0.0rc5
```
I believe this will happen with...### Summary
The asciih5block script returns error messages and an empty (header only) file
### Steps to reproduce
```
module use unstable; module load gcc/7.3.0 mpich/3.3 hdf5/1.10.4 H5hut/2.0.0rc5
```
I believe this will happen with any input file, an example is given here.
Example input file: [NewChimney_R000_D000E.txt](/uploads/88ca38d65d6d433b084ac7ec2765c716/NewChimney_R000_D000E.txt)
Modify ascii2h5block_asgic.cpp for the right dimensions: [ascii2h5block_asgic.cpp](/uploads/dcbcdc4b7018f73169bc7a507ee2b496/ascii2h5block_asgic.cpp)
```bash
$ export LDLIBS=-lH5hut
$ make ascii2h5block_asgic
$ ./ascii2h5block_asgic NewChimney_R000_D000E.txt out
--------------------------------------------------------
Using NewChimney_R000_D000E.txt to create test_CYC.h5part
Lines in finE: 67370
Hardcoded limits: x(-90/-10) cm
Hardcoded limits: y(-30/30) cm
Hardcoded limits: z(-1/1) cm
Hardcoded spacing: 0.5 cm
Hardcoded nlines: 67367
File nlines: 67365
Grid dimensions: Px = 23 , Py = 29 , Pz = 101
E_max = (29.0302, -5.6267, -23.2274) V/cm at index 20641.
Converting from V/cm and cm to kV/mm and mm before saving h5part
[proc 0] E: H5Block3dSetView: Iteration is invalid! Have you set the time step?
[proc 0] E: H5Block3dWriteVector3dFieldFloat64: No view has been defined!
[proc 0] E: H5Block3dWriteVector3dFieldFloat64: No view has been defined!
Done, bye ...
```
### What is the current *bug* behavior?
Header only H5-file
### What is the expected *correct* behavior?
H5-file with correct field
### Possible fixes
The `H5SetStep` should be set before the View:
```c++
H5SetStep(file, 0);
h5_err_t h5err = H5Block3dSetView(file,
0, gridPx - 1,
0, gridPy - 1,
0, gridPz - 1);
```
[This modified ascii2h5block_asgic.cpp](/uploads/3e55c0263d5930c84b6b5d933467277f/ascii2h5block_asgic.cpp) runs successfully.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/468Format of _ElementPositions.sdds files wrong2020-02-19T17:04:41+01:00krausFormat of _ElementPositions.sdds files wrong### Summary
The format of the data values in `_ElementPositions.sdds` is wrong. The numbers are written with `std::ios_base::hex` instead of `std::ios_base::dec`.
### Steps to reproduce
Run any input file for OPAL-T and check the dat...### Summary
The format of the data values in `_ElementPositions.sdds` is wrong. The numbers are written with `std::ios_base::hex` instead of `std::ios_base::dec`.
### Steps to reproduce
Run any input file for OPAL-T and check the data in the SDDS file.
### What is the current *bug* behavior?
The data look like this:
```
&data
mode=ascii,
no_row_counts=1
&end
1
OPAL 2.1.0 git rev. #a23b3950ffa3756d157d4e41dc04569663c2eb13
opal-t
0x1.f97b4a2339c0ep+4 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 ""
0x1.037cd7b767d82p+5 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 ""
0x1.037cd7b767d82p+5 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x1p+0 "D69"
```
### What is the expected *correct* behavior?
The data should start with lines similar like this:
```
&data
mode=ascii,
no_row_counts=1
&end
1
OPAL 2.1.0 git rev. #a23b3950ffa3756d157d4e41dc04569663c2eb13
opal-t
31.5926000000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 ""
32.4359583214 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 ""
32.4359583214 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 1.0000 "D69"
```
OPAL 2.4.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/423SIndex<Dim>::clear() template method not compiling2020-01-09T10:38:04+01:00snuverink_jjochem.snuverink@psi.chSIndex<Dim>::clear() template method not compilingWhile porting some of the IPPL tests to unit test I got the following compiler error:
```c++
In file included from /home/scratch/OPAL/OPAL-fork/OPAL-src/ippl/src/Index/SIndex.h:302:0,
from /home/scratch/OPAL/OPAL-fork/O...While porting some of the IPPL tests to unit test I got the following compiler error:
```c++
In file included from /home/scratch/OPAL/OPAL-fork/OPAL-src/ippl/src/Index/SIndex.h:302:0,
from /home/scratch/OPAL/OPAL-fork/OPAL-src/ippl/src/Field/BareField.h:31,
from /home/scratch/OPAL/OPAL-fork/OPAL-src/ippl/src/Field/Field.h:15,
from /home/scratch/OPAL/OPAL-fork/OPAL-src/tests/ippl_src/Index/Index.cpp:60:
/home/scratch/OPAL/OPAL-fork/OPAL-src/ippl/src/Index/SIndex.hpp: In instantiation of ‘void SIndex<Dim>::clear() [with unsigned int Dim = 2]’:
/home/scratch/OPAL/OPAL-fork/OPAL-src/ippl/src/Index/SIndexAssign.hpp:52:44: required from ‘static void SIndexAssignTraits<Dim, OpAssign>::initialize(SIndex<Dim>&) [with unsigned int Dim = 2]’
/home/scratch/OPAL/OPAL-fork/OPAL-src/ippl/src/Index/SIndexAssign.hpp:347:41: required from ‘void assign(SIndex<Dim>&, RHS, OP, const NDIndex<Dim>&, SIExprTag<IsExpr>) [with unsigned int Dim = 2; RHS = PETE_TBTree<OpOr, PETE_TBTree<OpEQ, BareFieldIterator<int, 2>, PETE_Scalar<int> >, PETE_TBTree<OpEQ, BareFieldIterator<int, 2>, PETE_Scalar<int> > >; OP = OpAssign; bool IsExpr = false]’
/home/scratch/OPAL/OPAL-fork/OPAL-src/ippl/src/Index/SIndexAssign.h:72:1: required from ‘void assign(SIndex<Dim>&, const PETE_Expr<T>&) [with unsigned int Dim = 2; RHS = PETE_TBTree<OpOr, PETE_TBTree<OpEQ, BareFieldIterator<int, 2>, PETE_Scalar<int> >, PETE_TBTree<OpEQ, BareFieldIterator<int, 2>, PETE_Scalar<int> > >]’
/home/scratch/OPAL/OPAL-fork/OPAL-src/ippl/src/Index/SIndex.h:100:11: required from ‘SIndex<Dim>& SIndex<Dim>::operator=(const PETE_Expr<B>&) [with T1 = PETE_TBTree<OpOr, PETE_TBTree<OpEQ, BareFieldIterator<int, 2>, PETE_Scalar<int> >, PETE_TBTree<OpEQ, BareFieldIterator<int, 2>, PETE_Scalar<int> > >; unsigned int Dim = 2]’
/home/scratch/OPAL/OPAL-fork/OPAL-src/tests/ippl_src/Index/Index.cpp:82:25: required from here
/home/scratch/OPAL/OPAL-fork/OPAL-src/ippl/src/Index/SIndex.hpp:339:10: error: ‘class std::shared_ptr<LSIndex<2> >’ has no member named ‘CopyForWrite’
(*a).CopyForWrite();
```
The method `CopyForWrite()` is defined in the RefCountedP class LSIndex does not inherit from it (only from class RefCounted).
The relevant templated method was never used (and thus not compiled).OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/420boost linker error that use boost_timer library2020-07-06T11:43:21+02:00snuverink_jjochem.snuverink@psi.chboost linker error that use boost_timer libraryFor some of the test applications I get a boost linker error:
```
[ 19%] Linking CXX executable TestFFT
../../src/libippl.a(Timer.cpp.o): In function `Timer::Timer()':
Timer.cpp:(.text+0x9): undefined reference to `boost::timer::cpu_tim...For some of the test applications I get a boost linker error:
```
[ 19%] Linking CXX executable TestFFT
../../src/libippl.a(Timer.cpp.o): In function `Timer::Timer()':
Timer.cpp:(.text+0x9): undefined reference to `boost::timer::cpu_timer::start()'
../../src/libippl.a(Timer.cpp.o): In function `Timer::stop()':
Timer.cpp:(.text+0x71): undefined reference to `boost::timer::cpu_timer::stop()'
Timer.cpp:(.text+0x7c): undefined reference to `boost::timer::cpu_timer::elapsed() const'
../../src/libippl.a(Timer.cpp.o): In function `Timer::start()':
Timer.cpp:(.text+0x55): undefined reference to `boost::timer::cpu_timer::start()'
collect2: error: ld returned 1 exit status
make[2]: *** [ippl/test/FFT/TestFFT] Error 1
make[1]: *** [ippl/test/FFT/CMakeFiles/TestFFT.dir/all] Error 2
```
This was with the recommended module list:
```
Currently Loaded Modulefiles:
1) cmake/3.10.3 4) boost/1.68.0 7) gsl/2.5 10) opal-toolchain/master
2) gcc/7.3.0 5) hdf5/1.10.4 8) trilinos/12.12.1
3) openmpi/3.1.3 6) H5hut/2.0.0rc5 9) OpenBLAS/0.2.20
```
This can be fixed by linking to the boost_timer library.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/409`DISTRIBUTION, CUTOFFPZ = 0` does not imply cutoff infinity and produces infi...2020-01-07T09:44:45+01:00snuverink_jjochem.snuverink@psi.ch`DISTRIBUTION, CUTOFFPZ = 0` does not imply cutoff infinity and produces infinite loop### Summary
The documentation of `DISTRIBUTION, CUTOFFPZ = 0` mentions an infinity cutoff, but this is currently not true.
### Steps to reproduce
set `DISTRIBUTION, CUTOFFPZ = 0`
### What is the current *bug* behavior?
Infinite loo...### Summary
The documentation of `DISTRIBUTION, CUTOFFPZ = 0` mentions an infinity cutoff, but this is currently not true.
### Steps to reproduce
set `DISTRIBUTION, CUTOFFPZ = 0`
### What is the current *bug* behavior?
Infinite loop
### What is the expected *correct* behavior?
According to the [manual](https://gitlab.psi.ch/OPAL/manual-master/wikis/distribution) `CUTOFFPZ`:
*Defines cutoff in $`p_{z}`$ dimension in units of $`\sigma_{pz}`$. If `CUTOFFPZ` $`= 0`$ then actual cutoff is $`p_{z}`$ is set to infinity.*
### Possible fixes
The following line in Distribution.cpp should be changed for cutoffP_m[2] in a similar way as x and y:
```c++
allow = (xAndYOk && pxAndPyOk && std::abs(z) < cutoffR_m[2] && std::abs(pz) < cutoffP_m[2]);
```
### Varia
For consistency I propose also to make `CUTOFFLONG=0` an infinite cutoff.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/405multiple regression tests are broken with DKS enabled2020-05-01T10:04:38+02:00gsellmultiple regression tests are broken with DKS enabledThe following regression tests failed or are broken with DKS enabled:
* AWAGun-1
* AWAGun-TrackBack-1
* Degrader-1
* Distribution-Binomial-1
* Distribution-Gaus-1
* EGunCTF3-1
* EGunCTF3-2
* ExternalField
* PSIGUN-1
* PerfectDiode
* Rest...The following regression tests failed or are broken with DKS enabled:
* AWAGun-1
* AWAGun-TrackBack-1
* Degrader-1
* Distribution-Binomial-1
* Distribution-Gaus-1
* EGunCTF3-1
* EGunCTF3-2
* ExternalField
* PSIGUN-1
* PerfectDiode
* RestartTest-1
* RestartTest-3
* RestartTest-4
* RingCyclotronMatched (broken with and without DKS)
* VFFA (not a DKS issue)
Results of the regression test for OPAL 2.1 with DKS enabled can be found here:
http://amas.web.psi.ch/opal/regressionTests/master-dksOPAL 2.4.0locans_ulocans_uhttps://gitlab.psi.ch/OPAL/src/-/issues/404regression test EGunCTF3-1 timed out with DKS2020-05-01T10:05:02+02:00gsellregression test EGunCTF3-1 timed out with DKS### Summary
OPAL 2.1 get stuck in regression test EGunCTF3-1 with DKS
### Steps to reproduce
Run regression test EGunCTF3-1 on opalrunner with DKS enabled
### What is the current *bug* behavior?
OPAL doesn't exit.### Summary
OPAL 2.1 get stuck in regression test EGunCTF3-1 with DKS
### Steps to reproduce
Run regression test EGunCTF3-1 on opalrunner with DKS enabled
### What is the current *bug* behavior?
OPAL doesn't exit.OPAL 2.4.0locans_ulocans_uhttps://gitlab.psi.ch/OPAL/src/-/issues/374Doxygen missing logo2019-12-27T10:51:51+01:00snuverink_jjochem.snuverink@psi.chDoxygen missing logoFrom @kraus in https://gitlab.psi.ch/OPAL/src/merge_requests/189#note_14016:
> Too late for this MR: doxygen assumes that the file ./amas.png exists. But currently it doesn't and should be added.From @kraus in https://gitlab.psi.ch/OPAL/src/merge_requests/189#note_14016:
> Too late for this MR: doxygen assumes that the file ./amas.png exists. But currently it doesn't and should be added.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/317Trim coils and closed orbit finder2020-06-18T15:42:32+02:00frey_mTrim coils and closed orbit finder### Summary
The closed orbit finder does not apply the trim coil fields correctly. One does not see any effect of TC15 to avoid the
Walkinshaw resonance in the PSI Ring cyclotron.
### Steps to reproduce
Apply different trim coil fiel...### Summary
The closed orbit finder does not apply the trim coil fields correctly. One does not see any effect of TC15 to avoid the
Walkinshaw resonance in the PSI Ring cyclotron.
### Steps to reproduce
Apply different trim coil fields and compute tune diagram.
### What is the current *bug* behavior?
(Almost) No effect of any trim coils.
### What is the expected *correct* behavior?
Trim coil 15 should shift the tune diagram such that the Walkinshaw resonance is avoided.
### Relevant logs and/or screenshots
Figure 14 of
https://arxiv.org/pdf/1905.06654.pdf
### Possible fixes
I assume it has something to do with units.
CC: @snuverink\_j OPAL 2.4.0frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/316reading fields in H5Block format fails if z-dimension is less than the number...2020-07-01T15:46:46+02:00gsellreading fields in H5Block format fails if z-dimension is less than the number of coresOPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/308Time shift and time structure in phase space after particle-matter interaction2020-07-30T21:23:18+02:00krausTime shift and time structure in phase space after particle-matter interaction### Summary
The longitudinal phase space exhibits a time structure and the time needed to penetrate the material differs significantly depending on the seed and number of cores used to compute. This can be seen in the following plot sho...### Summary
The longitudinal phase space exhibits a time structure and the time needed to penetrate the material differs significantly depending on the seed and number of cores used to compute. This can be seen in the following plot showing histograms for the time of arrival at a monitor after a degrader:
![hist_t](/uploads/86eed088ff9fbb4ac4b533f6510d5616/hist_t.png)
### Steps to reproduce
Run the Degrader-1 regression test and plot a histogram of the time of arrival at the monitor M1. Use different seeds and number of cores to run the test.
### What is the current *bug* behavior?
The phase space exhibits a time structure that corresponds to the length of the time step and the mean time of arrival differs significantly for different setups. This size of this time shift cannot be explained by the stochastic nature of the particle-matter interaction.
### What is the expected *correct* behavior?
There shouldn't be a regular time structure and the difference of mean time of arrival for different setups should be very small.
### Relevant logs and/or screenshots
See above.OPAL 2.4.0krauskraus2020-07-24