src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2021-06-10T17:40:49+02:00https://gitlab.psi.ch/OPAL/src/-/issues/608Use library to parse the command line arguments2021-06-10T17:40:49+02:00krausUse library to parse the command line argumentsCurrently the command line arguments are parsed with manually written `if ... else if ... `. Additionally the arguments are parsed in different locations. Instead we should use a library such as Boost Program_options.Currently the command line arguments are parsed with manually written `if ... else if ... `. Additionally the arguments are parsed in different locations. Instead we should use a library such as Boost Program_options.https://gitlab.psi.ch/OPAL/src/-/issues/605BANDRF fieldmaps have no effect beginning with OPAL 2.22022-02-04T10:22:01+01:00winklehner_dBANDRF fieldmaps have no effect beginning with OPAL 2.2h5hut field maps (.h5part), loaded as part of the BANDRF cyclotron type that produce the desired effect in OPAL 2.0, don't seem to have any effect in OPAL 2.2 and up. Cyclotron units used to be mm and kV/mm (same as MV/m). Have these inp...h5hut field maps (.h5part), loaded as part of the BANDRF cyclotron type that produce the desired effect in OPAL 2.0, don't seem to have any effect in OPAL 2.2 and up. Cyclotron units used to be mm and kV/mm (same as MV/m). Have these input units been changed somehow?
My current example is that of an electrostatic extraction septum that correctly pushes the final turn out by ~2 cm in OPAL 2.0, but does nothing in OPAL 2.2 and up.https://gitlab.psi.ch/OPAL/src/-/issues/591Compiler error2023-11-30T16:14:16+01:00frey_mCompiler errorIn `trilinos/12.18.1` we get an error `-Werror=aggressive-loop-optimizations` due to `Ifpack2`. The issue is temporarily fixed
by reducing the optimization level from `-O3` to `-O2` (see !415).
###### Toolchain (on Merlin6):
* amrex/18....In `trilinos/12.18.1` we get an error `-Werror=aggressive-loop-optimizations` due to `Ifpack2`. The issue is temporarily fixed
by reducing the optimization level from `-O3` to `-O2` (see !415).
###### Toolchain (on Merlin6):
* amrex/18.07_3d
* boost/1.73.0
* cmake/3.15.5
* gcc/9.3.0
* gsl/2.6
* hdf5/1.10.6
* H5hut/2.0.0rc6
* OpenBLAS/0.3.10
* openmpi/3.1.6
* parmetis/4.0.3
* trilinos/12.18.1
###### Error message:
```
In member function ‘void Ifpack2::Impl::InvertDiagBlocks<BlockDiagView>::operator()(Ifpack2::Impl::InvertDiagBlocks<BlockDiagView>::Size, int&) const [with BlockDiagView = Kokkos::View<double***, Kokkos::Device<Kokkos::Serial, Kokkos::HostSpace>, Kokkos::MemoryTraits<1> >]’:
cc1plus: error: iteration 2147483649 invokes undefined behavior [-Werror=aggressive-loop-optimizations]
In file included from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Tpetra_BlockMultiVector_def.hpp:46,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Tpetra_BlockMultiVector.hpp:2,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Tpetra_BlockCrsMatrix_def.hpp:51,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Tpetra_BlockCrsMatrix.hpp:2,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Ifpack2_Relaxation_decl.hpp:52,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Ifpack2_Relaxation.hpp:1,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Ifpack2_Details_OneLevelFactory_def.hpp:51,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Ifpack2_Details_OneLevelFactory.hpp:2,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Ifpack2_Details_Factory_def.hpp:46,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Ifpack2_Details_Factory.hpp:2,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Ifpack2_Factory_decl.hpp:48,
from /opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Ifpack2_Factory.hpp:1,
from /psi/home/frey_m/test_opal_2.4/src/src/Solvers/AMR_MG/AmrSmoother.h:28,
from /psi/home/frey_m/test_opal_2.4/src/src/Solvers/AMR_MG/AmrSmoother.cpp:27:
/opt/psi/HDF5/trilinos/12.18.1/hdf5/1.10.6/openmpi/3.1.6/gcc/9.3.0/include/Tpetra_BlockView.hpp:1239:34: note: within this loop
1239 | for(IndexType j = numCols-2; j >= 0; j--) {
| ~~^~~~
cc1plus: all warnings being treated as errors
```https://gitlab.psi.ch/OPAL/src/-/issues/583Particles miss step in element with particle / matter interaction2023-11-30T15:49:00+01:00krausParticles miss step in element with particle / matter interactionIf two elements with particle / matter interaction are closer to each other than a single time step then the particles drift for one time step after leaving the first element and before entering the second element. In #308 the variable `...If two elements with particle / matter interaction are closer to each other than a single time step then the particles drift for one time step after leaving the first element and before entering the second element. In #308 the variable `tau` was introduced in the class `CollimatorPhysics` in order to get rid of a time structure. The quantity `tau` is computed for the first and the last time step. The meaning of `tau` is the fraction of a time step the current position of a particle is away from the edge. `tau` has to between `0.0` and `1.0`. However this isn't true if a particle hops from one element with particle / matter interaction to another. Currently this isn't handled correctly yet. Instead the particles drifts for at least one time step before it can enter another element with particle / matter interaction.krausext-calvo_ppedro.calvo@ciemat.eskraushttps://gitlab.psi.ch/OPAL/src/-/issues/576Emit particles from position of Source element2021-08-11T14:35:52+02:00krausEmit particles from position of Source elementCurrently the particles are always emitted from `z = 0` even if the source element is shifted.Currently the particles are always emitted from `z = 0` even if the source element is shifted.https://gitlab.psi.ch/OPAL/src/-/issues/575SAAMG: Review of the BoxCornerDomain2021-06-10T18:27:14+02:00frey_mSAAMG: Review of the BoxCornerDomainThe following discussion from !372 should be addressed:
- [ ] @winklehner_d started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/372#note_24735): (+2 comments)
> Is this what the BoxCorner geometry is supposed to l...The following discussion from !372 should be addressed:
- [ ] @winklehner_d started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/372#note_24735): (+2 comments)
> Is this what the BoxCorner geometry is supposed to look like?
>
> ![BoxCorner_Cartoon](/uploads/2248077c4f3749aacfaea715b1023638/BoxCorner_Cartoon.png)https://gitlab.psi.ch/OPAL/src/-/issues/557Optimizer gets stuck2021-06-10T19:16:54+02:00snuverink_jjochem.snuverink@psi.chOptimizer gets stuckAs reported by Finn O'Shea: the optimizer get stuck from time to time with the following example:
[fdopt.in](/uploads/e8ef7cb47cc60dcfbb8daab723b461df/fdopt.in)
[fdopt.data](/uploads/2f965a6b27a71ba36ab64519a5d8c74d/fdopt.data)
[fdopt.t...As reported by Finn O'Shea: the optimizer get stuck from time to time with the following example:
[fdopt.in](/uploads/e8ef7cb47cc60dcfbb8daab723b461df/fdopt.in)
[fdopt.data](/uploads/2f965a6b27a71ba36ab64519a5d8c74d/fdopt.data)
[fdopt.tmpl](/uploads/6e7dc37c7fe54832e01c0d7a41755e2f/fdopt.tmpl)snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/555Move Distribution attribute from the TrackRun command to the Beam command.2021-06-10T17:47:27+02:00krausMove Distribution attribute from the TrackRun command to the Beam command.It seems more logic to have them together since the distribution describes the beam of particles.It seems more logic to have them together since the distribution describes the beam of particles.https://gitlab.psi.ch/OPAL/src/-/issues/547Replace all plain pointers with smart pointers2022-11-05T23:09:24+01:00krausReplace all plain pointers with smart pointersWe should replace all plain pointers with smart pointers, either from std or from boost.
#### Some random notes
- Each class `T` for which a shared pointer `std::shared_ptr<T>` is used should feature a `typedef std::shared_ptr<T> SP`. T...We should replace all plain pointers with smart pointers, either from std or from boost.
#### Some random notes
- Each class `T` for which a shared pointer `std::shared_ptr<T>` is used should feature a `typedef std::shared_ptr<T> SP`. This reduces the amount of code we have to write.
- Cyclic references have to be avoided using weak pointers.
#### ToDos
- [ ] `ElementBase *` -> `std::shared_ptr<ElementBase>`
- [ ] return type of Object::clone
- [ ] (almost) all occurrences of the keyword `new`
- [ ] replace (occurrences of) `Pointer` class
- [ ] replace pointers in Classic/Fields with smart pointers (#744)
- [ ] replace plain pointers in Classic/AbsBeamline with smart pointers (#746)https://gitlab.psi.ch/OPAL/src/-/issues/473Cleanup field map classes and remove slow field map2021-06-10T17:50:31+02:00krausCleanup field map classes and remove slow field mapFor many field map types there are two versions: a fast (marked with `_fast` in the file name) and a slow version. For a long time the fast version is default and I don't think that anyone is using the slower ones. We should get rid of t...For many field map types there are two versions: a fast (marked with `_fast` in the file name) and a slow version. For a long time the fast version is default and I don't think that anyone is using the slower ones. We should get rid of the slow versions, e.g. the files
```
src/Classic/Fields/Astra1DDynamic.h
src/Classic/Fields/Astra1DMagnetoStatic.h
src/Classic/Fields/Astra1DElectroStatic.h
src/Classic/Fields/FM1DDynamic.h
src/Classic/Fields/FM1DMagnetoStatic.h
src/Classic/Fields/FM1DElectroStatic.h
```krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/457Dipoles in Opal-T to support quadrupole component field gradients2021-12-27T11:30:52+01:00snuverink_jjochem.snuverink@psi.chDipoles in Opal-T to support quadrupole component field gradientsThe following discussion from !269 should be addressed:
- @snuverink_j started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/269#note_16644): (+3 comments)
> The commenting out was introduced by @kraus in 595b4b83 ....The following discussion from !269 should be addressed:
- @snuverink_j started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/269#note_16644): (+3 comments)
> The commenting out was introduced by @kraus in 595b4b83 .. perhaps he can comment. Note that the class at that time was called `Bend` : https://gitlab.psi.ch/OPAL/src/blob/595b4b83818596b5f7a72e086cbbda4325f70aa8/src/Classic/AbsBeamline/Bend.cpp
- @kraus The dipoles in Opal-T used to support field gradients in version 1.6 and before. When I rewrote Opal-T I disabled it to speed up the development. However it was my intention to re-enable it (but didn't happen). I still think that we should support the quadruple component.https://gitlab.psi.ch/OPAL/src/-/issues/359CCollimator not properly implemented for horizontal cut2021-06-10T17:53:04+02:00frey_mCCollimator not properly implemented for horizontal cutAs far as I understand, the CCollimator checks the [vertical direction](https://gitlab.psi.ch/OPAL/src/blob/master/src/Classic/AbsBeamline/CCollimator.cpp#L60) in order to find out if the bunch is close to the collimator. However, this o...As far as I understand, the CCollimator checks the [vertical direction](https://gitlab.psi.ch/OPAL/src/blob/master/src/Classic/AbsBeamline/CCollimator.cpp#L60) in order to find out if the bunch is close to the collimator. However, this only works for vertical collimators (consisting of 2 CCollimator elements, i.e. upper and lower plate). In case of horizontal collimators this does not apply.frey_msnuverink_jjochem.snuverink@psi.chfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/357Unify units in Elements and Input / Output2023-10-17T13:29:00+02:00frey_mUnify units in Elements and Input / OutputAccording to #45 and #227 the units of OPAL-T and OPAL-Cycl should be unified.
The following units should be used:
* meter
* second
* MeV or eV
* Tesla
* MV
For the full list see http://amas.web.psi.ch/opal/Documentation/master/OPAL...According to #45 and #227 the units of OPAL-T and OPAL-Cycl should be unified.
The following units should be used:
* meter
* second
* MeV or eV
* Tesla
* MV
For the full list see http://amas.web.psi.ch/opal/Documentation/master/OPAL_Manual.html#sec.conventions.units
Some elements are already fixed. This issue (as discussed with @gsell) should keep track of elements that are not yet updated. If an element is missing, please add it to the list.
Developers that fixed an element should mark it here:
- [x] Bend2D - no fixing needed
- [x] BeamStripping (!368, !479)
- [x] CCollimator (!368, !479)
- [x] ~~Corrector~~ deleted in !390
- [x] Cyclotron (!632)
- [x] ~~CyclotronValley~~ deleted in !218
- [ ] Degrader
- [ ] Drift
- [ ] FlexibleCollimator
- [ ] Monitor
- [ ] Multipole
- [ ] MultipoleTBase
- [ ] MultipoleTCurvedConstRadius
- [ ] MultipoleTCurvedVarRadius
- [x] MultipoleT (!643)
- [ ] MultipoleTStraight
- [x] Offset
- [x] ~~ParallelPlate~~ deleted in !390
- [x] PluginElement (!368)
- [x] Probe (!368, !479)
- [x] RBend3D - no fixing needed
- [x] RBend - no fixing needed
- [x] RFCavity (!619)
- [x] ~~RFQuadrupole~~ deleted in !390
- [x] Ring (!632, !643)
- [x] SBend3D - no fixing needed
- [x] SBend - no fixing needed
- [x] ScalingFFAMagnet (!643)
- [x] ~~SectorFieldMapComponent~~ deleted in !230
- [x] Septum (!368, !479)
- [ ] Solenoid
- [x] Source - no fixing needed
- [x] Stripper (!368, !479)
- [ ] TravelingWave
- [x] TrimCoil
- [x] VariableRFCavityFringeField (!643)
- [x] VariableRFCavity (!643)
- [x] VerticalFFAMagnet (!643)
Input / Output
- [ ] ID1 and ID2 in stat file and track file
- [ ] Field Maps (!506)snuverink_jjochem.snuverink@psi.chext-calvo_ppedro.calvo@ciemat.esext-rogers_ckraussnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/354Add Analytic model of a transverse deflecting cavity (TCAV)2021-06-10T17:54:19+02:00adelmannAdd Analytic model of a transverse deflecting cavity (TCAV)adelmannkrausext-neveu_nadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/352Collection of simple and commented input files2021-06-10T18:10:11+02:00krausCollection of simple and commented input files1. Start with external distribution, FROMFILE, (self generated, elegant, astra,...)
2. simple optimization of beamline with multi-part goal, e.g. to minimize 6D phase space
3. OPAL with CSR
4. OPAL with 3D Fields (RBend)
5. OPAL with arb...1. Start with external distribution, FROMFILE, (self generated, elegant, astra,...)
2. simple optimization of beamline with multi-part goal, e.g. to minimize 6D phase space
3. OPAL with CSR
4. OPAL with 3D Fields (RBend)
5. OPAL with arbitrary short range wakes
J. Knedelhttps://gitlab.psi.ch/OPAL/src/-/issues/351Extend Coding Style page with a set of recommended usages2021-06-10T18:06:51+02:00snuverink_jjochem.snuverink@psi.chExtend Coding Style page with a set of recommended usagesIt would be nice if the [Coding Style page](https://gitlab.psi.ch/OPAL/src/wikis/For%20Developers/CodingStyle) would be extended with some recommended snippets how to do basics like printing to output, throwing/catching exceptions etc.
...It would be nice if the [Coding Style page](https://gitlab.psi.ch/OPAL/src/wikis/For%20Developers/CodingStyle) would be extended with some recommended snippets how to do basics like printing to output, throwing/catching exceptions etc.
For example there are several ways to print output present in the code base (cout, printf, global gmsg, INFOMSG, ERRORMSG etc.).https://gitlab.psi.ch/OPAL/src/-/issues/327General field map reader2022-01-26T19:47:13+01:00ext-neveu_nGeneral field map reader### Summary
Requesting capability to provide a field map with real and imaginary parts.
i.e. see field map here for LCLS TW structure (~3m long):
https://www.slac.stanford.edu/~lizh/link/lcls/sband-1d-field-map/lcls1-sband-1d-field-m...### Summary
Requesting capability to provide a field map with real and imaginary parts.
i.e. see field map here for LCLS TW structure (~3m long):
https://www.slac.stanford.edu/~lizh/link/lcls/sband-1d-field-map/lcls1-sband-1d-field-map-complex-field.datkrauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/297Suggestion for improvements to the Optimiser2021-06-10T17:56:24+02:00snuverink_jjochem.snuverink@psi.chSuggestion for improvements to the OptimiserSome suggestions and observations to improve usability of the optimiser by Michael Abo-Bakr (as far as not already covered in other issues):
* [ ] For 1 or 2 optimisation parameters there is no hypervolume calculation.
* [ ] It would be...Some suggestions and observations to improve usability of the optimiser by Michael Abo-Bakr (as far as not already covered in other issues):
* [ ] For 1 or 2 optimisation parameters there is no hypervolume calculation.
* [ ] It would be very nice to get at the end a final best solution in the output (defined with some cost function)
* [ ] .json format is not always ideal for reading or writing new generation files (as starting condition)
* [ ] Not all individuals appear to be really new.
* [ ] Option to adaptively change optimisation parameters (mutation, crossover etc.)snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/287Reference Particle Class for all Trackers2021-06-10T17:56:59+02:00snuverink_jjochem.snuverink@psi.chReference Particle Class for all TrackersThe cyclotron tracker has no good reference particle treatment. In addition, it would be nice to adapt the reference particle treatment of the t-tracker into a separate class. This can be used for all trackers.The cyclotron tracker has no good reference particle treatment. In addition, it would be nice to adapt the reference particle treatment of the t-tracker into a separate class. This can be used for all trackers.snuverink_jjochem.snuverink@psi.chkraussnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/286Cyclotron elements geometry option: annulus sector2023-01-27T11:45:55+01:00snuverink_jjochem.snuverink@psi.chCyclotron elements geometry option: annulus sectorSuggested by @matlocha_t: provide an annulus sector as a geometry option for the cyclotron elements (CColimator, Septum, Stripper):
![image](/uploads/9cff1d89a79d8cee66dcd30aa9d21e95/image.png)
The shape can be described as in ANSYS (h...Suggested by @matlocha_t: provide an annulus sector as a geometry option for the cyclotron elements (CColimator, Septum, Stripper):
![image](/uploads/9cff1d89a79d8cee66dcd30aa9d21e95/image.png)
The shape can be described as in ANSYS (https://www.sharcnet.ca/Software/Ansys/16.2.3/en-us/help/ans_cmd/Hlp_C_CYL4.html) with a centre position (x,y), two radii (r1, r2) and two angles.snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.ch