src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2023-12-20T13:35:05+01:00https://gitlab.psi.ch/OPAL/src/-/issues/793OutputPlane2023-12-20T13:35:05+01:00ext-rogers_cOutputPlaneFor some precision work it is important to have accurate readout of particle positions at a particular plane. In the presence of fields, PROBE function interpolation is not accurate enough.
As registered in Issue #22 it would be useful ...For some precision work it is important to have accurate readout of particle positions at a particular plane. In the presence of fields, PROBE function interpolation is not accurate enough.
As registered in Issue #22 it would be useful to have a probe that can be perpendicular to a reference trajectory (for e.g. calculating dispersions/etc).
To meet these requirements I have implemented a new _PluginElement_ called OutputPlane. Features:
- detects hits using a RK4 stepping routine, iteratively finding correct step size to find the intersection of tracks with the plane and registering a hit at the exact point
- position can be specified in 2D using PROBE-style placement or 3D with a centre and normal vector
- position can be specified to update to be aligned with the position/momentum vector when a particle with user-defined ID crosses the plane.
- rectangular or circular apertures can be specified (maximum distance from PROBE centre to register hits)ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/22SBEND3D - Off Momentum beam2023-12-20T13:35:05+01:00adelmannSBEND3D - Off Momentum beam
I have some problems in understanding my result. In bold you can see the two questions I have for you. I will explain you briefly.
The configuration is the following:
- single field map from OPERA
- nominal energy: 185 MeV
- RING def...
I have some problems in understanding my result. In bold you can see the two questions I have for you. I will explain you briefly.
The configuration is the following:
- single field map from OPERA
- nominal energy: 185 MeV
- RING definition + Local Cartesian Offset
- Particle distribution from file
From this configuration, the beam envelope looks reasonable and agrees with COSY-Infinity.
However, the dispersion seems not to be completely suppressed at the end of the beamline. This means that I need to study more the dispersion and the off-momentum beam.
* 1st Analysis: Dispersion function
In the distribution file, I set one particle with 1% momentum shift (py = 1% p0) with respect to the nominal momentum. The tracking of this particle represents the dispersion function. The result is attached (Dispersion-Test1)
* 2nd Analysis: Off-Momentum Beam
The goal is to study the beamline behaviour with a beam that has 5% momentum shift from the nominal value. Then I have prepared a new distribution, where all the particles (except 2 particles) has a momentum shift of 5% (py = 5% p0).
In the OPAL input file, I let 185 MeV as nominal energy (EDES = 0.185), the shift in momentum comes from the beam distribution.
The two not-updated particles are:
1- reference particle: py = 0
2- dispersion function: py = 1% p0
Since the majority of the particles have a different energy, the mean beam energy has been updated to 202 MeV. Has this an influence in the tracking?
At the end of this “off-momentum run”, I displayed again the dispersion function, expecting to get the same result as in the first Analysis. The nominal energy, EDES, (185 MeV) did not change and the field map as well.
Instead I got a completely different trajectory (see Dispersion-Test2).
Which is the best way to perform this kind of analysis?
Thanks for your help
Regards
Valeria
Former #23
- Does SBEND3D use a local coordinate system, relative to the
beginning of the element? If so, how is this coordinate system
defined?
- Is the OPAL manual's description of the LENGTHUNITS correct? When
adding an SBEND3D, the diagnostic output from OPAL specifies the
lengths in both 'm' and 'mm,' it seems one of these is wrong and
confusing. I.e. `zini= -1.0000000000000000e+03 m; zfinal=
1.0000000000000000e+03 mm` for the input file attached.
As a test case, I have tried to propagate a beam through a simple π/6
sector (input files attached). However, the beam travels straight in
the initial direction, indicating to me that my element is either the
wrong size or placed incorrectly relative to the beam. Perhaps you can
shed some light on what I am misunderstanding about how this element
interacts with the global coordinate system.
[generate_fieldmap.py](/uploads/ff562c84c870b355ab03161318241823/generate_fieldmap.py)
[sbend3D_test.in](/uploads/4b28f17596b27c218f1c5e6487fb5d86/sbend3D_test.in)
[testbend.bmap](/uploads/302ca3d3632c4c0787bfde583922f037/testbend.bmap)ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/795Regression test broken: string constant duplicated2023-12-11T09:18:24+01:00ext-calvo_ppedro.calvo@ciemat.esRegression test broken: string constant duplicatedAfter merging !648 all the regression tests are broken (see [link](http://amas.web.psi.ch/opal/master/output/2023-12-01_21-49.txt)).
A string constant has been created for an attribute of OutputPlane that overwrites the name of an eleme...After merging !648 all the regression tests are broken (see [link](http://amas.web.psi.ch/opal/master/output/2023-12-01_21-49.txt)).
A string constant has been created for an attribute of OutputPlane that overwrites the name of an element. Therefore, all simulations are broken. The addition of this string constant is not necessary and should be deleted.ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/790OpalRingDefinition MAX_R MIN_R options2023-11-15T13:12:39+01:00ext-rogers_cOpalRingDefinition MAX_R MIN_R optionsThere are a few issues with this code:
1) It is not in the wiki/documented
2) The exception in OpalRingDefinition.cpp is a char* not an OpalException
3) If MAX_R, MIN_R is not set, the bound checking seems to happen sometimes anyway - no...There are a few issues with this code:
1) It is not in the wiki/documented
2) The exception in OpalRingDefinition.cpp is a char* not an OpalException
3) If MAX_R, MIN_R is not set, the bound checking seems to happen sometimes anyway - note that `Classic/AbsBeamline/Ring.h` `Ring::willDoAperture_m` defaults to false, so not quite sure what is happening there.
Thanks to @carl_j for spotting.2023.1ext-rogers_cext-rogers_chttps://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/789Compile error2023-10-16T13:16:21+02:00ext-rogers_cCompile error### Summary
The main branch fails to compile with the error
```
n file included from /usr/include/c++/11/cassert:44,
from /home/cr67/Software/install/include/boost/numeric/ublas/detail/config.hpp:16,
f...### Summary
The main branch fails to compile with the error
```
n file included from /usr/include/c++/11/cassert:44,
from /home/cr67/Software/install/include/boost/numeric/ublas/detail/config.hpp:16,
from /home/cr67/Software/install/include/boost/numeric/ublas/exception.hpp:19,
from /home/cr67/Software/install/include/boost/numeric/ublas/storage.hpp:26,
from /home/cr67/Software/install/include/boost/numeric/ublas/vector.hpp:21,
from /home/cr67/Software/install/include/boost/numeric/ublas/matrix.hpp:18,
from /home/cr67/Software/OPAL/opal_src_3/src/Algorithms/BoostMatrix.h:21,
from /home/cr67/Software/OPAL/opal_src_3/src/Classic/Algorithms/CoordinateSystemTrafo.h:4,
from /home/cr67/Software/OPAL/opal_src_3/src/Classic/AbsBeamline/ElementBase.h:67,
from /home/cr67/Software/OPAL/opal_src_3/src/AbstractObjects/Element.h:34,
from /home/cr67/Software/OPAL/opal_src_3/src/AbstractObjects/BeamSequence.h:21,
from /home/cr67/Software/OPAL/opal_src_3/src/AbstractObjects/BeamSequence.cpp:19:
/home/cr67/Software/OPAL/opal_src_3/src/Algorithms/BoostMatrix.h: In instantiation of ‘T prod_boost_vector(const boost::numeric::ublas::matrix<double>&, const T&) [with T = Vektor<double, 3>]’:
/home/cr67/Software/OPAL/opal_src_3/src/Classic/Algorithms/CoordinateSystemTrafo.h:78:29: required from here
/home/cr67/Software/OPAL/opal_src_3/src/Algorithms/BoostMatrix.h:28:19: error: ‘const class Vektor<double, 3>’ has no member named ‘size’; did you mean ‘Size’?
28 | assert(vector.size() == 3);
| ~~~~~~~^~~~
```
This arises because the compiler is expecting a method like ``Vektor::size()`` which does not exist. I note that Vektor::Size does appear to exist, but note the upper case.
Not that it should matter, but:
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
### Steps to reproduce
Build the master2023.1https://gitlab.psi.ch/OPAL/src/-/issues/788PyOpal cmake option2023-10-11T10:06:06+02:00ext-calvo_ppedro.calvo@ciemat.esPyOpal cmake optionThe `BUILD_OPAL_PYTHON` flag must be added as a compile option to be available from CMake settingsThe `BUILD_OPAL_PYTHON` flag must be added as a compile option to be available from CMake settings2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/786Unused degrader attributes2023-10-10T16:03:08+02:00ext-calvo_ppedro.calvo@ciemat.esUnused degrader attributesThe attributes of the degrader (`XSIZE` and `YSIZE`) are currently unused. A function should be added to verify that the particles are inside the element employing these attributes according to the [description](http://amas.web.psi.ch/op...The attributes of the degrader (`XSIZE` and `YSIZE`) are currently unused. A function should be added to verify that the particles are inside the element employing these attributes according to the [description](http://amas.web.psi.ch/opal/Documentation/master/#sec.elements.degrader-opal-t).2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://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/780Regression tests broken2023-09-29T12:25:17+02:00ext-calvo_ppedro.calvo@ciemat.esRegression tests brokenBeamLine-1, BeamLine-2 and PROSCAN-1 regression tests [are broken](http://amas.web.psi.ch/opal/regressionTests/master/results_2023-08-24_21-49.xml) since f1081e540647eef178c4350fd97b82d45e814cdcBeamLine-1, BeamLine-2 and PROSCAN-1 regression tests [are broken](http://amas.web.psi.ch/opal/regressionTests/master/results_2023-08-24_21-49.xml) since f1081e540647eef178c4350fd97b82d45e814cdc2023.1sadr_msadr_mhttps://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/779No lbal output file with ENABLE_AMR2023-09-25T16:06:46+02:00ext-calvo_ppedro.calvo@ciemat.esNo lbal output file with ENABLE_AMR`.lbal` output file is not written when OPAL is compiled with `ENABLE_AMR=TRUE`
`LBalWriter::write(PartBunchBase<double, 3>* beam)` has to be declared upper in SDDSWriter class`.lbal` output file is not written when OPAL is compiled with `ENABLE_AMR=TRUE`
`LBalWriter::write(PartBunchBase<double, 3>* beam)` has to be declared upper in SDDSWriter class2023.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/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/783Define AMR refinement criteria as scoped enum2023-09-18T16:25:13+02:00ext-calvo_ppedro.calvo@ciemat.esDefine AMR refinement criteria as scoped enumTaggingCriteria must be defined as a scoped enumeration to avoid string comparisonTaggingCriteria 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/774VFFA-1 regression test fails2023-09-14T08:40:39+02:00ext-calvo_ppedro.calvo@ciemat.esVFFA-1 regression test failsVFFA-1 test fails since commit bfc9b5f226219494303f162371c6cc36cdabc10cVFFA-1 test fails since commit bfc9b5f226219494303f162371c6cc36cdabc10c2023.1https://gitlab.psi.ch/OPAL/src/-/issues/781Segmentation fault running Opal-cycl with boundary geometry2023-09-13T11:20:37+02:00ext-calvo_ppedro.calvo@ciemat.esSegmentation fault running Opal-cycl with boundary geometryI've got an unexpected segmentation fault running Opal-Cycl simulations.
```
[aceler15:459721] *** Process received signal ***
[aceler15:459721] Signal: Segmentation fault (11)
[aceler15:459721] Associated errno: Unknown error 21871 (21...I've got an unexpected segmentation fault running Opal-Cycl simulations.
```
[aceler15:459721] *** Process received signal ***
[aceler15:459721] Signal: Segmentation fault (11)
[aceler15:459721] Associated errno: Unknown error 21871 (21871)
[aceler15:459721] Signal code: (-1210805744)
[aceler15:459721] Failing at address: 0x25c
[aceler15:459721] [ 0] /usr/lib64/libc.so.6(+0x4eb50)[0x7f5ab1a7fb50]
[aceler15:459721] [ 1] opal(+0xecc644)[0x556f23eb8644]
[aceler15:459721] [ 2] opal(+0x9c528a)[0x556f239b128a]
[aceler15:459721] [ 3] opal(+0x75b576)[0x556f23747576]
[aceler15:459721] [ 4] opal(+0x75b899)[0x556f23747899]
[aceler15:459721] [ 5] opal(+0x718d6a)[0x556f23704d6a]
[aceler15:459721] [ 6] /usr/lib64/libc.so.6(+0x5126c)[0x7f5ab1a8226c]
[aceler15:459721] [ 7] /usr/lib64/libc.so.6(on_exit+0x0)[0x7f5ab1a823a0]
[aceler15:459721] [ 8] /usr/lib64/libc.so.6(__libc_start_main+0xec)[0x7f5ab1a6bd8c]
[aceler15:459721] [ 9] opal(+0x5243ae)[0x556f235103ae]
[aceler15:459721] *** End of error message ***
--------------------------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--------------------------------------------------------------------------
```
I attach the input files needed to reproduce the issue:
[tracking.in](/uploads/a84549a3f0c0e72fc2528edade1b1001/tracking.in)
[particulas_1E4.dat](/uploads/b398ed9242251cb467a9f440ac6ac824/particulas_1E4.dat)
[Geom_holeTargetLine.h5](/uploads/84d6c6c15d316fc0228fd3b04affaa1a/Geom_holeTargetLine.h5)
[Gap_18ene19.h5part](https://gitlab.psi.ch/OPAL/src/uploads/e46d8e040ba6dd3d973d458949a71b47/Gap_18ene19.h5part)
[Vacio_18ene19_2mm.h5part](https://gitlab.psi.ch/OPAL/src/uploads/cf9c48fc479e96e4491f6f687e946154/Vacio_18ene19_2mm.h5part)
[BField_real_4T_2.dat](https://gitlab.psi.ch/OPAL/src/uploads/f9567783d8a24a17dbb5a36c6c30bef8/BField_real_4T_2.dat)
Curiously, the simulation finalizes properly… (see [tracking.out](/uploads/8bdb58dbba9b08d6b50f6642e1ea9be4/tracking.out))2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/782Single-particle simulation gets stuck2023-09-07T08:41:49+02:00ext-calvo_ppedro.calvo@ciemat.esSingle-particle simulation gets stuck### Summary
The simulation hangs when try to run single-particle simulation in parallel.
### Steps to reproduce
Run RingCyclotronSingleParticle regression test
```
mpirun -np 4 RingCyclotronSingleParticle.in
```
### What is the cur...### Summary
The simulation hangs when try to run single-particle simulation in parallel.
### Steps to reproduce
Run RingCyclotronSingleParticle regression test
```
mpirun -np 4 RingCyclotronSingleParticle.in
```
### What is the current *bug* behavior?
The reduce function of IPPL called in `Distribution::printDist` fails.
### What is the expected *correct* behavior?
There is an exception in `ParallelCyclotronTracker::initializeTracking_m` to avoid it, but the simulation gets stuck before entering the tracker.
### Possible fixes
A feasible solution is introduced a check between the number of particles in the distribution and the number of nodes before that, in `Distribution::checkParticleNumber`2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/778RFkick bug with MTS integrator2023-09-04T11:52:38+02:00ext-calvo_ppedro.calvo@ciemat.esRFkick bug with MTS integratorWorking on #773 I have found that there is an error produced by a wrongly implemented unit change. So up, ParallelCyclotronTracker works internally in ns, therefore, several unit changes are necessary throughout the code.
`ParallelCyclo...Working on #773 I have found that there is an error produced by a wrongly implemented unit change. So up, ParallelCyclotronTracker works internally in ns, therefore, several unit changes are necessary throughout the code.
`ParallelCyclotronTracker::RFkick` method has as input variables `t` and `dt` in ns, as they are subsequently transformed to s in `RFCavity::getMomentaKick`. However, `ParallelCyclotronTracker::push` used with MTS integrator calculates `dt1` in s, and is not changed to ns before calling `RFkick`, so the results are not corrected.
This error affects the RingCyclotronMTS regression tests (OPAL/regression-tests#116).2023.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/777Regression test Mask-1 fails2023-09-01T09:24:51+02:00ext-calvo_ppedro.calvo@ciemat.esRegression test Mask-1 failsThe `Mask-1` regression test [fails](http://amas.web.psi.ch/opal/regressionTests/master/results_2023-08-30_21-49.xml) after merging (!633) by small differences with respect to the reference values:
```
Checksum for reference Mask-1.st...The `Mask-1` regression test [fails](http://amas.web.psi.ch/opal/regressionTests/master/results_2023-08-30_21-49.xml) after merging (!633) by small differences with respect to the reference values:
```
Checksum for reference Mask-1.stat.md5 OK
Checksum for reference Mask-1.out.md5 OK
Checksum for reference Mask-1.lbal.md5 OK
Run regression test Mask-1
Test rms_x(last) failed: 4.829711787474912e-06 (eps=2e-08)
Test rms_y(last) failed: 1.6291845585723712e-06 (eps=2e-08)
Test rms_s(last) failed: 9.365723447670588e-07 (eps=2e-08)
Test energy(last) failed: 0.00029003990081832853 (eps=2e-08)
Test numParticles(last) failed: 8.0 (eps=2e-08)
```