src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2023-12-20T14:07:50+01:00https://gitlab.psi.ch/OPAL/src/-/issues/794MultipoleT Cleanup and Placement2023-12-20T14:07:50+01:00ext-rogers_cMultipoleT Cleanup and PlacementCurrently MultipoleT places from the middle. Would be nice if it were possible to place from the start, as with other elements. Also some cleanup would be useful (and improved docs).Currently MultipoleT places from the middle. Would be nice if it were possible to place from the start, as with other elements. Also some cleanup would be useful (and improved docs).ext-rogers_cext-rogers_chttps://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/669New MITHRA module for Undulator2023-11-30T15:49:46+01:00albajacas_aarnau.albajacas@psi.chNew MITHRA module for UndulatorWhile fixing the Undulator regression tests (#658) we found some bugs in [MITHRA](https://github.com/aryafallahi/mithra).
I have opened issues and MRs in the Mithra repo to fix this, and once this is fixed we should make a new MITHRA mo...While fixing the Undulator regression tests (#658) we found some bugs in [MITHRA](https://github.com/aryafallahi/mithra).
I have opened issues and MRs in the Mithra repo to fix this, and once this is fixed we should make a new MITHRA module for Merlin.
- [ ] Resolve issues and MRs in the Mithra repository
- [ ] Test Mithra's master branch with OPAL and implement necessary changes in `Undulator.cpp`
- [ ] Ask Arya (Mithra developer) to make new release MITHRA-2.1
- [ ] Achim compiles module on Merlinalbajacas_aarnau.albajacas@psi.chalbajacas_aarnau.albajacas@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/274SBend3d field map not parsed2023-11-30T15:49:12+01:00ext-rogers_cSBend3d field map not parsedWhen attempting to load an SBend3D field map, the input is not parsed correctly. OPAL dies with error
> User error detected by function SectorMagneticFieldMap::IO::getInterpolator
> Ran out of field points during read operation; che...When attempting to load an SBend3D field map, the input is not parsed correctly. OPAL dies with error
> User error detected by function SectorMagneticFieldMap::IO::getInterpolator
> Ran out of field points during read operation; check bounds and ordering
> Ran out of field points during read operation; check bounds and ordering
and then the usual MPI_ABORT stuff
Files:
[Bfield.dat.gz](/uploads/ac220399c42a92b40ee8542ca208a753/Bfield.dat.gz)
[Bfield-nobump.dat.gz](/uploads/1227ca0fa9b8a501630e01298989099b/Bfield-nobump.dat.gz)
[tosca.in](/uploads/bd535625cba6ef794dfd2680e0ed7711/tosca.in)ext-rogers_csnuverink_jjochem.snuverink@psi.chext-rogers_c2020-09-23https://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/792OPAL Monitor Memory Usage2023-11-29T17:22:02+01:00adelmannOPAL Monitor Memory Usage### Summary
(Summarize the bug encountered concisely)
One thing I ran into recently is an out-of-memory issue when I run it with many "monitor" elements. What seems to be happening is that the memory allocated while saving the particles...### Summary
(Summarize the bug encountered concisely)
One thing I ran into recently is an out-of-memory issue when I run it with many "monitor" elements. What seems to be happening is that the memory allocated while saving the particles to disk doesn't get freed after the file is output. In my case, I was using 2 million particles and I could see the memory usage rise by 200MB as the first monitor output is saved to disk and then rise by another 200MB at the second and so on. Since I was producing video-like output with 48 monitors, it didn't take long to exceed our cluster's 4GB per core limit.
### Steps to reproduce
Run simulation with 2E6 particles and 48 monitors
### What is the current *bug* behavior?
out of memory
### What is the expected *correct* behavior?
no out of memory
### Relevant logs and/or screenshots
I did some digging in the source code and on line 367 in `src/Classic/Structure/LossDataSink.cpp` I saw that the vectors storing particle information in the monitor objects do get cleared. Reading online, though (since I'm not a C++ expert) I saw some people saying this might not free memory (https://stackoverflow.com/questions/13944886/is-stdvector-memory-freed-upon-a-clear). I implemented their suggestion, ie the following code to replace all of the clear methods.
### Possible fixes
std::vector<OpalParticle>().swap(particles_m);
std::vector<size_t>().swap(turnNumber_m);
std::vector<size_t>().swap(bunchNumber_m);
std::vector<double>().swap(spos_m);
std::vector<double>().swap(refTime_m);
std::vector<Vector_t>().swap(RefPartR_m);
std::vector<Vector_t>().swap(RefPartP_m);
std::vector<h5_int64_t>().swap(globalTrackStep_m);2023.1adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/791OPAL release 2023.12023-11-20T13:31:04+01:00gsellOPAL release 2023.1**source code**
* [ ] review the file `src/addToDoxygenMainPage.h` (list of Authors)
* [x] create issue "Release version YEAR.N" (without MR)
* [x] create branch OPAL-YEAR.N
* [x] create issue and MR with target branch YEAR.N...**source code**
* [ ] review the file `src/addToDoxygenMainPage.h` (list of Authors)
* [x] create issue "Release version YEAR.N" (without MR)
* [x] create branch OPAL-YEAR.N
* [x] create issue and MR with target branch YEAR.N
* [x] update version string in CMakeLists.txt and Doxyfile to YEAR.N
* [ ] wait for approval and merge
* [ ] tag version OPAL-YEAR.N.0 on branch OPAL-YEAR.N
* [ ] create MR with target branch master
* [ ] update version string in CMakeLists.txt and Doxyfile to YEAR.N+1-dev
* [ ] wait for approval and merge
**binaries**
* [ ] upload source tar-ball to <br>
`/afs/psi.ch/project/amas/webhosting/Downloads/OPAL/src/OPAL-YEAR.N.0.tar.xz`
* [ ] binary for Linux
* [ ] compile on opalrunner with build-recipes <br>
Note:
* [ ] upload Linux binary package to <br>
`/afs/psi.ch/project/amas/webhosting/Downloads/OPAL/package/OPAL-YEAR.N.0-1-x86_64-linux.tar.xz`
* [ ] tested by other developers
* [ ] binary for macOS x86_64
* [ ] compile with Clang on macOS with Intel CPU and current OS/Xcode
* [ ] upload macOS binary package to <br>
`/afs/psi.ch/project/amas/webhosting/Downloads/OPAL/package/OPAL-YEAR.N.0-1-x86_64-macos.tar.xz`
* [ ] tested by other developers
* [ ] binary for macOS M1
* [ ] compile with Clang on macOS with M1 CPU and current OS/Xcode
* [ ] upload macOS binary package to <br>
`/afs/psi.ch/project/amas/webhosting/Downloads/OPAL/package/OPAL-YEAR.N.0-1-arm-macos.tar.xz`
* [ ] tested by other developers
**regression-tests**
* [ ] create new branch YEAR.N
* [ ] setup the regression-tests to run the new version on opalrunner.psi.ch
**manual/documentation**
* [ ] setup a new branch for the new version of the manual
* [ ] fix version, branches and links in `Manual.attributes`
* [ ] clone repository into <br>
`/afs/psi.ch/project/amas/webhosting/opal/Documentation/YEAR.N` <br>
and checkout new branch: <br>
`git clone https://gitlab.psi.ch/OPAL/documentation/manual.git YEAR.N && cd YEAR.N && git checkout OPAL-YEAR.N`
* [ ] add links to the binaries in the wiki
* [ ] update https://gitlab.psi.ch/OPAL/src/wikis/For-Developers/Compile-OPAL
* [ ] compile the change log/release notes and publish it in the wiki: https://gitlab.psi.ch/OPAL/src/wikis/ReleaseNotes
* [ ] build Doxygen documentation
* [ ] update https://gitlab.psi.ch/OPAL/src/wikis/home
**tracker**
* [ ] new milestone for `OPAL x.(y+1)`
* [ ] update labels and milestones in issues
**varia**
* [ ] PSI module
* [ ] write e-mail to mailing list2023.1gsellgsellhttps://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/784Get PyOpal + OPAL-T working2023-09-27T12:34:58+02:00ext-rogers_cGet PyOpal + OPAL-T workingJob list:
0. Install OPAL, with PyOPAL switched on, and check that the tests pass.
1. Take a test like `tests/opal_src/PyOpal/PyObjects/test_parser.py` and check that the parser can parse an "old-style" OPAL-T lattice. I think this shou...Job list:
0. Install OPAL, with PyOPAL switched on, and check that the tests pass.
1. Take a test like `tests/opal_src/PyOpal/PyObjects/test_parser.py` and check that the parser can parse an "old-style" OPAL-T lattice. I think this should just work without any edits.
2. Take an example like `tests/opal_src/PyOpal/PyObjects/test_field.py` and adapt for OPAL-T. You will likely need to edit `src/PyOpal/PyObjects/PyField.cpp` to handle the case where _tracker_ inherits from ParallelTTracker.
3. Take an example like `tests/opal_src/PyOpal/PyObjects/test_track_run.py` and adapt for a minimal OPAL-T example. Note that test_track_run employs the pre-built Opal "Minimal" lattice `src/PyOpal/PyPython/minimal_runner.py`
Would be great if in all these cases you could add in the unit tests so that we know if the code breaks in the future.https://gitlab.psi.ch/OPAL/src/-/issues/686Use a library that provides dimensional analysis and unit/quantity manipulation.2023-07-24T11:02:38+02:00krausUse a library that provides dimensional analysis and unit/quantity manipulation.Once we switch to c++20 then we should use [this library](https://github.com/mpusz/units) to make unit convertions safe. Ideally we also provide units for the parser such that the user can provide quantities in different units than meter...Once we switch to c++20 then we should use [this library](https://github.com/mpusz/units) to make unit convertions safe. Ideally we also provide units for the parser such that the user can provide quantities in different units than meter, seconds etc.
See also [here](https://mpusz.github.io/units/introduction.html) and [here](https://www.youtube.com/watch?v=7dExYGSOJzo).https://gitlab.psi.ch/OPAL/src/-/issues/757Zero field should create a warning2023-04-12T10:58:36+02:00adelmannZero field should create a warning### Summary
In case a zero field is read in, a warning should be issued.
Such almost zero fields make sense however one field component must be non zero.
The attached example shows the zero field and the fixed zero field.
[zero-field-...### Summary
In case a zero field is read in, a warning should be issued.
Such almost zero fields make sense however one field component must be non zero.
The attached example shows the zero field and the fixed zero field.
[zero-field-example.zip](/uploads/334c29c62cd2efbaff2e81f244885022/zero-field-example.zip)2023.1adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/749More geometries for cyclotron elements2023-01-27T17:57:31+01:00snuverink_jjochem.snuverink@psi.chMore geometries for cyclotron elementsFrom @zhang_h: It would be better if the collimators in forms other than a rectangular could also be defined in OPAL_cycl. The collimators in Ring or Injector2 or COMET could be in forms of a trapezoid, a triangle, a circle, and an ellipse.From @zhang_h: It would be better if the collimators in forms other than a rectangular could also be defined in OPAL_cycl. The collimators in Ring or Injector2 or COMET could be in forms of a trapezoid, a triangle, a circle, and an ellipse.https://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.chhttps://gitlab.psi.ch/OPAL/src/-/issues/746Use smart pointers for elements2022-11-05T23:09:24+01:00krausUse smart pointers for elements2023.1krauskraushttps://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/717Writing initial distribution fails in multicore case2022-05-19T14:35:52+02:00ext-calvo_ppedro.calvo@ciemat.esWriting initial distribution fails in multicore caseWriting the initial distribution to file (making use of `WRITETOFILE` attribute) fails for injected distributions when the simulation is run in a parallel environment. The output file only saves the particles of the first nodeWriting the initial distribution to file (making use of `WRITETOFILE` attribute) fails for injected distributions when the simulation is run in a parallel environment. The output file only saves the particles of the first nodehttps://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/705Enabling 3DDynamics to accept complex field2022-01-26T20:26:07+01:00ext-piot_pEnabling 3DDynamics to accept complex field### Summary
Right now OPAL only allows for 3D map to be real-values. For a project at AWA we need the map to be complex values. I would like to implement by introducing a 3DDynamicsComplex flat in the external map describing the field w...### Summary
Right now OPAL only allows for 3D map to be real-values. For a project at AWA we need the map to be complex values. I would like to implement by introducing a 3DDynamicsComplex flat in the external map describing the field with columns being Re(Ex), Re(Ey) Re(Ez), Im(Ex), Im(Ey) Im(Ez), Re(Hx), Re(Hy) Re(Hz), Im(Hx), Im(Hy) Im(Hz) . I will try to implement this in the next few days -- this is related to the question from one of my colleagues (Seong-Yeol). Any better suggestion?ext-piot_pext-piot_phttps://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/227Tasks for Opal Developer Retreat 2021 work list2022-01-17T09:25:11+01:00krausTasks for Opal Developer Retreat 2021 work listStart adapting the Erice working list for the new retreat in [Berlin (2019)](https://gitlab.psi.ch/OPAL/src/wikis/opal-developer-&-user-retreat/berlin-2019).
Start adapting the Berlin working list for the new retreat in [SLAC (2020)](ht...Start adapting the Erice working list for the new retreat in [Berlin (2019)](https://gitlab.psi.ch/OPAL/src/wikis/opal-developer-&-user-retreat/berlin-2019).
Start adapting the Berlin working list for the new retreat in [SLAC (2020)](https://gitlab.psi.ch/OPAL/src/wikis/opal-developer-&-user-retreat/slac-2020).
Start adapting the Slac working list for the new retreat in [WWW (2021)](https://gitlab.psi.ch/OPAL/src/-/wikis/opal-developer-retreat/Opal-Developer-Retreate,-WWW-2021).
**General**
- [ ] **pyOPAL (#516, #624)**
- [ ] **IPPL V 2.0 integration**
- [ ] OPAL Paper
- [x] Manual
- [x] Finish #46
- [ ] Finish #45 (and #357)
- [ ] Minimum number of particles for statistic (*.stat file) write
- [ ] Minimum number of particles for statistic H5
- [x] Unify usage of Quaternion
- [ ] Reference particle(s) class, for both flavours #287
- [ ] Many unit conversions (m,T) (#690, #704)
- [ ] Clean and collect existing examples in one location
**OPAL-cycl**
- [x] Refactoring OPAL-cycl, remove duplicated/not used code (#124, #666, !462)
- [x] Double check multibunch tracking in OPAL-cycl
- [ ] Unify units OPAL-t / OPAL-cycl (#242) , check also #80 ?
- [ ] Has special files do we want to keep them or add the information into the h5 file?
- [ ] Cleanup cyclotron units:
- [ ] internal x,y,z
- [ ] external use x,z,y later this can be set by a switch
- [x] delete trackers
- [ ] Timedependent E (B) a la Ring
- [x] Fieldsolver sanity check
**OPAL-T**
- [ ] Make energy bins dynamic where the number of energy bins and the number of particles per bin can vary (#270)
- [ ] ~~Test~~ Implement adaptive time integration
**SAAMG solver**
- [ ] Fix one issue with defining reference point in geometry for SAAMG solver
- [ ] Make SAAMG solver parallel again
- [x] Use new TRILINOS packages (#507)
**Testing framework**
- [x] Regression tests, with/without GPU
- [x] Unit tests (regression-tests#53)
- [ ] Jenkins/Continous Integration etc
**Distribution class**
- [ ] Split into code for the parser and implementation (#629)
- [ ] Use separate classes for the different types (#629)
- [ ] Rethinking / refactoring algorithms
**Additional tasks**
- [x] ~~Enable~~ Remove OPAL-Slice (!343)
- [x] Enable OPAL-Map (!42)
- [x] Merge beam stripping physics (forked) (!183)
- [x] Enable the work of Pedro and add documentation (https://gitlab.psi.ch/OPAL/Manual-2.1/merge_requests/20)