src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2021-06-10T18:05:39+02:00https://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/144Fixed reference point for inside check2020-06-05T18:34:47+02:00krausFixed reference point for inside checkIn the class ArbitraryDomain globalIsInside_m is hard coded. This should be computed automatically for any domain and shouldn't be hard coded or needed from the input file. Possibility:
1. compute the bounding box
2. pick one corner a...In the class ArbitraryDomain globalIsInside_m is hard coded. This should be computed automatically for any domain and shouldn't be hard coded or needed from the input file. Possibility:
1. compute the bounding box
2. pick one corner and move from there away from the opposite corner by an arbitrary length
3. pick an arbitrary triangle from the surface mesh
4. compute its balance point and move a small distance from it in normal direction
5. test whether the connecting line crosses an odd number of times
- if the test is positive then you're done
- otherwise move the same distance from the triangle to the other side
- compute number crosses with surface
- if the test is still negative then diminish distance from the triangle by factor 2 and try on both sides if necessaryOPAL 1.9.xgsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/143BoundaryGeometries VTK output produces odd results2018-05-16T13:12:14+02:00krausBoundaryGeometries VTK output produces odd resultsUsed the SAAMG-Test-1 to produce [attached screenshot](/uploads/695901d8c9e8a2e7afc37278f666eef7/Pipe_1m_10cm.png) (serial and parallel).Used the SAAMG-Test-1 to produce [attached screenshot](/uploads/695901d8c9e8a2e7afc37278f666eef7/Pipe_1m_10cm.png) (serial and parallel).gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/142Energy threshold documentation2021-02-16T08:39:33+01:00adelmannEnergy threshold documentation#83 and #131 need to go to the documenttion#83 and #131 need to go to the documenttionOPAL 2021.1adelmannext-calvo_ppedro.calvo@ciemat.esadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/141Improve PAssert to print more diagnostics analog to ASSERT_EQ, ASSERT_LT aso ...2017-12-26T21:58:40+01:00krausImprove PAssert to print more diagnostics analog to ASSERT_EQ, ASSERT_LT aso from GTestASSERT_LT in GTest prints
~/gitwork/opal/ippl/src/Particle/ParticleAttrib.hpp:104: Failure
Expected: (I + M) < (LocalSize), actual: 5039 vs 5039ASSERT_LT in GTest prints
~/gitwork/opal/ippl/src/Particle/ParticleAttrib.hpp:104: Failure
Expected: (I + M) < (LocalSize), actual: 5039 vs 5039krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/140Particle delete2017-08-05T14:31:50+02:00adelmannParticle deleteWith OPAL-1.6 (newest pull) and Regressiontest PSIGUN-1 Bin 0 gets no particles at timestep 2:
....
OPAL {0}[3]> * Wrote beam statistics.
Ippl{0}[2]> Bin 0 gamma = 1.00717e+00; NpInBin= 667
Ippl{0}[2]> Bin 1 has...With OPAL-1.6 (newest pull) and Regressiontest PSIGUN-1 Bin 0 gets no particles at timestep 2:
....
OPAL {0}[3]> * Wrote beam statistics.
Ippl{0}[2]> Bin 0 gamma = 1.00717e+00; NpInBin= 667
Ippl{0}[2]> Bin 1 has no particles
Ippl{0}[2]> Bin 2 has no particles
Ippl{0}[2]> Bin 3 has no particles
Ippl{0}[2]> Bin 4 has no particles
Ippl{0}[3]> * Bin number: 2 has emitted all particles (new emit).
ParallelTTracker {0}> * Deleted 667 particles, remaining 4755 particles
ParallelTTracker {0}[3]> 12:03:09 Step 1 at -0.053 [mm] t= 1.060e-11 [s] E= 5.388 [keV]
...
OPAL {0}>
OPAL {0}[3]> * Wrote beam statistics.
Ippl{0}[2]> Bin 0 has no particles
Ippl{0}[2]> Bin 1 gamma = 1.01054e+00; NpInBin= 4755
Ippl{0}[2]> Bin 2 has no particles
Later on we are running into
I + M < LocalSize
@kraus Is there still an autophpse problem?OPAL 1.6.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/139Replace length given in input file with length of field map2018-09-22T15:45:42+02:00krausReplace length given in input file with length of field mapOPAL 2.0.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/138Setting autophase option without a cavity in beamline throws mysterious error2017-08-05T20:04:40+02:00ext-hall_cSetting autophase option without a cavity in beamline throws mysterious errorWith `"OPTION, AUTOPHASE=4;"` in my input file when I use a beamline without a cavity I see an error like:
`opal(7879,0x7fff7f140000) malloc: *** error for object 0x7fff9a15b9f3: pointer being freed was not allocated`
Turning autophase...With `"OPTION, AUTOPHASE=4;"` in my input file when I use a beamline without a cavity I see an error like:
`opal(7879,0x7fff7f140000) malloc: *** error for object 0x7fff9a15b9f3: pointer being freed was not allocated`
Turning autophase off allowed my input file to run without error, but this error was not very informative and it took quite a while to find the culprit. It might be helpful if making this mistake generated a specific error message.OPAL 1.6.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/136Duplicated Bunch2017-08-13T17:23:59+02:00frey_mDuplicated Bunch```ParallelCyclotronTracker``` is a derived class of ```Tracker``` that has a protected member variable ```PartBunch```. As far as I see, the bunch is copied at construction, i.e. leading to a duplicated bunch: One stored in the instance...```ParallelCyclotronTracker``` is a derived class of ```Tracker``` that has a protected member variable ```PartBunch```. As far as I see, the bunch is copied at construction, i.e. leading to a duplicated bunch: One stored in the instance of ```Tracker``` and the other stored in ```Track::block```.OPAL 1.9.xfrey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/135Restart in Opal-Cycl2018-04-11T10:36:40+02:00krausRestart in Opal-CyclThe restart in the RestartTest-2 looks odd to me. Maybe some Opal-Cycl-expert should look into it.The restart in the RestartTest-2 looks odd to me. Maybe some Opal-Cycl-expert should look into it.adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/134Perfect Diode Regression-Test2017-07-24T06:20:51+02:00adelmannPerfect Diode Regression-TestI remember seeing this lately and connect the solution wit @winklehner_d
Ippl{0}> *** Error:
Ippl{0}> RUN,METHOD="PARALLEL-T",BEAM=BEAM1,FIELDSOLVER=FS1,DISTRIBUTION=DIST2;
Ippl{0}> Internal OPAL error: vector::_M_range_check:...I remember seeing this lately and connect the solution wit @winklehner_d
Ippl{0}> *** Error:
Ippl{0}> RUN,METHOD="PARALLEL-T",BEAM=BEAM1,FIELDSOLVER=FS1,DISTRIBUTION=DIST2;
Ippl{0}> Internal OPAL error: vector::_M_range_check: __n (which is 25000) >= this->size() (which is 25000)
I concerns the fail of PerfectDiode regression testOPAL 1.6.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/133BeamLine fails isInside test during OrbitThreader execute() when Aperture CIR...2017-08-02T22:49:58+02:00winklehner_dBeamLine fails isInside test during OrbitThreader execute() when Aperture CIRCLE is defined in RFCavity.It took me a long time to find out why my RFCavity was not in the imap_m generated by the OrbitThreader during execute(), so I wasn't able to test this with other apertures, but it seems that having a "CIRCLE(0.008, 1)" aperture defined ...It took me a long time to find out why my RFCavity was not in the imap_m generated by the OrbitThreader during execute(), so I wasn't able to test this with other apertures, but it seems that having a "CIRCLE(0.008, 1)" aperture defined in the RFCavity element prevents it from being added to the elementSet list in the getElements(nextR) function. I think the culprit is somehow the ElementBase::isInsideTransverse() function.krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/132_M_range_check error2017-08-13T10:13:16+02:00winklehner_d_M_range_check errorSince pulling today, this happens:
```
Error{1}> *** Error:
Error{1}> *** in line 86 of file "RFQ_VECC-T.in":
Error{1}> RUN,METHOD="PARALLEL-T",BEAM=BEAM1,FIELDSOLVER=FS1,DISTRIBUTION=DIST;
Error{1}> vector::_M_range_check
...Since pulling today, this happens:
```
Error{1}> *** Error:
Error{1}> *** in line 86 of file "RFQ_VECC-T.in":
Error{1}> RUN,METHOD="PARALLEL-T",BEAM=BEAM1,FIELDSOLVER=FS1,DISTRIBUTION=DIST;
Error{1}> vector::_M_range_check
```
Any insights anyone? @kraus, did you write something about distributions now being arrays? @adelmann?https://gitlab.psi.ch/OPAL/src/-/issues/130Unit tests report2017-10-09T06:17:32+02:00snuverink_jjochem.snuverink@psi.chUnit tests reportRunning the unit tests on master gives the following result:
```
[==========] 66 tests from 12 test cases ran. (1266 ms total)
[ PASSED ] 61 tests.
[ FAILED ] 5 tests, listed below:
[ FAILED ] RingTest.TestApply
[ FAILED ] RingT...Running the unit tests on master gives the following result:
```
[==========] 66 tests from 12 test cases ran. (1266 ms total)
[ PASSED ] 61 tests.
[ FAILED ] 5 tests, listed below:
[ FAILED ] RingTest.TestApply
[ FAILED ] RingTest.TestApply2
[ FAILED ] RingTest.TestApply3
[ FAILED ] GaussTest.FullSigmaTest1
[ FAILED ] GaussTest.FullSigmaTest2
5 FAILED TESTS
```
Tentatively assigned to @ext-rogers_c. Please reassign or open a new report for individual tests.
The Ring tests were not failing on `OPAL-1.6`.
`RingTest.TestApply`:
```
tests/classic_src/AbsBeamline/RingTest.cpp:259: Failure
The difference between B(i) and BRef(i) is 0.90010000000000012, which exceeds 1e-6, where
B(i) evaluates to 0,
BRef(i) evaluates to -0.90010000000000012, and
1e-6 evaluates to 9.9999999999999995e-07.
for pos ( 0.099899999999999878 , -2.2000000000000002 , -0.5 )
```
`RingTest.TestApply2`:
```
tests/classic_src/AbsBeamline/RingTest.cpp:298: Failure
Value of: ring.apply(pos, Vector_t(0.0), 0., E, B)
Actual: true
Expected: false
tests/classic_src/AbsBeamline/RingTest.cpp:303: Failure
Expected: (-B(2)) >= (0.1), actual: -0 vs 0.1
```
`RingTest.TestApply3`:
```
tests/classic_src/AbsBeamline/RingTest.cpp:395: Failure
The difference between B(0) and bx is 3, which exceeds 1e-6, where
B(0) evaluates to 0,
bx evaluates to 3, and
1e-6 evaluates to 9.9999999999999995e-07.
```
The `GaussTests` fail both in the same way (also on `OPAL-1.6`), output for Test1:
```
tests/opal_src/Distribution/GaussTest.cpp:119: Failure
Expected: (std::abs(expectedR11 - R11)) < (0.05 * expectedR11), actual: 0.247124 vs 0.1957
src/tests/opal_src/Distribution/GaussTest.cpp:120: Failure
Expected: (std::abs(expectedR21 - R21)) < (-0.05 * expectedR21), actual: 0.062553 vs 0.03243
src/tests/opal_src/Distribution/GaussTest.cpp:121: Failure
Expected: (std::abs(expectedR22 - R22)) < (0.05 * expectedR22), actual: 0.0412111 vs 0.03198
src/tests/opal_src/Distribution/GaussTest.cpp:123: Failure
Expected: (std::abs(expectedR52 - R52)) < (0.05 * expectedR52), actual: 0.0466059 vs 0.036325
src/tests/opal_src/Distribution/GaussTest.cpp:124: Failure
Expected: (std::abs(expectedR61 - R61)) < (0.05 * expectedR61), actual: 0.0998879 vs 0.0681
src/tests/opal_src/Distribution/GaussTest.cpp:125: Failure
Expected: (std::abs(expectedR62 - R62)) < (-0.05 * expectedR62), actual: 0.0256172 vs 0.013425
[ FAILED ] GaussTest.FullSigmaTest1 (552 ms)
```ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/129Array of distributions containing FROMFILE2017-08-13T10:13:16+02:00krausArray of distributions containing FROMFILEThis won't work properly because e.g. the number of particles in a FROMFILE distribution is fixed. Thus when computing the number of particles the other distributions should contain we have first to subtract the number of particles in th...This won't work properly because e.g. the number of particles in a FROMFILE distribution is fixed. Thus when computing the number of particles the other distributions should contain we have first to subtract the number of particles in the FROMFILE distributions.OPAL 1.6.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/128Let each distribution in array of distributions have its own offset in R and P.2017-07-15T20:33:10+02:00krausLet each distribution in array of distributions have its own offset in R and P.When providing an array of distribution and each distribution has its own OFFSET{X|Y|Z|PX|PY|PZ} then, so far, all distributions use the offsets of the first distribution.When providing an array of distribution and each distribution has its own OFFSET{X|Y|Z|PX|PY|PZ} then, so far, all distributions use the offsets of the first distribution.OPAL 1.6.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/127Bug in BorisPusher ParallelTTracker?2017-07-12T22:30:10+02:00frey_mBug in BorisPusher ParallelTTracker?Comparing the push part of the Boris-Brunemann algorithm as written in [Toggweiler_BorisIntegrator.pdf](/uploads/1fc710b9496b0bcb9a7def7f505d3fef/Toggweiler_BorisIntegrator.pdf) (pseudo code in Algorithm 2), I noticed that the time step ...Comparing the push part of the Boris-Brunemann algorithm as written in [Toggweiler_BorisIntegrator.pdf](/uploads/1fc710b9496b0bcb9a7def7f505d3fef/Toggweiler_BorisIntegrator.pdf) (pseudo code in Algorithm 2), I noticed that the time step ```dt```, respectively ```h``` in the paper, is missing. Is this on purpose or is it really a bug? I don't know if it's taken care of that in the ParallelTTracker.krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/126Documentation2017-07-12T10:56:47+02:00adelmannDocumentation![image](/uploads/38526391c24562a6608f256bdbc1e23d/image.png)
@ext-mayes_c This seams not a fatal error, with "Q" the manual compiles.
Chris is getting
! Misplaced \noalign.
\hline ->\noalign
{\ifnum 0=`}\f...![image](/uploads/38526391c24562a6608f256bdbc1e23d/image.png)
@ext-mayes_c This seams not a fatal error, with "Q" the manual compiles.
Chris is getting
! Misplaced \noalign.
\hline ->\noalign
{\ifnum 0=`}\fi \hrule \@height \arrayrulewidth \futurelet...
l.72 \hline
OPAL 1.9.xadelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/125Vector of time steps: error in the parser2017-07-13T09:32:41+02:00Valeria RizzoglioVector of time steps: error in the parser[PROSCAN-G3-230.in](/uploads/0f541b042bd39fdf2fe62688529cc406/PROSCAN-G3-230.in)
If I track the particles using a vector of time steps:
```
TRACK, LINE=BEAMLINE_TOT,
BEAM=BEAM_G3_LA1,
MAXSTEPS={5e+08,5e+08,5e+08},
...[PROSCAN-G3-230.in](/uploads/0f541b042bd39fdf2fe62688529cc406/PROSCAN-G3-230.in)
If I track the particles using a vector of time steps:
```
TRACK, LINE=BEAMLINE_TOT,
BEAM=BEAM_G3_LA1,
MAXSTEPS={5e+08,5e+08,5e+08},
DT={5*PICOSECONDS,1*PICOSECONDS,5*PICOSECOND},
ZSTOP={6.145,6.75,16}OPAL 1.6.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/123No stat-file output in case of MTS tracking2017-07-05T12:12:53+02:00frey_mNo stat-file output in case of MTS trackingRunning the regression test [RingCyclotronMTS](https://gitlab.psi.ch/OPAL/regression-tests/blob/master/RegressionTests/RingCyclotronMTS/RingCyclotronMTS.in) however with ```nsteps = 2000``` and ```SPTDUMPFREQ = 10``` -- as in the test [R...Running the regression test [RingCyclotronMTS](https://gitlab.psi.ch/OPAL/regression-tests/blob/master/RegressionTests/RingCyclotronMTS/RingCyclotronMTS.in) however with ```nsteps = 2000``` and ```SPTDUMPFREQ = 10``` -- as in the test [RingCyclotron](https://gitlab.psi.ch/OPAL/regression-tests/blob/master/RegressionTests/RingCyclotron/RingCyclotron.in) using RK-4 -- I get only one dump in the RingCyclotronMTS.stat.OPAL 1.9.xfrey_mfrey_m