src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2021-02-08T13:30:30+01:00https://gitlab.psi.ch/OPAL/src/-/issues/636Loss files overwritten for collimators2021-02-08T13:30:30+01:00ext-calvo_ppedro.calvo@ciemat.esLoss files overwritten for collimatorsThe particles hitting the collimator and lost particles by energy loss in the material are saved in the same file because the file name are equal.
Renaming the file for lost particles by particle-matter interactions according to the lab...The particles hitting the collimator and lost particles by energy loss in the material are saved in the same file because the file name are equal.
Renaming the file for lost particles by particle-matter interactions according to the label of `PARTICLEMATTERINTERACTION` command, we'll be able to distinguish both casesOPAL 2021.1ext-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/603WHAT command used in regression tests2021-01-04T03:23:32+01:00krausWHAT command used in regression testsThe `WHAT` command was removed in revision 01405a79. However it is used in the regression tests to determine the revision of the source repository, [see here](https://gitlab.psi.ch/OPAL/NightlyBuild/-/blob/master/scripts/OpalRegressionTe...The `WHAT` command was removed in revision 01405a79. However it is used in the regression tests to determine the revision of the source repository, [see here](https://gitlab.psi.ch/OPAL/NightlyBuild/-/blob/master/scripts/OpalRegressionTests/regressiontest.py#L78). We should either find a different way to determine the revision or revert the deletion of the `WHAT` command.https://gitlab.psi.ch/OPAL/src/-/issues/439Unit Test TestSolvePolynomialQuadraticSmoothed disabled2020-12-04T14:21:53+01:00snuverink_jjochem.snuverink@psi.chUnit Test TestSolvePolynomialQuadraticSmoothed disabled### Summary
The (currently disabled) unit test PPSolveFactoryTestFixture.TestSolvePolynomialQuadraticSmoothed is crashing.
### Steps to reproduce
Enable the TestSolvePolynomialQuadraticSmoothed test in PPSolveFactoryTest.cpp and run t...### Summary
The (currently disabled) unit test PPSolveFactoryTestFixture.TestSolvePolynomialQuadraticSmoothed is crashing.
### Steps to reproduce
Enable the TestSolvePolynomialQuadraticSmoothed test in PPSolveFactoryTest.cpp and run the test.
### What is the current *bug* behavior?
Crash
### What is the expected *correct* behavior?
Successful test
### Relevant logs and/or screenshots
```
[ RUN ] PPSolveFactoryTestFixture.TestSolvePolynomialQuadraticSmoothed
gsl: ../gsl/gsl_vector_double.h:206: ERROR: index out of range
Default GSL error handler invoked.
Program received signal SIGABRT, Aborted.
0x0000003da42324f5 in raise () from /lib64/libc.so.6
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 zlib-1.2.3-29.el6.x86_64
(gdb) bt
#0 0x0000003da42324f5 in raise () from /lib64/libc.so.6
#1 0x0000003da4233cd5 in abort () from /lib64/libc.so.6
#2 0x00007ffff7bce65d in gsl_error () at /var/tmp/gsell/gsl-2.5/src/err/error.c:47
#3 0x00007ffff7d34669 in gsl_vector_ptr () from /opt/psi/Compiler/gsl/2.5/gcc/7.3.0/lib64/libgsl.so.23
#4 0x0000000000b1a010 in interpolation::PPSolveFactory::getDerivs(interpolation::Mesh::Iterator) ()
at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/Classic/Fields/Interpolation/PPSolveFactory.cpp:289
#5 0x0000000000b22a6c in interpolation::PPSolveFactory::solve() ()
at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/Classic/Fields/Interpolation/PPSolveFactory.cpp:322
#6 0x00000000006be2f0 in PPSolveFactoryTestFixture_TestSolvePolynomialQuadraticSmoothed_Test::TestBody() ()
at /home/scratch/OPAL/OPAL-fork/OPAL-src/tests/classic_src/Fields/Interpolation/PPSolveFactoryTest.cpp:194
```
### Possible fixes
This is due to these lines (https://gitlab.psi.ch/OPAL/src/blob/master/src/Classic/Fields/Interpolation/PPSolveFactory.cpp#L284):
```c++
MMatrix<double> coeffs =
polynomials_m[nearest.toInteger()]->GetCoefficientsAsMatrix();
MVector<double> values = coeffs*derivPolyVec_m[i];
derivValues_m[i] = std::vector<double>(polyDim_m);
for(int j = 0; j < posDim; ++j) {
derivValues_m[i][j] = values(j+1);
}
```
`posDim` is 3, while `values` and `derivValues_m[i]` have only length 2. Presumably the loop should be until `polyDim_m`? However while this change runs through without crash, the unit test fails.
### Todo List
* [x] Add a method to SquarePolynomialVector that analytically calculates the derivative of the polynomial vector at some point;
* [x] add appropriate test.
* [x] Add a test to SolveFactory;
* [x] check that SolveFactory does indeed correctly solve when given derivatives as well as values and returns a correct polynomial.
* [x] Fix the test in PPSolveFactory; in principle this is just handing off values to SolveFactory (it is a wrapper to handle building a number of polynomials from a grid, e.g. a field map).
* [x] Modify the boundary condition handling to improve quality of the fit when doing smoothing.
* [x] Add notes on interpolation to manual or wiki OPAL 2021.1ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/622Check read of FROMFILE distribution2020-12-01T09:03:37+01:00ext-calvo_ppedro.calvo@ciemat.esCheck read of FROMFILE distributionThere is an `OpalException` in `Distribution::createDistributionFromFile` to check if the external file of the initial distribution exists. But it is not working in parallel environment.There is an `OpalException` in `Distribution::createDistributionFromFile` to check if the external file of the initial distribution exists. But it is not working in parallel environment.OPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/620Header of loss files2020-11-30T16:49:59+01:00ext-calvo_ppedro.calvo@ciemat.esHeader of loss files### Summary
Bad implementation of the header in ASCII files
### What is the current *bug* behavior?
The header of loss files in ASCII format is bad written when simulations are performed in parallel environment and the time variable ...### Summary
Bad implementation of the header in ASCII files
### What is the current *bug* behavior?
The header of loss files in ASCII format is bad written when simulations are performed in parallel environment and the time variable is considered. If the node 0 has no particles, the header is incomplete
### What is the expected *correct* behavior?
The header should include `turn`, `bunchNum` and `time` variables
### Possible fixes
Make use of `hasTimeAttribute()` functionOPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/611fix floating point comparisons in BoundaryGeometry2020-10-09T15:15:02+02:00gsellfix floating point comparisons in BoundaryGeometry### Summary
Under certain conditions the line-segment triangle intersection test fails due to incorrect usage of floating point comparisons.
### Steps to reproduce
Run simulation with the following input files:
* [SAAMG-BeamPipe.in](...### Summary
Under certain conditions the line-segment triangle intersection test fails due to incorrect usage of floating point comparisons.
### Steps to reproduce
Run simulation with the following input files:
* [SAAMG-BeamPipe.in](https://amas.web.psi.ch/opal/issues/611/SAAMG-BeamPipe.in)
* [Pipe_1m_10cm.h5](https://amas.web.psi.ch/opal/issues/611/Pipe_1m_10cm.h5)
### What is the current *bug* behavior?
If a line-segment intersects with a triangle on or very close to an edge, the intersection is not found.
### Possible fixes
Use a proper algorithm to compare floating point numbers.OPAL 2021.1gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/615Opal version in master branch2020-10-09T13:30:32+02:00ext-calvo_ppedro.calvo@ciemat.esOpal version in master branchOPAL VERSION should be change to 2.5 in master branch (CMakeLists.txt actually shows 2.3)OPAL VERSION should be change to 2.5 in master branch (CMakeLists.txt actually shows 2.3)ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/612master does not compile any more2020-10-07T12:24:19+02:00gsellmaster does not compile any moreAfter merging !441 OPAL does not compile any more - at least if SAAMG_SOLVER is enabledAfter merging !441 OPAL does not compile any more - at least if SAAMG_SOLVER is enabledOPAL 2021.1gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/585Opal-T fails to write LossDataSink if executed in parallel2020-09-24T10:58:46+02:00krausOpal-T fails to write LossDataSink if executed in parallelThe order of switching of the elements is different on node 0 than on the other nodes.The order of switching of the elements is different on node 0 than on the other nodes.OPAL 2021.1krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/577Unexpected results for BANDRF2020-09-16T10:03:02+02:00ext-calvo_ppedro.calvo@ciemat.esUnexpected results for BANDRF### Summary
Since !388 (commit 10c4aa19) the results with BANDRF simulations are unexpected
### Steps to reproduce
Run single-particle simulations with the input [tracking_test.in](/uploads/0a4ed1e83da65945925860a5b3ad4130/tracking_t...### Summary
Since !388 (commit 10c4aa19) the results with BANDRF simulations are unexpected
### Steps to reproduce
Run single-particle simulations with the input [tracking_test.in](/uploads/0a4ed1e83da65945925860a5b3ad4130/tracking_test.in) in commits 10c4aa19 and 0d2ccc73 with the following fields ([Gap_18ene19.h5part](/uploads/e46d8e040ba6dd3d973d458949a71b47/Gap_18ene19.h5part), [Vacio_18ene19_2mm.h5part](/uploads/cf9c48fc479e96e4491f6f687e946154/Vacio_18ene19_2mm.h5part),[particulas_1_00.dat](/uploads/cfd32d95e17db92de37ac175c43092db/particulas_1_00.dat), [BField_real_4T_2.dat](/uploads/f9567783d8a24a17dbb5a36c6c30bef8/BField_real_4T_2.dat))
### What is the current *bug* behavior?
The tracking are completely different by a bad reading of electric fields in h5part format (I guess)
### What is the expected *correct* behavior?
The particle tracking should be exactly the same
### Relevant logs and/or screenshots
![Tracking_unexpected](/uploads/8cb09230e4cd2025614859b6640ac2c5/Tracking_unexpected.png)
### Possible fixesOPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/604link unit tests fails2020-08-27T18:13:49+02:00gselllink unit tests fails### Summary
Linking the unit-tests fails on macOS 10.15 using the OPAL Build Tool-chain
### Steps to reproduce
Error occurs on a almost minimal macOS installation in a VM
### Possible fixes
libs must be added to the link libraries o...### Summary
Linking the unit-tests fails on macOS 10.15 using the OPAL Build Tool-chain
### Steps to reproduce
Error occurs on a almost minimal macOS installation in a VM
### Possible fixes
libs must be added to the link libraries of the unit-testsOPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/586OrbitThreader doesn't track far enough when TRACKBACK=true2020-08-14T00:56:56+02:00krausOrbitThreader doesn't track far enough when TRACKBACK=trueOPAL 2.4.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/582EBDUMP for 3DDynamic field maps not working if in subdirectory2020-08-14T00:46:41+02:00krausEBDUMP for 3DDynamic field maps not working if in subdirectoryEBDUMP writes a VTK file for each field map of type 3DDynamic. It tries to write it to the directory `data/subdirectory` which in general doesn't exists. In the method `Fieldmap::write3DField` we should make sure that path is stripped fr...EBDUMP writes a VTK file for each field map of type 3DDynamic. It tries to write it to the directory `data/subdirectory` which in general doesn't exists. In the method `Fieldmap::write3DField` we should make sure that path is stripped from the file name.OPAL 2.4.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/593ClosedOrbitFinder/SigmaGenerator: Charge not applied correctly2020-08-11T11:40:36+02:00frey_mClosedOrbitFinder/SigmaGenerator: Charge not applied correctly### Summary
The class `ClosedOrbitFinder` does not apply the charge correctly. It is currently only valid with a `+1` elementary charge. If a user wants to find a closed orbit with electrons or other ions, the magnetic field is not cor...### Summary
The class `ClosedOrbitFinder` does not apply the charge correctly. It is currently only valid with a `+1` elementary charge. If a user wants to find a closed orbit with electrons or other ions, the magnetic field is not correctly applied.
See the computation of [bcon_m](https://gitlab.psi.ch/OPAL/src/-/blob/master/src/Distribution/ClosedOrbitFinder.h#L247) and
check [SigmaGenerator::initialize](https://gitlab.psi.ch/OPAL/src/-/blob/master/src/Distribution/SigmaGenerator.cpp#L469).
### Possible fixes
Used `PartBunchBase::getQ()` in order to compute the quantities correctly.
CC: @ext-calvo_p, @snuverink_jOPAL 2.4.0frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/594fix compilation error if NDEBUG is defined2020-08-10T16:02:52+02:00gsellfix compilation error if NDEBUG is defined### Summary
IPPL test p3m3dMicrobunching does not compile if `NDEBUG` is defined due to an unused variable.
### Steps to reproduce
Compile OPAL with IPPL tests enabled
### What is the current *bug* behavior?### Summary
IPPL test p3m3dMicrobunching does not compile if `NDEBUG` is defined due to an unused variable.
### Steps to reproduce
Compile OPAL with IPPL tests enabled
### What is the current *bug* behavior?OPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/587compiler errors with AMR/SAAMG enabled2020-08-07T17:47:38+02:00frey_mcompiler errors with AMR/SAAMG enabled[compiler_errors.txt](/uploads/03325acb25cc1db29b8718350e5004c8/compiler_errors.txt)
CC: @gsell[compiler_errors.txt](/uploads/03325acb25cc1db29b8718350e5004c8/compiler_errors.txt)
CC: @gsellOPAL 2.4.0frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/592Real array broken2020-08-07T14:31:06+02:00adelmannReal array broken### Summary
A definition of an array results in
```
Error>
Error> *** Parse error detected by function "Expressions::parseString()"
Error> *** in line 1 of file "array.in" before token "{":
Error> Real primary expected.
Error> ...### Summary
A definition of an array results in
```
Error>
Error> *** Parse error detected by function "Expressions::parseString()"
Error> *** in line 1 of file "array.in" before token "{":
Error> Real primary expected.
Error> Real primary expected.
```
### Steps to reproduce
Run this simple input file:
`REAL rf_settings = {10.1,11.1};`
### What is the current *bug* behavior?
OPAL stops with an parser error
### What is the expected *correct* behavior?
No errorOPAL 2.4.0https://gitlab.psi.ch/OPAL/src/-/issues/584parse error in VFFA-1.in2020-08-05T11:06:34+02:00gsellparse error in VFFA-1.in### Summary
The regression test VFFA-1 failed with a parse error if OPAL is compiled with
`-DENABLE_AMR=ON -DENABLE_SAAMG_SOLVER=ON`
### Steps to reproduce
Compile OPAL with the recommended tool-chain, enable
`-DENABLE_AMR=ON -DENABL...### Summary
The regression test VFFA-1 failed with a parse error if OPAL is compiled with
`-DENABLE_AMR=ON -DENABLE_SAAMG_SOLVER=ON`
### Steps to reproduce
Compile OPAL with the recommended tool-chain, enable
`-DENABLE_AMR=ON -DENABLE_SAAMG_SOLVER=ON` and run the VFFA-1
regression-test
### What is the current *bug* behavior?
```
105 OFFSET_X(delta_x, delta_y, tilt, bb_length, x_out): MACRO {
106 x_out = delta_x-bb_length*cos(tilt)/2.;
107 }
Error>
Error> *** Parse error detected by function "MacroCmd::makeTemplate()"
Error> *** in line 105 of file "VFFA-1.in" before token "MACRO":
Error> Missing MACRO body, should be "{...}".
Error> Missing MACRO body, should be "{...}".
```
--------------------------------------------------------------------------OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/588compiler errors with clang92020-08-04T14:13:03+02:00snuverink_jjochem.snuverink@psi.chcompiler errors with clang9### Summary
Compiler error with clang.
### Steps to reproduce
```
-- The C++ compiler identification is: Clang
-- The C++ compiler version is: 9.0.1
-- The MPI C++ compiler is: /opt/local/bin/mpicxx-mpich-clang90
```
### Relevant log...### Summary
Compiler error with clang.
### Steps to reproduce
```
-- The C++ compiler identification is: Clang
-- The C++ compiler version is: 9.0.1
-- The MPI C++ compiler is: /opt/local/bin/mpicxx-mpich-clang90
```
### Relevant logs and/or screenshots
```
[ 45%] Building CXX object src/CMakeFiles/libOPAL.dir/Classic/BeamlineCore/RBendRep.cpp.o
/Users/jsnuverink/Documents/OPAL/fork/src/src/Classic/BeamlineCore/RBendRep.cpp:35:17: error: unused variable
'entries' [-Werror,-Wunused-const-variable]
const Entry entries[] = {
^
1 error generated.
make[2]: *** [src/CMakeFiles/libOPAL.dir/Classic/BeamlineCore/RBendRep.cpp.o] Error 1
```snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.ch