src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2022-07-13T13:47:19+02:00https://gitlab.psi.ch/OPAL/src/-/issues/724Fix particle deletion by beam stripping interactions2022-07-13T13:47:19+02:00ext-calvo_ppedro.calvo@ciemat.esFix particle deletion by beam stripping interactionsThe deletion of the particles is performed differently in Opal-cycl and Opal-t. Therefore, the call to `destroyT` in beam stripping algorithm must be restricted to simulations in Opal-t. Opal-cycl remove particles from the bunch in a spe...The deletion of the particles is performed differently in Opal-cycl and Opal-t. Therefore, the call to `destroyT` in beam stripping algorithm must be restricted to simulations in Opal-t. Opal-cycl remove particles from the bunch in a specific method in `ParallelCyclotronTracker`2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/721error: variable set but not used2022-09-14T11:30:36+02:00adelmannerror: variable set but not usedNew clang is very picky: variable set but not used
./400-build-opal: error in compiling the software!New clang is very picky: variable set but not used
./400-build-opal: error in compiling the software!2022.1adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/720anonymous non-C-compatible type given name for linkage purposes by typedef de...2022-07-07T13:13:10+02:00adelmannanonymous non-C-compatible type given name for linkage purposes by typedef declaration;### Summary
Compile master with clang 13.1.6
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: arm64-apple-darwin21.5.0
Thread model: posix
### Steps to reproduce
Compile build-recipes
### What is the current *bug* behavior?
...### Summary
Compile master with clang 13.1.6
Apple clang version 13.1.6 (clang-1316.0.21.2.5)
Target: arm64-apple-darwin21.5.0
Thread model: posix
### Steps to reproduce
Compile build-recipes
### What is the current *bug* behavior?
compilation results in error
### What is the expected *correct* behavior?
obvious
### Relevant logs and/or screenshots
''' /Users/adelmann/OPAL/tmp/src/OPAL/OPAL-2021.1.0/optimizer/Util/Types.h:65:15: error: anonymous non-C-compatible type given name for linkage purposes by typedef declaration; add a tag name here [-Werror,-Wnon-c-typedef-for-linkage]
typedef struct {
'''
### Possible fixes
name the struct2022.1adelmannadelmann2022-06-30https://gitlab.psi.ch/OPAL/src/-/issues/719ScalingFFAMagnet still using wrong units2022-07-18T10:27:39+02:00ext-rogers_cScalingFFAMagnet still using wrong unitsScalingFFAMagnet still seems to be using kG. Note the manual says it is Tesla.ScalingFFAMagnet still seems to be using kG. Note the manual says it is Tesla.2022.1ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/718Wrong particle counting in CCollimator with particle-matter interactions2022-06-30T11:45:47+02:00ext-calvo_ppedro.calvo@ciemat.esWrong particle counting in CCollimator with particle-matter interactionsThe following discussion from !577 should be addressed:
- @ext-calvo_p started a [discussion](https://gitlab.psi.ch/OPAL/src/-/merge_requests/577#note_38608): (+1 comment)
> There is an additional problem with particle counting. T...The following discussion from !577 should be addressed:
- @ext-calvo_p started a [discussion](https://gitlab.psi.ch/OPAL/src/-/merge_requests/577#note_38608): (+1 comment)
> There is an additional problem with particle counting. The cyclotron tracker does not detect the particles that are in the material, and therefore always thrown the exception in `ParallelCyclotronTracker::deleteParticle()`.
>
> To reproduce it, just run the input file attached in the issue description. I've just updated it to the current format
The ScatteringPhysics algorithm delete from the bunch the particles that collide with the material. It then performs energy loss and Coulomb scattering calculations. Particles with energy above the threshold are returned to the beam by `addBackToBunch`, otherwise, the particles are considered lost.
OpalCycl updates the number of particles in a specific method focused on delete particles, so the local number of particles must coincide with the accumulated particles in all bunches after deletion. Therefore, the particles lost in ScatteringPhysics must be included in the bunch with the proper attribute to be deleted.2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/715Missing attributes values for AMR solver2022-05-03T09:22:53+02:00ext-calvo_ppedro.calvo@ciemat.esMissing attributes values for AMR solverThe attributes `ITSOLVER` and `AMR_MG_REUSE` are not considering all the options described in the [Manual](http://amas.web.psi.ch/opal/Documentation/master/#tab_AMR_MG_Commands) for the AMR Poisson Solver.
The lists of accepted predefin...The attributes `ITSOLVER` and `AMR_MG_REUSE` are not considering all the options described in the [Manual](http://amas.web.psi.ch/opal/Documentation/master/#tab_AMR_MG_Commands) for the AMR Poisson Solver.
The lists of accepted predefined string values have to be extended.2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/714Fieldsolver types for AMR not considered2022-05-03T09:22:53+02:00ext-calvo_ppedro.calvo@ciemat.esFieldsolver types for AMR not consideredReported by Sherlp: AMR solver types are not declared as `PredefinedString` in `FSTYPE` attribute, so all simulations will be finished in an exception.
This bug had gone unnoticed until now because the AMR regression tests are not enab...Reported by Sherlp: AMR solver types are not declared as `PredefinedString` in `FSTYPE` attribute, so all simulations will be finished in an exception.
This bug had gone unnoticed until now because the AMR regression tests are not enabled (see OPAL/regression-tests#95).2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/713Check assignation of BEAM, FIELDSOLVER and DISTRIBUTION in RUN command2022-03-21T07:59:48+01:00ext-calvo_ppedro.calvo@ciemat.esCheck assignation of BEAM, FIELDSOLVER and DISTRIBUTION in RUN commandThe attributes `BEAM`, `FIELDSOLVER` and `DISTRIBUTION` in the `RUN` command take default values when they are not specifically defined.
Currently, in the case that `FIELDSOLVER` is not defined, a segmentation fault is raised. In the ca...The attributes `BEAM`, `FIELDSOLVER` and `DISTRIBUTION` in the `RUN` command take default values when they are not specifically defined.
Currently, in the case that `FIELDSOLVER` is not defined, a segmentation fault is raised. In the case of `BEAM` or `DISTRIBUTION`, an exception is thrown, since OPAL does not find the internal attributes of those commands when taking the default value.
Early exceptions should be thrown in TrackRun to guarantee the assignation of these attributes.2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/709Missing std header result in compilation bug2022-02-23T14:43:10+01:00ext-calvo_ppedro.calvo@ciemat.esMissing std header result in compilation bugCompilation has failed (see [link](http://amas.web.psi.ch/opal/master/output/2022-02-22_10-49.txt)) after MR OPAL/src!558. Missing include in `ValueRange.h` could be a possible cause of the failure, because `std::numeric_limits` needs h...Compilation has failed (see [link](http://amas.web.psi.ch/opal/master/output/2022-02-22_10-49.txt)) after MR OPAL/src!558. Missing include in `ValueRange.h` could be a possible cause of the failure, because `std::numeric_limits` needs header `<limits>`.2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/707Segmentation fault with COMPUTEPERCENTILES2022-03-07T16:38:50+01:00ext-calvo_ppedro.calvo@ciemat.esSegmentation fault with COMPUTEPERCENTILES`COMPUTEPERCENTILES` gives a segmentation fault when all particles die during the simulation. It can happen when the whole beam collides with the geometry, by particle-matter interaction or by interaction with interceptive elements (stri...`COMPUTEPERCENTILES` gives a segmentation fault when all particles die during the simulation. It can happen when the whole beam collides with the geometry, by particle-matter interaction or by interaction with interceptive elements (stripper, collimator...).
A simple way to reproduce the bug is to run GasStripping regression test increasing the pressure level enough to achieve total particle loss (`PRESSURE=1.0e-1`) with `OPTION, COMPUTEPERCENTILES=TRUE;`2022.1krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/706Bug with Temporal Monitor when running in parallel2022-01-31T16:15:22+01:00albajacas_aarnau.albajacas@psi.chBug with Temporal Monitor when running in parallel### Summary
@muralikrishnan pointed out that he was having this error:
When a temporal monitor is used, and you run on multiple cores, you get the following error:
```
Error{1}> ...### Summary
@muralikrishnan pointed out that he was having this error:
When a temporal monitor is used, and you run on multiple cores, you get the following error:
```
Error{1}>
Error{1}> *** Error:
Error{1}> Internal OPAL error:
Error{1}> basic_string::_M_construct null not valid
Error{1}> basic_string::_M_construct null not valid
```
This happens for example running [test_fft.in](/uploads/da1a334c67bed7c2c6fe692cea331714/test_fft.in), only when run on multiple cores. When running on a single core it works fine.
The problem seems to come from the line `auto stats = lossDs_m->computeStatistics(1);` (https://gitlab.psi.ch/OPAL/src/-/blob/master/src/Classic/AbsBeamline/Monitor.cpp#L132), which was added in !557
I don't exactly know why this line was added or why it gives an error here. Maybe @kraus can comment.2022.1https://gitlab.psi.ch/OPAL/src/-/issues/703Fix particle definition2022-01-17T08:57:41+01:00ext-calvo_ppedro.calvo@ciemat.esFix particle definition- The `BEAM` command must verify that the particle definition (`PARTICLE` or `MASS` and `CHARGE`) has been explicitly set.
- Likewise, the proper assignment of `NPART` attribute must be checked (it must be positive).
- The `CARBON` charg...- The `BEAM` command must verify that the particle definition (`PARTICLE` or `MASS` and `CHARGE`) has been explicitly set.
- Likewise, the proper assignment of `NPART` attribute must be checked (it must be positive).
- The `CARBON` charge value is erroneous2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/702Back-track simulation not stopping2022-01-20T09:14:21+01:00albajacas_aarnau.albajacas@psi.chBack-track simulation not stopping### Summary
Back-tracking simulations worked fine for me with OPAL 2.4, but with OPAL 2021.1 they are not stopping anymore and go to infinity!
For example this [input file](/uploads/757ebbea744b87dc1809329ce2e898d3/back_track_drift.in) ...### Summary
Back-tracking simulations worked fine for me with OPAL 2.4, but with OPAL 2021.1 they are not stopping anymore and go to infinity!
For example this [input file](/uploads/757ebbea744b87dc1809329ce2e898d3/back_track_drift.in) used to work fine, and stop at `s=0.0`, but now it just goes forever [slurm-120179.out](/uploads/64939725a0d7f33e1637d05c9afa56a0/slurm-120179.out).
```
ParallelTTracker {0}> 19:59:38 Step 999 at 5.887 [m], t= 19.637 [ns], E=44.457 [MeV]
ParallelTTracker {0}> 20:00:09 Step 1999 at 4.987 [m], t= 16.637 [ns], E=44.457 [MeV]
ParallelTTracker {0}> 20:00:41 Step 2999 at 4.088 [m], t= 13.637 [ns], E=44.458 [MeV]
ParallelTTracker {0}> 20:01:13 Step 3999 at 3.189 [m], t= 10.637 [ns], E=44.458 [MeV]
ParallelTTracker {0}> 20:01:46 Step 4999 at 2.289 [m], t= 7.637 [ns], E=44.458 [MeV]
ParallelTTracker {0}> 20:02:18 Step 5999 at 1.390 [m], t= 4.637 [ns], E=44.459 [MeV]
ParallelTTracker {0}> 20:02:50 Step 6999 at 490.765 [mm], t= 1.637 [ns], E=44.459 [MeV]
ParallelTTracker {0}> 20:03:23 Step 7999 at -93.005 [m], t= -1.363 [ns], E=44.460 [MeV]
ParallelTTracker {0}> 20:03:55 Step 8999 at -951.669 [m], t= -4.363 [ns], E=44.460 [MeV]
ParallelTTracker {0}> 20:04:27 Step 9999 at -2709.652 [m], t= -7.363 [ns], E=44.460 [MeV]
ParallelTTracker {0}> 20:05:00 Step 10999 at -5366.954 [m], t= -10.363 [ns], E=44.460 [MeV]
ParallelTTracker {0}> 20:05:32 Step 11999 at -8923.576 [m], t= -13.363 [ns], E=44.461 [MeV]
ParallelTTracker {0}> 20:06:04 Step 12999 at -13379.517 [m], t= -16.363 [ns], E=44.461 [MeV]
slurmstepd: error: *** JOB 120179 ON merlin-c-117 CANCELLED AT 2021-12-20T20:06:15 ***
```
I can't figure out why this is happening. When I have time I will check at which commit it broke, somewhere between 2.4 and 2021.1. Not sure if it is related to #675. Any ideas?2022.1https://gitlab.psi.ch/OPAL/src/-/issues/701Check momentum between `FROMFILE` distribution and BEAM2022-08-10T10:56:56+02:00albajacas_aarnau.albajacas@psi.chCheck momentum between `FROMFILE` distribution and BEAM### Summary
In the MR !513 we made that the `BEAM` command checks if energy or pc or gamma have been given, since the default `P0` is not used anymore.
But this means that in the case where the distribution is `FROMFILE`, an energy ne...### Summary
In the MR !513 we made that the `BEAM` command checks if energy or pc or gamma have been given, since the default `P0` is not used anymore.
But this means that in the case where the distribution is `FROMFILE`, an energy needs to be given even though it should be read from the distribution file. For example this input [file](/uploads/042f03bc5ebd1681975a171c6128035e/drift.in) doesn't work anymore because there is no energy or gamma or pc in the `BEAM` command. It used to work because the default `P0` kicked in, even though it was immediately replaced when teh distirbution file was read in.
Of course a work-around is to give any dummy energy, and it will be over-written when the distribution file is read in. But this will confuse users since they can give an energy different from the energy in the distribution file. The momentum specified in the `BEAM` command and in `FROMFILE` distribution type must be verified so that both values are consistent with each other.
Also, the regression tests that use `FROMFILE` still have `PC` in the `BEAM` command, that is why no regression tests had failed after this change.
TODO list:
- [x] Add cross-check between `BEAM` command energy and `FROMFILE` energy (done in !562 )
- [x] Update broken regression tests that used `FROMFILE` and the default `P0` ( regression-tests#109)
- [x] Update manual section 15.3.1 regarding `FROMFILE` type distribution. (https://gitlab.psi.ch/OPAL/documentation/manual/-/issues/76)2022.1albajacas_aarnau.albajacas@psi.chalbajacas_aarnau.albajacas@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/700Compiler error: boost::bimap assignation fails2021-12-15T15:36:30+01:00ext-calvo_ppedro.calvo@ciemat.esCompiler error: boost::bimap assignation failsI'm getting compiler errors due to invalid arguments in bimap initialization:
```
OPAL/src/src/BasicActions/Option.cpp:49:1:
error: conversion ‘<brace-enclosed initializer list>’ to
‘const::bimaps::bimap<enum class, std::__cxx11...I'm getting compiler errors due to invalid arguments in bimap initialization:
```
OPAL/src/src/BasicActions/Option.cpp:49:1:
error: conversion ‘<brace-enclosed initializer list>’ to
‘const::bimaps::bimap<enum class, std::__cxx11::basic_string<char> >’ is ambiguous
```
The adequate `boost::bimap` allocation must be done without braces.2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/698Longitudinal positions in temporal monitor wrong2022-01-31T16:12:52+01:00krausLongitudinal positions in temporal monitor wrongWhen one compares the mean longitudinal positions of the bunch relative to the reference particle in temporal monitor and the phase space file then one observes that the values dont agree very well. In the h5 file the values are continuo...When one compares the mean longitudinal positions of the bunch relative to the reference particle in temporal monitor and the phase space file then one observes that the values dont agree very well. In the h5 file the values are continuous whereas in the monitor file the values are randomly (?) shifted, [see here](/uploads/58fd2be9e7eb79e6659e43c94134ca9c/compare_mean_values_of_monitors_and_stat.pdf).2022.1krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/697Fix elementTypeToString map2021-12-12T23:23:05+01:00ext-calvo_ppedro.calvo@ciemat.esFix elementTypeToString mapThe map `elementTypeToString_s` introduce in the implementation of OPAL/src#694 contains some bugs that have broken [UndulatorTest](http://amas.web.psi.ch/opal/unitTests/master/results_2021-11-30_10-49.xml) and [VFFA-1 regression test](h...The map `elementTypeToString_s` introduce in the implementation of OPAL/src#694 contains some bugs that have broken [UndulatorTest](http://amas.web.psi.ch/opal/unitTests/master/results_2021-11-30_10-49.xml) and [VFFA-1 regression test](http://amas.web.psi.ch/opal/regressionTests/master/results_2021-11-30_10-49.xml):
- Element string names must be lowercase
- `Ring` element is missing2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/696Some regression tests fails2021-11-16T19:42:15+01:00ext-calvo_ppedro.calvo@ciemat.esSome regression tests failsAfter implementing OPAL/src!552, some regression tests [fails](http://amas.web.psi.ch/opal/regressionTests/master/results_2021-11-16_10-49.xml) due to a bad unit conversion perform in `OpalCavity.cpp` (line 110): the correct conversion i...After implementing OPAL/src!552, some regression tests [fails](http://amas.web.psi.ch/opal/regressionTests/master/results_2021-11-16_10-49.xml) due to a bad unit conversion perform in `OpalCavity.cpp` (line 110): the correct conversion is `MHz2Hz`2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/695Compilation broken2021-11-16T08:58:57+01:00ext-calvo_ppedro.calvo@ciemat.esCompilation brokenCompilation with AMR solver was broken (see [link](http://amas.web.psi.ch/opal/master/output/2021-11-15_10-49.txt)) due to a missing bracket in Line 361 of `AmrBoxLib.cpp` after merging OPAL/src!552Compilation with AMR solver was broken (see [link](http://amas.web.psi.ch/opal/master/output/2021-11-15_10-49.txt)) due to a missing bracket in Line 361 of `AmrBoxLib.cpp` after merging OPAL/src!5522022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/691Fix units in DumpEMFields header2022-01-17T09:03:08+01:00ext-calvo_ppedro.calvo@ciemat.esFix units in DumpEMFields headerThe header of the output files `DumpEMFields` shows units in `mm` when in fact `m` is used (since 62632e45daedb236457be5909bf7144849404c8a).
The units of the input variables must be specified in the Manual (see OPAL/documentation/manual...The header of the output files `DumpEMFields` shows units in `mm` when in fact `m` is used (since 62632e45daedb236457be5909bf7144849404c8a).
The units of the input variables must be specified in the Manual (see OPAL/documentation/manual#68).2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.es