src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2017-10-09T06:17:32+02:00https://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/124Reimplementation of ParallelCyclotronTracker2020-04-22T12:01:54+02:00frey_mReimplementation of ParallelCyclotronTrackerWe should re-implement the tracker such that it is independent of the integrator in order to avoid duplicated code. Adding new integrators is then also simplified.We should re-implement the tracker such that it is independent of the integrator in order to avoid duplicated code. Adding new integrators is then also simplified.OPAL 1.9.xfrey_mfrey_mhttps://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_mhttps://gitlab.psi.ch/OPAL/src/-/issues/122Attempt to create IpplInfo with argc, argv again.2018-11-25T16:01:27+01:00adelmannAttempt to create IpplInfo with argc, argv again.Brach: scalable-emission and use OPAL in optimiser mode
Warning> Attempt to create IpplInfo with argc, argv again.
Warning> Using previous argc,argv settings.
merlinl01:/gpfs/home/adelmann/scratch/opt-pilot-week/ANL/optLinac-1
use ru...Brach: scalable-emission and use OPAL in optimiser mode
Warning> Attempt to create IpplInfo with argc, argv again.
Warning> Using previous argc,argv settings.
merlinl01:/gpfs/home/adelmann/scratch/opt-pilot-week/ANL/optLinac-1
use runopt-opal.sgeOPAL 2.0.0adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/121Interpolator::getFieldIter: attempt to access non-local2017-07-08T21:59:56+02:00adelmannInterpolator::getFieldIter: attempt to access non-localReproducible error on one core: Interpolator::getFieldIter: attempt to access non-local:
merlinl01:error/25f0fe5c361321294c559e667430d6125c346809_6
Brach: scalable-emissionReproducible error on one core: Interpolator::getFieldIter: attempt to access non-local:
merlinl01:error/25f0fe5c361321294c559e667430d6125c346809_6
Brach: scalable-emissionOPAL 2.0.0frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/154Creation of first generation not optimal when infeasible solutions exist2018-08-03T15:07:58+02:00snuverink_jjochem.snuverink@psi.chCreation of first generation not optimal when infeasible solutions existSay we have a problem where a large number of solutions do not return proper objective values. In the first generation opt-pilot dispatches `n` jobs, where `n = initialPopulation`. When say 50% give an infeasible solution, then `n/2` job...Say we have a problem where a large number of solutions do not return proper objective values. In the first generation opt-pilot dispatches `n` jobs, where `n = initialPopulation`. When say 50% give an infeasible solution, then `n/2` jobs are dispatched of which 50% fail, then `n/4` are dispatched, etc., until the full population has a solution.
This will mean that many cores are idle.
It would be better to dispatch as many jobs as possible (nr of cores) until there are more than `n` feasible solutions.snuverink_jjochem.snuverink@psi.chfrey_msnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/120Particle Termination2019-12-12T23:16:08+01:00winklehner_dParticle TerminationHi,
Anybody else noticing that particles are not terminated correctly anymore if Bin is set to -1 (which is the usual way in the CyclotronTracker) since last week's commits to the head? It still works for the BoundaryGeometry, but not, f...Hi,
Anybody else noticing that particles are not terminated correctly anymore if Bin is set to -1 (which is the usual way in the CyclotronTracker) since last week's commits to the head? It still works for the BoundaryGeometry, but not, for example, for the Cyclotron outer boundaries. I think it might have to do with removing all the boundp's
Best,
DanielOPAL-2.2.0winklehner_dwinklehner_dhttps://gitlab.psi.ch/OPAL/src/-/issues/153Constraints validation fails2017-11-08T10:25:08+01:00frey_mConstraints validation failsI tried out the constraints with the condition that the number of particles should be greater than zero.
```
...
//c1: CONSTRAINT, EXPR="numParticles > 0";
//objs: OBJECTIVES=(dpeak1,dpeak2,dpeak3_5);
//constrs: CONSTRAINTS = (c1);...I tried out the constraints with the condition that the number of particles should be greater than zero.
```
...
//c1: CONSTRAINT, EXPR="numParticles > 0";
//objs: OBJECTIVES=(dpeak1,dpeak2,dpeak3_5);
//constrs: CONSTRAINTS = (c1);
//opt: OPTIMIZE, OBJECTIVES = objs, DVARS = dvars, CONSTRAINTS = constrs;
...
```
This is a dummy constraint since in our simulation we lose no particles. 'numParticles' is part of the SDDS file, i.e. *.stat file (OPAL 1.6).
For some reason -- I do not understand -- I get following message in [opt.trace.0](/uploads/71d42dd821ddfcc95d3fa165cb5ef5ad/opt.trace.0):
```
invalid individual, constraint "c1" failed to yield true; result: 0
```
OPT-Pilot never finds a solution. Without the constraint, it works fine. The template and data file attached:
[Ring.tmpl](/uploads/c94789c099aa26a0d20acd0daca29f93/Ring.tmpl)
[Ring.data](/uploads/95c2dac28b6a7785e708cc363977957c/Ring.data)
Best,
Matthias :bug:snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/119Periodic BC's2021-07-06T10:08:36+02:00winklehner_dPeriodic BC'sIt seems that when I set BCFFTT = PERIODIC, not only the z-direction but all directions are automatically set to periodic boundary conditions. @uldis_l I am assuming "UL" in the comment of PartBunch::setBCForDCBeam() is you. Was there a ...It seems that when I set BCFFTT = PERIODIC, not only the z-direction but all directions are automatically set to periodic boundary conditions. @uldis_l I am assuming "UL" in the comment of PartBunch::setBCForDCBeam() is you. Was there a particular reason to do this? In my understanding, a DC beam would have open BC in x and y and periodic BC in z.
In addition, the manual calls the parameters "BCFFTZ" and "PARFFTZ" but OPAL tells me those don't exist and throws an Exception, I have to use "BCFFTT" and "PARFFTT". Just a minor bug.adelmannkrausadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/118ParallelCyclotronTracker::applyPluginElements2017-07-27T08:32:10+02:00frey_mParallelCyclotronTracker::applyPluginElementsIn ParallelCyclotronTracker the particles are mapped several times from local to global coordinates and vice versa. The PartBunch::boundp() operation where the particles are redistributed among the cores is always performed in local coor...In ParallelCyclotronTracker the particles are mapped several times from local to global coordinates and vice versa. The PartBunch::boundp() operation where the particles are redistributed among the cores is always performed in local coordinates except in during the function call ParallelCyclotronTracker::applyPluginElements in case the boolean flag_stripper being true
(line 3389 ff.).
```
if(((*sindex)->first) == ElementBase::STRIPPER) {
bool flag_stripper = (static_cast<Stripper *>(((*sindex)->second).second))
-> checkStripper(itsBunch, turnnumber_m, itsBunch->getT() * 1e9, dt);
if(flag_stripper) {
itsBunch->boundp();
*gmsg << "* Total number of particles after stripping = " << itsBunch->getTotalNum() << endl;
}
}
```
The workflow of ParallelCyclotronTracker::Tracker_Generic()
```
...
ParallelCyclotronTracker::initDistInGlobalFrame(); // (line 1235) --> particle in global coordinates
ParallelCyclotronTracker::applyPluginElements(dt); // (line 1285) --> PartBunch::boundp() in global coordinates !!!
...
// start tracking
```
Shouldn't the PartBunch::bounp() operation always be performed in local coordinates?
Best,
Matthiaswinklehner_dwinklehner_dhttps://gitlab.psi.ch/OPAL/src/-/issues/117Distribution.cpp2017-07-24T10:29:37+02:00adelmannDistribution.cppCan you explain me the additional particles
we add at line 518 and the for loop starting
at line 531.Can you explain me the additional particles
we add at line 518 and the for loop starting
at line 531.OPAL 1.9.xkrauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/116CollimatorPhysics::EnergyLoss2021-02-16T08:39:33+01:00adelmannCollimatorPhysics::EnergyLossis hard coded for protons. Need also make clear in the manual (exception in code) that electrons are not supported.is hard coded for protons. Need also make clear in the manual (exception in code) that electrons are not supported.OPAL 2021.1ext-calvo_ppedro.calvo@ciemat.esext-calvo_ppedro.calvo@ciemat.eshttps://gitlab.psi.ch/OPAL/src/-/issues/115Emission2017-06-17T20:38:35+02:00adelmannEmissionEmission is very slow and hardly can be used above 1E7 particles. Reason the algorithm does not scale.Emission is very slow and hardly can be used above 1E7 particles. Reason the algorithm does not scale.OPAL 1.9.xadelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/114Help command gives error2017-06-17T20:38:35+02:00adelmannHelp command gives error```
==>help, source;
1 help, source;
OPAL>
OPAL> The "SOURCE" element defines a Source.
Attributes:
OPAL> string TYPE The element design type (the project name)
OPAL> string APERTURE The ...```
==>help, source;
1 help, source;
OPAL>
OPAL> The "SOURCE" element defines a Source.
Attributes:
OPAL> string TYPE The element design type (the project name)
OPAL> string APERTURE The element aperture
OPAL> real L The element length in m
OPAL> real ELEMEDGE The position of the element in path length (in m)
OPAL> string WAKEF Defines the wake function
Error>
Error> *** Error:
Error> *** in line 1 of file "standard input":
Error> HELP,SOURCE;
Error> basic_string::_M_create
Error>
```OPAL 1.9.xkrauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/113Static cuda libraries2017-07-24T10:29:38+02:00Uldis LocansStatic cuda librarieslink to static cuda libraries when compiling with DKSlink to static cuda libraries when compiling with DKSOPAL 1.9.x