src issueshttps://gitlab.psi.ch/OPAL/src/-/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/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/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/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/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/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/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/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.1krauskraus