src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2022-09-14T13:27:24+02:00https://gitlab.psi.ch/OPAL/src/-/issues/722Asymmetric Enge function for Scaling FFA Magnet2022-09-14T13:27:24+02:00ext-rogers_cAsymmetric Enge function for Scaling FFA Magnet### Summary
Request to add in a new end field model - using an asymmetric enge function - for Scaling FFA magnet.### Summary
Request to add in a new end field model - using an asymmetric enge function - for Scaling FFA magnet.2022.1https://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/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/716Remove usage of IPPL:Tenzor class2023-08-23T16:29:38+02:00adelmannRemove usage of IPPL:Tenzor class### Summary
Remove IPPL `AppTypes/Tenzor.h` usage in
- Classic/AbsBeamline/Bend2D.cpp
- Classic/Algorithms/Quaternion.h:class
- Classic/Algorithms/CoordinateSystemTrafo.h
- Classic/Algorithms/Quaternion.cpp
- Classic/Utilities/MSLang.h
...### Summary
Remove IPPL `AppTypes/Tenzor.h` usage in
- Classic/AbsBeamline/Bend2D.cpp
- Classic/Algorithms/Quaternion.h:class
- Classic/Algorithms/CoordinateSystemTrafo.h
- Classic/Algorithms/Quaternion.cpp
- Classic/Utilities/MSLang.h
- Algorithms/ParallelCyclotronTracker.cpp
- Distribution/Distribution.cpp
- Distribution/Distribution.h
`Tenzor` is mostly used as matrix and in the `Classic/Algorithms/Quaternion.cpp`.
Maybe replacing `Quaternion` by Boost could also be an option.2023.1sadr_msadr_mhttps://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/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.es