src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2020-04-02T09:16:08+02:00https://gitlab.psi.ch/OPAL/src/-/issues/34Autophasing when follow-up track starts inside cavity2020-04-02T09:16:08+02:00krausAutophasing when follow-up track starts inside cavityWhen a follow-up track starts inside a cavity then the phase doesn't seem to be correct.[EGunCTF3-1_energy.pdf](/uploads/400d91f3c741a38f90e9b3cfa5c91a23/EGunCTF3-1_energy.pdf)When a follow-up track starts inside a cavity then the phase doesn't seem to be correct.[EGunCTF3-1_energy.pdf](/uploads/400d91f3c741a38f90e9b3cfa5c91a23/EGunCTF3-1_energy.pdf)krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/33compilation of branch OPAL-1.6 fails if DKS is enabled2020-04-02T09:16:08+02:00gsellcompilation of branch OPAL-1.6 fails if DKS is enabledIf DKS is enables compilation fails on the OPAL-1.6 branch:
```
/opt/tmp/gsell/src/OPAL-1.5.1-20170210/src/Classic/Solvers/CollimatorPhysics.cpp: In member function ‘void CollimatorPhysics::setupCollimatorDKS(PartBunch&, Degrader*, size_...If DKS is enables compilation fails on the OPAL-1.6 branch:
```
/opt/tmp/gsell/src/OPAL-1.5.1-20170210/src/Classic/Solvers/CollimatorPhysics.cpp: In member function ‘void CollimatorPhysics::setupCollimatorDKS(PartBunch&, Degrader*, size_t)’:
/opt/tmp/gsell/src/OPAL-1.5.1-20170210/src/Classic/Solvers/CollimatorPhysics.cpp:1081:47: error: ‘class Degrader’ has no member named ‘getZSize’
double params[numpar] = {zBegin, deg->getZSize(), rho_m, Z_m,
```
Without DKS it compiles without problems.OPAL 1.5.2https://gitlab.psi.ch/OPAL/src/-/issues/32OPAL-T: Error handling2019-02-13T08:52:38+01:00Valeria RizzoglioOPAL-T: Error handlingIn case of missing SELECTION of the beamline and TRACK command (I merged two input files and I forgot to copy those two lines)
```
SELECT, LINE=BEAMLINE_G3_LA2_LD;
TRACK, LINE=BEAMLINE_G3_LA2_LD, BEAM=BEAM_G3_LA2_LD,
```
this is...In case of missing SELECTION of the beamline and TRACK command (I merged two input files and I forgot to copy those two lines)
```
SELECT, LINE=BEAMLINE_G3_LA2_LD;
TRACK, LINE=BEAMLINE_G3_LA2_LD, BEAM=BEAM_G3_LA2_LD,
```
this is the error message that appears:
```
OPAL>
OPAL> *** Parse error detected by function "OpalParser::parseEnd()"
OPAL> *** in line 51 of file "TestShort.in" before token ",":
OPAL> MAXSTEPS=5e+08,DT=1*PICOSECONDS,ZSTOP=34.4;
OPAL> Syntax error (maybe missing comma or semicolon ? )
OPAL>
```
Maybe mentioning that the **TRACK** command is missing would be better and easier to find the problem.adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/31OPAL-T: missing particles stored in the monitor2017-02-11T08:18:45+01:00Valeria RizzoglioOPAL-T: missing particles stored in the monitorI am running the following simulation (input file attached):
**Beam:** 250 MeV proton beam degraded to 230 MeV due to interaction with graphite
**Last part of the beamline without CollimatorPhysics**
```
KMA8: ECOLLIMATOR, XSIZE=0.00...I am running the following simulation (input file attached):
**Beam:** 250 MeV proton beam degraded to 230 MeV due to interaction with graphite
**Last part of the beamline without CollimatorPhysics**
```
KMA8: ECOLLIMATOR, XSIZE=0.007, YSIZE=0.007, L=0.075, ZSIZE=0.075, ELEMEDGE=19.004;
MMAP25X: MONITOR, OUTFN="MMAP25X.h5", ELEMEDGE=30.3;
```
The simulation ends **ZSTOP = 34.4 m** so there are 4 m of drift space (no losses) between the monitor MMAP25X and the end of the simulation.
The longitudinal beam extension is 0.5 m: the entire beam crosses the monitor. In this case the number of particles recorded by the monitor MMAP25X **agrees** with the protons stored at the end of the simulation.
If I apply the CollimatorPhysics on KMA8,
```
CopperCol: SURFACEPHYSICS, TYPE="COLLIMATOR", MATERIAL="Copper";
KMA8: ECOLLIMATOR, XSIZE=0.007, YSIZE=0.007, L=0.075, ZSIZE=0.075, SURFACEPHYSICS=CopperCol, ELEMEDGE=19.004;
```
then the longitudinal beam extension increases to 2 m due to the scattering effect. Even in this case, the entire beam should cross the monitor, however the number of protons recorded by the monitor is **less** than the final number of particles:
**Protons at MMAP25X:** 9312
**Protons at the last step:** 9988
**Collimator does not go Offline**
The situation does not change moving the monitor closer to the collimator (= increasing the distance between the monitor and ZSTOP)
**OPAL Version:** "old " OPAL binary from Uldis (/home/scratch/locans/install/opal-dks-1.5/src/)
```
OPAL> This is OPAL (Object Oriented Parallel Accelerator Library) Version 1.5.00.1
OPAL> OPAL compiled with DKS (Dynamic Kernel Scheduler) Version 1.0.2
```
at the moment this is the only binary I can use that runs the CollimatorPhysics multi-cores and writes the monitor files (issue #29).
[PROSCAN-G3-LA1-LD-230.in](/uploads/1c18f6f67381ebdf31c4805dda90cc51/PROSCAN-G3-LA1-LD-230.in)adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/30Regression test 'RestartTest-2' is running forever.2017-03-16T14:44:43+01:00gsellRegression test 'RestartTest-2' is running forever.OPAL 1.6.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/29Failed to open h5 file2019-10-25T13:47:36+02:00Valeria RizzoglioFailed to open h5 fileOPAL - T
- Module OPAL/1.5.0-20170126
```
Ippl{0}> Save MMAP1X.h5
OPAL{0}>
OPAL{0}> *** User error detected by function "LossDataSink::openH5"
OPAL{0}> *** in line 149 of file "PROSCAN-G3-LA1-230-4p.in":
OPAL{0}> RUN,METHO...OPAL - T
- Module OPAL/1.5.0-20170126
```
Ippl{0}> Save MMAP1X.h5
OPAL{0}>
OPAL{0}> *** User error detected by function "LossDataSink::openH5"
OPAL{0}> *** in line 149 of file "PROSCAN-G3-LA1-230-4p.in":
OPAL{0}> RUN,METHOD="PARALLEL-T",BEAM=BEAM_G3_LA1,FIELDSOLVER=FS1,DISTRIBUTION=DISTRIB1;
OPAL{0}> failed to open h5 file 'MMAP1X.h5'
OPAL{0}>
```
Attached the OPAL input file. [OPAL-Test.in](/uploads/2ff3e732337377a793f1c65484e687f4/OPAL-Test.in)adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/28OPAL-Flavor in the .stat file2017-02-17T22:15:08+01:00Valeria RizzoglioOPAL-Flavor in the .stat fileIn order to display properly the beam envelope in ROGER, we need to distinguished between OPAL-T (dataset x - y) and OPAL-Cyc (dataset x-z).
In case of reading from .h5 file, the attribute OPAL-Flavor is used to load the proper dataset...In order to display properly the beam envelope in ROGER, we need to distinguished between OPAL-T (dataset x - y) and OPAL-Cyc (dataset x-z).
In case of reading from .h5 file, the attribute OPAL-Flavor is used to load the proper dataset. The OPAL-Flavor should be stored also in the .stat file, so that the correct envelope can be displayed when the .stat file is loaded in ROGER.adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/27RingCyclotron- and RingCyclotronMTS-Test broken2017-03-18T00:05:29+01:00adelmannRingCyclotron- and RingCyclotronMTS-Test brokencommit 005f20628c7049f5fd1c8c06610ea084d1db2983
Author: Andreas Adelmann <andreas.adelmann@psi.ch>
Date: Tue Nov 8 21:45:26 2016 +0100
remove particle with ID==0 form the H5 file in case of opal-cycl and from the statistics ca...commit 005f20628c7049f5fd1c8c06610ea084d1db2983
Author: Andreas Adelmann <andreas.adelmann@psi.ch>
Date: Tue Nov 8 21:45:26 2016 +0100
remove particle with ID==0 form the H5 file in case of opal-cycl and from the statistics calculation
src/Classic/Algorithms/PartBunch.cpp | 34 +++++++++++++++++++++++++++++++++-
src/Structure/H5PartWrapperForPC.cpp | 21 +++++++++++++++++++++
2 files changed, 54 insertions(+), 1 deletion(-)
bricht nicht ganz unerwartet den RingCyclotron- und RingCyclotronMTS-Test.
gCOPAL 1.6.0adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/26regression tests do not run on head of the repo2017-03-16T15:34:26+01:00adelmannregression tests do not run on head of the repoHoi zäme,
ich habe gerade gesehen, dass die Regression Tests nicht mehr die neueste Version des Codes aus dem git-repo holt, sie blieben bei Andreas' Commit vom 19 August (2016!), 987ab1f stehen. Vielleicht müsste einer von euch beide...Hoi zäme,
ich habe gerade gesehen, dass die Regression Tests nicht mehr die neueste Version des Codes aus dem git-repo holt, sie blieben bei Andreas' Commit vom 19 August (2016!), 987ab1f stehen. Vielleicht müsste einer von euch beiden nachschauen, was das Problem ist.
Grüsse,
christofOPAL 1.6.0gsellgsell2017-02-06https://gitlab.psi.ch/OPAL/src/-/issues/25SBEND3D - Local and Global Frame: different particle trajectories2017-12-18T18:21:19+01:00Valeria RizzoglioSBEND3D - Local and Global Frame: different particle trajectoriesThe tracking of the particles in the **LOCAL frame** reveals different behavior with respect to the **GLOBAL frame**
**Field Map**
* 120° Combined Function Magnet
* Reference energy: 230 MeV
**Beam distribution**
* From file...The tracking of the particles in the **LOCAL frame** reveals different behavior with respect to the **GLOBAL frame**
**Field Map**
* 120° Combined Function Magnet
* Reference energy: 230 MeV
**Beam distribution**
* From file: 10000 protons
* First 12 particles are:
```
#ID0: Reference particle
#ID1: Reference particle
#ID2 - #ID9: Particles with defined position and divergence offsets
#ID10: Off-momemtum particle (-11.5 % ) -> py = -0.08531
#ID11: Off-momemtum particle (+13.5 %) -> py = 0.1001511
#ID12: Dispersion function (1 %) -> py = 0.0074186
```
**Tracking** for particles #ID1 (reference), #ID10 and #ID11 (with momentum shift)
* **Global Frame**
![GlobalFrame](/uploads/3ade8aaf8db834db004c57cf8d1e49fa/GlobalFrame.png)
* **Local Frame**
![LocalFrame](/uploads/f079b9a5ee7e43b0918223b3d415f4ba/LocalFrame.png)
**Conclusion**
The particle trajectories in the **LOCAL frame**:
* show a "jump" at 3.8 m, where the field map ends.
* cross the reference trajectory, while in the **GLOBAL frame** the trajectory are separatedOPAL 1.5.2ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/24Fieldsolver ?2017-03-16T14:44:47+01:00adelmannFieldsolver ?Dear OPAL users, I write you because we have some problems about the simulation of a big number of particles.
We simulate without problems our machine with the correct electric and magnetic fields, including the geometry in the simulatio...Dear OPAL users, I write you because we have some problems about the simulation of a big number of particles.
We simulate without problems our machine with the correct electric and magnetic fields, including the geometry in the simulation. But when we increase the number of particles above 1000, we obtain the following error in the output:
Error> Interpolator::getFieldIter: attempt to access non-local index{[-2147483648:-2147483648:1],[-2147483648:-2147483648:1],[-2147483648:-2147483648:1]} on node 0
Error> Dumping local owned and allocated domains:
Error> 0: owned = {[0:31:1],[0:31:1],[0:31:1]}, allocated = {[-1:32:1],[-1:32:1],[-1:32:1]}
Error> Error occurred for BareField with layout = Domain = {[0:31:1],[0:31:1],[0:31:1]}
Error> FieldLayoutUsers = 3
Error> Total number of vnodes = 1
Error> Local Vnodes = 1
Error> vnode 0: Node = 0 ; vnode_m = -1 ; Domain = {[0:31:1],[0:31:1],[0:31:1]}
Error> Remote Vnodes = 0
Error>
Error> Calling abort ...
This error don't occur when the number of particles is lower than 1000.
We have tried to solve this error changing the fieldsolver in the code for a 1000 particles, but the results are completly diferent if we compare with the simulation with a number of particles of 999. I
I will appreciate any suggestion to solve this problem.
Best Regards
Pedro CalvoOPAL 1.6.0adelmannadelmannhttps://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/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/21Build system puts Boost include directory before OPAL include directories2017-03-16T14:34:54+01:00snuverink_jjochem.snuverink@psi.chBuild system puts Boost include directory before OPAL include directoriesThe build system puts the Boost include directory before the OPAL include directories. When installing OPAL in the same directory as where boost resides (I know perhaps not the best idea), a new build will give preference to the header f...The build system puts the Boost include directory before the OPAL include directories. When installing OPAL in the same directory as where boost resides (I know perhaps not the best idea), a new build will give preference to the header files in the install directory. This gives compilation errors when the files are updated.
I was able to fix this by putting the OPAL include directories explicitly before others (see [attached patch](/uploads/5ec73615603049c56cadb8dd6ec28daa/include.patch)).OPAL 1.5.1gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/20Option Handling2017-01-25T13:16:43+01:00frey_mOption HandlingThe STATDUMPFREQ in OPAL-Cycl is not allowed to be zero. However, this is not handled in OPAL. It would be nice we could add some exception handlings or something else for the OPAL input options.The STATDUMPFREQ in OPAL-Cycl is not allowed to be zero. However, this is not handled in OPAL. It would be nice we could add some exception handlings or something else for the OPAL input options.adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/19DKS Documentation in OPAL manual2018-01-30T13:42:19+01:00adelmannDKS Documentation in OPAL manualAdd DKS documentation to OPAL manual
- reference to paper
- how to compile
- how to use
- update OPTION, remove DKS
A brief description on how to install cuda and install dks is available on the Wiki. Add DKS documentation to OPAL manual
- reference to paper
- how to compile
- how to use
- update OPTION, remove DKS
A brief description on how to install cuda and install dks is available on the Wiki. OPAL 1.6.0https://gitlab.psi.ch/OPAL/src/-/issues/18OPAL-Cyc: Mixing coordinates and momenta for ID02018-03-16T06:03:55+01:00Valeria RizzoglioOPAL-Cyc: Mixing coordinates and momenta for ID0The first two particles from the input beam are:
```
0.000 0.000 0.000 0.0000 0.0000 0.0000
0.000 -0.0074186 0.0000 0.00000 0.0000 0.00000
```
the OFFSETZ and OFFSETY have been used in the input file: OFFSETZ = 0.15 m and OFFSETY =...The first two particles from the input beam are:
```
0.000 0.000 0.000 0.0000 0.0000 0.0000
0.000 -0.0074186 0.0000 0.00000 0.0000 0.00000
```
the OFFSETZ and OFFSETY have been used in the input file: OFFSETZ = 0.15 m and OFFSETY = 0.0001 m
**Outputs**
* **Step 0**
** **Track-orbit**: it is already known that the y and z coordinates for ID0 are not updated with respect to OFFSETY and OFFSETZ. X-coor is correct.
```
x [mm] beta_x*gamma y [mm] beta_y*gamma z [mm] beta_z*gamma
ID0 -1.30000000e+03 -3.30872245e-24 2.71050543e-17 7.41857376e-01 -2.58493941e-26 1.69406589e-21
ID1 -1.30000000e+03 -7.41860000e-03 1.00000000e-01 7.41857376e-01 1.50000000e+02 0.00000000e+00
```
** **H5**: only ID0 coordinates are copied from ID1
```
x [m] y [m] z [m] px py pz
ID0 * -1.3 * 0.0001 * 0.15 * 0 * 0.7418573 * 0 *
ID1 * -1.3 * 0.0001 * 0.15 * -0.007418 * 0.7418573 * 0 *
```
* **Step 100**
** **Track-ordit**
```
x [mm] beta_x*gamma y [mm] beta_y*gamma z [mm] beta_z*gamma
ID0 4.91648494e+02 5.82908115e-01 2.17698321e+03 -2.50847030e-01 2.86192018e+02 3.85769984e-01
ID1 5.14833464e+02 6.81873741e-01 2.19127413e+03 -2.92328139e-01 1.50000000e+02 2.56591691e-16
```
** **H5**
```
x [m] y [m] z [m] px py pz
ID0 * 0.5148334 * 2.1912741 * 0.15 * 0.5829081 * -0.250847 * 0.3857699 *
ID1 * 0.5148334 * 2.1912741 * 0.15 * 0.6818737 * -0.292328 * 0 *
```
* **Conclusions**
1. In case of OFFSETs, the ID0 particle stored in the track-Orbits is not shifted. Depending on the simulation, the track of this particle could be wrong. For example, assuming to place the beam in the mid-plane of a dipole, as in my case, the ID0 particle sees a wrong magnetic field. In my simulation, this particle is useless, it cannot be used as reference particle and removed from the track-Orbit file.
2. In the H5 file, a combination of ID0 and ID1 is stored. The coordinates of ID0 are copied from ID1 (properly tracked in the simulation), while the momenta are from the track of ID0. The result is a mixture of particle coordinates and momenta.
* **Solutions**
1. Update the position of the ID0 (already discussed, but too complicated)
2. Write a note in the manual that explains this situation
3. In the H5 file, copy completely ID1 and not mix two particles.adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/17Dispersion in stat file2017-01-25T13:17:30+01:00Valeria RizzoglioDispersion in stat fileAccording to **Issue #14 Particles stored in trackOrbit.dat** and the new implementation,
the dispersion should be removed from the stat file
```
&column name=Dx1, type=double, units=m , description="26 Dispersion in x particle 1 " &en...According to **Issue #14 Particles stored in trackOrbit.dat** and the new implementation,
the dispersion should be removed from the stat file
```
&column name=Dx1, type=double, units=m , description="26 Dispersion in x particle 1 " &end
&column name=Dx2, type=double, units=m , description="27 Dispersion in x particle 2 " &end
&column name=Dx3, type=double, units=m , description="28 Dispersion in x particle 3 " &end
&column name=Dx4, type=double, units=m , description="29 Dispersion in x particle 4 " &end
```
also because of wrong units. According to the way that it is implemented than it should be [m/%] and not [m]adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/16OPAL-Cyc - single particle tracking: not store right statistics in .h5 file2017-03-02T22:19:34+01:00Valeria RizzoglioOPAL-Cyc - single particle tracking: not store right statistics in .h5 file**Simulation**:
* single particle tracking in OPAL-Cyc (1.5.002)
* PSDUMPLOCALFRAME = FALSE
* Input file: /afs/psi.ch/project/SCGantry/CCT_Concept/OPAL_Test
**OPAL outputs**
* **trackOrbit**: IDO in global frame. The p...**Simulation**:
* single particle tracking in OPAL-Cyc (1.5.002)
* PSDUMPLOCALFRAME = FALSE
* Input file: /afs/psi.ch/project/SCGantry/CCT_Concept/OPAL_Test
**OPAL outputs**
* **trackOrbit**: IDO in global frame. The particle coordinates are right
```
# The six-dimensional phase space data in the global Cartesian coordinates
# Part. ID x [mm] beta_x*gamma y [mm] beta_y*gamma z [mm] beta_z*gamma
ID0 -1.30000000e+03 0.00000000e+00 1.00000000e-01 6.56544376e-01 1.50000000e+02 0.00000000e+00
ID0 -1.30000000e+03 0.00000000e+00 3.39069250e+00 6.56544376e-01 1.50000000e+02 0.00000000e+00
ID0 -1.30000000e+03 0.00000000e+00 6.68138500e+00 6.56544376e-01 1.50000000e+02 0.00000000e+00
ID0 -1.30000000e+03 0.00000000e+00 9.97207750e+00 6.56544376e-01 1.50000000e+02 0.00000000e+00
ID0 -1.30000000e+03 0.00000000e+00 1.32627700e+01 6.56544376e-01 1.50000000e+02 0.00000000e+00
ID0 -1.30000000e+03 0.00000000e+00 1.65534625e+01 6.56544376e-01 1.50000000e+02 0.00000000e+00
```
* **h5**: the particle coordinates seem to be not stored. They are always zero. Here an example for different steps (0, 1, 10, 100, 120)
```
root [3] TNtupleD *opalC = dataC.GetNtuple(0);
root [4] opalC->Scan()
************************************************************************************************************
* Row * x * y * z * px * py * pz * phiz * enez *
************************************************************************************************************
* 0 * 1.63e-322 * 6.90e-310 * 6.90e-310 * 0 * 0.6565443 * 0 * 0 * 0 *
************************************************************************************************************
root [5] TNtupleD *opalC = dataC.GetNtuple(1);
root [6] opalC->Scan()
************************************************************************************************************
* Row * x * y * z * px * py * pz * phiz * enez *
************************************************************************************************************
* 0 * 1.63e-322 * 6.90e-310 * 6.90e-310 * 0 * 0.6565443 * 0 * 0 * 0 *
************************************************************************************************************
root [7] TNtupleD *opalC = dataC.GetNtuple(10);
root [8] opalC->Scan()
************************************************************************************************************
* Row * x * y * z * px * py * pz * phiz * enez *
************************************************************************************************************
* 0 * 1.63e-322 * 6.90e-310 * 6.90e-310 * 0 * 0.6565443 * 0 * 0 * 0 *
************************************************************************************************************
root [9] TNtupleD *opalC = dataC.GetNtuple(100);
root [10] opalC->Scan()
************************************************************************************************************
* Row * x * y * z * px * py * pz * phiz * enez *
************************************************************************************************************
* 0 * 1.63e-322 * 6.90e-310 * 6.90e-310 * 0.6408104 * -0.142872 * 0 * 0 * 0 *
************************************************************************************************************
```
adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/15Distribution FROMFILE: different behaviour OPAL-T and OPAL-Cyc2019-10-25T13:47:36+02:00Valeria RizzoglioDistribution FROMFILE: different behaviour OPAL-T and OPAL-CycWhen the distribution "FROMFILE" is used, the number of particles (N) in the distribution file and in the OPAL input file (NPart) should match.
It could happen that two different numbers are used. In this case OPAL-T and OPAL-Cyc have ...When the distribution "FROMFILE" is used, the number of particles (N) in the distribution file and in the OPAL input file (NPart) should match.
It could happen that two different numbers are used. In this case OPAL-T and OPAL-Cyc have different behaviour:
* **OPAL-T**: Warning message, but the simulation still runs
```
OPAL> --------------------------------------------------
OPAL> Warning!! The number of particles in the initial
OPAL> distribution is 100000.
OPAL>
OPAL> This is different from the number of particles
OPAL> defined by the BEAM command: 10
OPAL>
OPAL> This is often happens when using a FROMFILE type
OPAL> distribution and not matching the number of
OPAL> particles in the particles file(s) with the number
OPAL> given in the BEAM command.
OPAL>
OPAL> The number of particles in the initial distribution
OPAL> (100000) will take precedence.
OPAL> ---------------------------------------------------
```
* **OPAL-Cyc**: Error message and the simulation stops
```
OPAL> *** User error detected by function "TrackRun::execute CYCLOTRON_T"
OPAL> *** in line 46 of file "120_deg_CFM.in" at end of statement:
OPAL> RUN,METHOD="CYCLOTRON-T",BEAM=BEAM_4,FIELDSOLVER=FS1,DISTRIBUTION=DIST1;
OPAL> Number of macro particles and NPART on BEAM are not equal
```OPAL 1.5.1adelmannadelmann2017-01-17