src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2022-05-03T09:22:53+02:00https://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/712Use keyword nullptr as null pointer constant2022-03-17T09:17:00+01:00ext-calvo_ppedro.calvo@ciemat.esUse keyword nullptr as null pointer constantSince C++11, `nullptr` provides a typesafe pointer value representing an empty (null) pointer, resolving ambiguous situations unlike the existing implementation dependent null pointer constant `NULL`. Therefore, `NULL` instances should b...Since C++11, `nullptr` provides a typesafe pointer value representing an empty (null) pointer, resolving ambiguous situations unlike the existing implementation dependent null pointer constant `NULL`. Therefore, `NULL` instances should be replaced it by `nullptr`2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/711Remove literal comparison of empty strings2022-03-16T12:01:31+01:00ext-calvo_ppedro.calvo@ciemat.esRemove literal comparison of empty stringsLiteral comparison to check if a string is empty (`string == ""`) is quite slow, so it must be replaced it with call to `empty()`Literal comparison to check if a string is empty (`string == ""`) is quite slow, so it must be replaced it with call to `empty()`2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/710Improve standard output2022-03-15T14:17:36+01:00ext-calvo_ppedro.calvo@ciemat.esImprove standard outputSome items in the standard output can be improved to make it easier for the user to read parameters, unifying messages within their group and eliminating duplicate parts within the code.
Some examples about that:
- Parameters of `BANDRF...Some items in the standard output can be improved to make it easier for the user to read parameters, unifying messages within their group and eliminating duplicate parts within the code.
Some examples about that:
- Parameters of `BANDRF` cyclotron type are vectors, but only the initial value is printed in the output.
- `DISTRIBUTION` command must show the units of the input moment, output file when `WRITETOFILE` is enabled…
- The output of the `RUN` command is duplicated in each of the OPAL flavors.
- Unify style for units and filenames2022.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/708Cleanup string comparison2022-03-09T08:08:52+01:00ext-calvo_ppedro.calvo@ciemat.esCleanup string comparisonSome variables can be declared as scoped enumerations to improve the code, avoiding string comparison. In addition, some `enum class` can be passed as private within their class, leaving them out of the global scope.Some variables can be declared as scoped enumerations to improve the code, avoiding string comparison. In addition, some `enum class` can be passed as private within their class, leaving them out of the global scope.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/705Enabling 3DDynamics to accept complex field2022-01-26T20:26:07+01:00ext-piot_pEnabling 3DDynamics to accept complex field### Summary
Right now OPAL only allows for 3D map to be real-values. For a project at AWA we need the map to be complex values. I would like to implement by introducing a 3DDynamicsComplex flat in the external map describing the field w...### Summary
Right now OPAL only allows for 3D map to be real-values. For a project at AWA we need the map to be complex values. I would like to implement by introducing a 3DDynamicsComplex flat in the external map describing the field with columns being Re(Ex), Re(Ey) Re(Ez), Im(Ex), Im(Ey) Im(Ez), Re(Hx), Re(Hy) Re(Hz), Im(Hx), Im(Hy) Im(Hz) . I will try to implement this in the next few days -- this is related to the question from one of my colleagues (Seong-Yeol). Any better suggestion?ext-piot_pext-piot_phttps://gitlab.psi.ch/OPAL/src/-/issues/704Move unit conversions to separate file2022-03-17T08:53:13+01:00ext-calvo_ppedro.calvo@ciemat.esMove unit conversions to separate fileUnit conversions shouldn't be in the same file as physical entities, such as e.g. the speed of light (see OPAL/src#690). Instead move them to a new file and a new namespace.Unit conversions shouldn't be in the same file as physical entities, such as e.g. the speed of light (see OPAL/src#690). Instead move them to a new file and a new namespace.2022.1krauskraushttps://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/699Redefine heavy ion beams2022-01-17T08:08:55+01:00ext-calvo_ppedro.calvo@ciemat.esRedefine heavy ion beamsThe following discussion from !548 should be addressed:
- @snuverink_j started a [discussion](https://gitlab.psi.ch/OPAL/src/-/merge_requests/548#note_35297): (+9 comments)
> Is there maybe a reference why we use these particle ch...The following discussion from !548 should be addressed:
- @snuverink_j started a [discussion](https://gitlab.psi.ch/OPAL/src/-/merge_requests/548#note_35297): (+9 comments)
> Is there maybe a reference why we use these particle charges for Xenon and Uranium? I think it would be good to add this here.
Beam particle definition for heavy ions is not well determined. Uranium and xenon beams can have different ionization states, but currently OPAL only considers a given charge state. The definition of these particles must be reviewed, establishing univocal values for the mass and the charge states as `PARTICLE` types in the `BEAM` command. If any user wants to simulate these type of ions with a different ionization state or other isotope kind, it can be done by means of the attributes `MASS` and `CHARGE`. In addition, the documentation in the Manual must be modified (see OPAL/documentation/manual#70).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.es