src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2019-11-08T22:52:39+01:00https://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.chhttps://gitlab.psi.ch/OPAL/src/-/issues/371Modulation on flattop distribution creates a gap2019-10-18T23:43:02+02:00albajacas_aarnau.albajacas@psi.chModulation on flattop distribution creates a gap### Summary
When introducing a modulation in the flattop distribution, there is a gap between the end of t_flattop and t_rise. This is because the flat part is mistakenly displaced.
The line `t += sigmaTFall_m * cutoffR_m[2];` is missin...### Summary
When introducing a modulation in the flattop distribution, there is a gap between the end of t_flattop and t_rise. This is because the flat part is mistakenly displaced.
The line `t += sigmaTFall_m * cutoffR_m[2];` is missing.
### Steps to reproduce
Flattop distribution with
```
FTOSCAMPLITUDE = 50,
FTOSCPERIODS = 7,
WRITETOFILE = True,
```
Then look at the particle distribution along the longitudinal axis
albajacas_aarnau.albajacas@psi.chalbajacas_aarnau.albajacas@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/365Bug in Variator::variate()2019-10-16T15:26:19+02:00snuverink_jjochem.snuverink@psi.chBug in Variator::variate()Observed by @ext-kranjcevic_m:
> I've been looking at [..] commits c21cfcf1 and 29790810.
>In Optimizer/EA/Variate.h, in variate, the individual can be declared infeasible (lines 221, 224). However, I don't see that it is then also rem...Observed by @ext-kranjcevic_m:
> I've been looking at [..] commits c21cfcf1 and 29790810.
>In Optimizer/EA/Variate.h, in variate, the individual can be declared infeasible (lines 221, 224). However, I don't see that it is then also removed from individualsToEvaluate_m, which can result in a segmentation fault in dispatch_forward_solves, because ind (line 459 in Optimizer/EA/FixedPisaNsga2.tcc) can be a null pointer. Fortunately, when the number of tries in the variator is high enough (e.g., 100 tries), this is unlikely to happen.
>Executing lines 460-485 in Optimizer/EA/FixedPisaNsga2.tcc only if (ind != NULL) should fix the problem.snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/364Optimizer stops to write to disk after a couple of configurations2019-10-08T10:16:18+02:00bellotti_rOptimizer stops to write to disk after a couple of configurationsI'm having problems with the configurations in [this repo](https://gitlab.psi.ch/bellotti_r/awa_masters), in the directory ```optim-quads```.
Steps to reproduce
==================
- Run the batch job provided in the repo (change the pat...I'm having problems with the configurations in [this repo](https://gitlab.psi.ch/bellotti_r/awa_masters), in the directory ```optim-quads```.
Steps to reproduce
==================
- Run the batch job provided in the repo (change the path to OPAL to your path)
- The job runs normally, but after 2min or so, nothing is written to the disk anymore, even if you wait 20min
- Problems do not arise if ```--ntasks=8``` is set in the Slurm file
- The same job runs fine with OPAL 2.0, so it is not a bad configurationhttps://gitlab.psi.ch/OPAL/src/-/issues/360End position in findStartPosition wrong2019-09-30T14:16:19+02:00krausEnd position in findStartPosition wrongFrom [this line to line 1265](https://gitlab.psi.ch/OPAL/src/blob/OPAL-2.0/src/Algorithms/ParallelTTracker.cpp#L1258) there are two errors:
1. There is a sign error in line 1265
1. The push method of the Boris pusher pushes particles for...From [this line to line 1265](https://gitlab.psi.ch/OPAL/src/blob/OPAL-2.0/src/Algorithms/ParallelTTracker.cpp#L1258) there are two errors:
1. There is a sign error in line 1265
1. The push method of the Boris pusher pushes particles for a half time step. But we want it to push a full time step.
These bugs are fixed in the master with f5edc17e but needs to be fixed in OPAL-2.0.krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/356Cavity cuts lines2019-09-27T09:11:48+02:00frey_mCavity cuts lines### Summary
When a cavity is in the beam line it cuts the beam in longitudinal direction.
### Steps to reproduce
Run the Injector 2 with cavities in.
### What is the current *bug* behavior?
[injector_2](/uploads/925750a5a5194eb6a4...### Summary
When a cavity is in the beam line it cuts the beam in longitudinal direction.
### Steps to reproduce
Run the Injector 2 with cavities in.
### What is the current *bug* behavior?
[injector_2](/uploads/925750a5a5194eb6a495feb76c2ffbb0/injector_2.png)frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/355Wrong bunch information2019-09-27T09:12:54+02:00frey_mWrong bunch information### Summary
Wrong magnitude of `rmin` and `rmax` in case of OPAL-Cycl.
### Steps to reproduce
Run Injector-2 with OPAL-master or OPAL-1.6
### What is the current *bug* behavior?
`rmin` and `rmax` are scaled by a factor 1000 which ...### Summary
Wrong magnitude of `rmin` and `rmax` in case of OPAL-Cycl.
### Steps to reproduce
Run Injector-2 with OPAL-master or OPAL-1.6
### What is the current *bug* behavior?
`rmin` and `rmax` are scaled by a factor 1000 which yields:
```bash
OPAL> * *********************** Bunch information in local frame: ************************
OPAL> * rmax = ( 14.11518 , 22.17745 , 8.35929 ) [um]
OPAL> * rmin = ( -13.28184 , -20.78026 , -8.34465 ) [um]
OPAL> * rms beam size = ( 3.13787 , 4.45083 , 2.06234 ) [mm]
OPAL> * **********************************************************************************
```
```bash
OPAL> * *********************** Bunch information in global frame: ***********************
OPAL> * rmax = ( 355.14915 , 214.51694 , 8.35600 ) [um]
OPAL> * rmin = ( 323.97821 , 178.14940 , -8.34800 ) [um]
OPAL> * rms beam size = ( 3.55602 , 4.12442 , 2.06234 ) [mm]
OPAL> * **********************************************************************************
```
The bunch position in global frame is ```R = 392.01 mm``` which does not agree with the unit of `[um]`. The bunch
is also bigger!
### What is the expected *correct* behavior?
```bash
OPAL> * *********************** Bunch information in local frame: ************************
OPAL> * rmax = ( 14.11518 , 22.17745 , 8.35929 ) [mm]
OPAL> * rmin = ( -13.28184 , -20.78026 , -8.34465 ) [mm]
OPAL> * rms beam size = ( 3.13787 , 4.45083 , 2.06234 ) [mm]
OPAL> * **********************************************************************************
```
and
```bash
OPAL> * *********************** Bunch information in global frame: ***********************
OPAL> * rmax = ( 355.14915 , 214.51694 , 8.35600 ) [mm]
OPAL> * rmin = ( 323.97821 , 178.14940 , -8.34800 ) [mm]
OPAL> * rms beam size = ( 3.55602 , 4.12442 , 2.06234 ) [mm]
OPAL> * **********************************************************************************
```
### Possible fixes
Remove `lengthUnitConverter`
```C++
if (OpalData::getInstance()->isInOPALCyclMode()) {
lengthUnitConverter = 0.001;
pathLength = getLPath();
}
rmax_m *= lengthUnitConverter;
rmin_m *= lengthUnitConverter;
```frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/350CMAKE add on NERSC2019-08-20T10:44:45+02:00adelmannCMAKE add on NERSC### Summary
Compilation fails on cori.nersc.gov
### Steps to reproduce
(How one can reproduce the issue - this is very important)
On cori01.nersc.gov try to compile OPAL/master
### What is the current *bug* behavior?
Compilation fai...### Summary
Compilation fails on cori.nersc.gov
### Steps to reproduce
(How one can reproduce the issue - this is very important)
On cori01.nersc.gov try to compile OPAL/master
### What is the current *bug* behavior?
Compilation fails
### Relevant logs and/or screenshots
none
### Possible fixes
For any one else who might be compiling soon.
Adding one line to CMakeLists.txt allowed me to use the defaults on NERSC:
```
cookbg@cori01:~/consult/INC0141785/src> ls
diff --git a/CMakeLists.txt b/CMakeLists.txt
index c60179a4..29d64821 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -126,6 +126,7 @@ if (USE_STATIC_LIBRARIES)
endif ()
set (Boost_USE_MULTITHREADED OFF)
set (Boost_USE_STATIC_RUNTIME OFF)
+set (Boost_NO_BOOST_CMAKE ON)
find_package (Boost
REQUIRED COMPONENTS chrono filesystem iostreams regex serialization system timer)
if (Boost_INCLUDE_DIRS)
```OPAL 2.0.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/345remove obsolete build instructions and Makefile.def's2019-07-26T11:39:14+02:00gsellremove obsolete build instructions and Makefile.def'sAll the Makefile.def's are obsolete
- [x] done in OPAL-2.0
- [ ] done in masterAll the Makefile.def's are obsolete
- [x] done in OPAL-2.0
- [ ] done in mastergsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/342Wrong turn number at restart2019-07-24T11:09:46+02:00frey_mWrong turn number at restart### Summary
The turn number is initialized with a wrong value at restart. In OPAL-Cycl the turn number starts at 1 and is subtracted for print outs. However, at restart it is not taken care of this feature.
### Steps to reproduce
Ju...### Summary
The turn number is initialized with a wrong value at restart. In OPAL-Cycl the turn number starts at 1 and is subtracted for print outs. However, at restart it is not taken care of this feature.
### Steps to reproduce
Just restart a cyclotron simulation.
### Possible fix
As discussed with @snuverink\_j we need to increment the value by one at [line](https://gitlab.psi.ch/OPAL/src/blob/master/src/Algorithms/ParallelCyclotronTracker.cpp#L2848)
and subtract by one at [line](https://gitlab.psi.ch/OPAL/src/blob/master/src/Algorithms/ParallelCyclotronTracker.cpp#L2851).frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/341binning parameter not properly initialized in constructor2019-07-19T15:19:09+02:00frey_mbinning parameter not properly initialized in constructorIn the constructor of the `MultiBunchHandler` the variable `eta` is not assigned to the member variable `eta_m`.In the constructor of the `MultiBunchHandler` the variable `eta` is not assigned to the member variable `eta_m`.frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/340review tools/BandRF/ascii2h5block_asgic.cpp2019-07-18T15:35:32+02:00gsellreview tools/BandRF/ascii2h5block_asgic.cpp* does not compile with current H5hut
* use std::cout for output not Ippl messages* does not compile with current H5hut
* use std::cout for output not Ippl messagesgsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/339Fix time in Leap-frog2019-07-18T09:33:02+02:00frey_mFix time in Leap-frogThe leap-frog stepper has code to be removed. The time is also doubled which is wrong.The leap-frog stepper has code to be removed. The time is also doubled which is wrong.frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/337Sampler fails due to static variable in MueLuBottomSolver2020-07-14T10:29:45+02:00frey_mSampler fails due to static variable in MueLuBottomSolver### Summary
As in #336 the sampler crashes when dispatching new individuals after some finished.
### Steps to reproduce
Run the sampler with AMR Trilinos and the smoothed aggregation algebraic multigrid solver for the linear system o...### Summary
As in #336 the sampler crashes when dispatching new individuals after some finished.
### Steps to reproduce
Run the sampler with AMR Trilinos and the smoothed aggregation algebraic multigrid solver for the linear system of
equations.
### What is the current *bug* behavior?
The sampler crashes.
### What is the expected *correct* behavior?
The sampler runs smoothly.
### Possible fixes
Remove the static variable.frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/336Sampler fails due to static variable in SDDSWriters2020-07-14T10:41:25+02:00frey_mSampler fails due to static variable in SDDSWriters### Summary
Sampler crashed due to SDDSWriters.
### Steps to reproduce
Run the sampler.
### What is the current *bug* behavior?
The static variable `isFirst` of the new SDDSWriter interface (e.g.
[GridLBalWriter](https://gitlab.ps...### Summary
Sampler crashed due to SDDSWriters.
### Steps to reproduce
Run the sampler.
### What is the current *bug* behavior?
The static variable `isFirst` of the new SDDSWriter interface (e.g.
[GridLBalWriter](https://gitlab.psi.ch/OPAL/src/blob/master/src/Structure/GridLBalWriter.cpp#L16)) causes the sampler to crash with
```
Error{0}>
Error{0}> *** User error detected by function "SDDSColumnSet::addColumnValue"
Error{0}> column name 't' doesn't exists
Error{0}> column name 't' doesn't exists
```
### What is the expected *correct* behavior?
The sampler runs smoothly.
### Possible fixes
Making the variable a non-static `isFirst` a member of `SDDSWriter.h` fixes the problem.frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/333fixes for overloaded virtual errors on macOS2019-08-08T17:45:26+02:00gsellfixes for overloaded virtual errors on macOSgsellgsell