src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2020-02-25T17:26:17+01:00https://gitlab.psi.ch/OPAL/src/-/issues/476missing include of <algorithm> and usage of std::minmax()2020-02-25T17:26:17+01:00gsellmissing include of <algorithm> and usage of std::minmax()In `bet/profile.cpp` the header `<algorithm>` must be included. Don't now why it compiles on macOS without ...
`std::minmax()` has been removed from C++17! This should be replaced.In `bet/profile.cpp` the header `<algorithm>` must be included. Don't now why it compiles on macOS without ...
`std::minmax()` has been removed from C++17! This should be replaced.OPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/475Formula momentum conversion2021-04-23T17:10:39+02:00albajacas_aarnau.albajacas@psi.chFormula momentum conversion* [x] Add two functions to Utilities/Util
* [x] Update documentation
### Summary
I'm not sure if this is a bug, but I don't understand the formula used to convert P [eV/c] to $`\beta\gamma`$ [dimensionless] in the function [`Distribut...* [x] Add two functions to Utilities/Util
* [x] Update documentation
### Summary
I'm not sure if this is a bug, but I don't understand the formula used to convert P [eV/c] to $`\beta\gamma`$ [dimensionless] in the function [`Distribution::converteVToBetaGamma`](https://gitlab.psi.ch/OPAL/src/blob/master/src/Distribution/Distribution.cpp#L904):
```math
(\beta_x\gamma)=\sqrt{(\frac{P_x[{eV/c}]}{m_0c}+1)^2-1}.
```
If the user gives momentum in eV/c, I would imagine that the conversion should be
```math
\gamma\beta_x = \frac{P_xc}{mc^2}.
```
If it's not a bug then I think it should be better explained in the manual.OPAL 2.4.0albajacas_aarnau.albajacas@psi.chalbajacas_aarnau.albajacas@psi.ch2020-07-24https://gitlab.psi.ch/OPAL/src/-/issues/472Compiler warnings from unit tests and ippl tests2020-02-24T13:31:25+01:00snuverink_jjochem.snuverink@psi.chCompiler warnings from unit tests and ippl testsThe following discussion from !279 should be addressed:
- [ ] @kraus started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/279#note_17520): (+1 comment)
> @gsell you've forgotten to fix the unit tests... In the atta...The following discussion from !279 should be addressed:
- [ ] @kraus started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/279#note_17520): (+1 comment)
> @gsell you've forgotten to fix the unit tests... In the attached patch there are some more removed unused parameters.[0001-forgotten-unused-arguments.patch](/uploads/5efd63b13a3fba136972b8e72c4ce8c5/0001-forgotten-unused-arguments.patch)OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/471output info cyclotron type BANDRF2020-02-21T11:08:56+01:00ext-calvo_ppedro.calvo@ciemat.esoutput info cyclotron type BANDRFAdding relevant additional information into output file for cyclotron `TYPE=BANDRF` as initial phase of the electric field map (`RFPHI`) or scale factor (`ESCALE`)Adding relevant additional information into output file for cyclotron `TYPE=BANDRF` as initial phase of the electric field map (`RFPHI`) or scale factor (`ESCALE`)OPAL 2.4.0ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/470New multiGauss distribution2020-02-20T10:32:48+01:00albajacas_aarnau.albajacas@psi.chNew multiGauss distribution### Summary
In the cathode at the Argonne Wakefield Accelerator they have the ability to produce microbunched electron bunches, thanks to a laser beam which has a train of Gaussian pulses.
[Temporal Laser Pulse Shaping for RF Photocatho...### Summary
In the cathode at the Argonne Wakefield Accelerator they have the ability to produce microbunched electron bunches, thanks to a laser beam which has a train of Gaussian pulses.
[Temporal Laser Pulse Shaping for RF Photocathode Guns](https://aip.scitation.org/doi/10.1063/1.3080991)
At the moment there is no OPAL distribution to reproduce this.
Here is an example with 4 Gaussian microbunches separated (peak-to-peak) by 1.26 mm:
```
Dist: DISTRIBUTION, TYPE = MULTIGAUSS,
SIGMAPX = 1e-2, SIGMAPY = 1e-2, SIGMAPZ = 1e-2, // In units of betaGamma
CUTOFFPX = 4.0, CUTOFFPY = 4.0, CUTOFFPZ = 4.0, // In units of SIGMAP
SIGMAR = 340e-6,
SIGMAZ = .9e-3 / 2.355, // FWHM = 2.355 * sigma
CUTOFFLONG = 4.0, // In units of SIGZ
SEPPEAKS = 1.26e-3,
NPEAKS = 4,
EMITTED = FALSE;
```
This is what it looks like:
![distroInject](/uploads/65acbe6003cd1c8336272d98e3ddc5a8/distroInject.png)
In the case where the bunch is emitted, SIGMAPX/Y/Z and CUTOFFPX/Y/Z are omitted, and SIGMAZ and SEPPEAKS are to be given in seconds.OPAL 2.4.0albajacas_aarnau.albajacas@psi.chalbajacas_aarnau.albajacas@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/469asciih5block not working with recent H5Hut library?2020-03-02T13:48:39+01:00snuverink_jjochem.snuverink@psi.chasciih5block not working with recent H5Hut library?### Summary
The asciih5block script returns error messages and an empty (header only) file
### Steps to reproduce
```
module use unstable; module load gcc/7.3.0 mpich/3.3 hdf5/1.10.4 H5hut/2.0.0rc5
```
I believe this will happen with...### Summary
The asciih5block script returns error messages and an empty (header only) file
### Steps to reproduce
```
module use unstable; module load gcc/7.3.0 mpich/3.3 hdf5/1.10.4 H5hut/2.0.0rc5
```
I believe this will happen with any input file, an example is given here.
Example input file: [NewChimney_R000_D000E.txt](/uploads/88ca38d65d6d433b084ac7ec2765c716/NewChimney_R000_D000E.txt)
Modify ascii2h5block_asgic.cpp for the right dimensions: [ascii2h5block_asgic.cpp](/uploads/dcbcdc4b7018f73169bc7a507ee2b496/ascii2h5block_asgic.cpp)
```bash
$ export LDLIBS=-lH5hut
$ make ascii2h5block_asgic
$ ./ascii2h5block_asgic NewChimney_R000_D000E.txt out
--------------------------------------------------------
Using NewChimney_R000_D000E.txt to create test_CYC.h5part
Lines in finE: 67370
Hardcoded limits: x(-90/-10) cm
Hardcoded limits: y(-30/30) cm
Hardcoded limits: z(-1/1) cm
Hardcoded spacing: 0.5 cm
Hardcoded nlines: 67367
File nlines: 67365
Grid dimensions: Px = 23 , Py = 29 , Pz = 101
E_max = (29.0302, -5.6267, -23.2274) V/cm at index 20641.
Converting from V/cm and cm to kV/mm and mm before saving h5part
[proc 0] E: H5Block3dSetView: Iteration is invalid! Have you set the time step?
[proc 0] E: H5Block3dWriteVector3dFieldFloat64: No view has been defined!
[proc 0] E: H5Block3dWriteVector3dFieldFloat64: No view has been defined!
Done, bye ...
```
### What is the current *bug* behavior?
Header only H5-file
### What is the expected *correct* behavior?
H5-file with correct field
### Possible fixes
The `H5SetStep` should be set before the View:
```c++
H5SetStep(file, 0);
h5_err_t h5err = H5Block3dSetView(file,
0, gridPx - 1,
0, gridPy - 1,
0, gridPz - 1);
```
[This modified ascii2h5block_asgic.cpp](/uploads/3e55c0263d5930c84b6b5d933467277f/ascii2h5block_asgic.cpp) runs successfully.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/468Format of _ElementPositions.sdds files wrong2020-02-19T17:04:41+01:00krausFormat of _ElementPositions.sdds files wrong### Summary
The format of the data values in `_ElementPositions.sdds` is wrong. The numbers are written with `std::ios_base::hex` instead of `std::ios_base::dec`.
### Steps to reproduce
Run any input file for OPAL-T and check the dat...### Summary
The format of the data values in `_ElementPositions.sdds` is wrong. The numbers are written with `std::ios_base::hex` instead of `std::ios_base::dec`.
### Steps to reproduce
Run any input file for OPAL-T and check the data in the SDDS file.
### What is the current *bug* behavior?
The data look like this:
```
&data
mode=ascii,
no_row_counts=1
&end
1
OPAL 2.1.0 git rev. #a23b3950ffa3756d157d4e41dc04569663c2eb13
opal-t
0x1.f97b4a2339c0ep+4 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 ""
0x1.037cd7b767d82p+5 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 ""
0x1.037cd7b767d82p+5 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x0p+0 0x1p+0 "D69"
```
### What is the expected *correct* behavior?
The data should start with lines similar like this:
```
&data
mode=ascii,
no_row_counts=1
&end
1
OPAL 2.1.0 git rev. #a23b3950ffa3756d157d4e41dc04569663c2eb13
opal-t
31.5926000000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 ""
32.4359583214 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 ""
32.4359583214 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 1.0000 "D69"
```
OPAL 2.4.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/467cleanup: make OPAL compile with -Wextra and -Werror2020-04-22T13:16:31+02:00gsellcleanup: make OPAL compile with -Wextra and -WerrorOPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/464What is the status of OPAL Map?2020-03-11T11:19:23+01:00gsellWhat is the status of OPAL Map?To me it looks like that there is still something to do. (See `Algorithms/MapAnalyser.cpp`)
EDIT 18-2 (@snuverink\_j):
* [x] Add thesis to wiki
* [x] Review TODOs in code -> code not used, but to be kept for now.
* [x] Remove bodies of...To me it looks like that there is still something to do. (See `Algorithms/MapAnalyser.cpp`)
EDIT 18-2 (@snuverink\_j):
* [x] Add thesis to wiki
* [x] Review TODOs in code -> code not used, but to be kept for now.
* [x] Remove bodies of unfinished methods, add note (!294)OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/463prevent Emacs from adding a new line at end of file2020-02-14T17:14:04+01:00gsellprevent Emacs from adding a new line at end of fileWith the default configuration Emacs requires a final new-line at the end of a file. If the last character of a file is not a new-line, Emacs adds one while saving. This can be changed by setting `require-final-newline` to `nil`With the default configuration Emacs requires a final new-line at the end of a file. If the last character of a file is not a new-line, Emacs adds one while saving. This can be changed by setting `require-final-newline` to `nil`OPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/462cleanup: Runge-Kutta implementation2020-04-23T14:56:01+02:00gsellcleanup: Runge-Kutta implementationWe have two Runge-Kutta method implementations in OPAL:
```
src/Steppers/RK4.{h,hpp}
```
and
```
src/Algorithms/bet/math/rk.{cpp,h}
```We have two Runge-Kutta method implementations in OPAL:
```
src/Steppers/RK4.{h,hpp}
```
and
```
src/Algorithms/bet/math/rk.{cpp,h}
```OPAL 2.4.0https://gitlab.psi.ch/OPAL/src/-/issues/461cleanup: beam envelope tracker2020-02-25T14:29:40+01:00gsellcleanup: beam envelope tracker* Remove unused functions
* fix -Wextra warnings
* cleanup/review code in bet/math
* use stack for small arrays and matrices instead of alloc memory
* throw `OpalException` in case of an error instead using writeBetError() and continue
*...* Remove unused functions
* fix -Wextra warnings
* cleanup/review code in bet/math
* use stack for small arrays and matrices instead of alloc memory
* throw `OpalException` in case of an error instead using writeBetError() and continue
* cleanup headers in bet/math, remove CVS tags
* add footer with editor settings
OPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/460cleanup: remove readline support in Classic parser2020-05-05T15:19:24+02:00gsellcleanup: remove readline support in Classic parserThe TerminalStream class features support for the readline library. But this is not used for the time being, untested and adds one more dependencies. Since this was never supported in OPAL, readline support should be removed.The TerminalStream class features support for the readline library. But this is not used for the time being, untested and adds one more dependencies. Since this was never supported in OPAL, readline support should be removed.OPAL 2.4.0gsellsnuverink_jjochem.snuverink@psi.chgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/459review FlexibleCollimator::isStopped() method in Classic2020-07-06T13:49:42+02:00gsellreview FlexibleCollimator::isStopped() method in Classic@kraus "The question is, where we should check whether a particle hits material at the center or at the end of a time step (ideally everywhere but too time consuming). It used to be at the end (before I implemented the configurable colli...@kraus "The question is, where we should check whether a particle hits material at the center or at the end of a time step (ideally everywhere but too time consuming). It used to be at the end (before I implemented the configurable collimator) and I changed it to the middle. The extra argument could probably be removed."
See discussion on MR !269 OPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/458cleanup: unused arguments in beam stripping files2020-02-19T09:17:53+01:00ext-calvo_ppedro.calvo@ciemat.escleanup: unused arguments in beam stripping filesThe following discussion from !269 should be addressed:
- [ ] @ext-calvo_p started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/269#note_16635):
> The argument `const Vector_t &/*R*/` could be remove totally from t...The following discussion from !269 should be addressed:
- [ ] @ext-calvo_p started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/269#note_16635):
> The argument `const Vector_t &/*R*/` could be remove totally from this method, it is completely uselessOPAL 2.4.0ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/455Make `src/Classic/Solvers/GreenWakeFunction::testApply()` a unit test2020-02-04T19:58:41+01:00snuverink_jjochem.snuverink@psi.chMake `src/Classic/Solvers/GreenWakeFunction::testApply()` a unit testThe following discussion from !269 should be addressed:
- [x] @snuverink_j started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/269#note_16640):
> It should be made into a unit test. I will open a new issue for it....The following discussion from !269 should be addressed:
- [x] @snuverink_j started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/269#note_16640):
> It should be made into a unit test. I will open a new issue for it.
The preprocesser definition `#ifdef ENABLE_WAKE_TESTS` and the function `testApply()` in `src/Classic/Solvers/GreenWakeFunction.cpp` should be transformed into a unit test.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/454cleanup: make Classic compile with -Wextra and -Werror2020-02-22T22:21:22+01:00gsellcleanup: make Classic compile with -Wextra and -WerrorThere are quite a lot of methods with unused arguments. These arguments should be commended out like:
```
bool operator==(const AntiSymTenzor<T,1>& /*that*/) const {
return true;
}
```
(example from IPPL)There are quite a lot of methods with unused arguments. These arguments should be commended out like:
```
bool operator==(const AntiSymTenzor<T,1>& /*that*/) const {
return true;
}
```
(example from IPPL)OPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/453cleanup: make optimizer compile with -Wextra and -Werror2020-02-22T22:21:22+01:00gsellcleanup: make optimizer compile with -Wextra and -WerrorThere are quite a lot of methods with unused arguments. These arguments should be commended out like:
```
bool operator==(const AntiSymTenzor<T,1>& /*that*/) const {
return true;
}
```
(from IPPL)There are quite a lot of methods with unused arguments. These arguments should be commended out like:
```
bool operator==(const AntiSymTenzor<T,1>& /*that*/) const {
return true;
}
```
(from IPPL)OPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/452cleanup: make IPPL compile with -Wextra and -Werror2020-01-24T16:23:26+01:00gsellcleanup: make IPPL compile with -Wextra and -WerrorThere are quite a lot of methods with unused arguments. These arguments should be commended out like:
```
bool operator==(const AntiSymTenzor<T,1>& /*that*/) const {
return true;
}
```There are quite a lot of methods with unused arguments. These arguments should be commended out like:
```
bool operator==(const AntiSymTenzor<T,1>& /*that*/) const {
return true;
}
```OPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/451Unused classes in OPAL2020-01-23T12:44:07+01:00snuverink_jjochem.snuverink@psi.chUnused classes in OPALThe following files / classes are unused as far as I can see:
* ippl/src/AppTypes/GenVektor.h
* ippl/src/Utility/IplCounter.h
* ippl/src/Utility/RNGBitReverse.h
* ippl/src/Utility/RNGLattice.h
* src/Classic/Algebra/NormalForm.h / cpp
* ...The following files / classes are unused as far as I can see:
* ippl/src/AppTypes/GenVektor.h
* ippl/src/Utility/IplCounter.h
* ippl/src/Utility/RNGBitReverse.h
* ippl/src/Utility/RNGLattice.h
* src/Classic/Algebra/NormalForm.h / cpp
* src/Classic/Algebra/ComplexEigen
* src/Classic/Algebra/DoubleEigen
* src/Classic/FixedAlgebra/FComplexEigen
* src/Classic/Utilities/NormalFormError
* src/Lines/FlatWriter.h / cpp
* src/Utilities/InverseGauss
* src/Utilities/TpsWerrf.h / cpp
* optimizer/Comm/Splitter/GeometricStrategy.h
* optimizer/Comm/Splitter/RandomStrategy.h
@adelmann : can these be deleted?OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.ch