src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2020-12-01T09:03:37+01:00https://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/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/605BANDRF fieldmaps have no effect beginning with OPAL 2.22022-02-04T10:22:01+01:00winklehner_dBANDRF fieldmaps have no effect beginning with OPAL 2.2h5hut field maps (.h5part), loaded as part of the BANDRF cyclotron type that produce the desired effect in OPAL 2.0, don't seem to have any effect in OPAL 2.2 and up. Cyclotron units used to be mm and kV/mm (same as MV/m). Have these inp...h5hut field maps (.h5part), loaded as part of the BANDRF cyclotron type that produce the desired effect in OPAL 2.0, don't seem to have any effect in OPAL 2.2 and up. Cyclotron units used to be mm and kV/mm (same as MV/m). Have these input units been changed somehow?
My current example is that of an electrostatic extraction septum that correctly pushes the final turn out by ~2 cm in OPAL 2.0, but does nothing in OPAL 2.2 and up.https://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/583Particles miss step in element with particle / matter interaction2023-11-30T15:49:00+01:00krausParticles miss step in element with particle / matter interactionIf two elements with particle / matter interaction are closer to each other than a single time step then the particles drift for one time step after leaving the first element and before entering the second element. In #308 the variable `...If two elements with particle / matter interaction are closer to each other than a single time step then the particles drift for one time step after leaving the first element and before entering the second element. In #308 the variable `tau` was introduced in the class `CollimatorPhysics` in order to get rid of a time structure. The quantity `tau` is computed for the first and the last time step. The meaning of `tau` is the fraction of a time step the current position of a particle is away from the edge. `tau` has to between `0.0` and `1.0`. However this isn't true if a particle hops from one element with particle / matter interaction to another. Currently this isn't handled correctly yet. Instead the particles drifts for at least one time step before it can enter another element with particle / matter interaction.krausext-calvo_ppedro.calvo@ciemat.eskraushttps://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.0gsellgsell