src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2019-06-28T08:50:14+02:00https://gitlab.psi.ch/OPAL/src/-/issues/321Optimizer crash if SDDSVariable return value is NaN.2019-06-28T08:50:14+02:00frey_mOptimizer crash if SDDSVariable return value is NaN.I recently observed that the optimizer crashes with
```
Error{0}>
Error{0}> *** Error:
Error{0}> Internal OPAL error:
Error{0}> input stream error
Error{0}> input stream error
Rank 0 [Wed Jun 26 20:01:25 2019] [c0-0c0s2n0] ...I recently observed that the optimizer crashes with
```
Error{0}>
Error{0}> *** Error:
Error{0}> Internal OPAL error:
Error{0}> input stream error
Error{0}> input stream error
Rank 0 [Wed Jun 26 20:01:25 2019] [c0-0c0s2n0] application called MPI_Abort(MPI_COMM_WORLD, -100) - process 0
SIGABRT
```
if the return value of `SDDSVariable` is `ǸaN`. With a check `std::isnan` and `std::isinf` this can be fixed. It's probably best it's added to the `SDDSParser` which then throws an execption that is caught by `SDDSVariable`.frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/317Trim coils and closed orbit finder2020-06-18T15:42:32+02:00frey_mTrim coils and closed orbit finder### Summary
The closed orbit finder does not apply the trim coil fields correctly. One does not see any effect of TC15 to avoid the
Walkinshaw resonance in the PSI Ring cyclotron.
### Steps to reproduce
Apply different trim coil fiel...### Summary
The closed orbit finder does not apply the trim coil fields correctly. One does not see any effect of TC15 to avoid the
Walkinshaw resonance in the PSI Ring cyclotron.
### Steps to reproduce
Apply different trim coil fields and compute tune diagram.
### What is the current *bug* behavior?
(Almost) No effect of any trim coils.
### What is the expected *correct* behavior?
Trim coil 15 should shift the tune diagram such that the Walkinshaw resonance is avoided.
### Relevant logs and/or screenshots
Figure 14 of
https://arxiv.org/pdf/1905.06654.pdf
### Possible fixes
I assume it has something to do with units.
CC: @snuverink\_j OPAL 2.4.0frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/316reading fields in H5Block format fails if z-dimension is less than the number...2020-07-01T15:46:46+02:00gsellreading fields in H5Block format fails if z-dimension is less than the number of coresOPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/315cleanup/fixes in Bend.cpp, Cyclotron.cpp and BeamStrippingPhysics.cpp2019-07-11T10:48:57+02:00gsellcleanup/fixes in Bend.cpp, Cyclotron.cpp and BeamStrippingPhysics.cppgsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/314in BoundaryGeometry: replace recursive algorithm to set orientation of triang...2019-07-03T15:59:34+02:00gsellin BoundaryGeometry: replace recursive algorithm to set orientation of triangle with iterativeFor the time being an recursive algorithm is used to make the normal vector of each triangle inward pointing. This is inefficient for large meshes and - more important - can cause crashes due to memory consumption.For the time being an recursive algorithm is used to make the normal vector of each triangle inward pointing. This is inefficient for large meshes and - more important - can cause crashes due to memory consumption.gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/313PluginElements: particles not recorded when element crosses (or close to) origin2019-07-14T16:56:42+02:00snuverink_jjochem.snuverink@psi.chPluginElements: particles not recorded when element crosses (or close to) origin### Summary
Noticed by @nesteruk\_k: Particles are not recorded in some Probes.
Likely the other PluginElements are affected too.
### Steps to reproduce
A Probe crossing the origin, e.g. one defined as:
```
P: Probe, XSTART=-1e10, YS...### Summary
Noticed by @nesteruk\_k: Particles are not recorded in some Probes.
Likely the other PluginElements are affected too.
### Steps to reproduce
A Probe crossing the origin, e.g. one defined as:
```
P: Probe, XSTART=-1e10, YSTART=0, XEND=1e10, YEND=0;
```
will not record any particles.
### What is the expected *correct* behavior?
Recorded particle and output files: P.hist, P.h5, P.peaks
### Possible fixes
A check is performed if the bunch is close to the probe (and only then individual particles are checked) as follows:
https://gitlab.psi.ch/OPAL/src/blob/master/src/Classic/AbsBeamline/Probe.cpp#L62
```c++
if( rbunch_max > rstart_m - 10.0 && rbunch_min < rend_m + 10.0 ) {
```
With `rstart_m` and `rend_m` defined as:
https://gitlab.psi.ch/OPAL/src/blob/master/src/Classic/AbsBeamline/PluginElement.cpp#L86
```cpp
rstart_m = std::hypot(xstart, ystart);
rend_m = std::hypot(xend, yend);
// start position is the one with lowest radius
if (rstart_m > rend_m) {
std::swap(xstart_m, xend_m);
std::swap(ystart_m, yend_m);
std::swap(rstart_m, rend_m);
}
```
Instead of `rstart_m` the closest point to the origin should be used in the check.snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/309review OPAL CMakeModule files2020-04-22T11:25:48+02:00gsellreview OPAL CMakeModule filesSearching for a library with
```
FIND_LIBRARY (GSL_LIBRARY gsl
HINTS $ENV{GSL_ROOT_DIR}/lib $ENV{GSL_LIBRARY_PATH} $ENV{GSL_LIBRARY_DIR} $ENV{GSL_PREFIX}/lib $ENV{GSL_DIR}/lib $ENV{GSL}/lib
PATHS ENV LIBRARY_PATH
)
```
can fail i...Searching for a library with
```
FIND_LIBRARY (GSL_LIBRARY gsl
HINTS $ENV{GSL_ROOT_DIR}/lib $ENV{GSL_LIBRARY_PATH} $ENV{GSL_LIBRARY_DIR} $ENV{GSL_PREFIX}/lib $ENV{GSL_DIR}/lib $ENV{GSL}/lib
PATHS ENV LIBRARY_PATH
)
```
can fail if the library is installed in `/lib` or `/lib64`. For some unknown reasons this works on Merlin-5 but fails on Merlin-6 if e.g. `libgsl` is installed.
What is the problem?
* On RHEL7 `/usr/lib64` is a symbolic link to `/lib64`.
* If e.g. `GSL_ROOT_DIR` is not set in the environment `/lib` and `/lib64` are used to search for the library.
* In RHEL7 most system libraries are installed in `/lib64`, which is the first hint if `GSL_ROOT_DIR` is not set.gsellgsellhttps://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/305Calculation of chord length in RBend wrong2019-05-09T14:16:31+02:00krausCalculation of chord length in RBend wrong### Summary
When the deflection angle is negative then the chord length that is calculated in RBend is wrong. In a rectangular bend when the orientation of the face relative to the beam (`E1`) is half of the deflection angle then the ch...### Summary
When the deflection angle is negative then the chord length that is calculated in RBend is wrong. In a rectangular bend when the orientation of the face relative to the beam (`E1`) is half of the deflection angle then the chord length should be equal to the length of the dipole. Instead the calculated length is as if `E1` was multiplied by `-1`.
### Steps to reproduce
Add `OPTION, LOGBENDTRAJECTORY=TRUE;` to the input file and track a bunch through a rectangular bend with `ANGLE < 0` and `E1 = ANGLE / 2`. Then look up the distance in the file `data/<input_fname>_<bend_name>_traj.dat` between the two locations where the reference particle crosses `x=0`.
### What is the current *bug* behavior?
The current chord length is as if `E1 = -ANGLE / 2`.
### What is the expected *correct* behavior?
The chord length should be equal to `L` in the description of the bend in the input file.krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/301Premature termination of integration when reference particle after MAXSTEPS i...2019-05-15T22:43:30+02:00krausPremature termination of integration when reference particle after MAXSTEPS in implicit drift.The Degrader-1 test is flagged as broken because the number of saved steps in the `.stat` file differ. This is caused by the fact that after 230 steps (MAXSTEPS) the reference particle in the OrbitThreader class is located in a drift, th...The Degrader-1 test is flagged as broken because the number of saved steps in the `.stat` file differ. This is caused by the fact that after 230 steps (MAXSTEPS) the reference particle in the OrbitThreader class is located in a drift, that isn't explicitly mentioned in the input file. During simulation ParallelTTracker stops because it seems to have reached the end of the beamline.krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/300reading H5Block formatted field-maps crashes2019-04-12T10:47:46+02:00gsellreading H5Block formatted field-maps crashesif the size of the field-map in z-direction is less than the number of cores, reading the field-map crashes.
This is already fixed in OPAL 2.0: see 0172837a and #292 if the size of the field-map in z-direction is less than the number of cores, reading the field-map crashes.
This is already fixed in OPAL 2.0: see 0172837a and #292 gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/298Reference particle has to be slowed down by material2019-08-01T05:57:13+02:00krausReference particle has to be slowed down by materialAt the moment the reference particle isn't slowed down when passing a degrader. The beam then has a different kinetic energy which poses a problem in subsequent dipoles and in the statistical analysis.At the moment the reference particle isn't slowed down when passing a degrader. The beam then has a different kinetic energy which poses a problem in subsequent dipoles and in the statistical analysis.krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/295ParallelTTracker crashes when using particle matter integration and space cha...2019-04-12T13:26:34+02:00krausParallelTTracker crashes when using particle matter integration and space charge solver if all particles are in material```
ParallelTTracker [2]> --- CollimatorPhysics - Name AIR1 Material AIR
ParallelTTracker [2]> Particle Statistics @ 12:29:52
ParallelTTracker [2]> entered: 1
ParallelTTracker [2]> rediffused: 0
ParallelTTracker [2]>...```
ParallelTTracker [2]> --- CollimatorPhysics - Name AIR1 Material AIR
ParallelTTracker [2]> Particle Statistics @ 12:29:52
ParallelTTracker [2]> entered: 1
ParallelTTracker [2]> rediffused: 0
ParallelTTracker [2]> stopped: 0
ParallelTTracker [2]> total in material: 50'000
Error>
Error> *** User error detected by function "boundp() "
Error> h<0, can not build a mesh
Error> h<0, can not build a mesh
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
with errorcode -100.
NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
```krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/294ParallelCyclotronTracker crashes (in single particle?) mode when all particle...2019-04-04T13:32:15+02:00snuverink_jjochem.snuverink@psi.chParallelCyclotronTracker crashes (in single particle?) mode when all particles are lostI noticed that in single particle mode (might not be related) that if all particles (in this case on a stripper) are lost OPAL crashes:
```
OPAL> At step 25071, lost 1 particles on stripper, collimator, septum, or out of cyclotron apert...I noticed that in single particle mode (might not be related) that if all particles (in this case on a stripper) are lost OPAL crashes:
```
OPAL> At step 25071, lost 1 particles on stripper, collimator, septum, or out of cyclotron aperture
Error>
Error> *** User error detected by function "boundp() "
Error> h<0, can not build a mesh
Error> h<0, can not build a mesh
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
with errorcode -100.
```
In [ParallelCyclotronTracker::deleteParticle()](https://gitlab.psi.ch/OPAL/src/blob/master/src/Algorithms/ParallelCyclotronTracker.cpp#L2169) there needs to be a check after the particles are removed if there are any particles left and early return before the [boundp()](https://gitlab.psi.ch/OPAL/src/blob/master/src/Algorithms/ParallelCyclotronTracker.cpp#L2243) call.snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/293Stripper Element not losing any particles2019-04-06T09:55:12+02:00snuverink_jjochem.snuverink@psi.chStripper Element not losing any particlesDiscovered by @ext\-calvo\_p . The stripper element is not recording any particles.
This is due to a forgotten `bunch->get_bounds()` statement. This was introduced in commit 60b4de13 and 57787997 (OPAL-2.0)Discovered by @ext\-calvo\_p . The stripper element is not recording any particles.
This is due to a forgotten `bunch->get_bounds()` statement. This was introduced in commit 60b4de13 and 57787997 (OPAL-2.0)snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/292reading H5hut fieldmap fails due to unset view2019-04-12T10:57:21+02:00gsellreading H5hut fieldmap fails due to unset viewIn method FM3dH5Block::readMap() a view must be set before we can read the map.In method FM3dH5Block::readMap() a view must be set before we can read the map.gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/285Matched Distribution: Not matched?2020-07-15T16:53:42+02:00frey_mMatched Distribution: Not matched?@cortes_c experienced that a particle tracking with a matched distribution doesn't remain matched after 1 turn. @baumgarten suggested to check the orientation of the integration.
Corresponding branch: https://gitlab.psi.ch/OPAL/src/tree...@cortes_c experienced that a particle tracking with a matched distribution doesn't remain matched after 1 turn. @baumgarten suggested to check the orientation of the integration.
Corresponding branch: https://gitlab.psi.ch/OPAL/src/tree/matched-gauss-fixes **(deleted)**
CC: @snuverink_j @cortes_c
- [x] fix crash of regression test (see https://gitlab.psi.ch/OPAL/src/merge_requests/364)
- [x] ~~check unit~~ [**Edit:** Checked with !393]
- [x] check why not matched (see !393)
- [x] update regression test due to changes of !393 (see https://gitlab.psi.ch/OPAL/regression-tests/merge_requests/20)OPAL 2.4.0frey_mfrey_m2020-07-24https://gitlab.psi.ch/OPAL/src/-/issues/283Element positions in *_ElementPositions.txt file not correct2019-03-24T11:59:14+01:00krausElement positions in *_ElementPositions.txt file not correct- If ELEMEDGE isn't at the beginning of the element then BEGIN and END are computed as if it were at the beginning.
- Dipoles with negative angle are flipped.- If ELEMEDGE isn't at the beginning of the element then BEGIN and END are computed as if it were at the beginning.
- Dipoles with negative angle are flipped.krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/282Closed Orbit Finder not always converging2019-04-01T15:01:25+02:00snuverink_jjochem.snuverink@psi.chClosed Orbit Finder not always convergingThe closed orbit finder is not always converging as found by @matlocha_t. His input file is [u2_seo.in](/uploads/ca99e5634a65602ee0f2a91c61033aa6/u2_seo.in).
cc: @frey_mThe closed orbit finder is not always converging as found by @matlocha_t. His input file is [u2_seo.in](/uploads/ca99e5634a65602ee0f2a91c61033aa6/u2_seo.in).
cc: @frey_msnuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/277OPAL-Cycl - Particle out of bounds2019-03-20T12:06:00+01:00frey_mOPAL-Cycl - Particle out of boundsClose to the septum of the PSI Ring cyclotron we lose a lot of particles and particles might end up out of the field map. Thus, we get magnetic field values of $`\mathcal{O}(10^{177})`$ which is not physical. This ends up of producing ``...Close to the septum of the PSI Ring cyclotron we lose a lot of particles and particles might end up out of the field map. Thus, we get magnetic field values of $`\mathcal{O}(10^{177})`$ which is not physical. This ends up of producing ```NAN``` values of the particle positions what causes problems in case of AMR (adaptive mesh refinement) simulations.
I propose to destroy the particles directly after applying the field [line 3494](https://gitlab.psi.ch/OPAL/src/blob/master/src/Algorithms/ParallelCyclotronTracker.cpp#L3494) of ```ParallelCyclotronTracker::computeExternalFields_m``` by
```C++
if ( outOfBound ) {
itsBunch_m->destroy(1, i, true);
}
```
With this fix, it works -- that is: a small test worked.
Are there any concerns or better suggestions?
CC: @snuverink_jfrey_msnuverink_jjochem.snuverink@psi.chfrey_m