src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2023-12-20T13:35:05+01:00https://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/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/750Trimcoil implementation bug2023-07-24T11:00:49+02:00snuverink_jjochem.snuverink@psi.chTrimcoil implementation bug### Summary
In #276 and !53 a trim coil range in the azimuthal direction was introduced. However, this was not properly tested and it contained a bug, that was discovered by @zhang_h. This was partly fixed in #736 / !598, but not comple...### Summary
In #276 and !53 a trim coil range in the azimuthal direction was introduced. However, this was not properly tested and it contained a bug, that was discovered by @zhang_h. This was partly fixed in #736 / !598, but not completely tested.
### What is the current *bug* behavior?
The trim coils do not work anymore without `PHIMIN` and `PHIMAX` specified.
### What is the expected *correct* behavior?
Trim coils working as normal.
### Possible fixes
The bug was introduced in 77c975dcca3b99cf195cbf020d5039f8be745646, especially the default value of `PHIMAX` was not specified (https://gitlab.psi.ch/OPAL/src/-/commit/77c975dcca3b99cf195cbf020d5039f8be745646#fa26d1e4b267fcc893fcd886f40d73b50d62cdef_46_56) and the `TrimCoil::setAzimuth` method was not so well implemented (https://gitlab.psi.ch/OPAL/src/-/commit/77c975dcca3b99cf195cbf020d5039f8be745646#c96f8a350e29295ac068d6a60d9a39c1972d72e6_16_28).2023.1snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://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/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/751Cyclotron out of range field lookup2023-03-31T14:48:00+02:00snuverink_jjochem.snuverink@psi.chCyclotron out of range field lookup### Summary
The magnetic field lookup can be out of range resulting in an segmentation fault.
### Steps to reproduce
One way to reproduce this is to have a trim coil with a very large `BMAX`, e.g.:
```
tc15: TRIMCOIL, TYPE="PSI-PHASE...### Summary
The magnetic field lookup can be out of range resulting in an segmentation fault.
### Steps to reproduce
One way to reproduce this is to have a trim coil with a very large `BMAX`, e.g.:
```
tc15: TRIMCOIL, TYPE="PSI-PHASE", RMIN = 3000, RMAX = 4560.073, BMAX=100.0025264327051118017, COEFNUM = {-0.0312020990404, 0.0227946756108, -0.00354827255973}, COEFDENOM = {14.7460286849, -16.9186605846, 7.61516943548, -1.53074181639, 0.11384470123};
psi_ring: Cyclotron, TYPE="RING", CYHARMON=6, PHIINIT=0.0, PRINIT=pr0, RINIT=r0 , SYMMETRY=8.0, RFFREQ=frequency, FMAPFN="./s03av.nar", FMLOWE=0.072, FMHIGHE=0.595,
TRIMCOIL={tc15};
```
### What is the current *bug* behavior?
segmentation fault:
```
OPAL> * ---------------------- Start tracking ---------------------------------- *
/afs/psi.ch/sys/psi.x86_64_slp6/Programming/gcc/10.3.0/include/c++/10.3.0/bits/stl_vector.h:1045: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = double; _Alloc = std::allocator<double>; std::vector<_Tp, _Alloc>::reference = double&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed.
Thread 1 "opal" received signal SIGABRT, Aborted.
0x00007ffff43a2aff in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: yum debuginfo-install bzip2-libs-1.0.6-26.el8.x86_64 glibc-2.28-211.el8.x86_64 zlib-1.2.11-21.el8_7.x86_64
(gdb) bt
#0 0x00007ffff43a2aff in raise () from /lib64/libc.so.6
#1 0x00007ffff4375ea5 in abort () from /lib64/libc.so.6
#2 0x00000000004c60c2 in std::__replacement_assert (
__file=__file@entry=0xce5908 "/afs/psi.ch/sys/psi.x86_64_slp6/Programming/gcc/10.3.0/include/c++/10.3.0/bits/stl_vector.h", __line=__line@entry=1045,
__function=__function@entry=0xce77d8 "std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = double; _Alloc = std::allocator<double>; std::vector<_Tp, _Alloc>::reference ="..., __condition=__condition@entry=0xce5e98 "__builtin_expect(__n < this->size(), true)")
at /afs/psi.ch/sys/psi.x86_64_slp6/Programming/gcc/10.3.0/include/c++/10.3.0/x86_64-pc-linux-gnu/bits/c++config.h:461
#3 0x00000000007785c0 in std::vector<double, std::allocator<double> >::operator[] (__n=19210, this=0x1999428)
at /home/snuverink_j/OPAL/src/src/Classic/AbsBeamline/Cyclotron.cpp:767
#4 Cyclotron::interpolate (this=this@entry=0x1998fd0, rad=@0x7fffffff6ac8: 4.7088452431449133,
tet_rad=@0x7fffffff6ad0: 0.1981665351710836, brint=@0x7fffffff6ad8: 0, btint=@0x7fffffff6ae0: 0,
bzint=@0x7fffffff6ae8: 0) at /home/snuverink_j/OPAL/src/src/Classic/AbsBeamline/Cyclotron.cpp:750
#5 0x000000000077887b in Cyclotron::apply (this=0x1998fd0, R=..., t=@0x7fffffff6f38: 6000.00000001014, E=..., B=...)
at /home/snuverink_j/OPAL/src/src/Classic/AbsBeamline/Cyclotron.cpp:454
#6 0x0000000000775b38 in Cyclotron::apply (this=0x1998fd0, id=@0x7fffffff70d8: 1, t=@0x7fffffff6f38: 6000.00000001014,
E=..., B=...) at /home/snuverink_j/OPAL/src/src/Classic/AbsBeamline/Cyclotron.cpp:409
#7 0x00000000006d2154 in ParallelCyclotronTracker::computeExternalFields_m (this=this@entry=0x1996380,
i=@0x7fffffff70d8: 1, t=<optimized out>, Efield=..., Bfield=...)
at /home/snuverink_j/OPAL/src/src/Algorithms/ParallelCyclotronTracker.cpp:3417
#8 0x00000000006d21bf in ParallelCyclotronTracker::getFieldsAtPoint (this=0x1996380, t=<optimized out>,
Pindex=@0x7fffffff70d8: 1, Efield=..., Bfield=...)
at /home/snuverink_j/OPAL/src/src/Algorithms/ParallelCyclotronTracker.cpp:1463
#9 0x00000000006ebe66 in std::function<bool (double const&, unsigned long const&, Vektor<double, 3u>&, Vektor<double, 3u>&)>::operator()(double const&, unsigned long const&, Vektor<double, 3u>&, Vektor<double, 3u>&) const (__args#3=...,
__args#2=..., __args#1=@0x7fffffff70d8: 1, __args#0=@0x7fffffff6da8: 6.9533465388994597e-310, this=<optimized out>)
at /afs/psi.ch/sys/psi.x86_64_slp6/Programming/gcc/10.3.0/include/c++/10.3.0/bits/std_function.h:248
#10 RK4<std::function<bool (double const&, unsigned long const&, Vektor<double, 3u>&, Vektor<double, 3u>&)>>::derivate_m(PartBunchBase<double, 3u>*, double*, double const&, double*, unsigned long const&) const (this=this@entry=0x193f8f0,
bunch=bunch@entry=0x193c500, y=y@entry=0x7fffffff7030, t=@0x7fffffff6f38: 6000.00000001014,
yp=yp@entry=0x7fffffff7000, i=@0x7fffffff70d8: 1) at /home/snuverink_j/OPAL/src/src/Steppers/RK4.hpp:108
#11 0x00000000006ec366 in RK4<std::function<bool (double const&, unsigned long const&, Vektor<double, 3u>&, Vektor<double, 3u>&)>>::doAdvance_m(PartBunchBase<double, 3u>*, unsigned long const&, double const&, double) const (this=0x193f8f0,
bunch=0x193c500, i=@0x7fffffff70d8: 1, t=@0x7fffffff7168: 5999.9341888880599, dt=0.065811122079631468)
at /home/snuverink_j/OPAL/src/src/Steppers/RK4.hpp:70
#12 0x00000000006d2a51 in Stepper<std::function<bool (double const&, unsigned long const&, Vektor<double, 3u>&, Vektor<double, 3u>&)>>::advance(PartBunchBase<double, 3u>*, unsigned long const&, double const&, double) const (
dt=0.065811122079631468, t=@0x7fffffff7168: 5999.9341888880599, i=@0x7fffffff70d8: 1, bunch=0x193c500,
this=<optimized out>) at /home/snuverink_j/OPAL/src/src/Algorithms/ParallelCyclotronTracker.cpp:3046
#13 ParallelCyclotronTracker::seoMode_m (this=this@entry=0x1996380, t=@0x7fffffff7168: 5999.9341888880599,
dt=0.065811122079631468, Ttime=..., Tdeltr=..., Tdeltz=..., TturnNumber=...)
at /home/snuverink_j/OPAL/src/src/Algorithms/ParallelCyclotronTracker.cpp:3046
#14 0x00000000006e21dd in ParallelCyclotronTracker::GenericTracker (this=0x1996380)
at /home/snuverink_j/OPAL/src/src/Algorithms/ParallelCyclotronTracker.cpp:1429
#15 0x00000000006e2765 in ParallelCyclotronTracker::execute (this=0x1996380)
at /home/snuverink_j/OPAL/src/src/Algorithms/ParallelCyclotronTracker.cpp:1238
#16 0x00000000006b2651 in TrackRun::execute (this=0x193e6c0) at /home/snuverink_j/OPAL/src/src/Track/TrackRun.cpp:245
#17 0x000000000053531b in OpalParser::execute (this=this@entry=0x193bb50, object=object@entry=0x193e6c0, name=...)
at /home/snuverink_j/OPAL/src/src/OpalParser/OpalParser.cpp:140
#18 0x0000000000538d29 in OpalParser::parseAction (this=0x193bb50, stat=...)
at /home/snuverink_j/OPAL/src/src/OpalParser/OpalParser.cpp:173
#19 0x00000000005392d9 in OpalParser::parse (this=0x193bb50, stat=...)
at /home/snuverink_j/OPAL/src/src/OpalParser/OpalParser.cpp:91
#20 0x00000000005390d6 in OpalParser::run (this=0x193bb50)
at /home/snuverink_j/OPAL/src/src/OpalParser/OpalParser.cpp:608
#21 0x00000000006aaba9 in TrackCmd::execute (this=0x18947b0) at /home/snuverink_j/OPAL/src/src/Track/TrackCmd.cpp:230
#22 0x000000000053531b in OpalParser::execute (this=this@entry=0x7fffffff8490, object=object@entry=0x18947b0, name=...)
at /home/snuverink_j/OPAL/src/src/OpalParser/OpalParser.cpp:140
#23 0x0000000000538d29 in OpalParser::parseAction (this=0x7fffffff8490, stat=...)
at /home/snuverink_j/OPAL/src/src/OpalParser/OpalParser.cpp:173
#24 0x00000000005392d9 in OpalParser::parse (this=0x7fffffff8490, stat=...)
at /home/snuverink_j/OPAL/src/src/OpalParser/OpalParser.cpp:91
#25 0x00000000005390d6 in OpalParser::run (this=0x7fffffff8490)
at /home/snuverink_j/OPAL/src/src/OpalParser/OpalParser.cpp:608
#26 0x0000000000535800 in OpalParser::run (this=this@entry=0x7fffffff8490, is=is@entry=0x1890ad0)
at /home/snuverink_j/OPAL/src/src/OpalParser/OpalParser.cpp:633
#27 0x00000000004b3843 in opalMain (argc=<optimized out>, argv=<optimized out>)
at /home/snuverink_j/OPAL/src/src/Main.cpp:364
#28 0x00007ffff438ed85 in __libc_start_main () from /lib64/libc.so.6
#29 0x00000000004af24e in _start () at /home/snuverink_j/OPAL/src/src/Main.cpp:131
```
### What is the expected *correct* behavior?
not crash and ignore the field. the particle will be cleaned up afterwards.
### Possible fixes
https://gitlab.psi.ch/OPAL/src/-/blob/master/src/Classic/AbsBeamline/Cyclotron.cpp#L747:
```cpp
if (fieldType_m != BFieldType::FFABF) {
/*
For FFA this does not work
*/
r1t1 = it + ntetS * ir - 1;
r1t2 = r1t1 + 1;
r2t1 = r1t1 + ntetS;
r2t2 = r2t1 + 1 ;
} else {
/*
With this we have B-field AND this is far more
intuitive for me ....
*/
r1t1 = idx(ir, it);
r2t1 = idx(ir + 1, it);
r1t2 = idx(ir, it + 1);
r2t2 = idx(ir + 1, it + 1);
}
if ((it >= 0) && (ir >= 0) && (it < Bfield_m.ntetS_m) && (ir < Bfield_m.nrad_m)) {
// lookup and apply field
```
The range check should rather be `ir + 1 < Bfield_m.nrad_m`2023.1snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/736Trimcoil implementation bug2023-02-13T15:50:53+01:00snuverink_jjochem.snuverink@psi.chTrimcoil implementation bug### Summary
In #276 and !53 a trim coil range in the azimuthal direction was introduced. However, this was not properly tested and it contained a bug, that was discovered by @zhang_h.
### What is the current *bug* behavior?
The trim c...### Summary
In #276 and !53 a trim coil range in the azimuthal direction was introduced. However, this was not properly tested and it contained a bug, that was discovered by @zhang_h.
### What is the current *bug* behavior?
The trim coils do not work anymore.
### What is the expected *correct* behavior?
Trim coils working as normal.
### Possible fixes
The bug was introduced in 77c975dcca3b99cf195cbf020d5039f8be745646, specifically in line
https://gitlab.psi.ch/OPAL/src/-/blob/160558d02705876d15775fe7527227a142bc2088/src/Classic/AbsBeamline/Cyclotron.cpp#L101
the order of the arguments is wrong, see also https://gitlab.psi.ch/OPAL/src/-/blob/0601ed262da6cd29690abff38053c900f9bafacc/src/Classic/TrimCoils/TrimCoil.cpp#L432022.1snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/502Geometry: Switch from hardcoded globalInsideP0_m to auto-detect2022-09-12T13:49:22+02:00winklehner_dGeometry: Switch from hardcoded globalInsideP0_m to auto-detect@gsell, the SAAMG solver still has a hardcoded varible `globalInsideP0_m` that should automatically be determined by the geometry class during geometry loading. Making it an OPTION could be an intermittent fix, but really the geometry ha...@gsell, the SAAMG solver still has a hardcoded varible `globalInsideP0_m` that should automatically be determined by the geometry class during geometry loading. Making it an OPTION could be an intermittent fix, but really the geometry handler should be able to determine a point that is clearly inside the geometry on its own.
from ArbitraryDomain.cpp:
```cpp
// TODO: THis needs to be made into OPTION of the geometry.
// A user defined point that is INSIDE with 100% certainty. -DW
globalInsideP0_m = Vector_t(0.0, 0.0, -0.13);
```
@frey\_m how does the AMR solver handle this? Or is it not using an imported geometry?
Cheers,
DanielOPAL 2.4.0gselladelmannwinklehner_dgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/718Wrong particle counting in CCollimator with particle-matter interactions2022-06-30T11:45:47+02:00ext-calvo_ppedro.calvo@ciemat.esWrong particle counting in CCollimator with particle-matter interactionsThe following discussion from !577 should be addressed:
- @ext-calvo_p started a [discussion](https://gitlab.psi.ch/OPAL/src/-/merge_requests/577#note_38608): (+1 comment)
> There is an additional problem with particle counting. T...The following discussion from !577 should be addressed:
- @ext-calvo_p started a [discussion](https://gitlab.psi.ch/OPAL/src/-/merge_requests/577#note_38608): (+1 comment)
> There is an additional problem with particle counting. The cyclotron tracker does not detect the particles that are in the material, and therefore always thrown the exception in `ParallelCyclotronTracker::deleteParticle()`.
>
> To reproduce it, just run the input file attached in the issue description. I've just updated it to the current format
The ScatteringPhysics algorithm delete from the bunch the particles that collide with the material. It then performs energy loss and Coulomb scattering calculations. Particles with energy above the threshold are returned to the beam by `addBackToBunch`, otherwise, the particles are considered lost.
OpalCycl updates the number of particles in a specific method focused on delete particles, so the local number of particles must coincide with the accumulated particles in all bunches after deletion. Therefore, the particles lost in ScatteringPhysics must be included in the bunch with the proper attribute to be deleted.2022.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/380Cyclotron collimator time step2022-06-29T19:32:27+02:00ext-calvo_ppedro.calvo@ciemat.esCyclotron collimator time step### Summary
Cyclotron collimator needs that each particle has own time step
### Steps to reproduce
Collimator in BANDRF cyclotron without acceleration:
[particulas_1000_xUyUzU_pxpypz.dat](/uploads/dbd53ea31cd5dde9d0d78704af2b9ad2/par...### Summary
Cyclotron collimator needs that each particle has own time step
### Steps to reproduce
Collimator in BANDRF cyclotron without acceleration:
[particulas_1000_xUyUzU_pxpypz.dat](/uploads/dbd53ea31cd5dde9d0d78704af2b9ad2/particulas_1000_xUyUzU_pxpypz.dat)
[BField_0T_const.dat](/uploads/1a6266e88c7494c18ce440936b276061/BField_0T_const.dat)
[trackingColl.in](/uploads/96a144999126653bd129a5f1c029770d/trackingColl.in)
### What is the current *bug* behavior?
In `ParallelCyclotronTracker` time step is not an attribute not null for each particle, so the simulations breaks in `CollimatorPhysics::copyFromBunch`, because `stepWidth=0`
### What is the expected *correct* behavior?
`dt[i]` should be equal to general timestep
### Relevant logs and/or screenshots
```
Error>
Error> *** Error:
Error> Internal OPAL error:
Error> Assertion 'tau >= 0.0' failed.
Error> tau = -inf, 0.0 = 0.000000
Error> in
Error> OPAL/src/src/Classic/Solvers/CollimatorPhysics.cpp, line 554
```
### Possible fixes
For `ParallelTTracker`, `dt[i]` is update throught `PartBunchBase<T, Dim>::switchToUnitlessPositions`2022.1snuverink_jjochem.snuverink@psi.chext-calvo_ppedro.calvo@ciemat.eskraussnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/649INPUTMOUNITS is now eV/c instead of eV2021-10-13T17:11:54+02:00albajacas_aarnau.albajacas@psi.chINPUTMOUNITS is now eV/c instead of eVAs pointed out by Hui Zhang, when we updated the momentum conversion formula in #475, the input units for momentum became [eV/c] instead of [eV].
Accordingly, the command for changing units
```
INPUTMOUNITS=EV
```
should be changed to s...As pointed out by Hui Zhang, when we updated the momentum conversion formula in #475, the input units for momentum became [eV/c] instead of [eV].
Accordingly, the command for changing units
```
INPUTMOUNITS=EV
```
should be changed to something like
```
INPUTMOUNITS=EV/c
```
And it should also be corrected in the manual in section 15.1
- [x] Update code OPAL/src!490
- [x] Update documentation OPAL/documentation/manual!126
- [x] Update regression tests OPAL/regression-tests!29OPAL 2021.1albajacas_aarnau.albajacas@psi.chalbajacas_aarnau.albajacas@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/666Refactoring method for cyclotron output field files2021-06-30T10:34:53+02:00ext-calvo_ppedro.calvo@ciemat.esRefactoring method for cyclotron output field filesOutput file gnu.out is written by different field map types. A new method could be added to avoid duplication of the code, separating the reading of the field map and the writing of the output.Output file gnu.out is written by different field map types. A new method could be added to avoid duplication of the code, separating the reading of the field map and the writing of the output.OPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/662eb.out has units in kilodegrees2021-06-25T14:47:25+02:00snuverink_jjochem.snuverink@psi.cheb.out has units in kilodegreesThe `OPAL-cycl` output file `eb.out`, which describes the electric and b field has as unit for the angle kilodegrees. This is due to a wrong conversion and should be changed back to degrees.The `OPAL-cycl` output file `eb.out`, which describes the electric and b field has as unit for the angle kilodegrees. This is due to a wrong conversion and should be changed back to degrees.OPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/23SBEND3D2021-06-10T18:37:45+02:00adelmannSBEND3D- 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 ...- 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.ext-rogers_cadelmannext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/145Review of MagneticField class and field map reading in Cyclotron class2021-06-10T18:05:39+02:00snuverink_jjochem.snuverink@psi.chReview of MagneticField class and field map reading in Cyclotron classSplit from issue #70.
The class [MagneticField](https://gitlab.psi.ch/OPAL/src/blob/master/src/Distribution/MagneticField.h) has the task to read a cyclotron field map for the `MatchedGauss` distribution. It does this by inheriting and ...Split from issue #70.
The class [MagneticField](https://gitlab.psi.ch/OPAL/src/blob/master/src/Distribution/MagneticField.h) has the task to read a cyclotron field map for the `MatchedGauss` distribution. It does this by inheriting and duplicating code from the `Cyclotron` class.
This seems not ideal to me. So I am wondering if we can split off the field map reading from the Cyclotron class?
This would
- split off functionality into a separate class
- avoid duplication
- reduce the large Cyclotron class
- (one could use a factory-like pattern to produce the fieldmaps).https://gitlab.psi.ch/OPAL/src/-/issues/651Printing info of DumpFields and DumpEMFields2021-05-11T10:45:39+02:00ext-calvo_ppedro.calvo@ciemat.esPrinting info of DumpFields and DumpEMFieldsDumpFields and DumpEMFields statements must print information about their attributes to stdout.DumpFields and DumpEMFields statements must print information about their attributes to stdout.OPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/643Remove unnecessary condition in CCollimators2021-03-26T11:52:31+01:00ext-calvo_ppedro.calvo@ciemat.esRemove unnecessary condition in CCollimatorsCCollimator is currently restricted only for `REGULAR` particles, but all the `ParticleOrigin` must be consideredCCollimator is currently restricted only for `REGULAR` particles, but all the `ParticleOrigin` must be consideredOPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/642Stop particles in probe2021-03-26T08:27:43+01:00ext-calvo_ppedro.calvo@ciemat.esStop particles in probeAdds a user option to stop particle tracking in the probe elementAdds a user option to stop particle tracking in the probe elementext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/626Add RING cyclotron fieldmap type2020-12-10T09:23:33+01:00ext-calvo_ppedro.calvo@ciemat.esAdd RING cyclotron fieldmap type`RING` fieldmap type (PSI format measured field file) for cyclotron is considered as default if one of the other types are not mentioned. I propose to add this `TYPE` explicitly to the different options, to prevent the bad assignment of ...`RING` fieldmap type (PSI format measured field file) for cyclotron is considered as default if one of the other types are not mentioned. I propose to add this `TYPE` explicitly to the different options, to prevent the bad assignment of the `TYPE` parameter.OPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.es