src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2021-04-23T17:10:39+02:00https://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/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/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/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-24https://gitlab.psi.ch/OPAL/src/-/issues/564LONG-TRANSV-SHORT-RANGE wake not implemented2020-07-23T17:25:12+02:00snuverink_jjochem.snuverink@psi.chLONG-TRANSV-SHORT-RANGE wake not implemented### Summary
As discovered by @ext\-piot\_p the `LONG-TRANSV-SHORT-RANGE` wake is not implemented.
### Steps to reproduce
`WAKE` command with `TYPE=LONG-TRANSV-SHORT-RANGE`.
### What is the current *bug* behavior?
No warning message,...### Summary
As discovered by @ext\-piot\_p the `LONG-TRANSV-SHORT-RANGE` wake is not implemented.
### Steps to reproduce
`WAKE` command with `TYPE=LONG-TRANSV-SHORT-RANGE`.
### What is the current *bug* behavior?
No warning message, no wakefield.
### What is the expected *correct* behavior?
Correctly implemented wake, or exception thrown.
### Relevant logs and/or screenshots
```c++
} else if (Attributes::getString(itsAttr[TYPE]) == "LONG-TRANSV-SHORT-RANGE") {
//FIXME: NOT IMPLEMENTED YET!!!
} else {
wf_m = 0;
INFOMSG("no wakefunction attached" << endl);
}
```
### Possible fixes
An exception can be thrown, also in the case of a non-matching type (might be a typo).
The mention of `LONG-TRANSV-SHORT-RANGE` should be removed from the manual.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://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/570segmentation fault in unit-test Field.PeriodicBC2020-07-22T15:09:16+02:00gsellsegmentation fault in unit-test Field.PeriodicBC### Summary
Segmentation fault in unit-test `Field.PeriodicBC` on Merlin with the following toolchain:
```
module load cmake/3.15.5
module load gnuplot/5.2.7
module load Python/3.6.3
module load gcc/8.4.0
module load gsl/2.6
module lo...### Summary
Segmentation fault in unit-test `Field.PeriodicBC` on Merlin with the following toolchain:
```
module load cmake/3.15.5
module load gnuplot/5.2.7
module load Python/3.6.3
module load gcc/8.4.0
module load gsl/2.6
module load OpenBLAS/0.3.10
module load gtest/1.10.0
module load openmpi/3.1.6
module load amrex/18.07_3d
module load boost/1.70.0
module load hdf5/1.10.6
module load parmetis/4.0.3
module load H5hut/2.0.0rc6
module load trilinos/12.18.1
```
Same problem on macOS and Clang/10 instead of gcc/8.4.0.
But no problem on `opalrunner.psi.ch`!
### Steps to reproduce
Login to one of the login-node of Merlin, compile OPAL with above modules and run unit.tests or run on macOS 10.15 with current Xcode.
### What is the current *bug* behavior?
Segmentation fault in `Field.PeriodicBC`
```
[ RUN ] Field.PeriodicBC
[merlin-l-002:20033] *** Process received signal ***
[merlin-l-002:20033] Signal: Segmentation fault (11)
[merlin-l-002:20033] Signal code: Address not mapped (1)
[merlin-l-002:20033] Failing at address: 0xffffffffffffffe8
[merlin-l-002:20033] [ 0] /lib64/libpthread.so.0(+0xf630)[0x7fbc1aa4b630]
[merlin-l-002:20033] [ 1] /opt/psi/Programming/gcc/8.4.0/lib64/libstdc++.so.6(_ZNSo6sentryC2ERSo+0x16)[0x7fbc18a479c6]
[merlin-l-002:20033] [ 2] /opt/psi/Programming/gcc/8.4.0/lib64/libstdc++.so.6(_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l+0x28)[0x7fbc18a47fd8]
[merlin-l-002:20033] [ 3] /opt/psi/Programming/gcc/8.4.0/lib64/libstdc++.so.6(_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc+0x27)[0x7fbc18a483e7]
[merlin-l-002:20033] [ 4] opal_unit_tests(_ZN15FieldDebugPrintIdLj3EE5printER9BareFieldIdLj3EERK7NDIndexILj3EER6Informb+0x8fb)[0x136ef7b]
[merlin-l-002:20033] [ 5] opal_unit_tests(_Z4sfp3IdEvR9BareFieldIT_Lj3EEiiiiiiiiib+0x2dc)[0x136ff9c]
[merlin-l-002:20033] [ 6] opal_unit_tests(_Z3fp3IdEvR9BareFieldIT_Lj3EEb+0x75)[0x13705f5]
[merlin-l-002:20033] [ 7] opal_unit_tests(_ZN21Field_PeriodicBC_Test8TestBodyEv+0x996)[0x13960b6]
[merlin-l-002:20033] [ 8] opal_unit_tests(_ZN7testing8internal35HandleExceptionsInMethodIfSupportedINS_4TestEvEET0_PT_MS4_FS3_vEPKc+0x3a)[0x370176a]
[merlin-l-002:20033] [ 9] opal_unit_tests(_ZN7testing4Test3RunEv+0xba)[0x36f69ca]
[merlin-l-002:20033] [10] opal_unit_tests(_ZN7testing8TestInfo3RunEv+0x118)[0x36f6b18]
[merlin-l-002:20033] [11] opal_unit_tests(_ZN7testing8TestCase3RunEv+0xb5)[0x36f7135]
[merlin-l-002:20033] [12] opal_unit_tests(_ZN7testing8internal12UnitTestImpl11RunAllTestsEv+0x44c)[0x36f855c]
[merlin-l-002:20033] [13] opal_unit_tests(_ZN7testing8UnitTest3RunEv+0x51)[0x36f8651]
[merlin-l-002:20033] [14] opal_unit_tests(main+0xa8)[0xeb9a98]
[merlin-l-002:20033] [15] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7fbc18367545]
[merlin-l-002:20033] [16] opal_unit_tests[0xeec448]
[merlin-l-002:20033] *** End of error message ***
./run-tests: line 305: 20033 Segmentation fault ${tests_bin} "${unittests_args[@]}"
```OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.ch2020-07-24https://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/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.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/571Option MINBINEMITTED and MINSTEPFORREBIN not working2020-07-20T11:45:16+02:00krausOption MINBINEMITTED and MINSTEPFORREBIN not workingThese options just give the default values instead of the ones provided by the user.These options just give the default values instead of the ones provided by the user.OPAL 2.4.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/569fitting bend angle in Bend2D may run indefinitely in some circumstances2020-07-18T18:31:32+02:00krausfitting bend angle in Bend2D may run indefinitely in some circumstancesThe variable `fieldStep` has to change its sign depending on the sign of the amplitude.The variable `fieldStep` has to change its sign depending on the sign of the amplitude.OPAL 2.4.0krauskraushttps://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.ch