OPAL issueshttps://gitlab.psi.ch/groups/OPAL/-/issues2023-10-17T13:26:49+02:00https://gitlab.psi.ch/OPAL/src/-/issues/787VariableRF, FFA, Offset and MultipoleT: unify units internally2023-10-17T13:26:49+02:00ext-calvo_ppedro.calvo@ciemat.esVariableRF, FFA, Offset and MultipoleT: unify units internallyPart of #357: all elements should use the same units internally to eliminate unnecessary conversions and less error-prone.
VariableRF, FFA, Offset and MultipoleT elements use `mm` internally even though the input attributes are correctl...Part of #357: all elements should use the same units internally to eliminate unnecessary conversions and less error-prone.
VariableRF, FFA, Offset and MultipoleT elements use `mm` internally even though the input attributes are correctly implemented in `m`2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/NightlyBuild/-/issues/34Validate output files2023-10-13T11:41:08+02:00ext-calvo_ppedro.calvo@ciemat.esValidate output filesThe regression tests must verify that all reference files are created when they are run, regardless of whether those output files are used as tests. Thus, bugs (as OPAL/src#779) can be avoided when the output files are not generated.The regression tests must verify that all reference files are created when they are run, regardless of whether those output files are used as tests. Thus, bugs (as OPAL/src#779) can be avoided when the output files are not generated.ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/654Add Attribute Type PredefinedString2023-09-26T11:56:07+02:00krausAdd Attribute Type PredefinedStringAttributes of type `PredefinedString` should only accept strings which are contained in a predefined set of strings. For each such attribute the set of accepted strings have to be provided to the constructor. The input of the user is the...Attributes of type `PredefinedString` should only accept strings which are contained in a predefined set of strings. For each such attribute the set of accepted strings have to be provided to the constructor. The input of the user is then checked and if the provided string isn't contained in the predefined set an exception is thrown. Examples for such attributes are the attribute `FSTYPE` of the `FIELDSOLVER` command which accepts `FFT`, `FFTPERIODIC`, `SAAMG` and `NONE` or the attribute `EMISSIONMODEL` of the `DISTRIBUTION` command which accepts `NONE`, `ASTRA` and `NONEQUIL`.
The list of accepted strings as well as the default value, if any, are added to the help message.
The type of most `UpperCaseString` attributes can be change to `PredefinedString`.OPAL 2021.1krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/773Cyclotron: unify units internally2023-09-22T14:29:46+02:00ext-calvo_ppedro.calvo@ciemat.esCyclotron: unify units internallyAccording to #357, all elements should use the same units internally to eliminate unnecessary conversions and less error-prone. Unit conversion should be done for input parameters upon reading the variables.According to #357, all elements should use the same units internally to eliminate unnecessary conversions and less error-prone. Unit conversion should be done for input parameters upon reading the variables.2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/785h5 file initialization2023-09-20T15:10:25+02:00ext-calvo_ppedro.calvo@ciemat.esh5 file initializationThe output file in HDF5 format (.h5) should be created only when the option `ENABLEHDF5 = TRUE`. Currently, when this option is not selected, an empty file is created. In addition, the `H5PartWrapper` call can be refactored to avoid code...The output file in HDF5 format (.h5) should be created only when the option `ENABLEHDF5 = TRUE`. Currently, when this option is not selected, an empty file is created. In addition, the `H5PartWrapper` call can be refactored to avoid code duplication.2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/694Replace plain enum by enum class2023-08-28T12:37:41+02:00ext-calvo_ppedro.calvo@ciemat.esReplace plain enum by enum classSince C++11 scoped enumerations (`enum class`) overcomes a lot of the drawbacks of classical enumerations. Some plain enum may be substituted throughout the code, such as e.g. `ElementType` or `DistrTypeT`.Since C++11 scoped enumerations (`enum class`) overcomes a lot of the drawbacks of classical enumerations. Some plain enum may be substituted throughout the code, such as e.g. `ElementType` or `DistrTypeT`.2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/766RF Cavity, Global Offset and Debugging2023-08-22T10:13:18+02:00ext-rogers_cRF Cavity, Global Offset and DebuggingCouple more things to add into PyOpal - Variable Frequency RF Cavity, Global Offset and a couple more minor bug fixesCouple more things to add into PyOpal - Variable Frequency RF Cavity, Global Offset and a couple more minor bug fixes2023.1ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/759Check attributes of the cyclotron element2023-05-12T09:45:53+02:00ext-calvo_ppedro.calvo@ciemat.esCheck attributes of the cyclotron elementSome attributes of the cyclotron element must be verified for correct assignment. For example, `MINR` cannot be negative and the initial position of the reference particle (`RINIT` and `ZINIT`) must be defined within the range of the mac...Some attributes of the cyclotron element must be verified for correct assignment. For example, `MINR` cannot be negative and the initial position of the reference particle (`RINIT` and `ZINIT`) must be defined within the range of the machine.2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/762RFCavity: unify units internally2023-05-09T10:21:56+02:00ext-calvo_ppedro.calvo@ciemat.esRFCavity: unify units internallyAccording to #357, all elements should use the same units internally to eliminate unnecessary conversions and less error-prone. Unit conversion should be done for input parameters upon reading the variables.According to #357, all elements should use the same units internally to eliminate unnecessary conversions and less error-prone. Unit conversion should be done for input parameters upon reading the variables.2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/760gmsgALL should be common across all objects2023-05-09T09:50:46+02:00ext-rogers_cgmsgALL should be common across all objectsAt the moment a "gmsgALL" is implemented independently by each object. Verbose output can be controlled by command line options like --info but would be nice to control at OPTION level as is done by gmsg. Propose implementing a gmsgALL i...At the moment a "gmsgALL" is implemented independently by each object. Verbose output can be controlled by command line options like --info but would be nice to control at OPTION level as is done by gmsg. Propose implementing a gmsgALL in the same way as gmsg is done.
Task:
* Add gmsgALL to Main.cpp, test/Main.cpp, PyOpal/PyCore/Globals.cpp
* Edit relevant classes to use extern gmsgALL2023.1ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/482File header for OPAL source proposal2023-04-19T13:20:01+02:00snuverink_jjochem.snuverink@psi.chFile header for OPAL source proposalThe following discussion from !294 should be addressed:
- @gsell started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/294#note_18341): (+4 comments)
> @snuverink\_j @ext\-rogers\_c
> Ok, maybe we have to chang...The following discussion from !294 should be addressed:
- @gsell started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/294#note_18341): (+4 comments)
> @snuverink\_j @ext\-rogers\_c
> Ok, maybe we have to change/extend the file header for OPAL source files according the recommendations in https://www.gnu.org/licenses/gpl-howto.html. What do you think about the following proposal:
> ```
> //
> // Brief description
> //
> // Copyright (c) YYYY, Notice mentioning University, Institute, Lab or Author
> //
> // Optional: related work, e.g. title of PhD or Master thesis
> //
> // This file is part of OPAL.
> //
> // OPAL is free software: you can redistribute it and/or modify
> // it under the terms of the GNU General Public License as published by
> // the Free Software Foundation, either version 3 of the License, or
> // (at your option) any later version.
> //
> // You should have received a copy of the GNU General Public License
> // along with OPAL. If not, see <https://www.gnu.org/licenses/>.
> //
> ```
> For PSI employees the copyright notice would be:
> ```
> // Copyright (c) YYYY1[, YYYY2...], Paul Scherrer Institut, Villigen PSI, Switzerland
> // All rights reserved.
> ```
> For a PhD or Master student something like:
> ```
> // Copyright (c) YYYY1[, YYYY2...], Firstname Lastname, University
> // All rights reserved
> ```
> My proposal for the header of the file `MapAnalyser.h` would be something like:
> ```
> //
> // Class: MapAnalyser
> // Organizes the function for a linear map analysis from
> // ThickTracker.
> // Transfer map -> tunes, symplecticity and stability
> // Sigma Matrix -> (not projected) beam emittance
> //
> // This class is in an unfinished state.
> // For some dicussion see https://gitlab.psi.ch/OPAL/src/issues/464
> // Some cleanup was done in https://gitlab.psi.ch/OPAL/src/merge_requests/294
> //
> // Copyright (c) 2017, Philippe Ganz, ETH Zürich
> // All rights reserved
> //
> // Implemented as part of the Master thesis
> // "s-based maps from TPS & Lie-Series applied to Proton-Therapy Gantries"
> //
> // This file is part of OPAL.
> //
> // OPAL is free software: you can redistribute it and/or modify
> // it under the terms of the GNU General Public License as published by
> // the Free Software Foundation, either version 3 of the License, or
> // (at your option) any later version.
> //
> // You should have received a copy of the GNU General Public License
> // along with OPAL. If not, see <https://www.gnu.org/licenses/>.
> //
> ```
Tasks:
* [x] Extend the list of student files (@frey\_m)
* [x] Adapt source files from students
* [x] Strongly modified classes (e.g. `PartBunchBase` and `RK4`) (as pointed out in #501) (fixed with !380)
* [x] OPAL-map and Matched distribution (!308)
* [x] Fix .cpp files with same file header as header files (!355)
* [x] Beam stripping physics (see https://gitlab.psi.ch/OPAL/src/merge_requests/328)
* [x] Optimiser (see https://gitlab.psi.ch/OPAL/src/merge_requests/323),
* [x] SAAMG solver (see https://gitlab.psi.ch/OPAL/src/merge_requests/324)
* [x] Fix: SAAMG originally developed in MSc thesis not PhD (see comment https://gitlab.psi.ch/OPAL/src/merge_requests/327#note_20157) (!369)
* [x] ~~envelope tracker (Yves Ineichen ?)~~ **Edit:** This solver got removed (see !343).
* [x] @frey\_m see #501
* [x] ~~all DKS stuff is @locans\_u's work~~ **Edit:** DKS got removed (see #523)
* [x] all P3M files are part of [Benjamin Ulmer's work](http://amas.web.psi.ch/people/aadelmann/ETH-Accel-Lecture-1/projectscompleted/cse/thesisBUlmer.pdf) (see https://gitlab.psi.ch/OPAL/src/merge_requests/325)
* [x] Cyclotron work by Jianjun Yang (!356)
* [x] Update wiki on code styleOPAL 2.4.0snuverink_jjochem.snuverink@psi.chgsellfrey_msnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/748Improve error message for using protected keywords2023-03-31T14:12:22+02:00snuverink_jjochem.snuverink@psi.chImprove error message for using protected keywordsReported by @zhang_h:
An input like:
```
ring: Cyclotron, TYPE="RING", ...;
```
will generate an error:
```
Error>
Error> *** User error detected by function "OpalData::define()"
Error> You cannot replace the object "RING".
Error...Reported by @zhang_h:
An input like:
```
ring: Cyclotron, TYPE="RING", ...;
```
will generate an error:
```
Error>
Error> *** User error detected by function "OpalData::define()"
Error> You cannot replace the object "RING".
Error> You cannot replace the object "RING".
```
This is because `ring` is a protected keyword and can't be used as an object name. However, from the user perspective this seems not very clear.
The error message comes from OpalData.cpp:
```c++
if (oldObject->isBuiltin() || ! oldObject->canReplaceBy(newObject)) {
throw OpalException("OpalData::define()",
"You cannot replace the object \"" + name + "\".");
} else {
```
I propose to make a distinction between the two cases and change it to:
```c++
if (oldObject->isBuiltin()) {
throw OpalException("OpalData::define()",
"The keyword \"" + name + "\" is protected and can't be used to name an object.");
else if (! oldObject->canReplaceBy(newObject)) {
throw OpalException("OpalData::define()",
"You cannot replace the already defined object \"" + name + "\".");
} // else not needed
```
Also it might be good not to have "name" in uppercase letters if the user writes it in lowercase, but I couldn't quickly find out where this happens.2023.1snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/744Use smart pointers for fieldmaps2022-11-08T09:18:57+01:00krausUse smart pointers for fieldmaps2023.1krauskraushttps://gitlab.psi.ch/OPAL/documentation/manual/-/issues/84Trim coil description to be improved2022-09-13T09:28:31+02:00snuverink_jjochem.snuverink@psi.chTrim coil description to be improvedFrom @zhang_h:
For the trim coils, the description of `TRIMCOILTHRESHOLD` is missing and the description of `BMAX` is wrong for `PSI-PHASE` (it is the same for all models).From @zhang_h:
For the trim coils, the description of `TRIMCOILTHRESHOLD` is missing and the description of `BMAX` is wrong for `PSI-PHASE` (it is the same for all models).snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/650Define OUTFN as common attribute2022-03-17T08:55:14+01:00ext-calvo_ppedro.calvo@ciemat.esDefine OUTFN as common attributeThe `OUTFN` attribute to set the output file name of some elements could be fixed as a common attribute for all elements to avoid code duplication.The `OUTFN` attribute to set the output file name of some elements could be fixed as a common attribute for all elements to avoid code duplication.OPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/690Adding unit conversions to Physics.h2022-03-17T08:53:13+01:00carl_jAdding unit conversions to Physics.hI've updated the Physics.h to include a series of common unit conversions used throughout the code.
So far I've included:
- m <--> mm
- s <--> ns
- T <--> kG
- V <--> kV
- GeV/c^2 <--> kg
I've then used these conversions to replace ...I've updated the Physics.h to include a series of common unit conversions used throughout the code.
So far I've included:
- m <--> mm
- s <--> ns
- T <--> kG
- V <--> kV
- GeV/c^2 <--> kg
I've then used these conversions to replace the hard coded conversions in the following files:
- ParallelCyclotronTracker.cpp
- RK4.h
- OpalMultipoleT.cpp
I've linked [this issue](https://gitlab.psi.ch/OPAL/src/-/issues/357).
There's a bit more discussion on this in the comments there.2022.1carl_jext-rogers_ccarl_jhttps://gitlab.psi.ch/OPAL/src/-/issues/710Improve standard output2022-03-15T14:17:36+01:00ext-calvo_ppedro.calvo@ciemat.esImprove standard outputSome items in the standard output can be improved to make it easier for the user to read parameters, unifying messages within their group and eliminating duplicate parts within the code.
Some examples about that:
- Parameters of `BANDRF...Some items in the standard output can be improved to make it easier for the user to read parameters, unifying messages within their group and eliminating duplicate parts within the code.
Some examples about that:
- Parameters of `BANDRF` cyclotron type are vectors, but only the initial value is printed in the output.
- `DISTRIBUTION` command must show the units of the input moment, output file when `WRITETOFILE` is enabled…
- The output of the `RUN` command is duplicated in each of the OPAL flavors.
- Unify style for units and filenames2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/680Remove interactive mode, replace it with additional help option.2022-02-04T16:05:23+01:00krausRemove interactive mode, replace it with additional help option.The interactive mode is presumably not used by anyone. I propose therefore to remove it and add instead an option to print the help for commands on the command line.
Additionally I noticed that Opal crashes while printing the help messa...The interactive mode is presumably not used by anyone. I propose therefore to remove it and add instead an option to print the help for commands on the command line.
Additionally I noticed that Opal crashes while printing the help messages. The reason is that the type names `predefined string`, `upper case string` and `upper case string array` are longer than 16 characters. However the user doesn't have to know what these types represent, they are simply strings and string arrays respectively.2022.1krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/692New class storing particle properties2022-01-17T08:49:01+01:00ext-calvo_ppedro.calvo@ciemat.esNew class storing particle propertiesFollowing discussion from https://gitlab.psi.ch/OPAL/src/-/merge_requests/542#note_34815, `ParticleType` must be placed into a new file, avoiding having a static function and static map in global scopeFollowing discussion from https://gitlab.psi.ch/OPAL/src/-/merge_requests/542#note_34815, `ParticleType` must be placed into a new file, avoiding having a static function and static map in global scope2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/699Redefine heavy ion beams2022-01-17T08:08:55+01:00ext-calvo_ppedro.calvo@ciemat.esRedefine heavy ion beamsThe following discussion from !548 should be addressed:
- @snuverink_j started a [discussion](https://gitlab.psi.ch/OPAL/src/-/merge_requests/548#note_35297): (+9 comments)
> Is there maybe a reference why we use these particle ch...The following discussion from !548 should be addressed:
- @snuverink_j started a [discussion](https://gitlab.psi.ch/OPAL/src/-/merge_requests/548#note_35297): (+9 comments)
> Is there maybe a reference why we use these particle charges for Xenon and Uranium? I think it would be good to add this here.
Beam particle definition for heavy ions is not well determined. Uranium and xenon beams can have different ionization states, but currently OPAL only considers a given charge state. The definition of these particles must be reviewed, establishing univocal values for the mass and the charge states as `PARTICLE` types in the `BEAM` command. If any user wants to simulate these type of ions with a different ionization state or other isotope kind, it can be done by means of the attributes `MASS` and `CHARGE`. In addition, the documentation in the Manual must be modified (see OPAL/documentation/manual#70).2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.es