src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2019-12-12T10:26:01+01:00https://gitlab.psi.ch/OPAL/src/-/issues/384Increase simulation efficiency2019-12-12T10:26:01+01:00frey_mIncrease simulation efficiencyIn OPAL-cyclotron the function `ParallelCyclotronTracker::deleteParticle` has an `allreduce` function call that consumes quite a lot of runtime. I have a simulation of the PSI Ring cyclotron that runs for 17 h where 7 h are just calls of...In OPAL-cyclotron the function `ParallelCyclotronTracker::deleteParticle` has an `allreduce` function call that consumes quite a lot of runtime. I have a simulation of the PSI Ring cyclotron that runs for 17 h where 7 h are just calls of this MPI-function. I think we sould add a `DELETE_PARTICLE_FREQ` option to OPAL in order to reduce computational cost. The default behaviour should of course remain.frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/383building unit-tests failing after commit 9f2a3bd22019-11-11T14:08:54+01:00gsellbuilding unit-tests failing after commit 9f2a3bd2Since the "target link libraries" (dependencies) of libOPAL has been removed in 9f2a3bd2, building the unit-tests is failing.
EDIT (@snuverink\_j): replaced c530d5b7 with correct hash commit 9f2a3bd2 Since the "target link libraries" (dependencies) of libOPAL has been removed in 9f2a3bd2, building the unit-tests is failing.
EDIT (@snuverink\_j): replaced c530d5b7 with correct hash commit 9f2a3bd2 gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/382Restart append data to probe2019-11-11T13:37:16+01:00frey_mRestart append data to probe### Summary
When restarting a simulation, the output is not properly appended to the probe H5 file.
### Steps to reproduce
Restart a cyclotron simulation having a probe element.
### What is the current *bug* behavior?
It overwrite...### Summary
When restarting a simulation, the output is not properly appended to the probe H5 file.
### Steps to reproduce
Restart a cyclotron simulation having a probe element.
### What is the current *bug* behavior?
It overwrites the H5 file.
### What is the expected *correct* behavior?
It appends the new turns to the H5 file leaving the previous steps untouched.
### Possible fixes
Several possible fixes:
* Set the `OpalData::OPENMODE` to `APPEND` in `TrackRun` if `opal->inRestartRun() == True`
* Extend if-clause with `|| OpalData::getInstance()->inRestartRun()` at [line 224](https://gitlab.psi.ch/OPAL/src/blob/master/src/Classic/AbsBeamline/PluginElement.cpp#L224) of `PluginElement::save()`.frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/381linking with static boost libraries fails2019-11-08T22:52:39+01:00gselllinking with static boost libraries failsCurrent CMake versions are linking against static boost libraries by default if they are available. With static linking the order of the libraries matters. CMake reorders the libraries in some cases so that linking failsCurrent CMake versions are linking against static boost libraries by default if they are available. With static linking the order of the libraries matters. CMake reorders the libraries in some cases so that linking failsgsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/379Add phase-space halo parameter to stat and smb file2020-04-22T11:53:50+02:00frey_mAdd phase-space halo parameter to stat and smb fileWe currently write the spatial-profile parameter to the stat file. However, I think, it makes sense to write also the phase-space halo parameter to the file. The formulas are in https://journals.aps.org/prab/abstract/10.1103/PhysRevSTAB....We currently write the spatial-profile parameter to the stat file. However, I think, it makes sense to write also the phase-space halo parameter to the file. The formulas are in https://journals.aps.org/prab/abstract/10.1103/PhysRevSTAB.5.124202frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/378Loss files units2019-11-07T10:04:36+01:00ext-calvo_ppedro.calvo@ciemat.esLoss files unitsFor consistency (and #45, #307, #357), the loss files should use unit `m` instead of `mm`For consistency (and #45, #307, #357), the loss files should use unit `m` instead of `mm`ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/377Update regression tests after "Resolve "Update physical constants"2019-12-09T09:04:46+01:00snuverink_jjochem.snuverink@psi.chUpdate regression tests after "Resolve "Update physical constants"The following discussion from !188 should be addressed:
- [ ] @kraus started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/188#note_14015): (+1 comment)
> This merge probabely breaks some of the regression tests. We...The following discussion from !188 should be addressed:
- [ ] @kraus started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/188#note_14015): (+1 comment)
> This merge probabely breaks some of the regression tests. We'll have to see tomorrow.
@ext\-calvo\_p :
> You were right, some [tests failed](http://amas.web.psi.ch/opal/regressionTests/master/results_2019-10-19.xml). It seems a problem of the accuracy of the results compare with the reference after changing constants value.snuverink_jjochem.snuverink@psi.chkraussnuverink_jjochem.snuverink@psi.ch2019-12-13https://gitlab.psi.ch/OPAL/src/-/issues/376Feature Request: OPAL Cheat Sheet2020-06-10T08:29:27+02:00bellotti_rFeature Request: OPAL Cheat SheetI think a cheat sheet would be very helpful for people who are new to OPAL. Especially to get an overview about what is possible, and which commands exist without having to go through the wiki section by section. Of course, detailed info...I think a cheat sheet would be very helpful for people who are new to OPAL. Especially to get an overview about what is possible, and which commands exist without having to go through the wiki section by section. Of course, detailed information should still be looked up.
My suggestion is to give a short config snippet for the most common building blocks. [This PDF](https://pandas.pydata.org/Pandas_Cheat_Sheet.pdf) might be a good guideline what I mean.
What do you think?adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/375Probe does not register all particles2019-10-28T09:39:02+01:00frey_mProbe does not register all particles### Summary
The probe does not register all particles
### Steps to reproduce
Run an Ring simulation. Attached an example (however, the size needs to be reduced since it is pretty expensive)
[Ring.in](/uploads/48a83139533905a19983fa4...### Summary
The probe does not register all particles
### Steps to reproduce
Run an Ring simulation. Attached an example (however, the size needs to be reduced since it is pretty expensive)
[Ring.in](/uploads/48a83139533905a19983fa441eef49be/Ring.in)
### What is the current *bug* behavior?
Not all particles are registered.
### What is the expected *correct* behavior?
All particles are registered.snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/373Doxyfile INPUT only containing `OPAL-Map` input files2019-10-18T10:39:46+02:00snuverink_jjochem.snuverink@psi.chDoxyfile INPUT only containing `OPAL-Map` input filesAs noticed by @kraus in https://gitlab.psi.ch/OPAL/src/commit/10a98c34b32047fad7252b93639d6ef33a60d227#note_13986, the doxygen input only contains `OPAL-MAP` input files.As noticed by @kraus in https://gitlab.psi.ch/OPAL/src/commit/10a98c34b32047fad7252b93639d6ef33a60d227#note_13986, the doxygen input only contains `OPAL-MAP` input files.snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/372Flattop distribution: particles in tail have wrong cutoff2019-10-16T15:43:09+02:00snuverink_jjochem.snuverink@psi.chFlattop distribution: particles in tail have wrong cutoffFor a flattop distribution the particles in the tail are calculated as follows (https://gitlab.psi.ch/OPAL/src/blob/master/src/Distribution/Distribution.cpp#L2660) introduced in 9c51f84b:
```c++
while (!allow) {
t = gs...For a flattop distribution the particles in the tail are calculated as follows (https://gitlab.psi.ch/OPAL/src/blob/master/src/Distribution/Distribution.cpp#L2660) introduced in 9c51f84b:
```c++
while (!allow) {
t = gsl_ran_gaussian_tail(randGen_m, 0, sigmaTFall_m);
if (t <= sigmaTRise_m * cutoffR_m[2]) {
t = -t + sigmaTFall_m * cutoffR_m[2];
allow = true;
}
}
```
For the cutoff `sigmaTRise_m` is used instead of `sigmaTFall_m`, it should read:
```c++
if (t <= sigmaTFall_m * cutoffR_m[2]) {
```snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/371Modulation on flattop distribution creates a gap2019-10-18T23:43:02+02:00albajacas_aarnau.albajacas@psi.chModulation on flattop distribution creates a gap### Summary
When introducing a modulation in the flattop distribution, there is a gap between the end of t_flattop and t_rise. This is because the flat part is mistakenly displaced.
The line `t += sigmaTFall_m * cutoffR_m[2];` is missin...### Summary
When introducing a modulation in the flattop distribution, there is a gap between the end of t_flattop and t_rise. This is because the flat part is mistakenly displaced.
The line `t += sigmaTFall_m * cutoffR_m[2];` is missing.
### Steps to reproduce
Flattop distribution with
```
FTOSCAMPLITUDE = 50,
FTOSCPERIODS = 7,
WRITETOFILE = True,
```
Then look at the particle distribution along the longitudinal axis
albajacas_aarnau.albajacas@psi.chalbajacas_aarnau.albajacas@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/370OPAL-T: RF Phases relative to time of arrival2021-10-13T09:28:47+02:00krausOPAL-T: RF Phases relative to time of arrivalCurrently RF phases are considere either as relative to the on-crest phase (if `APVETO=FALSE`) or relative to `t=0` (`APVETO=TRUE`). For the case `APVETO=TRUE` it would be more convenient if the phases were relative to the time of arriva...Currently RF phases are considere either as relative to the on-crest phase (if `APVETO=FALSE`) or relative to `t=0` (`APVETO=TRUE`). For the case `APVETO=TRUE` it would be more convenient if the phases were relative to the time of arrival. To avoid breaking existing input files, we could add another argument to the `RFCAVITY` command to specify the phase to which the specified phase is relative.
`APVETO=TRUE` has to be used i.a. when simulating a TDS (#354).krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/369GasStripping regression test fails2019-10-11T16:29:31+02:00ext-calvo_ppedro.calvo@ciemat.esGasStripping regression test failsThe regression test (9.10.19) for GasStripping in OPAL-2.0 fails due to !177The regression test (9.10.19) for GasStripping in OPAL-2.0 fails due to !177ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/368Update physical constants2020-12-17T10:39:08+01:00ext-calvo_ppedro.calvo@ciemat.esUpdate physical constantsChecking the values of physical constants in `Physics.h`, it is observed that they must be updated with more precise values according to [2018 CODATA recommended values](https://physics.nist.gov/cuu/Constants/)
The following discussio...Checking the values of physical constants in `Physics.h`, it is observed that they must be updated with more precise values according to [2018 CODATA recommended values](https://physics.nist.gov/cuu/Constants/)
The following discussion from !183 should be addressed:
- [x] @snuverink_j started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/183#note_13783): (+1 comment)
> I think it would be nicer if m_h is added to `Physics.h` instead of a member.ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/367Info level for messages2019-10-18T23:43:02+02:00ext-calvo_ppedro.calvo@ciemat.esInfo level for messagesInfo shown in output file must have the same structure for all elements to ease of user (level, indentation...)Info shown in output file must have the same structure for all elements to ease of user (level, indentation...)ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/366Geometry losses are not recorded2019-10-08T14:45:41+02:00ext-calvo_ppedro.calvo@ciemat.esGeometry losses are not recordedParticles colliding with boundary geometry are deleted from the beam, but they are not recorded in any file .lossParticles colliding with boundary geometry are deleted from the beam, but they are not recorded in any file .losshttps://gitlab.psi.ch/OPAL/src/-/issues/365Bug in Variator::variate()2019-10-16T15:26:19+02:00snuverink_jjochem.snuverink@psi.chBug in Variator::variate()Observed by @ext-kranjcevic_m:
> I've been looking at [..] commits c21cfcf1 and 29790810.
>In Optimizer/EA/Variate.h, in variate, the individual can be declared infeasible (lines 221, 224). However, I don't see that it is then also rem...Observed by @ext-kranjcevic_m:
> I've been looking at [..] commits c21cfcf1 and 29790810.
>In Optimizer/EA/Variate.h, in variate, the individual can be declared infeasible (lines 221, 224). However, I don't see that it is then also removed from individualsToEvaluate_m, which can result in a segmentation fault in dispatch_forward_solves, because ind (line 459 in Optimizer/EA/FixedPisaNsga2.tcc) can be a null pointer. Fortunately, when the number of tries in the variator is high enough (e.g., 100 tries), this is unlikely to happen.
>Executing lines 460-485 in Optimizer/EA/FixedPisaNsga2.tcc only if (ind != NULL) should fix the problem.snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/364Optimizer stops to write to disk after a couple of configurations2019-10-08T10:16:18+02:00bellotti_rOptimizer stops to write to disk after a couple of configurationsI'm having problems with the configurations in [this repo](https://gitlab.psi.ch/bellotti_r/awa_masters), in the directory ```optim-quads```.
Steps to reproduce
==================
- Run the batch job provided in the repo (change the pat...I'm having problems with the configurations in [this repo](https://gitlab.psi.ch/bellotti_r/awa_masters), in the directory ```optim-quads```.
Steps to reproduce
==================
- Run the batch job provided in the repo (change the path to OPAL to your path)
- The job runs normally, but after 2min or so, nothing is written to the disk anymore, even if you wait 20min
- Problems do not arise if ```--ntasks=8``` is set in the Slurm file
- The same job runs fine with OPAL 2.0, so it is not a bad configurationhttps://gitlab.psi.ch/OPAL/src/-/issues/363compilation error with OPAL_DKS2019-10-01T17:56:55+02:00snuverink_jjochem.snuverink@psi.chcompilation error with OPAL_DKSAs reported by @gsell the master branch does not compile with `-DOPAL_DKS`.
```c++
/afs/psi.ch/user/g/gsell/private/src/OPAL/src/src/Classic/Solvers/CollimatorPhysics.cpp: In member function 'void CollimatorPhysics::gatherStatistics()':...As reported by @gsell the master branch does not compile with `-DOPAL_DKS`.
```c++
/afs/psi.ch/user/g/gsell/private/src/OPAL/src/src/Classic/Solvers/CollimatorPhysics.cpp: In member function 'void CollimatorPhysics::gatherStatistics()':
/afs/psi.ch/user/g/gsell/private/src/OPAL/src/src/Classic/Solvers/CollimatorPhysics.cpp:720:9: error: 'locPartsInMat_m' was not declared in this scope
locPartsInMat_m = numparticles_m + dksParts_m.size();
^~~~~~~~~~~~~~~
/afs/psi.ch/user/g/gsell/private/src/OPAL/src/src/Classic/Solvers/CollimatorPhysics.cpp:720:9: note: suggested alternative: 'locPartsInMat'
locPartsInMat_m = numparticles_m + dksParts_m.size();
^~~~~~~~~~~~~~~
locPartsInMat
/afs/psi.ch/user/g/gsell/private/src/OPAL/src/src/Classic/Solvers/CollimatorPhysics.cpp: In member function 'void CollimatorPhysics::applyDKS(PartBunchBase<double, 3>*, const std::pair<Vektor<double, 3>, double>&, size_t)':
/afs/psi.ch/user/g/gsell/private/src/OPAL/src/src/Classic/Solvers/CollimatorPhysics.cpp:799:47: error: no matching function for call to 'CollimatorPhysics::addBackToBunchDKS(PartBunchBase<double, 3>*&, unsigned int&)'
addBackToBunchDKS(bunch, i);
^
In file included from /afs/psi.ch/user/g/gsell/private/src/OPAL/src/src/Classic/Solvers/CollimatorPhysics.cpp:9:0:
/afs/psi.ch/user/g/gsell/private/src/OPAL/src/src/Classic/Solvers/CollimatorPhysics.hh:134:10: note: candidate: void CollimatorPhysics::addBackToBunchDKS(PartBunchBase<double, 3>*)
void addBackToBunchDKS(PartBunchBase<double, 3> *bunch);
^~~~~~~~~~~~~~~~~
/afs/psi.ch/user/g/gsell/private/src/OPAL/src/src/Classic/Solvers/CollimatorPhysics.hh:134:10: note: candidate expects 1 argument, 2 provided
/afs/psi.ch/user/g/gsell/private/src/OPAL/src/src/Classic/Solvers/CollimatorPhysics.cpp: At global scope:
/afs/psi.ch/user/g/gsell/private/src/OPAL/src/src/Classic/Solvers/CollimatorPhysics.cpp:834:6: error: prototype for 'void CollimatorPhysics::addBackToBunchDKS(PartBunchBase<double, 3>*, unsigned int)' does not match any in class 'CollimatorPhysics'
void CollimatorPhysics::addBackToBunchDKS(PartBunchBase<double, 3> *bunch, unsigned i) {
^~~~~~~~~~~~~~~~~
In file included from /afs/psi.ch/user/g/gsell/private/src/OPAL/src/src/Classic/Solvers/CollimatorPhysics.cpp:9:0:
/afs/psi.ch/user/g/gsell/private/src/OPAL/src/src/Classic/Solvers/CollimatorPhysics.hh:134:10: error: candidate is: void CollimatorPhysics::addBackToBunchDKS(PartBunchBase<double, 3>*)
void addBackToBunchDKS(PartBunchBase<double, 3> *bunch);
^~~~~~~~~~~~~~~~~
make[2]: *** [src/CMakeFiles/libOPAL.dir/Classic/Solvers/CollimatorPhysics.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [src/CMakeFiles/libOPAL.dir/all] Error 2
make: *** [all] Error 2
$ module list
Currently Loaded Modulefiles:
1) cmake/3.10.3 4) boost/1.68.0 7) gsl/2.5 10) opal-toolchain/2.0
2) gcc/7.3.0 5) hdf5/1.10.4 8) trilinos/12.12.1 11) cuda/10.0.130
3) openmpi/3.1.3 6) H5hut/2.0.0rc5 9) OpenBLAS/0.2.20 12) dks/1.1.2
```