src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2022-01-31T16:15:22+01:00https://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.eshttps://gitlab.psi.ch/OPAL/src/-/issues/689Fix description of minimum values in monitor statistics2021-10-25T11:42:40+02:00krausFix description of minimum values in monitor statisticsThe description for the values min_x, min_y and min_s claim that the max beamsize in the respective component is stored. Instead it should read min beamsize.The description for the values min_x, min_y and min_s claim that the max beamsize in the respective component is stored. Instead it should read min beamsize.2022.1krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/687No values assigned to dispersion2021-11-03T13:20:02+01:00krausNo values assigned to dispersionAll values for the dispersion in statistics file are zero everywhere. The reason is that no values are assigned.All values for the dispersion in statistics file are zero everywhere. The reason is that no values are assigned.2022.1krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/685Output file names for LossDataSink can't have prefixed dots if no extension i...2022-03-17T08:55:14+01:00krausOutput file names for LossDataSink can't have prefixed dots if no extension is providedInstead of correct paths an empty string is returned in `ElementBase::getOutputFN()`if the paths start with a prefixed dot such as e.g. `../` and the file name doesn't include an extension. The user shouldn't have to use a file name with...Instead of correct paths an empty string is returned in `ElementBase::getOutputFN()`if the paths start with a prefixed dot such as e.g. `../` and the file name doesn't include an extension. The user shouldn't have to use a file name with extension, the extension is provided by Opal anyway to support both ascii and HDF5 output.2022.1krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/682Somethings wrong with the algorithm for spatial monitors2021-09-20T09:25:15+02:00krausSomethings wrong with the algorithm for spatial monitorslongitudinal phase space
![chopped](/uploads/b6883e5e1ef686cc053393a5cd3dc1d7/chopped.png)longitudinal phase space
![chopped](/uploads/b6883e5e1ef686cc053393a5cd3dc1d7/chopped.png)2022.1krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/680Remove interactive mode, replace it with additional help option.2022-02-04T16:05:23+01:00krausRemove interactive mode, replace it with additional help option.The interactive mode is presumably not used by anyone. I propose therefore to remove it and add instead an option to print the help for commands on the command line.
Additionally I noticed that Opal crashes while printing the help messa...The interactive mode is presumably not used by anyone. I propose therefore to remove it and add instead an option to print the help for commands on the command line.
Additionally I noticed that Opal crashes while printing the help messages. The reason is that the type names `predefined string`, `upper case string` and `upper case string array` are longer than 16 characters. However the user doesn't have to know what these types represent, they are simply strings and string arrays respectively.2022.1krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/679OPAL header is not printed in interactive mode2021-08-27T14:01:20+02:00gsellOPAL header is not printed in interactive mode### Summary
OPAL header is not printed in interactive mode
### Steps to reproduce
Run opal without argumante
### What is the current *bug* behavior?
No header printed
### What is the expected *correct* behavior?
Print header### Summary
OPAL header is not printed in interactive mode
### Steps to reproduce
Run opal without argumante
### What is the current *bug* behavior?
No header printed
### What is the expected *correct* behavior?
Print headerOPAL 2021.1gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/678Clang does not support option -fno-aggressive-loop-optimizations2021-08-26T15:08:52+02:00gsellClang does not support option -fno-aggressive-loop-optimizationsClang does not support the option `-fno-aggressive-loop-optimizations`.Clang does not support the option `-fno-aggressive-loop-optimizations`.OPAL 2021.1gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/676Clang 12 compiler warnings on macOS2021-08-27T14:00:12+02:00gsellClang 12 compiler warnings on macOSOPAL doesn't compile on macOS with current Clang/Xcode 12:
- if compiled for production PAssert() is defined empty and Clang complains about unused variables
- declarations of virtual methods are missing in same base classesOPAL doesn't compile on macOS with current Clang/Xcode 12:
- if compiled for production PAssert() is defined empty and Clang complains about unused variables
- declarations of virtual methods are missing in same base classesOPAL 2021.1gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/675TrackBack not working correctly2022-02-21T17:42:05+01:00krausTrackBack not working correctlyI am trying to run a simulation forward then take the output distribution and run it backwards to confirm that I am setting up the simulation correctly — it should just return to the same initial distribution.
When running the simulatio...I am trying to run a simulation forward then take the output distribution and run it backwards to confirm that I am setting up the simulation correctly — it should just return to the same initial distribution.
When running the simulation with trackback on, the dipoles bend the reference particle the correct direction, and bend the actual particle distribution in the opposite direction.
Here are Sirepo simulations for the forward and backward. I've confirmed that my conversion script to go from the final distribution in the .h5 file to the initial distribution in a .txt file format for the FROMFILE distribution source is correct.
[AWA_TBA_Drive_Beamline_Backtrack.zip](/uploads/37feb8cf2e1da03a0ccbc7a8dd2038f7/AWA_TBA_Drive_Beamline_Backtrack.zip)2022.1krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/674CMake configuration file fixes2021-08-18T11:51:33+02:00gsellCMake configuration file fixes### Summary
Linking with static libraries fails
### Steps to reproduce
* Build all required software with the build recipes
* run cmake (static libs enabled by default)
* compile
### What is the current *bug* behavior?
Linking faile...### Summary
Linking with static libraries fails
### Steps to reproduce
* Build all required software with the build recipes
* run cmake (static libs enabled by default)
* compile
### What is the current *bug* behavior?
Linking failed.
The boost libraries must not be specified lexicographical (`chrono timer` doesn't work).
CMake does not always detect all libraries required to link with a static `libhdf5.a`.
Old CMake version have issues to detect current boost libraries.OPAL 2021.1gsellgsell