src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2020-01-07T09:44:45+01:00https://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/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/329CollimatorPhysics: Error{0}> reduce: mismatched element count in vector reduc...2019-12-17T09:30:18+01:00krausCollimatorPhysics: Error{0}> reduce: mismatched element count in vector reduction.### Summary
When running the Degrader-1 test OPAL prints the error message 'Error{0}> reduce: mismatched element count in vector reduction.' and then stops working.
### Steps to reproduce
Run the Degrader-1 test in parallel.
### Wha...### Summary
When running the Degrader-1 test OPAL prints the error message 'Error{0}> reduce: mismatched element count in vector reduction.' and then stops working.
### Steps to reproduce
Run the Degrader-1 test in parallel.
### What is the current *bug* behavior?
It stops working. It looks like a deadlock.
### What is the expected *correct* behavior?
It should run smoothly to the end of the lattice.
### Relevant logs and/or screenshots
```
ParallelTTracker {0}[3]> 23:33:54 Step 145 at 21.219 [mm], t= 191.015 [ps], E=72.000 [MeV]
ParallelTTracker {0}[2]> --- CollimatorPhysics - Name DEG1 Material GRAPHITE
ParallelTTracker {0}[2]> Particle Statistics @ 23:33:55
ParallelTTracker {0}[2]> entered: 4'343
ParallelTTracker {0}[2]> rediffused: 0
ParallelTTracker {0}[2]> stopped: 0
ParallelTTracker {0}[2]> total in material: 996'243
ParallelTTracker {0}[3]> 23:33:55 Step 146 at 21.328 [mm], t= 192.015 [ps], E=72.000 [MeV]
ParallelTTracker {0}[2]> --- CollimatorPhysics - Name DEG1 Material GRAPHITE
ParallelTTracker {0}[2]> Particle Statistics @ 23:33:55
ParallelTTracker {0}[2]> entered: 2'480
ParallelTTracker {0}[2]> rediffused: 0
ParallelTTracker {0}[2]> stopped: 0
ParallelTTracker {0}[2]> total in material: 998'723
ParallelTTracker {0}[3]> 23:33:55 Step 147 at 21.438 [mm], t= 193.015 [ps], E=72.000 [MeV]
ParallelTTracker {0}[2]> --- CollimatorPhysics - Name DEG1 Material GRAPHITE
ParallelTTracker {0}[2]> Particle Statistics @ 23:33:56
ParallelTTracker {0}[2]> entered: 1'277
ParallelTTracker {0}[2]> rediffused: 0
ParallelTTracker {0}[2]> stopped: 0
ParallelTTracker {0}[2]> total in material: 1000'000
ParallelTTracker {0}> All particles in degrader
Error{0}> reduce: mismatched element count in vector reduction.
```OPAL-2.2.0krauskraushttps://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/120Particle Termination2019-12-12T23:16:08+01:00winklehner_dParticle TerminationHi,
Anybody else noticing that particles are not terminated correctly anymore if Bin is set to -1 (which is the usual way in the CyclotronTracker) since last week's commits to the head? It still works for the BoundaryGeometry, but not, f...Hi,
Anybody else noticing that particles are not terminated correctly anymore if Bin is set to -1 (which is the usual way in the CyclotronTracker) since last week's commits to the head? It still works for the BoundaryGeometry, but not, for example, for the Cyclotron outer boundaries. I think it might have to do with removing all the boundp's
Best,
DanielOPAL-2.2.0winklehner_dwinklehner_dhttps://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/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/110PartBunch::get_bounds can produce NaNs2019-10-25T13:47:36+02:00snuverink_jjochem.snuverink@psi.chPartBunch::get_bounds can produce NaNsWhile trying to update the [PSI-Ring](https://gitlab.psi.ch/AMAS-BDModels/PSI-Ring) simulations to the master branch, I encountered the following running error:
```
OPAL> PartBunch.cpp: 1574 nan 2.000000e-02
Error>
Error> *** User...While trying to update the [PSI-Ring](https://gitlab.psi.ch/AMAS-BDModels/PSI-Ring) simulations to the master branch, I encountered the following running error:
```
OPAL> PartBunch.cpp: 1574 nan 2.000000e-02
Error>
Error> *** User error detected by function "PartBunch::boundp() "
Error> *** in line 311 of file "Ring.in":
Error> RUN,METHOD="CYCLOTRON-T",BEAM=BEAM1,FIELDSOLVER=FS1,DISTRIBUTION=DIST;
Error> h<0, can not build a mesh
```
The `nan` gets introduced in line 1521: `get_bounds(rmin_m, rmax_m);`
Printing out rmax and rmin before and after this line gives (ymmv):
before:
```
(i,rmax, rmin) 0 0.0000000000000000e+00 0.0000000000000000e+00
(i,rmax, rmin) 1 0.0000000000000000e+00 0.0000000000000000e+00
(i,rmax, rmin) 2 0.0000000000000000e+00 0.0000000000000000e+00
```
after
```
(i,rmax, rmin) 0 7.1153710538428058e-03 -6.9640951722910538e-03
(i,rmax, rmin) 1 4.0421699390708048e-02 -4.0512781208033796e-02
(i,rmax, rmin) 2 -nan -nan
```
I likely do something wrong with my input, but I believe the code should not get this far and produce a better error message.
This can be reproduced with OPAL master (0469d1ac), and the latest version of [PSI-Ring](https://gitlab.psi.ch/AMAS-BDModels/PSI-Ring) and executing `runOpal --nobatch`
**Edit 20 July:**
https://gitlab.psi.ch/OPAL/src/issues/110#note_1914: Simplified input file [Ring.in](https://gitlab.psi.ch/OPAL/src/uploads/ec9579a7c5009c1b7465266afe4373c0/Ring.in)
https://gitlab.psi.ch/OPAL/src/issues/110#note_1916: Regression test `RingCyclotron` has the same bug when one changes the distribution from gauss to either single particle or binomial. 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/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/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/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/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/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/333fixes for overloaded virtual errors on macOS2019-08-08T17:45:26+02:00gsellfixes for overloaded virtual errors on macOSgsellgsell