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/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/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/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/746Use smart pointers for elements2022-11-05T23:09:24+01:00krausUse smart pointers for elements2023.1krauskraushttps://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/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/688Make element MultipoleT useable from Opal-t2021-10-24T18:12:24+02:00krausMake element MultipoleT useable from Opal-tMultipoleT currently only supports Opal-cycl even though in the documentation it was stated that its only supports Opal-t (corrected 21.10.2021). Multipoles with fringe fields are also useful for Opal-t.MultipoleT currently only supports Opal-cycl even though in the documentation it was stated that its only supports Opal-t (corrected 21.10.2021). Multipoles with fringe fields are also useful for Opal-t.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/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/661BANDRF field map type needs both E and B field2021-06-23T11:42:16+02:00snuverink_jjochem.snuverink@psi.chBANDRF field map type needs both E and B fieldThe `BANDRF` / `T3DDynamicH5Block` field map type, as produced by the `ascii2h5block` script, only accepts fields that have both the E field and B field specified. This shouldn't be necessary, and either only an electric field or magneti...The `BANDRF` / `T3DDynamicH5Block` field map type, as produced by the `ascii2h5block` script, only accepts fields that have both the E field and B field specified. This shouldn't be necessary, and either only an electric field or magnetic field could be specified as well.https://gitlab.psi.ch/OPAL/src/-/issues/629Use separate classes for different distribution types2021-06-10T17:27:41+02:00krausUse separate classes for different distribution types![Distributions.svg](/uploads/bb44bdfd74954e672c75c1187c2de554/Distributions.svg)
- Use separate classes for each type for parsing and for the actual generation of a distribution.
- Move the `DISTRIBUTION` attribute from the `TRACKRUN` ...![Distributions.svg](/uploads/bb44bdfd74954e672c75c1187c2de554/Distributions.svg)
- Use separate classes for each type for parsing and for the actual generation of a distribution.
- Move the `DISTRIBUTION` attribute from the `TRACKRUN` command to `BEAM` command.krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/628Add signal handler for SIGABRT, SIGSEGV with stacktrace2021-07-09T08:41:11+02:00krausAdd signal handler for SIGABRT, SIGSEGV with stacktraceOne could add a handler to `main(...)` to print a stacktrace in case a run is aborted or a segmentation fault occurred. See e.g. [here](https://stackoverflow.com/questions/77005/how-to-automatically-generate-a-stacktrace-when-my-program-...One could add a handler to `main(...)` to print a stacktrace in case a run is aborted or a segmentation fault occurred. See e.g. [here](https://stackoverflow.com/questions/77005/how-to-automatically-generate-a-stacktrace-when-my-program-crashes). I don't know if this is portable. One could also have a look at how [Glog](https://github.com/google/glog) does it in `Google::InstallFailureSignalHandler()`.
### Stacktrace with line numbers
[link#1](https://stackoverflow.com/questions/4636456/how-to-get-a-stack-trace-for-c-using-gcc-with-line-number-information)
[link#2](https://stackoverflow.com/questions/3151779/best-way-to-invoke-gdb-from-inside-program-to-print-its-stacktrace/4611112#4611112)
### Glog
[link#1](https://github.com/google/glog/blob/master/src/signalhandler.cc)https://gitlab.psi.ch/OPAL/src/-/issues/625Fix exceptions in parallel2021-06-09T21:19:42+02:00ext-calvo_ppedro.calvo@ciemat.esFix exceptions in parallelThe following discussion from !458 should be addressed:
- [ ] @snuverink_j started a [discussion](https://gitlab.psi.ch/OPAL/src/-/merge_requests/458#note_28753): (+5 comments)
> If I understand correctly the file is only read by ...The following discussion from !458 should be addressed:
- [ ] @snuverink_j started a [discussion](https://gitlab.psi.ch/OPAL/src/-/merge_requests/458#note_28753): (+5 comments)
> If I understand correctly the file is only read by node 0, so this check can be done by node 0 only (as it was before).
>
> But to be honest, I don't understand why it was not working before in the parallel environment. Can you elaborate a bit?
@ext-calvo_p
> I thought in the same way, but when OPAL is run in the parallel environment and the distribution file doesn't exist, OpalException is not thrown.
>
> I think that checking if the file exists before opening it does not have to be done exclusively by node 0.
@snuverink_j
> I can reproduce it: the simulation hangs.
>
>But this seems something more fundamental to me, because I would also have expected that a throw by a single node would be enough to stop the simulation. @gsell: Should that not be the case?
@kraus
> In Main.cpp we catch the exception and then call MPI_Abort on MPI_COMM_WORLD. I thought that this should also stop the other nodes but this isn't the case. So we try to throw the exception on all nodes.https://gitlab.psi.ch/OPAL/src/-/issues/623Unify styles of separator lines2021-06-10T17:29:34+02:00krausUnify styles of separator linesCurrently `-`, `=` and `*` are used to draw separator lines in the output and also the length of these lines vary. Do the different styles have different meanings or could they be unified both in the character and length?Currently `-`, `=` and `*` are used to draw separator lines in the output and also the length of these lines vary. Do the different styles have different meanings or could they be unified both in the character and length?https://gitlab.psi.ch/OPAL/src/-/issues/619review and cleanup IPPL FieldLayout classes2021-06-10T17:34:40+02:00gsellreview and cleanup IPPL FieldLayout classesOnly layout constructors using NDIndex are used in OPAL. The layout constructors using 1 to 6 arguments of type index are not used and can be removedOnly layout constructors using NDIndex are used in OPAL. The layout constructors using 1 to 6 arguments of type index are not used and can be removedgsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/616Enable H5 files as input for FROMFILE distributions2021-06-10T17:35:43+02:00krausEnable H5 files as input for FROMFILE distributionsIf one wants to use the distribution from a "temporal" monitor or from the regular phase space dump then one has to export the phase space of the HDF5 file to Ascii. Instead we should allow to use the HDF5 directly.If one wants to use the distribution from a "temporal" monitor or from the regular phase space dump then one has to export the phase space of the HDF5 file to Ascii. Instead we should allow to use the HDF5 directly.https://gitlab.psi.ch/OPAL/src/-/issues/614Make sampler more robust2020-10-09T10:33:26+02:00bellotti_rMake sampler more robust**Current state**<br />
If one machine configuration crashes (e. g. segfault), the entire random sample dies.
**Why is it bad**<br />
I'm referring to a situation where the sampler reads from a TSV file instead of generating configurati...**Current state**<br />
If one machine configuration crashes (e. g. segfault), the entire random sample dies.
**Why is it bad**<br />
I'm referring to a situation where the sampler reads from a TSV file instead of generating configurations.<br />
- The more machines are run in parallel, the more configurations have to be restarted. This is a cumbersome manual process, and therefore error prone.
- All progress of simulations in progress is lost. (waste of resources)
- The unfinished machine settings have to be identified, copied to a new TSV file, and another RS has to be started, which is again a manual process.
Long story short, this bug imposes unnecessary work and introduces unnecessary error sources for OPAL users.