src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2017-07-27T08:32:10+02:00https://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/105RectangularDomain::getBoundaryStencil typo2017-06-17T20:38:34+02:00snuverink_jjochem.snuverink@psi.chRectangularDomain::getBoundaryStencil typolines [51-53](https://gitlab.psi.ch/OPAL/src/blob/master/src/Solvers/RectangularDomain.cpp#L51):
```c++
S = -hr[0] * hr[2] / hr[1];
F = -hr[0] * hr[1] / hr[2];
S = -hr[0] * hr[1] / hr[2];
```
The second `S` assignment is lik...lines [51-53](https://gitlab.psi.ch/OPAL/src/blob/master/src/Solvers/RectangularDomain.cpp#L51):
```c++
S = -hr[0] * hr[2] / hr[1];
F = -hr[0] * hr[1] / hr[2];
S = -hr[0] * hr[1] / hr[2];
```
The second `S` assignment is likely a typo and should be `B`, but it would be good if someone could check the formulas.OPAL 1.6.1https://gitlab.psi.ch/OPAL/src/-/issues/104--version or --help crashes OPAL2017-06-17T20:38:34+02:00adelmann--version or --help crashes OPAL--version or --help crashes OPAL--version or --help crashes OPALOPAL 1.9.xadelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/102PSDUMPFRAME report is wrong in OPTIOn TELL=TRUE2017-06-17T20:38:34+02:00adelmannPSDUMPFRAME report is wrong in OPTIOn TELL=TRUEThe following trivial OPAL input file:
```
OPTION, TELL=TRUE;
OPTION, PSDUMPFRAME=REFERENCE;
QUIT;
```
shows
OPAL> Current settings of options:
OPAL> OPTION,ECHO=FALSE,INFO=TRUE,TRACE=FALSE,VERIFY=FALSE,WARN=TRUE,
OPAL> SEED=1.2...The following trivial OPAL input file:
```
OPTION, TELL=TRUE;
OPTION, PSDUMPFRAME=REFERENCE;
QUIT;
```
shows
OPAL> Current settings of options:
OPAL> OPTION,ECHO=FALSE,INFO=TRUE,TRACE=FALSE,VERIFY=FALSE,WARN=TRUE,
OPAL> SEED=1.23457e+08,TELL=TRUE,PSDUMPFREQ=10,STATDUMPFREQ=10,
OPAL> PSDUMPEACHTURN=FALSE,PSDUMPLOCALFRAME=FALSE,**PSDUMPFRAME="GLOBAL"**,
OPAL> SPTDUMPFREQ=1,REPARTFREQ=10,REBINFREQ=100,SCSOLVEFREQ=1,
OPAL> MTSSUBSTEPS=1,REMOTEPARTDEL=0,SCAN=FALSE,RHODUMP=FALSE,
OPAL> EBDUMP=FALSE,CSRDUMP=FALSE,AUTOPHASE=0,PPDEBUG=FALSE,
OPAL> SURFDUMPFREQ=-1,NUMBLOCKS=0,RECYCLEBLOCKS=0,NLHS=1,CZERO=FALSE,
OPAL> RNGTYPE="RANDOM",SCHOTTKYCORR=FALSE,SCHOTTKYRENO=-1,ENABLEHDF5=TRUE,
OPAL> ASCIIDUMP=FALSE,BOUNDPDESTROYFQ=10,BEAMHALOBOUNDARY=0,
OPAL> CLOTUNEONLY=FALSE,VERSION=10000;OPAL 1.6.1adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/98Placement of elements in 3D coordinates not possible anymore2017-06-17T20:38:34+02:00krausPlacement of elements in 3D coordinates not possible anymorePlacement of elements in 3D coordinates (see attachment) was possible, this isn't the case anymore.
This issue has to do with the fact that I added the attribute ELEMEDGE and introduced access methods.
[Niowave_first_korrektur.dat](/u...Placement of elements in 3D coordinates (see attachment) was possible, this isn't the case anymore.
This issue has to do with the fact that I added the attribute ELEMEDGE and introduced access methods.
[Niowave_first_korrektur.dat](/uploads/ad152c3a3e13fa0ec231105ec4711817/Niowave_first_korrektur.dat)[Banana_ref.in](/uploads/68db2ec88393f764cfebd520466bf2de/Banana_ref.in)[ez_normalizedcathodepos_4.txt](/uploads/8015defbc8c4082e95296f6ff3133670/ez_normalizedcathodepos_4.txt)OPAL 1.9.xkrauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/96DKS 1.1.0 for OPAL 1.6 branch2017-06-17T20:38:34+02:00gsellDKS 1.1.0 for OPAL 1.6 branchDKS 1.1.0 must be used in OPAL 1.6. So we have the same toolchain for OPAL 1.6 and masterDKS 1.1.0 must be used in OPAL 1.6. So we have the same toolchain for OPAL 1.6 and masterhttps://gitlab.psi.ch/OPAL/src/-/issues/94Error detected by function "FileStream::fillLine()"2017-06-17T20:38:34+02:00ganz_pError detected by function "FileStream::fillLine()"I ran some simulations and at a certain point on all simulations gave me following error:
[Terminal.out](/uploads/8d537807dbf8586b2ec6f08e87a708ae/Terminal.out)
I've tried to vary the opal command (with and without `mpirun`, or `--use-d...I ran some simulations and at a certain point on all simulations gave me following error:
[Terminal.out](/uploads/8d537807dbf8586b2ec6f08e87a708ae/Terminal.out)
I've tried to vary the opal command (with and without `mpirun`, or `--use-dks`), but all files, even files which already ran well gave me that error.
The Opal Version I use is: `OPAL/1.5.1-20170217`
Example .in file:
[100MeV_InvQuad_1_NoColl.in](/uploads/44d81f1f63a2ffffc828556e7944cfdb/100MeV_InvQuad_1_NoColl.in)OPAL 1.6.0adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/91Documentation for attribute DESIGNENERGY of kickers missing2017-06-17T20:38:34+02:00krausDocumentation for attribute DESIGNENERGY of kickers missingOPAL 2.0.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/90OPAL-Cycl - COMET2017-06-17T20:38:34+02:00adelmannOPAL-Cycl - COMETI have been using a locally compiled code with a version number 1.2.1 SVN. I have also run the program through module load with a version number 1.4.3. The loss files are basically the same.
Attached is the input file vc.in. Two phase...I have been using a locally compiled code with a version number 1.2.1 SVN. I have also run the program through module load with a version number 1.4.3. The loss files are basically the same.
Attached is the input file vc.in. Two phase slits CMA1 and CMA2 work quite well. However, the loss data from the vertical collimators, for example, from the pair VC7 and VC8, often register the same particles.
[vc.in](/uploads/8630def3fe171c14cc64887dc9991232/vc.in)OPAL 1.6.0adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/86OPAL-1.6 check DKS version used to compile2017-06-17T20:38:34+02:00Uldis LocansOPAL-1.6 check DKS version used to compileOPAL-1.6 does not check which DKS version is used so compilation errors are possible due to the wrong versionsOPAL-1.6 does not check which DKS version is used so compilation errors are possible due to the wrong versionsOPAL 1.6.0https://gitlab.psi.ch/OPAL/src/-/issues/85Error in compiling OPAL-1.6 with -DENABLE_DKS=12017-06-17T20:38:34+02:00Valeria RizzoglioError in compiling OPAL-1.6 with -DENABLE_DKS=1I have the following modules loaded:
```
Currently Loaded Modulefiles:
1) gcc/5.4.0 4) hdf5/1.8.18 7) trilinos/12.10.1 10) OpenBLAS/0.2.19 13) opal-toolschain/1.6
2) openmpi/1.10.4 5) H5hut/2.0...I have the following modules loaded:
```
Currently Loaded Modulefiles:
1) gcc/5.4.0 4) hdf5/1.8.18 7) trilinos/12.10.1 10) OpenBLAS/0.2.19 13) opal-toolschain/1.6
2) openmpi/1.10.4 5) H5hut/2.0.0rc3 8) root/6.08.02 11) cuda/8.0.44
3) boost/1.62.0 6) gsl/2.2.1 9) cmake/3.6.3 12) dks/1.0.1
```
and I got the following error message:
```
/home/scratch/opal/src/src/Classic/Solvers/CollimatorPhysics.cpp: In member function ‘void CollimatorPhysics::setupCollimatorDKS(PartBunch&, Degrader*, size_t)’:
/home/scratch/opal/src/src/Classic/Solvers/CollimatorPhysics.cpp:1094:52: error: no matching function for call to ‘DKSBase::callInitRandoms(int&, int&)’
dksbase.callInitRandoms(size, Options::seed);
^
In file included from /home/scratch/opal/src/ippl/src/Utility/IpplInfo.h:59:0,
from /home/scratch/opal/src/ippl/src/Message/Message.hpp:29,
from /home/scratch/opal/src/ippl/src/Message/Message.h:618,
from /home/scratch/opal/src/ippl/src/AppTypes/Vektor.h:16,
from /home/scratch/opal/src/src/Classic/Algorithms/Vektor.h:6,
from /home/scratch/opal/src/src/Classic/Solvers/CollimatorPhysics.hh:13,
from /home/scratch/opal/src/src/Classic/Solvers/CollimatorPhysics.cpp:9:
/opt/psi/MPI/dks/1.0.1/openmpi/1.10.4/gcc/5.4.0/include/DKSBase.h:1077:7: note: candidate: int DKSBase::callInitRandoms(int)
int callInitRandoms(int size);
^
/opt/psi/MPI/dks/1.0.1/openmpi/1.10.4/gcc/5.4.0/include/DKSBase.h:1077:7: note: candidate expects 1 argument, 2 provided
[ 60%] Building CXX object src/CMakeFiles/OPALib.dir/Classic/Utilities/DivideError.cpp.o
```OPAL 1.6.0https://gitlab.psi.ch/OPAL/src/-/issues/81Segfault within Surfacephysics2017-06-17T20:38:35+02:00krausSegfault within SurfacephysicsWith input file [Degrader_70.in](/uploads/4971dc04fcdf6cbee66b92aea9f83832/Degrader_70.in) I got a segmentation fault. Suddenly an incredibly large number of additional particles were generated, then OPAL crashed. Couldn't reproduce it a...With input file [Degrader_70.in](/uploads/4971dc04fcdf6cbee66b92aea9f83832/Degrader_70.in) I got a segmentation fault. Suddenly an incredibly large number of additional particles were generated, then OPAL crashed. Couldn't reproduce it anymore, but something isn't correct.OPAL 2.0.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/76Make normalization of 3D fieldmaps optional2017-06-17T20:38:35+02:00krausMake normalization of 3D fieldmaps optionalCurrently the z-component of the (electric, if present) field of a 3D fieldmaps is normalized. The user should be able to disable this normalizaton to simulate e.g. transverse deflecting cavities.Currently the z-component of the (electric, if present) field of a 3D fieldmaps is normalized. The user should be able to disable this normalizaton to simulate e.g. transverse deflecting cavities.OPAL 2.0.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/70Regressiontest RingCyclotronMatched failed2017-08-11T10:50:28+02:00adelmannRegressiontest RingCyclotronMatched failedRegressiontest RingCyclotronMatched is failing with OPAL-1.5.x
```
OPAL{0}> *** User error detected by function "ClosedOrbitFinder::findOrbit()"
OPAL{0}> *** in line 84 of file "RingCyclotronMatched.in" at end of statement:
OPAL{0}>...Regressiontest RingCyclotronMatched is failing with OPAL-1.5.x
```
OPAL{0}> *** User error detected by function "ClosedOrbitFinder::findOrbit()"
OPAL{0}> *** in line 84 of file "RingCyclotronMatched.in" at end of statement:
OPAL{0}> RUN,METHOD="CYCLOTRON-T",BEAM=BEAM1,FIELDSOLVER=FS1,DISTRIBUTION=DIST1;
OPAL{0}> p_{r}^2 > p^{2} (defined in Gordon paper) --> Square root of negative number.
```OPAL 1.9.xfrey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/69VariableRFCavity is failing tests2017-06-17T20:38:35+02:00ext-rogers_cVariableRFCavity is failing testsTest incorrectly returns True during calls to apply (indicating particles "out of aperture" when they should not be)Test incorrectly returns True during calls to apply (indicating particles "out of aperture" when they should not be)ext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/63Unit tests throw segmentation fault2017-06-17T20:38:35+02:00ext-rogers_cUnit tests throw segmentation faultLooks like somehow the std::cout or std::cerr got set to NULL. I note there is some blobs of code which massages the output buffers to shut up noisy tests. This is handled on a per-test basis. and somewhere I think something went wrong. ...Looks like somehow the std::cout or std::cerr got set to NULL. I note there is some blobs of code which massages the output buffers to shut up noisy tests. This is handled on a per-test basis. and somewhere I think something went wrong. I would do this as a test fixture allowing code to be implemented once per test. Nb test fixtures docs are in here:
https://github.com/google/googletest/blob/master/googletest/docs/Primer.mdext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/59OpalRing components2017-06-17T20:38:35+02:00ext-rogers_cOpalRing componentsLooks like something changed in the way classic AbsBeamline/Component is handled. Whenever I do a field lookup I get a segv. On digging, I see that there is a aperture_m sitting somewhere up the inheritance tree that is not set by defau...Looks like something changed in the way classic AbsBeamline/Component is handled. Whenever I do a field lookup I get a segv. On digging, I see that there is a aperture_m sitting somewhere up the inheritance tree that is not set by default - and field lookups now seem to throw a segv if not set. This breaks the unit tests.
Fix would be to either:
* Check for NULL in aperture_m before assuming it is set
* Set it by default
If it were anywhere else, I would do a NULL check. But because it is right in the inner tracking loop, my preference would be to set aperture_m to a stupid default value (e.g. very large rectangular aperture).ext-rogers_cext-rogers_chttps://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/14Particles stored in trackOrbit.dat2018-01-05T08:58:48+01:00Valeria RizzoglioParticles stored in trackOrbit.datAccording to the OPAL manual (pag. 40):
**Multi-particle tracking mode**
The intermediate phase space data of centeral particle (with ID of 0) and an off-centering particle (with ID of 1) are stored in an ASCII file.
Concernin...According to the OPAL manual (pag. 40):
**Multi-particle tracking mode**
The intermediate phase space data of centeral particle (with ID of 0) and an off-centering particle (with ID of 1) are stored in an ASCII file.
Concerning the particle with *ID0*:
* particle position is not updated in case OFFSETY > 0 is set in the distribution definition. The tracking of this particle does not reflect the beam behavior (because of the offset)
* Is the general idea: ID0 particle = reference particle?
Concerning the particle with *ID1*:
* ***Distribution from file:*** the second particle in the distribution file is used as ID1
* ***Generated distribution:*** It seems that a random particle from the distribution is set as ID1
A possible suggestion:
* ***Distribution from file:*** the first and the second particle in the file are used as ID0 and ID1, respectively. The user is completely free to decide which particles track.
* ***Generated distribution (Option 1):*** ID0 is by default assigned to the reference particle (with updated offset). An option can be added to the DISTRIBUTION command where the user can specify which particle uses as ID1 (ie: DISPERSION, CENTROID or USERDEF or NULL = not stored). This means that the first two particles generated by OPAL are replaced with ID0 (reference) and ID1, if option NULL is not specified.
* ***Generated distribution (Option 2):*** An option can be added to the DISTRIBUTION command where the user can specify which particle uses as ID0 and ID1 (ie: DISPERSION, CENTROID or USERDEF or or NULL = not stored)
A possible problem could arise in case of multi-distribution or vector of distributionOPAL 1.5.1adelmannadelmannhttps://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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/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/106Segfault in case of Material at beginning of beamline2017-07-24T10:29:37+02:00frey_mSegfault in case of Material at beginning of beamlineWe run [sim.in](/uploads/94c1f0db20f572ae97a6a320574d9545/sim.in).
Error output:
```
OPAL>
OPAL> --- BEGIN FIELD LIST ---------------------------------------------------------------
OPAL>
OPAL> --- 0.2 m -- 0.200228 m -- has surface...We run [sim.in](/uploads/94c1f0db20f572ae97a6a320574d9545/sim.in).
Error output:
```
OPAL>
OPAL> --- BEGIN FIELD LIST ---------------------------------------------------------------
OPAL>
OPAL> --- 0.2 m -- 0.200228 m -- has surface physics ------------------------------------
OPAL> DMA_DEG1
OPAL> --- 0.200228 m -- 1.20023 m -- -----------------------------------------------------
OPAL> D1
OPAL>
OPAL> --- END FIELD LIST -----------------------------------------------------------------
OPAL>
[opalrunner:18498] *** Process received signal ***
[opalrunner:18498] Signal: Segmentation fault (11)
[opalrunner:18498] Signal code: Address not mapped (1)
[opalrunner:18498] Failing at address: 0x30
[opalrunner:18498] [ 0] /lib64/libpthread.so.0[0x32ea20f7e0]
[opalrunner:18498] [ 1] opal(_ZN12OpalBeamline14switchElementsERKdS1_S1_RKb+0x1cf)[0xf1829f]
[opalrunner:18498] [ 2] opal[0x10758bd]
[opalrunner:18498] [ 3] opal(_ZN16ParallelTTracker21executeDefaultTrackerEv+0x2c0)[0x107c520]
[opalrunner:18498] [ 4] opal(_ZN16ParallelTTracker7executeEv+0x1f)[0x107d35f]
[opalrunner:18498] [ 5] opal(_ZN8TrackRun7executeEv+0x751)[0x1043b51]
[opalrunner:18498] [ 6] opal(_ZNK10OpalParser7executeEP6ObjectRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x35)[0xcac6c5]
[opalrunner:18498] [ 7] opal(_ZNK10OpalParser11parseActionER9Statement+0x11a)[0xcb062a]
[opalrunner:18498] [ 8] opal(_ZNK10OpalParser5parseER9Statement+0x186)[0xcb0076]
[opalrunner:18498] [ 9] opal(_ZNK10OpalParser3runEv+0x2c)[0xcb158c]
[opalrunner:18498] [10] opal(_ZN8TrackCmd7executeEv+0x343)[0xd63cb3]
[opalrunner:18498] [11] opal(_ZNK10OpalParser7executeEP6ObjectRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x35)[0xcac6c5]
[opalrunner:18498] [12] opal(_ZNK10OpalParser11parseActionER9Statement+0x11a)[0xcb062a]
[opalrunner:18498] [13] opal(_ZNK10OpalParser5parseER9Statement+0x186)[0xcb0076]
[opalrunner:18498] [14] opal(_ZNK10OpalParser3runEv+0x2c)[0xcb158c]
[opalrunner:18498] [15] opal(_ZNK10OpalParser3runEP11TokenStream+0x6a)[0xcb0a8a]
[opalrunner:18498] [16] opal(main+0x8e8)[0xc3f858]
[opalrunner:18498] [17] /lib64/libc.so.6(__libc_start_main+0xfd)[0x32e961ed1d]
[opalrunner:18498] [18] opal[0xc36cb5]
[opalrunner:18498] *** End of error message ***
--------------------------------------------------------------------------
mpirun noticed that process rank 0 with PID 18498 on node opalrunner exited on signal 11 (Segmentation fault).
```
We doesn't crash when we add a drift in front of the material.OPAL 1.6.1adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/103Overlap of field maps OPAL-cycl2017-07-24T10:29:37+02:00adelmannOverlap of field maps OPAL-cyclCommunicated by @zhang_h
Case maps for COMET.
We have four non-superpose RF maps and one superpose electrostatic map. The read-in loop could be stopped at the third RF map, without reading the electrostatic map. We may put the ...Communicated by @zhang_h
Case maps for COMET.
We have four non-superpose RF maps and one superpose electrostatic map. The read-in loop could be stopped at the third RF map, without reading the electrostatic map. We may put the electrostatic map in front, but it could cause other problem.OPAL 1.9.xadelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/72Removal of data from a particle without reducing number of particles2017-07-24T10:29:37+02:00krausRemoval of data from a particle without reducing number of particlesThis leads to wrong results: https://gitlab.psi.ch/OPAL/src/blob/OPAL-1.6/src/Classic/Algorithms/PartBunch.cpp#L1930 . This is as if replacing position and momentum with zero.
Please remember to add the patch that solves this issue to ...This leads to wrong results: https://gitlab.psi.ch/OPAL/src/blob/OPAL-1.6/src/Classic/Algorithms/PartBunch.cpp#L1930 . This is as if replacing position and momentum with zero.
Please remember to add the patch that solves this issue to the master as well.adelmannadelmannhttps://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/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.xhttps://gitlab.psi.ch/OPAL/src/-/issues/111Move download page from Trac to gitlab2017-07-24T10:29:38+02:00krausMove download page from Trac to gitlabCurrently the download page is a page in the old Trac instance. Move it to gitlab.Currently the download page is a page in the old Trac instance. Move it to gitlab.OPAL 1.6.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/109OPAL does not compile with AMR Solver and unit tests2017-07-24T10:29:38+02:00snuverink_jjochem.snuverink@psi.chOPAL does not compile with AMR Solver and unit testsCompiling OPAL with ENABLE_AMR_SOLVER=1 and DBUILD_OPAL_UNIT_TESTS=1 gives the following compile error:
```
/home/scratch/OPAL/src/tests/opal_src/Distribution/GaussTest.cpp: In member function ‘virtual void GaussTest_FullSigmaTest1_Tes...Compiling OPAL with ENABLE_AMR_SOLVER=1 and DBUILD_OPAL_UNIT_TESTS=1 gives the following compile error:
```
/home/scratch/OPAL/src/tests/opal_src/Distribution/GaussTest.cpp: In member function ‘virtual void GaussTest_FullSigmaTest1_Test::TestBody()’:
<command-line>:0:6: error: expected unqualified-id before numeric constant
/home/scratch/OPAL/src/tests/opal_src/Distribution/GaussTest.cpp:74:15: note: in expansion of macro ‘OPAL’
OpalData *OPAL = OpalData::getInstance();
^
```
This is because OPAL is defined as preprocessor macro within CMake (with value 1):
```
[ 93%] Building CXX object tests/CMakeFiles/opal_unit_tests.dir/opal_src/Distribution/GaussTest.cpp.o
g++ -DBL_FORT_USE_UNDERSCORE -DBL_Linux -DBL_NOLINEVALUES -DBL_PARALLEL_IO -DBL_SPACEDIM=3 -DBL_USE_DOUBLE -DBL_USE_MPI -DMG_USE_F90_SOLVERS -DMG_USE_FBOXLIB -DNDEBUG -DOPAL .... tests/opal_src/Distribution/GaussTest.cpp
```
This is done in [CMakeModules/CCSEOptions.cmake](https://gitlab.psi.ch/OPAL/src/blob/master/CMakeModules/CCSEOptions.cmake#L74)
:
`list(APPEND BL_DEFINES "OPAL")`
I don't see a reason to add OPAL here since afaik it is not used anywhere as such.
That said it might good to adopt [camelCase for the variable name](https://gitlab.psi.ch/OPAL/src/wikis/for-developers#28-method-argument-and-local-variable-names).https://gitlab.psi.ch/OPAL/src/-/issues/108Revise macros such as DBG_SCALARFIELD and replace them with an Option command2017-07-24T10:29:38+02:00snuverink_jjochem.snuverink@psi.chRevise macros such as DBG_SCALARFIELD and replace them with an Option commandCompiling OPAL with the option DBG_SCALARFIELD gives the following compiler error:
```
src/Classic/Algorithms/PartBunch.cpp: In member function ‘void PartBunch::computeSelfFields(int)’:
/home/scratch/OPAL/src/src/Classic/Algorithms/...Compiling OPAL with the option DBG_SCALARFIELD gives the following compiler error:
```
src/Classic/Algorithms/PartBunch.cpp: In member function ‘void PartBunch::computeSelfFields(int)’:
/home/scratch/OPAL/src/src/Classic/Algorithms/PartBunch.cpp:715:29: error: ‘rmin’ was not declared in this scope
*gmsg << (rmin(0) - origin(0)) / spacing(0) << "\t"
^
```
This was introduced in commit https://gitlab.psi.ch/OPAL/src/commit/595b4b83818596b5f7a72e086cbbda4325f70aa8#852edcbb7804c7416aa51f7264a7a36fc1fa3fef_781_683snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/107keyword register2017-07-24T10:29:38+02:00snuverink_jjochem.snuverink@psi.chkeyword registerThe source code contains at several locations the keyword `register`. This is of no use anymore (see e.g. http://www.drdobbs.com/keywords-that-arent-or-comments-by-anoth/184403859). And with gcc compilers this might also gives some warni...The source code contains at several locations the keyword `register`. This is of no use anymore (see e.g. http://www.drdobbs.com/keywords-that-arent-or-comments-by-anoth/184403859). And with gcc compilers this might also gives some warnings:
```
src/Solvers/TaperDomain.cpp:89:66: warning: address requested for ‘y’, which is declared ‘register’ [-Wextra]
IntersectXDir.insert(std::pair<int, double>(y, xd));
```
Therefore, I propose to remove this keyword from the code everywhere.snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/101OPAL version2017-07-24T10:29:38+02:00frey_mOPAL versionAn additional flag at runtime of OPAL would be nice that returns the current version, i.e.
```
matthias@R2-D2:~$ opal --version
```An additional flag at runtime of OPAL would be nice that returns the current version, i.e.
```
matthias@R2-D2:~$ opal --version
```2017-05-02https://gitlab.psi.ch/OPAL/src/-/issues/99When APVETO=TRUE set phase relative to arrival time2017-07-24T10:29:38+02:00krausWhen APVETO=TRUE set phase relative to arrival timeThe phase of a cavity at time $`t`$ is given by
```math
\varphi (t) = \omega \cdot t + \varphi_{\text{LAG}} + \varphi_0.
```
When running the auto-phasing algorithm we set the phase of a cavity relative to the phase at which a cavity...The phase of a cavity at time $`t`$ is given by
```math
\varphi (t) = \omega \cdot t + \varphi_{\text{LAG}} + \varphi_0.
```
When running the auto-phasing algorithm we set the phase of a cavity relative to the phase at which a cavity yields maximal energy. Thus $`\varphi_0 = \varphi_{\text{max}}`$. In some cases we want or have to set APVETO=TRUE. Currently we set $`\varphi_0 = 0`$ but we should set it such that $`\varphi (t_{\text{ELEMEDGE}}) = 0`$. Here $`t_{\text{ELEMEDGE}}`$ is the time at which the reference particle enters the element (either physically or alternatively the region in which field of the cavity is non-zero).OPAL 2.0.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/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/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/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/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/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/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/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/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/147Beam frequency unit treated inconsistently2017-10-19T13:47:29+02:00snuverink_jjochem.snuverink@psi.chBeam frequency unit treated inconsistentlyAccording to the manual the beam frequency `BFREQ` is in MHz.
This is indeed the case for most important places:
* https://gitlab.psi.ch/OPAL/src/blob/master/src/Structure/Beam.cpp#L371
* https://gitlab.psi.ch/OPAL/src/blob/master/src/...According to the manual the beam frequency `BFREQ` is in MHz.
This is indeed the case for most important places:
* https://gitlab.psi.ch/OPAL/src/blob/master/src/Structure/Beam.cpp#L371
* https://gitlab.psi.ch/OPAL/src/blob/master/src/Track/TrackRun.cpp#L604
* https://gitlab.psi.ch/OPAL/src/blob/master/src/Track/TrackRun.cpp#L641
However in quite a few places it is treated or mentioned as Hz:
* ~~https://gitlab.psi.ch/OPAL/src/blob/master/src/Structure/Beam.cpp#L74~~
* ~~https://gitlab.psi.ch/OPAL/src/blob/master/src/Structure/Beam.cpp#L138~~
* ~~https://gitlab.psi.ch/OPAL/src/blob/master/src/Track/TrackRun.cpp#L935~~
* ~~Some of the documentation~~
* ~~Many of the regression tests, e.g. [Distribution-Binomial-1](https://gitlab.psi.ch/OPAL/regression-tests/blob/master/RegressionTests/Distribution-Binomial-1/Distribution-Binomial-1.in), Distribution-Gauss-1/2, Scan-1, Degrader-1~~OPAL 2.0.0adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/148Check that Enge function goes from 1 to 02017-08-13T10:13:16+02:00krausCheck that Enge function goes from 1 to 0OPAL 1.9.xkrauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/149Coulomb / Rutherford scattering2019-05-11T19:39:59+02:00krausCoulomb / Rutherford scatteringDoes multiplying R twice with 1000 really make sense?
- [first time here](https://gitlab.psi.ch/OPAL/src/blob/OPAL-1.6/src/Classic/Solvers/CollimatorPhysics.cpp#L773)
- [second time here](https://gitlab.psi.ch/OPAL/src/blob/OPAL-1.6/...Does multiplying R twice with 1000 really make sense?
- [first time here](https://gitlab.psi.ch/OPAL/src/blob/OPAL-1.6/src/Classic/Solvers/CollimatorPhysics.cpp#L773)
- [second time here](https://gitlab.psi.ch/OPAL/src/blob/OPAL-1.6/src/Classic/Solvers/CollimatorPhysics.cpp#L792)
@adelmann @baumgarten ?krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/150Add a user definable transverse limit to degrader class2017-08-12T18:17:25+02:00krausAdd a user definable transverse limit to degrader classOPAL 1.6.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/151OPAL does not compile with DKS enabled after recent commits2017-08-14T21:21:16+02:00gsellOPAL does not compile with DKS enabled after recent commits@kraus, @uldis_l:
```
59%] Building CXX object src/CMakeFiles/OPALib.dir/Classic/Structure/LossDataSink.cpp.o
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.cpp:38:30: error: ‘const int Coll...@kraus, @uldis_l:
```
59%] Building CXX object src/CMakeFiles/OPALib.dir/Classic/Structure/LossDataSink.cpp.o
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.cpp:38:30: error: ‘const int CollimatorPhysics::numpar’ is not a static data member of ‘class CollimatorPhysics’
const int CollimatorPhysics::numpar = 13;
^
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.cpp: In constructor ‘CollimatorPhysics::CollimatorPhysics(const string&, ElementBase*, std::__cxx11::string&, bool, double)’:
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.cpp:77:7: error: class ‘CollimatorPhysics’ does not have any field named ‘curandInitSet’
, curandInitSet(0)
^
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.cpp:78:7: error: class ‘CollimatorPhysics’ does not have any field named ‘ierr’
, ierr(0)
^
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.cpp:79:7: error: class ‘CollimatorPhysics’ does not have any field named ‘maxparticles’
, maxparticles(0)
^
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.cpp:80:7: error: class ‘CollimatorPhysics’ does not have any field named ‘numparticles’
, numparticles(0)
^
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.cpp:81:7: error: class ‘CollimatorPhysics’ does not have any field named ‘par_ptr’
, par_ptr(NULL)
^
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.cpp:82:7: error: class ‘CollimatorPhysics’ does not have any field named ‘mem_ptr’
, mem_ptr(NULL)
^
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.cpp: In member function ‘void CollimatorPhysics::applyDKS(PartBunch&, size_t)’:
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.cpp:875:58: error: cannot allocate an object of abstract type ‘Degrader’
Degrader deg = dynamic_cast<Degrader *>(element_ref_m);
^
In file included from /home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.hh:16:0,
from /home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.cpp:9:
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/AbsBeamline/Degrader.h:38:7: note: because the following virtual functions are pure within ‘Degrader’:
class Degrader: public Component {
^
In file included from /home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/AbsBeamline/Component.h:26:0,
from /home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.hh:14,
from /home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.cpp:9:
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/AbsBeamline/ElementBase.h:190:29: note: virtual BGeometryBase& ElementBase::getGeometry()
virtual BGeometryBase &getGeometry() = 0;
^
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/AbsBeamline/ElementBase.h:195:35: note: virtual const BGeometryBase& ElementBase::getGeometry() const
virtual const BGeometryBase &getGeometry() const = 0;
^
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/AbsBeamline/ElementBase.h:311:26: note: virtual ElementBase* ElementBase::clone() const
virtual ElementBase *clone() const = 0;
^
In file included from /home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.hh:14:0,
from /home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.cpp:9:
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/AbsBeamline/Component.h:64:22: note: virtual EMField& Component::getField()
virtual EMField &getField() = 0;
^
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/AbsBeamline/Component.h:69:28: note: virtual const EMField& Component::getField() const
virtual const EMField &getField() const = 0;
^
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.cpp:875:14: error: cannot declare variable ‘deg’ to be of abstract type ‘Degrader’
Degrader deg = dynamic_cast<Degrader *>(element_ref_m);
^
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.cpp:878:60: error: no matching function for call to ‘CollimatorPhysics::setupCollimatorDKS(PartBunch&, Degrader&, size_t&)’
setupCollimatorDKS(bunch, deg, numParticlesInSimulation);
^
In file included from /home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.cpp:9:0:
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.hh:110:10: note: candidate: void CollimatorPhysics::setupCollimatorDKS(PartBunch&, Degrader*, size_t)
void setupCollimatorDKS(PartBunch &bunch, Degrader *deg, size_t numParticlesInSimulation);
^
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.hh:110:10: note: no known conversion for argument 2 from ‘Degrader’ to ‘Degrader*’
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.cpp: In member function ‘void CollimatorPhysics::setupCollimatorDKS(PartBunch&, Degrader*, size_t)’:
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.cpp:1063:51: error: ‘numpar’ was not declared in this scope
par_mp = dksbase_m.allocateMemory<double>(numpar, ierr_m);
^
/home/opalci/NightlyBuild/workspace/OPAL-1.6-DKS/src/src/Classic/Solvers/CollimatorPhysics.cpp:1082:50: error: ‘class Degrader’ has no member named ‘getZSize’
double params[numpar_ms] = {zBegin, deg->getZSize(), rho_m, Z_m,
^
make[2]: *** [src/CMakeFiles/OPALib.dir/Classic/Solvers/CollimatorPhysics.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [src/CMakeFiles/OPALib.dir/all] Error 2
make: *** [all] Error 2
```krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/152More than 1 coworker2019-01-10T09:37:22+01:00adelmannMore than 1 coworker**--num-coworkers=2** does not work. Simulation of first generation is not terminating**--num-coworkers=2** does not work. Simulation of first generation is not terminatingYves IneichenYves Ineichenhttps://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/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.frey_msnuverink_jjochem.snuverink@psi.chfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/156The Degrader-1 test yields different results when dks is enabled2020-05-01T10:10:14+02:00krausThe Degrader-1 test yields different results when dks is enabledrms x and rms y seem to be fine, only the energy is affected. On a first inspection of the DKS code (CudaCollimatorPhysics.cu) I couldn't find anything obvious. I have no expertise nor the hardware to debug code for cuda.rms x and rms y seem to be fine, only the energy is affected. On a first inspection of the DKS code (CudaCollimatorPhysics.cu) I couldn't find anything obvious. I have no expertise nor the hardware to debug code for cuda.OPAL 2.4.0locans_ulocans_uhttps://gitlab.psi.ch/OPAL/src/-/issues/157Cyclotron trim coil has discontinuous derivative2018-04-26T15:35:40+02:00snuverink_jjochem.snuverink@psi.chCyclotron trim coil has discontinuous derivativefollow up from issue #110 as discussed there.
![image](/uploads/b10d3189af1733a1fefaecdff531d423/image.png)
As can be seen in the figure the derivative of the B field is discontinuous in the middle of the trim coil. This comes by [cons...follow up from issue #110 as discussed there.
![image](/uploads/b10d3189af1733a1fefaecdff531d423/image.png)
As can be seen in the figure the derivative of the B field is discontinuous in the middle of the trim coil. This comes by [construction of the calculation](https://gitlab.psi.ch/OPAL/src/blob/9118749a7c5ffa2657ff9d11393f3b839171e2b2/src/Classic/AbsBeamline/Cyclotron.cpp#L118).
I think it would be good to:
* find out where the calculation comes from (see also comment https://gitlab.psi.ch/OPAL/src/issues/110#note_2391)
* get some measured trim coil profiles to see how important the effect could be.
Task list added 26 March (from https://gitlab.psi.ch/OPAL/src/issues/157#note_5500):
* [x] PSI-trim coils polynomial fit (with minimal order) (@frey_m)
* [x] OPAL trim coil polynomial input (@snuverink_j)
* [x] Comparison with current implementation for TC15, make polynomial input default (@frey_m, @snuverink_j)
* [x] Documentation
* [x] Regression/Unit testOPAL 2.0.0frey_msnuverink_jjochem.snuverink@psi.chfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/158Somehow PSDump has influence on dumped statistics2017-08-18T09:32:49+02:00krausSomehow PSDump has influence on dumped statistics[red has PSDump simultaneously](/uploads/f289a4e3acd9d43703dc6b5c9c5c50fe/influencePSDump.png) This doesn't hurt any further but it's annoying.[red has PSDump simultaneously](/uploads/f289a4e3acd9d43703dc6b5c9c5c50fe/influencePSDump.png) This doesn't hurt any further but it's annoying.OPAL 1.6.0adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/92ENABLERUTHERFORD and DKS2019-03-15T13:40:02+01:00Valeria RizzoglioENABLERUTHERFORD and DKSI am testing the attribute **ENABLERUTHERFORD=FALSE** using the new OPAL module OPAL/1.5.2.
Analysing the particle distribution, I have noticed that phase space is different with and without DKS.
* **Run without DKS:** ` mpirun -np 8...I am testing the attribute **ENABLERUTHERFORD=FALSE** using the new OPAL module OPAL/1.5.2.
Analysing the particle distribution, I have noticed that phase space is different with and without DKS.
* **Run without DKS:** ` mpirun -np 8 opal Degrader_1Slab_230.in`
![OPAL_1.5.2_nodks](/uploads/135423a9df3842bc730cd54969389a75/OPAL_1.5.2_nodks.png)
* **Run with DKS:** ` mpirun -np 8 opal --use-dks Degrader_1Slab_230.in`
![OPAL_1.5.2_dks](/uploads/13a3731c8b3871d1e88630ab08d851cf/OPAL_1.5.2_dks.png)
It seems that running with DKS the attribute **ENABLERUTHERFORD** has not been implemented.
Here the input file: [Degrader_1Slab_230.in](/uploads/de37f170435fcdda5e621019974dda1e/Degrader_1Slab_230.in)OPAL 2.0.0baumgartenchristian.baumgarten@psi.chbaumgartenchristian.baumgarten@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/82IPPL extra message error2017-12-21T12:02:10+01:00frey_mIPPL extra message errorOPAL crashes for > 16 cores (but works with #cores = 4) with the error message
>>>
Error{0}> get_iter(): no more items in Message
Error{0}> reduce: mismatched element count in vector reduction.
Warning{0}> CommMPI: Found extra message...OPAL crashes for > 16 cores (but works with #cores = 4) with the error message
>>>
Error{0}> get_iter(): no more items in Message
Error{0}> reduce: mismatched element count in vector reduction.
Warning{0}> CommMPI: Found extra message from node 11, tag 10218: msg = Message contains 2 items (0 removed). Contents:
Warning{0}> Item 0: 1 elements, 1 bytes total, needDelete = 0
Warning{0}> Item 1: 3 elements, 24 bytes total, needDelete = 0
>>>
in case of serial x and y directions (i.e. PARFFTX=false, PARFFTY=false) and parallel z direction (i.e. PARFFTT=true). The simulation that was ran is [psiring.in](/uploads/06e3f41f765be149e96b56bd6b277485/psiring.in). The fieldmaps can be found in the repository [AMAS-BDModels / PSI-Ring](https://gitlab.psi.ch/AMAS-BDModels/PSI-Ring/tree/master/Fieldmaps). Following modules were used for running on Merlin:
>>>
module use unstable
module add gcc/5.4.0
module add openmpi/1.10.4
module add hdf5/1.8.18
module add H5hut/2.0.0rc3
module add trilinos/12.10.1
module add gsl/2.2.1
module add boost/1.62.0
>>>
When changing to parallel x, y and serial z, i.e. PARFFTX=true, PARFFTY=true and PARFFTT=false) no error occurs.OPAL 1.9.xfrey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/78Particle Matter interaction and Large Angle scattering2019-05-16T21:05:08+02:00adelmannParticle Matter interaction and Large Angle scatteringA 249 MeV proton beam is hitting a degrader
REAL WEDGE_HLEN=0.0197293;
REAL START = 0.02;
DEGPHYS_Wedge : SURFACEPHYSICS, TYPE="DEGRADER", MATERIAL="GraphiteR6710";
Wedge1: DEGRADER, L=WEDGE_HLEN, OUTFN="sWedge1.h5", SURFACEP...A 249 MeV proton beam is hitting a degrader
REAL WEDGE_HLEN=0.0197293;
REAL START = 0.02;
DEGPHYS_Wedge : SURFACEPHYSICS, TYPE="DEGRADER", MATERIAL="GraphiteR6710";
Wedge1: DEGRADER, L=WEDGE_HLEN, OUTFN="sWedge1.h5", SURFACEPHYSICS=DEGPHYS_Wedge, ELEMEDGE=START;
The claim is that the following transverse real space
![image](/uploads/96f74bd4cd02104fb0f45ba275702de5/image.png)
and transverse momenta space
![image](/uploads/4a30f2ebddb24ba7bc1e7da81e087bb9/image.png)
is **not** correct.
Switching off the large angle scattering (http://amas.web.psi.ch/docs/opal/opal_user_guide.pdf 18.2.2) the "halo" is disappearing, as shown
by the red dots in the following picture:
![image](/uploads/ea17023a70f261b39db30854795d1485/image.png)
Switch off == omment out: https://gitlab.psi.ch/OPAL/src/blob/master/src/Classic/Solvers/CollimatorPhysics.cpp#L777 and
https://gitlab.psi.ch/OPAL/src/blob/master/src/Classic/Solvers/CollimatorPhysics.cpp#L746
Now we can enable/disable Rutherford scattering
`DEGPHYS_Wedge : SURFACEPHYSICS, TYPE="DEGRADER", MATERIAL="GraphiteR6710", ENABLERUTHERFORD=TRUE;
`
Default is **ENABLED**
Be aware of the fact this inout file runs only with OPAL-1.6 (git checkout OPAL-1.6)
[sDegrader_70.in](/uploads/8ef0732890ee80d73567650e8e4f810a/sDegrader_70.in)
OPAL 1.9.xbaumgartenchristian.baumgarten@psi.chbaumgartenchristian.baumgarten@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/73'RestartTest-2' fails on master branch2018-03-20T10:08:59+01:00gsell'RestartTest-2' fails on master branch'RestartTest-2' fails with the following error message:
```
Error{0}> get_iter(): no more items in Message
Error{0}> reduce: mismatched element count in vector reduction.
```'RestartTest-2' fails with the following error message:
```
Error{0}> get_iter(): no more items in Message
Error{0}> reduce: mismatched element count in vector reduction.
```OPAL 1.9.xadelmannadelmannhttps://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/2option SCAN broken2018-01-09T09:27:20+01:00adelmannoption SCAN brokenThe option SCAN is broken.The option SCAN is broken.OPAL 1.9.xadelmannadelmannhttps://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/112ID0 particle replaced in the h5 file2020-07-02T08:17:04+02:00Valeria RizzoglioID0 particle replaced in the h5 filePlease check:
- if the ID0 is still replaced in the h5
- if the reference particle is stored as ID0. If yes, we could have the same problem with the beam sizePlease check:
- if the ID0 is still replaced in the h5
- if the reference particle is stored as ID0. If yes, we could have the same problem with the beam sizeOPAL 2.4.0adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/97Collimator/Probe2018-08-14T07:51:06+02:00adelmannCollimator/ProbeSuggestions from @zhang_h :
Distinguish between probes and collimator and name the collimators on the stdout.
Write probe and collimator data in one line for easy post processing
Add angles back per defaultSuggestions from @zhang_h :
Distinguish between probes and collimator and name the collimators on the stdout.
Write probe and collimator data in one line for easy post processing
Add angles back per defaultOPAL 1.9.xadelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/95OpalRingTest2020-04-22T17:05:41+02:00adelmannOpalRingTestOpalRingTest new with 2x2x2 space charge grid gives of course different answers w.r.t. emittance etc.
Please check that this makes still sense. I updated the reference with the actual resultsOpalRingTest new with 2x2x2 space charge grid gives of course different answers w.r.t. emittance etc.
Please check that this makes still sense. I updated the reference with the actual resultsext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/84Cyclotron (COMET) does not read RFMAPFN's2020-12-07T13:27:04+01:00adelmannCyclotron (COMET) does not read RFMAPFN's```
COMET: Cyclotron, TYPE="BANDRF", CYHARMON= 2, PHIINIT= -71.649, PRINIT= pr0, RINIT= r0 , SYMMETRY= 1.0,
FMAPFN="BMap_Christian.txt",
RFPHI= {hfphi0/180*pi,hfphi0/180*pi,hfphi0/180*pi,hfphi0/180...```
COMET: Cyclotron, TYPE="BANDRF", CYHARMON= 2, PHIINIT= -71.649, PRINIT= pr0, RINIT= r0 , SYMMETRY= 1.0,
FMAPFN="BMap_Christian.txt",
RFPHI= {hfphi0/180*pi,hfphi0/180*pi,hfphi0/180*pi,hfphi0/180*pi,0.5*pi,0.5*pi,0.5*pi,0.5*pi},
RFFREQ= {frequency,frequency,frequency,frequency,0,0,0,0},
RFMAPFN={"ChimneyEB.h5part","PullerEB.h5part","M77EB.h5part","COMETRF_x850EBc.h5part",
"ehfieldTR.h5part","ehfieldTR2.h5part","ehfieldTR3.h5part","ehfieldTR4.h5part"},
ESCALE={0.84,0.84,0.84,0.4395,-4.5,+6.5,+4.5,-6.5},
MAXZ=15, MINZ=-15, MINR=0, MAXR= 881.1,
SUPERPOSE={false,false,false,false,true,true,true,true};
```
The full set of inputfiles is to large. All inputfiles can be found at: merlinl1.psi.ch:~adelmann/COMET/1.5.1-20170217OPAL 2021.1adelmannext-calvo_ppedro.calvo@ciemat.esadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/83Bethe-Bloch threshold2021-01-30T19:16:00+01:00adelmannBethe-Bloch thresholdAllow the user to specify when a particle is dead (in the Bethe-Bloch) calculationAllow the user to specify when a particle is dead (in the Bethe-Bloch) calculationOPAL 2021.1adelmannext-calvo_ppedro.calvo@ciemat.esadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/71track-orbit of ID1 and ID2 OPAL-1.6 and master2021-06-10T18:49:09+02:00adelmanntrack-orbit of ID1 and ID2 OPAL-1.6 and masterIn data/track-orbit, the coordinates of ID1 and ID2 are **always** stored.
On the distribution command the user can set ID1 and ID2 by *hand*.
@rizzoglio_v : Please commentIn data/track-orbit, the coordinates of ID1 and ID2 are **always** stored.
On the distribution command the user can set ID1 and ID2 by *hand*.
@rizzoglio_v : Please commentadelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/68DumpEMFields option for OpalRing2018-09-19T12:59:30+02:00ext-rogers_cDumpEMFields option for OpalRingWould like to add a module to dump time varying magnetic fields for opalWould like to add a module to dump time varying magnetic fields for opalext-rogers_cext-rogers_chttps://gitlab.psi.ch/OPAL/src/-/issues/67Specification of distributions a la Elegant2020-04-22T11:38:48+02:00krausSpecification of distributions a la ElegantTo generate a distribution that corresponds to Elegant using betax, alphax, betay, alphay, nemittx, nemitty, sigma_s/sigma_t, p, sigma_dp.
J. KnedelTo generate a distribution that corresponds to Elegant using betax, alphax, betay, alphay, nemittx, nemitty, sigma_s/sigma_t, p, sigma_dp.
J. KnedelOPAL 1.9.xhttps://gitlab.psi.ch/OPAL/src/-/issues/66Reimplement boundary geometries, surface emission, multipacting etc in Parall...2021-06-10T18:10:55+02:00krausReimplement boundary geometries, surface emission, multipacting etc in ParallelTTrackerBoundary geometries, surface emission etc isn't ported from version 1.6 and in the near futur this won't be ported.Boundary geometries, surface emission etc isn't ported from version 1.6 and in the near futur this won't be ported.OPAL 1.9.xChuan WangChuan Wanghttps://gitlab.psi.ch/OPAL/src/-/issues/65Quadrupole components of dipoles is missing2021-06-10T18:10:26+02:00krausQuadrupole components of dipoles is missingK1 has been removed from RBEND/SBEND, reimplement it.K1 has been removed from RBEND/SBEND, reimplement it.OPAL 1.9.xhttps://gitlab.psi.ch/OPAL/src/-/issues/56Multi-Slit & PEPPERPOT2018-04-14T13:30:27+02:00adelmannMulti-Slit & PEPPERPOTPEPPERPOT with rectangular slits instead of circles.PEPPERPOT with rectangular slits instead of circles.OPAL 1.9.xkrausadelmannext-edelen_akraushttps://gitlab.psi.ch/OPAL/src/-/issues/53Layout-file (ascii-file with coordinates)2017-08-29T21:42:12+02:00baumgartenchristian.baumgarten@psi.chLayout-file (ascii-file with coordinates)It would be important not only for cross-checks but also for cooperation with engineers, to have the layout (numerical values) from OPAL. Especially useful are the central mechanical coordinates of the quadrupoles and the so-called "vert...It would be important not only for cross-checks but also for cooperation with engineers, to have the layout (numerical values) from OPAL. Especially useful are the central mechanical coordinates of the quadrupoles and the so-called "vertex"-points of dipoles (virtual intersection of the straights). A drawing is nice, but to compare the numerical data using sub-millimeter precision with drawings (or data from survey) is extremely important.OPAL 1.9.xhttps://gitlab.psi.ch/OPAL/src/-/issues/47Erice Work List2018-06-12T10:12:45+02:00adelmannErice Work ListWe should start with a list of things we want to achiveWe should start with a list of things we want to achiveOPAL 2.0.0adelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/43Add WARP attribute to collimators2021-10-13T09:28:24+02:00krausAdd WARP attribute to collimatorsAll elements except the dipoles have a stright geometry in OPAL-T. Somtimes it would be nice if an element could warp to fit the design path. This should be fairly easy to apply to passive elements such as a collimator. More effort is ne...All elements except the dipoles have a stright geometry in OPAL-T. Somtimes it would be nice if an element could warp to fit the design path. This should be fairly easy to apply to passive elements such as a collimator. More effort is needed for multipoles / other magnets.krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/37Some particles get kicked more in corrector2019-08-01T16:14:24+02:00krausSome particles get kicked more in correctorFor short correctors some particles may get kicked one time more than the majority. E.g. in the regression test HKick-Test-2 when inspecting the phase space after the corrector one observes that some particles get twice the kick in trans...For short correctors some particles may get kicked one time more than the majority. E.g. in the regression test HKick-Test-2 when inspecting the phase space after the corrector one observes that some particles get twice the kick in transverse direction than the majority. The field is modeled as a hard edge magnet. The majority gets kicked only once while a few particles get kicked twice. This behavior isn't satisfactory.OPAL 1.9.xkrauskraushttps://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.adelmannext-rogers_cadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/8optPilot is integrated in OPAL2017-10-17T21:18:49+02:00adelmannoptPilot is integrated in OPALOPAL 1.9.xadelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/6A new FFT solver2017-10-22T15:36:40+02:00adelmannA new FFT solverA new [FFT based solver](http://www.sciencedirect.com/science/article/pii/S0010465515003434) is
available and also integrated into DKSA new [FFT based solver](http://www.sciencedirect.com/science/article/pii/S0010465515003434) is
available and also integrated into DKSOPAL 1.9.xadelmannadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/160simplify gcc warning flags2017-08-29T10:18:36+02:00snuverink_jjochem.snuverink@psi.chsimplify gcc warning flagsCurrently we have the following compiler warning flags for gcc:
`-Wall -Wno-error -Wno-reorder -Wno-unused-local-typedefs -Werror=unused-variable -std=c++11`
I would like to remove the following flags if no one objects:
* `-Wno-error`...Currently we have the following compiler warning flags for gcc:
`-Wall -Wno-error -Wno-reorder -Wno-unused-local-typedefs -Werror=unused-variable -std=c++11`
I would like to remove the following flags if no one objects:
* `-Wno-error` : already default so no need to declare it.
* `-Wno-reorder` : suppresses a warning that is easy to fix and can (admittedly rarely) lead to non-intuitive code execution.
* `-Wno-unused-local-typedefs` : suppresses a warning that is easy to fix and usually points to uncleaned code or wrong logic.
Furthermore, there are very few code changes needed to fix the code (which I will do).snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/161PSDUMPLOCALFRAME and PSDUMPFRAME2017-08-31T10:28:35+02:00Valeria RizzoglioPSDUMPLOCALFRAME and PSDUMPFRAMEIf the list of the options is:
```
OPTION, PSDUMPLOCALFRAME=TRUE;
OPTION, PSDUMPFRAME=BUNCH_MEAN;
OPTION, TELL=TRUE;
```
OPAL starts the run without any problem.
If the list of the options is:
```
OPTION, PSDUMPFRAME=BUNCH_MEAN;
O...If the list of the options is:
```
OPTION, PSDUMPLOCALFRAME=TRUE;
OPTION, PSDUMPFRAME=BUNCH_MEAN;
OPTION, TELL=TRUE;
```
OPAL starts the run without any problem.
If the list of the options is:
```
OPTION, PSDUMPFRAME=BUNCH_MEAN;
OPTION, PSDUMPLOCALFRAME=TRUE;
OPTION, TELL=TRUE;
```
OPAL returns the following error
```
Error> *** in line 5 of file "B1_MultiMaps.in" at end of statement:
Ippl>
Ippl> *** User error detected by function "Option::handlePsDumpFrame"
Ippl> OPTION,PSDUMPLOCALFRAME=TRUE;
Ippl> Either set 'PSDUMPLOCALFRAME' Option or 'PSDUMPFRAME' Option but not both.
Ippl>
```
In addition when PSDUMPLOCALFRAME = TRUE and PSDUMPFRAME removed from the input file, the statistics is dumped in the GLOBAL frame.OPAL 1.9.xadelmannfrey_madelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/162K0 attribute in RBend2017-10-22T14:14:11+02:00Valeria RizzoglioK0 attribute in RBendIt seems that the attribute K0 (to set the magnetic field) is not working in the RBend element.
In the regression test, if I am not wrong, only the Angle attribute is tested.
From a simple RBend test:
1- if **ANGLE** attribute is us...It seems that the attribute K0 (to set the magnetic field) is not working in the RBend element.
In the regression test, if I am not wrong, only the Angle attribute is tested.
From a simple RBend test:
1- if **ANGLE** attribute is used
```
RBend [2]> 1DPROFILE1-DEFAULT (1D Profile type 1)
RBend [2]> BEND using file 1DPROFILE1-DEFAULT (1D Profile type 1)
RBend [2]>
RBend [2]> Start of field map: 0.146472 m (in s coordinates)
RBend [2]> End of field map: 0.484418 m (in s coordinates)
RBend [2]> Entrance edge of magnet: 0.25 m (in s coordinates)
RBend [2]>
RBend [2]> Reference Trajectory Properties
RBend [2]> ===============================
RBend [2]>
RBend [2]> Bend angle magnitude: 0.523599 rad (30 degrees)
RBend [2]> Entrance edge angle: 0.261799 rad (15 degrees)
RBend [2]> Exit edge angle: 0.261799 rad (15 degrees)
RBend [2]> Bend design radius: 0.249982 m
RBend [2]> Bend design energy: 7e+06 eV
RBend [2]>
RBend [2]> Bend Field and Rotation Properties
RBend [2]> ==================================
RBend [2]>
RBend [2]> Field amplitude: 1.53217 T
RBend [2]> Field index: 0
RBend [2]> Rotation about x axis: 0 rad (0 degrees)
RBend [2]> Rotation about y axis: 0 rad (0 degrees)
RBend [2]> Rotation about z axis: 0 rad (0 degrees)
RBend [2]>
RBend [2]> Reference Trajectory Properties Through Bend Magnet with Fringe Fields
RBend [2]> ======================================================================
RBend [2]>
RBend [2]> Reference particle is bent: 0.523599 rad (30 degrees) in x plane
RBend [2]> Reference particle is bent: 0 rad (0 degrees) in y plane
RBend [2]>
```
2- if **K0** attribute is used:
```
RBend [2]> 1DPROFILE1-DEFAULT (1D Profile type 1)
RBend [2]> BEND using file 1DPROFILE1-DEFAULT (1D Profile type 1)
RBend [2]>
RBend [2]> Start of field map: 0.146472 m (in s coordinates)
RBend [2]> End of field map: -nan m (in s coordinates)
RBend [2]> Entrance edge of magnet: 0.25 m (in s coordinates)
RBend [2]>
RBend [2]> Reference Trajectory Properties
RBend [2]> ===============================
RBend [2]>
RBend [2]> Bend angle magnitude: -nan rad (-nan degrees)
RBend [2]> Entrance edge angle: 0.261799 rad (15 degrees)
RBend [2]> Exit edge angle: -0.261799 rad (-15 degrees)
RBend [2]> Bend design radius: 0.25001 m
RBend [2]> Bend design energy: 7e+06 eV
RBend [2]>
RBend [2]> Bend Field and Rotation Properties
RBend [2]> ==================================
RBend [2]>
RBend [2]> Field amplitude: 1.532 T
RBend [2]> Field index: 0
RBend [2]> Rotation about x axis: 0 rad (0 degrees)
RBend [2]> Rotation about y axis: 0 rad (0 degrees)
RBend [2]> Rotation about z axis: 0 rad (0 degrees)
RBend [2]>
RBend [2]> Reference Trajectory Properties Through Bend Magnet with Fringe Fields
RBend [2]> ======================================================================
RBend [2]>
RBend [2]> Reference particle is bent: -0 rad (-0 degrees) in x plane
RBend [2]> Reference particle is bent: 0 rad (0 degrees) in y plane
RBend [2]>
```
Could, please, someone check?OPAL 2.0.0krausadelmannkraushttps://gitlab.psi.ch/OPAL/src/-/issues/163Charge zero in OPAL-cycl & OPAL-t2017-10-02T09:29:53+02:00adelmannCharge zero in OPAL-cycl & OPAL-tCompare beam size of 1.6 and 1.9.x
![opal-cycl](/uploads/e0253f94e8aaec164cae26c992f33eab/opal-cycl.png)
for the IsoDAR cyclotron. Inputfiles can be found on
`merlin-l-01: /gpfs/home/adelmann/scratch/UQ/isodar-1/Accelerated and
...Compare beam size of 1.6 and 1.9.x
![opal-cycl](/uploads/e0253f94e8aaec164cae26c992f33eab/opal-cycl.png)
for the IsoDAR cyclotron. Inputfiles can be found on
`merlin-l-01: /gpfs/home/adelmann/scratch/UQ/isodar-1/Accelerated and
...../Accelerated-1.9`
FUN fact: **Qtot = 0.000**
`
OPAL{0}> * ************** B U N C H *********************************************************
OPAL{0}> * NP = 133000
OPAL{0}> * Qtot = 0.000 [fC] Qi = 1.017 [fC]
OPAL{0}> * Ekin = 361.221 [keV] dEkin = 1.445 [keV]
OPAL{0}> * rmax = ( 3.18003 , 8.91427 , 9.34380 ) [um]
OPAL{0}> * rmin = ( -3.18003 , -8.95209 , -9.36713 ) [um]
OPAL{0}> * rms beam size = ( 1.02826 , 2.91108 , 3.02269 ) [mm]
OPAL{0}> * rms momenta = ( 1.70888e-04 , 3.92498e-05 , 7.85035e-05 ) [beta gamma]
OPAL{0}> * mean position = ( 0.00000 , -0.00000 , 0.00009 ) [um]
OPAL{0}> * mean momenta = ( 2.92045e-15 , 1.96206e-02 , -1.26375e-09 ) [beta gamma]
OPAL{0}> * rms emittance = ( 8.78539e-06 , 5.71264e-06 , 1.18639e-05 ) (not normalized)
OPAL{0}> * rms correlation = ( 2.39105e-04 , 1.14814e-03 , 1.85573e-03 )
OPAL{0}> * hr = ( 0.44096 , 1.23873 , 1.29729 ) [mm]
OPAL{0}> * dh = 2.00000e+00 [%]
OPAL{0}> * t = 0.000 [fs] dT = 28.251 [ps]
OPAL{0}> * spos = 0.000 [um]
OPAL{0}> * **********************************************************************************
`OPAL 1.9.xadelmannwinklehner_dadelmannhttps://gitlab.psi.ch/OPAL/src/-/issues/164Compiling OPAL on Daint causes internal compiler error2017-09-18T10:18:43+02:00frey_mCompiling OPAL on Daint causes internal compiler errorWhen compiling OPAL on Piz Daint one obtains an internal compiler error
```
/users/freym/git/opal/src/opt-pilot/Util/MPIHelper.cpp:36:11: required from here
/users/freym/git/opal/src/opt-pilot/Util/Types.h:50:16: internal compiler err...When compiling OPAL on Piz Daint one obtains an internal compiler error
```
/users/freym/git/opal/src/opt-pilot/Util/MPIHelper.cpp:36:11: required from here
/users/freym/git/opal/src/opt-pilot/Util/Types.h:50:16: internal compiler error: Segmentation fault
typedef struct {
^
0xb0248f crash_signal
../../cray-gcc-5.3.0/gcc/toplev.c:383
0xafa0ff layout_decl(tree_node*, unsigned int)
../../cray-gcc-5.3.0/gcc/stor-layout.c:783
0x660ba4 require_complete_types_for_parms
../../cray-gcc-5.3.0/gcc/cp/decl.c:11148
0x660ba4 check_function_type
../../cray-gcc-5.3.0/gcc/cp/decl.c:13297
0x660ba4 start_preparsed_function(tree_node*, tree_node*, int)
../../cray-gcc-5.3.0/gcc/cp/decl.c:13471
0x70f654 synthesize_method(tree_node*)
../../cray-gcc-5.3.0/gcc/cp/method.c:798
0x6b29f3 mark_used(tree_node*, int)
../../cray-gcc-5.3.0/gcc/cp/decl2.c:5196
0x651dc4 build_over_call
../../cray-gcc-5.3.0/gcc/cp/call.c:7536
0x650976 build_new_method_call_1
../../cray-gcc-5.3.0/gcc/cp/call.c:8252
0x650976 build_new_method_call(tree_node*, tree_node*, vec<tree_node*, va_gc, vl_embed>**, tree_node*, int, tree_node**, int)
../../cray-gcc-5.3.0/gcc/cp/call.c:8322
0x64a6ba build_special_member_call(tree_node*, tree_node*, vec<tree_node*, va_gc, vl_embed>**, tree_node*, int, int)
../../cray-gcc-5.3.0/gcc/cp/call.c:7862
0x709877 build_value_init(tree_node*, int)
../../cray-gcc-5.3.0/gcc/cp/init.c:358
0x70de58 perform_member_init
../../cray-gcc-5.3.0/gcc/cp/init.c:646
0x70de58 emit_mem_initializers(tree_node*)
../../cray-gcc-5.3.0/gcc/cp/init.c:1167
0x684656 tsubst_expr
../../cray-gcc-5.3.0/gcc/cp/pt.c:13962
0x6844fc tsubst_expr
../../cray-gcc-5.3.0/gcc/cp/pt.c:14142
0x683267 instantiate_decl(tree_node*, int, bool)
../../cray-gcc-5.3.0/gcc/cp/pt.c:20589
0x6b271d mark_used(tree_node*, int)
../../cray-gcc-5.3.0/gcc/cp/decl2.c:5217
0x651dc4 build_over_call
../../cray-gcc-5.3.0/gcc/cp/call.c:7536
0x650976 build_new_method_call_1
../../cray-gcc-5.3.0/gcc/cp/call.c:8252
Please submit a full bug report,
```frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/165opt-pilot: objectives based on design variables2021-06-10T18:03:26+02:00snuverink_jjochem.snuverink@psi.chopt-pilot: objectives based on design variablesas mentioned in https://gitlab.psi.ch/OPAL/src/issues/8#note_3112 writing objectives like (where d1 and d2 are design variables):
```
//obj1:OBJECTIVE,EXPR="fabs(d1+d2)";
```
seem not to work (not sure if it ever did). Since the optimi...as mentioned in https://gitlab.psi.ch/OPAL/src/issues/8#note_3112 writing objectives like (where d1 and d2 are design variables):
```
//obj1:OBJECTIVE,EXPR="fabs(d1+d2)";
```
seem not to work (not sure if it ever did). Since the optimiser still tries to look in the output file:
```
Exception while getting value from SDDS file: unkown column name!
```
Still such an objective could potentially be useful.
I might have a look at this eventually, or if there is a direct need for it. Right now putting a low weight on it.snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/166Placement of elements with PSI different from 0 and pi2017-10-15T22:12:10+02:00krausPlacement of elements with PSI different from 0 and piThe elements between dipoles are placed incorrectly when the dipoles have e.g. PSI = pi/2.The elements between dipoles are placed incorrectly when the dipoles have e.g. PSI = pi/2.OPAL 2.0.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/167Proper parsers of optPilot commands that is based on OpalParser2018-04-11T11:39:52+02:00krausProper parsers of optPilot commands that is based on OpalParserSofar the parser for optPilot within OPAl is rather a hack than properly done.Sofar the parser for optPilot within OPAl is rather a hack than properly done.OPAL 2.0.0kraussnuverink_jjochem.snuverink@psi.chkraus