src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2020-11-30T16:49:59+01:00https://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/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/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/609Transversely shifted distribution in temporal monitors2021-10-13T09:32:00+02:00krausTransversely shifted distribution in temporal monitorsIn temporal monitors the distribution is shifted in both transverse directions by half a centimeter.
There are more problems with monitors than initially thought.
- [x] The reference of a (infinitesimal thin) monitor is its center. Thi...In temporal monitors the distribution is shifted in both transverse directions by half a centimeter.
There are more problems with monitors than initially thought.
- [x] The reference of a (infinitesimal thin) monitor is its center. This is handled correctly for monitors that are placed with `ELEMEDGE` but not with absolute coordinates.
- [x] the path length stored in the h5 file isn't correct in case of "temporal" monitors
- [x] the stored position of the bunch relative to the reference particle in case of "temporal" monitors is shifted
Some more information on this. If I set a monitor at a position where Opal also stores the phase space then the phase space of the temporal monitor should be the same. Furthermore the stored s-pos and the position of the reference particle in lab coordinates should be the same as the position of the monitor (in input file and data/<file>_ElementPosition.txt).
For an example from bERLinPro I got\
**Position of monitor:**\
s-pos: 0.690843\
3D: (3.036208, 0, 9.772690)
**Position of reference particle in temporal monitor:**\
s-pos: 0.694659\
3D: (3.0345, 1.16469e-14, 9.76799)
The phase space:\
![longPhaseSpace](/uploads/5f4348a9b511889c4a20041b07b229db/longPhaseSpace.png)OPAL 2021.1krauskraushttps://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/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/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/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/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/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.chhttps://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/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/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/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/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/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/574P3M solver declaration is missing2021-05-26T12:54:27+02:00ext-calvo_ppedro.calvo@ciemat.esP3M solver declaration is missingP3M solver is missing as FieldSolver type (`FSTYPE`) in FieldSolver.cpp. In addition, it is not documented in the manual (OPAL/documentation/manual#41)P3M solver is missing as FieldSolver type (`FSTYPE`) in FieldSolver.cpp. In addition, it is not documented in the manual (OPAL/documentation/manual#41)OPAL-3.0https://gitlab.psi.ch/OPAL/src/-/issues/573Broken tests due to #5092020-07-22T16:32:17+02:00krausBroken tests due to #509OPAL 2.4.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/572Source elements should delete particles that are pushed back into it2020-07-21T09:52:51+02:00krausSource elements should delete particles that are pushed back into itThe current if statement doesn't detect any particle that has a negative z-component of the momentum and are pushed into it.The current if statement doesn't detect any particle that has a negative z-component of the momentum and are pushed into it.OPAL 2.4.0krauskraus