src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2023-09-22T14:29:46+02:00https://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/772Define TrimCoilType enum2023-08-30T09:38:40+02:00ext-calvo_ppedro.calvo@ciemat.esDefine TrimCoilType enumThe type of trim coil must be defined as a scoped enumeration to avoid string comparisonThe type of trim coil must be defined as a scoped enumeration to avoid string comparison2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/771use 0.0 instead of epsilon in division by zero check2023-08-17T15:45:04+02:00gselluse 0.0 instead of epsilon in division by zero checkThe division by zero test introduced in !626 should not use a epsilon but 0.0.The division by zero test introduced in !626 should not use a epsilon but 0.0.2023.1gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/770linking problems with boost::phoenix2023-08-14T12:34:54+02:00gselllinking problems with boost::phoenixDue to a bug in Boost 1.81.0 and newer we get linking related to boost::phoenix:
```
../optimizer/liboptp.a(expression.cpp.o):(.bss+0x0): multiple definition of `boost::phoenix::placeholders::uarg10'
libOPAL.a(matheval.cpp.o):(.bss+0x0):...Due to a bug in Boost 1.81.0 and newer we get linking related to boost::phoenix:
```
../optimizer/liboptp.a(expression.cpp.o):(.bss+0x0): multiple definition of `boost::phoenix::placeholders::uarg10'
libOPAL.a(matheval.cpp.o):(.bss+0x0): first defined here
```2023.1gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/769remove deprecated Tpetra::StaticProfil2023-08-15T16:30:31+02:00gsellremove deprecated Tpetra::StaticProfil2023.1gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/768testing2023-07-18T10:47:51+02:00sadr_mtesting### Summary
(Summarize the bug encountered concisely)
### Steps to reproduce
(How one can reproduce the issue - this is very important)
### What is the current *bug* behavior?
(What actually happens)
### What is the expected *co...### Summary
(Summarize the bug encountered concisely)
### Steps to reproduce
(How one can reproduce the issue - this is very important)
### What is the current *bug* behavior?
(What actually happens)
### What is the expected *correct* behavior?
(What you should see instead)
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's very hard to read otherwise.)
### Possible fixes
(If you can, link to the line of code that might be responsible for the problem)2023.1https://gitlab.psi.ch/OPAL/src/-/issues/767Problem in Command DUMPEMFIELDS and DUMPFIELDS2023-08-22T10:12:45+02:00ext-rogers_cProblem in Command DUMPEMFIELDS and DUMPFIELDS### Summary
By email from Dou Gouliang
>>>
When I use the command "DUMPFIELDS" and "DUMPEMFIELDS" , the opal_2.4 shows the error (annex 1):
```
Error> *** Error:
Error> Internal OPAL error:
Error> Assertion 'idx.i < num_gridpx_m - 1' ...### Summary
By email from Dou Gouliang
>>>
When I use the command "DUMPFIELDS" and "DUMPEMFIELDS" , the opal_2.4 shows the error (annex 1):
```
Error> *** Error:
Error> Internal OPAL error:
Error> Assertion 'idx.i < num_gridpx_m - 1' failed.
Error> idx.i = 118, num_gridpx_m - 1 = 118.000000
Error> in
Error> /afs/psi.ch/user/g/gsell/private/src/OPAL/src/src/Classic/Fields/FM3DH5BlockBase.h, line 163
```
I have checked my inputfile ,and there is no wrong experssion. The detailed experssion is :
```
DUMPEMFIELDS, COORDINATE_SYSTEM = Cartesian, X_START= -0.8, X_STEPS=1601, DX= 0.001, Y_START=-0.25, Y_STEPS=501, DY= 0.001, Z_START=-0.02, Z_STEPS=41, DZ=0.001, T_START=0,T_STEPS=1, DT=0.1 ,FILE_NAME="FIELDEM-MAPXYZ.dat";
```
When I try to split the original output area of X into two parts, opal can output the corresponding two parts normally. First change X_STEPS to 117, and then change X_START and X_STEPS to -0.215 and 204.
And I re-ran another cyclotron simulation and got the same error, except idx.i changed to 14 .
>>>
and later
>>>
I ran it again in a newer version of OPAL(opal-2022.01) and found the same errors. In particular, I used OPAL-2022.01 as a Linux binary package from the official website.
>>>
lattice in attached zip...
[input_file.zip](/uploads/0c4926991866db21e66977b22b9e06c7/input_file.zip)2023.1ext-rogers_cext-rogers_chttps://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/765Momentum tolerance in Opal-t2023-10-05T17:49:18+02:00ext-calvo_ppedro.calvo@ciemat.esMomentum tolerance in Opal-tPart of #727
A new parameter `MOMENTUM_TOLERANCE` has recently been introduced to control fractional tolerance to deviations in the distribution compared to the reference data at initialisation. This parameter should be extended to be ...Part of #727
A new parameter `MOMENTUM_TOLERANCE` has recently been introduced to control fractional tolerance to deviations in the distribution compared to the reference data at initialisation. This parameter should be extended to be useful in Opal-t.2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/764RingDefinition - Beam rotation and Momentum Tolerance2023-05-16T12:15:30+02:00ext-rogers_cRingDefinition - Beam rotation and Momentum Tolerance### Summary
I would like to be able to introduce an arbitrary rotation to beams in RingDefinition, independent of the azimuthal angle at which the ring is injected. At the moment, transverse "kicks" are enabled by `BEAM_PRINIT` but this...### Summary
I would like to be able to introduce an arbitrary rotation to beams in RingDefinition, independent of the azimuthal angle at which the ring is injected. At the moment, transverse "kicks" are enabled by `BEAM_PRINIT` but this does not permit full rotation through 360 degrees.
My use case:
We decided at a recent meeting that for consistency with the ring layout on the ground in the ring we are designing, the ring should start at "12 o'clock" and proceed in a clockwise direction. OPAL-Cycl mode currently supports element placements in clockwise or anticlockwise direction but beam can only proceed in an anti-clockwise direction.2023.1ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/763ascii2h5block error reading data2023-08-24T11:15:06+02:00ext-calvo_ppedro.calvo@ciemat.esascii2h5block error reading data### Summary
I've got the following error running ascii2h5block tool
```
[proc 0] E: H5Block3dWriteVector3dFieldFloat64: Write to dataset '/Step#0/Block/Efield/0' failed.
```
In addition, the loop to save the results in the h5part for...### Summary
I've got the following error running ascii2h5block tool
```
[proc 0] E: H5Block3dWriteVector3dFieldFloat64: Write to dataset '/Step#0/Block/Efield/0' failed.
```
In addition, the loop to save the results in the h5part format is not necessary, since the input files should already be sorted in the correct format. Therefore, it is sufficient to read the data directly
An enhancement can be included to ensure that the number of data in the fields matches the grid specified in the input header.
### Possible fixes
`H5Block3dSetView` has to be adapted to each field, separately for E-field and H-field.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/761Remove duplicate function to check integers2023-05-09T08:03:32+02:00ext-calvo_ppedro.calvo@ciemat.esRemove duplicate function to check integersDumpFields and DumpEMFields have repeated methods to check if an input variable is an integer. A new method could be created to avoid duplication in Util namespaceDumpFields and DumpEMFields have repeated methods to check if an input variable is an integer. A new method could be created to avoid duplication in Util namespace2023.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/758Quality of life improvements to PyOpal2023-05-05T12:02:53+02:00ext-rogers_cQuality of life improvements to PyOpalFollowing on from #745
Couple of extra "usability" features:
* It should be possible to pass multiple arguments to a "setup" function for PyOpal objects
* If an argument is passed that is not recognised, PyOpal should throw an error. A...Following on from #745
Couple of extra "usability" features:
* It should be possible to pass multiple arguments to a "setup" function for PyOpal objects
* If an argument is passed that is not recognised, PyOpal should throw an error. At the moment PyOpal quietly ignores unrecognised arguments - technically, this is consistent with "normal" python but it is not very nice
* It should be possible to define something as a required argument; if it is undefined, and user tries to use the class in anger (e.g. call to get_field_value) then PyOpal should throw an error.
* It should be possible to make PyOpal run silently (i.e. suppress output) or send output to a file. Bonus points if we can send PyOpal output to sys.stdout!
* In PyOpal/PyCore/Globals.cpp there is a hard coded constant for --processes (3). This should be user defined.2023.1ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/756Wrong class member2023-08-23T10:00:55+02:00ext-calvo_ppedro.calvo@ciemat.esWrong class memberOPAL compilation [fails](http://amas.web.psi.ch/opal/master/output/2023-04-05_10-49.txt). The bug was introduced in OPAL/src!613. I get the following error compiling with SAAMG solver
```
error: ‘class Tpetra::Map<>’ has no member named...OPAL compilation [fails](http://amas.web.psi.ch/opal/master/output/2023-04-05_10-49.txt). The bug was introduced in OPAL/src!613. I get the following error compiling with SAAMG solver
```
error: ‘class Tpetra::Map<>’ has no member named ‘getLocalNumElements’
```2023.1https://gitlab.psi.ch/OPAL/src/-/issues/755Tpetra CsrMatrix::getNodeNumElements() is deprecated2023-04-05T09:08:35+02:00gsellTpetra CsrMatrix::getNodeNumElements() is deprecated2023.1gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/754boost::filesystem::extension() is deprecated in new boost versions2023-04-05T09:50:50+02:00gsellboost::filesystem::extension() is deprecated in new boost versions2023.1gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/753fix assigned but unused variable warnings2023-04-05T09:08:00+02:00gsellfix assigned but unused variable warningsWith Clang 14 on macOS 13.3 and Xcode 14.3 we get several warning about variables assigned but not used. In some cases the value is used only if some debug output is enabled.With Clang 14 on macOS 13.3 and Xcode 14.3 we get several warning about variables assigned but not used. In some cases the value is used only if some debug output is enabled.2023.1gsellgsell