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/474cleanup ippl CMakeLists2020-02-24T13:36:50+01:00ext-calvo_ppedro.calvo@ciemat.escleanup ippl CMakeLists`ippl/src/Particle/CMakeLists.txt` call to `ParticleLayoutFromGrid.h`, but this file doesn't exist
`ippl/src/Utility/CMakeLists.txt` call to `RefBlock.h` but it doesn't exist`ippl/src/Particle/CMakeLists.txt` call to `ParticleLayoutFromGrid.h`, but this file doesn't exist
`ippl/src/Utility/CMakeLists.txt` call to `RefBlock.h` but it doesn't existext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://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/465Segmentation fault in FromFile due to RASTER=TRUE2020-02-22T22:21:22+01:00frey_mSegmentation fault in FromFile due to RASTER=TRUE### Summary
Bug report through OPAL mailing list:
```bash
Dear all,
I’m trying to use the FROMFILE option for scanning parameters in the sampler.
The files work fine for uniform distributions, but when I introduce FROMFILE,
I get the...### Summary
Bug report through OPAL mailing list:
```bash
Dear all,
I’m trying to use the FROMFILE option for scanning parameters in the sampler.
The files work fine for uniform distributions, but when I introduce FROMFILE,
I get the message, that
Error{1}> *** User error detected by function "FromFile()"
Error{1}> Couldn't find the dvar 'VQ1B' in the file './samplefile_corV3.dat'
Error{1}> Couldn't find the dvar 'VQ1B' in the file './samplefile_corV3.dat'
That happens, when I write ‘VQ1B’ – which is not in the manual.
Using the manual and writing VQ1B I get a segmentation fault.
[dinux9:59198] *** Process received signal ***
[dinux9:59198] Signal: Segmentation fault (11)
[dinux9:59198] Signal code: Address not mapped (1)
[dinux9:59198] Failing at address: (nil)
[dinux9:59198] [ 0] /lib64/libpthread.so.0(+0x10c10)[0x7fe6e78c4c10]
[dinux9:59198] [ 1] opal(_ZN8FromFile8allocateERKN5boost10shared_ptrI12CmdArgumentsEERKN4Comm8Bundle_tE+0x1190)[0x898ab0]
[dinux9:59198] [ 2] opal(_ZN9SampleCmd7executeEv+0x2d41)[0x8a16d1]
[dinux9:59198] [ 3] opal(_ZNK10OpalParser7executeEP6ObjectRKSs+0x35)[0x7b0e25]
[dinux9:59198] [ 4] opal(_ZNK10OpalParser11parseActionER9Statement+0x120)[0x7b4bc0]
[dinux9:59198] [ 5] opal(_ZNK10OpalParser5parseER9Statement+0x1cf)[0x7b541f]
[dinux9:59198] [ 6] opal(_ZNK10OpalParser3runEv+0x2c)[0x7b0aec]
[dinux9:59198] [ 7] opal(_ZNK10OpalParser3runEP11TokenStream+0x70)[0x7b5d40]
[dinux9:59198] [ 8] opal(main+0xf75)[0x6ff155]
[dinux9:59198] [ 9] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7fe6e5c2c725]
[dinux9:59198] [10] opal(_start+0x29)[0x70b039]
[dinux9:59198] *** End of error message ***
```
[2019_diag_EMF_corV3_sampler.in](/uploads/4c52ba86ecd3afbcca5ebefa8c52e095/2019_diag_EMF_corV3_sampler.in)
[samplefile_corV3.dat](/uploads/1d030ccb2d1c172171793f325963d805/samplefile_corV3.dat)
### What is the current *bug* behavior?
Segmentation fault.
### What is the expected *correct* behavior?
No segmentation fault.
### Possible fixes
The reason is the `RASTER=TRUE` option which increases the number of required samples in the `FROMFILE` file.
See in [line 335](https://gitlab.psi.ch/OPAL/src/blob/master/src/Sample/SampleCmd.cpp#L335) in `SampleCmd.cpp`. Hence `nSamples > globalSize_m` (`globalSize_m` is the number of lines in the provided FROMFILE file).
It can be fixed by
```C++
nSamples = std::min(nSamples, globalSize_m);
```frey_mfrey_mhttps://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/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/406OPAL aborts with "number of particles per cell too low" error when running SA...2019-12-16T09:00:12+01:00winklehner_dOPAL aborts with "number of particles per cell too low" error when running SAAMG solverOPAL aborts with "number of particles per cell too low" error when running SAAMG solver. This is due to a check in TrackRun.cpp. The SAAMG solver puts a grid not only around the bunch, but the whole simulation space, so this check should...OPAL aborts with "number of particles per cell too low" error when running SAAMG solver. This is due to a check in TrackRun.cpp. The SAAMG solver puts a grid not only around the bunch, but the whole simulation space, so this check should be avoided for SAAMG (similar to AMR).
(Note: I already resolved this, just need the issue for merging)winklehner_dwinklehner_dhttps://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/398use qualifier __restrict__ in src/Classic/Fields/Astra1DDynamic.h2019-11-21T13:50:39+01:00gselluse qualifier __restrict__ in src/Classic/Fields/Astra1DDynamic.hThe qualifier `__restrict__` must be used in `src/Classic/Fields/Astra1DDynamic.h` instead of `restrict`. This has been forgotten in MR !204The qualifier `__restrict__` must be used in `src/Classic/Fields/Astra1DDynamic.h` instead of `restrict`. This has been forgotten in MR !204gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/383building unit-tests failing after commit 9f2a3bd22019-11-11T14:08:54+01:00gsellbuilding unit-tests failing after commit 9f2a3bd2Since the "target link libraries" (dependencies) of libOPAL has been removed in 9f2a3bd2, building the unit-tests is failing.
EDIT (@snuverink\_j): replaced c530d5b7 with correct hash commit 9f2a3bd2 Since the "target link libraries" (dependencies) of libOPAL has been removed in 9f2a3bd2, building the unit-tests is failing.
EDIT (@snuverink\_j): replaced c530d5b7 with correct hash commit 9f2a3bd2 gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/382Restart append data to probe2019-11-11T13:37:16+01:00frey_mRestart append data to probe### Summary
When restarting a simulation, the output is not properly appended to the probe H5 file.
### Steps to reproduce
Restart a cyclotron simulation having a probe element.
### What is the current *bug* behavior?
It overwrite...### Summary
When restarting a simulation, the output is not properly appended to the probe H5 file.
### Steps to reproduce
Restart a cyclotron simulation having a probe element.
### What is the current *bug* behavior?
It overwrites the H5 file.
### What is the expected *correct* behavior?
It appends the new turns to the H5 file leaving the previous steps untouched.
### Possible fixes
Several possible fixes:
* Set the `OpalData::OPENMODE` to `APPEND` in `TrackRun` if `opal->inRestartRun() == True`
* Extend if-clause with `|| OpalData::getInstance()->inRestartRun()` at [line 224](https://gitlab.psi.ch/OPAL/src/blob/master/src/Classic/AbsBeamline/PluginElement.cpp#L224) of `PluginElement::save()`.frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/381linking with static boost libraries fails2019-11-08T22:52:39+01:00gselllinking with static boost libraries failsCurrent CMake versions are linking against static boost libraries by default if they are available. With static linking the order of the libraries matters. CMake reorders the libraries in some cases so that linking failsCurrent CMake versions are linking against static boost libraries by default if they are available. With static linking the order of the libraries matters. CMake reorders the libraries in some cases so that linking failsgsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/380Cyclotron collimator time step2022-06-29T19:32:27+02:00ext-calvo_ppedro.calvo@ciemat.esCyclotron collimator time step### Summary
Cyclotron collimator needs that each particle has own time step
### Steps to reproduce
Collimator in BANDRF cyclotron without acceleration:
[particulas_1000_xUyUzU_pxpypz.dat](/uploads/dbd53ea31cd5dde9d0d78704af2b9ad2/par...### Summary
Cyclotron collimator needs that each particle has own time step
### Steps to reproduce
Collimator in BANDRF cyclotron without acceleration:
[particulas_1000_xUyUzU_pxpypz.dat](/uploads/dbd53ea31cd5dde9d0d78704af2b9ad2/particulas_1000_xUyUzU_pxpypz.dat)
[BField_0T_const.dat](/uploads/1a6266e88c7494c18ce440936b276061/BField_0T_const.dat)
[trackingColl.in](/uploads/96a144999126653bd129a5f1c029770d/trackingColl.in)
### What is the current *bug* behavior?
In `ParallelCyclotronTracker` time step is not an attribute not null for each particle, so the simulations breaks in `CollimatorPhysics::copyFromBunch`, because `stepWidth=0`
### What is the expected *correct* behavior?
`dt[i]` should be equal to general timestep
### Relevant logs and/or screenshots
```
Error>
Error> *** Error:
Error> Internal OPAL error:
Error> Assertion 'tau >= 0.0' failed.
Error> tau = -inf, 0.0 = 0.000000
Error> in
Error> OPAL/src/src/Classic/Solvers/CollimatorPhysics.cpp, line 554
```
### Possible fixes
For `ParallelTTracker`, `dt[i]` is update throught `PartBunchBase<T, Dim>::switchToUnitlessPositions`2022.1snuverink_jjochem.snuverink@psi.chext-calvo_ppedro.calvo@ciemat.eskraussnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/375Probe does not register all particles2019-10-28T09:39:02+01:00frey_mProbe does not register all particles### Summary
The probe does not register all particles
### Steps to reproduce
Run an Ring simulation. Attached an example (however, the size needs to be reduced since it is pretty expensive)
[Ring.in](/uploads/48a83139533905a19983fa4...### Summary
The probe does not register all particles
### Steps to reproduce
Run an Ring simulation. Attached an example (however, the size needs to be reduced since it is pretty expensive)
[Ring.in](/uploads/48a83139533905a19983fa441eef49be/Ring.in)
### What is the current *bug* behavior?
Not all particles are registered.
### What is the expected *correct* behavior?
All particles are registered.snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://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/372Flattop distribution: particles in tail have wrong cutoff2019-10-16T15:43:09+02:00snuverink_jjochem.snuverink@psi.chFlattop distribution: particles in tail have wrong cutoffFor a flattop distribution the particles in the tail are calculated as follows (https://gitlab.psi.ch/OPAL/src/blob/master/src/Distribution/Distribution.cpp#L2660) introduced in 9c51f84b:
```c++
while (!allow) {
t = gs...For a flattop distribution the particles in the tail are calculated as follows (https://gitlab.psi.ch/OPAL/src/blob/master/src/Distribution/Distribution.cpp#L2660) introduced in 9c51f84b:
```c++
while (!allow) {
t = gsl_ran_gaussian_tail(randGen_m, 0, sigmaTFall_m);
if (t <= sigmaTRise_m * cutoffR_m[2]) {
t = -t + sigmaTFall_m * cutoffR_m[2];
allow = true;
}
}
```
For the cutoff `sigmaTRise_m` is used instead of `sigmaTFall_m`, it should read:
```c++
if (t <= sigmaTFall_m * cutoffR_m[2]) {
```snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.ch