src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2019-05-11T19:39:59+02:00https://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/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/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/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/133BeamLine fails isInside test during OrbitThreader execute() when Aperture CIR...2017-08-02T22:49:58+02:00winklehner_dBeamLine fails isInside test during OrbitThreader execute() when Aperture CIRCLE is defined in RFCavity.It took me a long time to find out why my RFCavity was not in the imap_m generated by the OrbitThreader during execute(), so I wasn't able to test this with other apertures, but it seems that having a "CIRCLE(0.008, 1)" aperture defined ...It took me a long time to find out why my RFCavity was not in the imap_m generated by the OrbitThreader during execute(), so I wasn't able to test this with other apertures, but it seems that having a "CIRCLE(0.008, 1)" aperture defined in the RFCavity element prevents it from being added to the elementSet list in the getElements(nextR) function. I think the culprit is somehow the ElementBase::isInsideTransverse() function.krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/132_M_range_check error2017-08-13T10:13:16+02:00winklehner_d_M_range_check errorSince pulling today, this happens:
```
Error{1}> *** Error:
Error{1}> *** in line 86 of file "RFQ_VECC-T.in":
Error{1}> RUN,METHOD="PARALLEL-T",BEAM=BEAM1,FIELDSOLVER=FS1,DISTRIBUTION=DIST;
Error{1}> vector::_M_range_check
...Since pulling today, this happens:
```
Error{1}> *** Error:
Error{1}> *** in line 86 of file "RFQ_VECC-T.in":
Error{1}> RUN,METHOD="PARALLEL-T",BEAM=BEAM1,FIELDSOLVER=FS1,DISTRIBUTION=DIST;
Error{1}> vector::_M_range_check
```
Any insights anyone? @kraus, did you write something about distributions now being arrays? @adelmann?https://gitlab.psi.ch/OPAL/src/-/issues/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/125Vector of time steps: error in the parser2017-07-13T09:32:41+02:00Valeria RizzoglioVector of time steps: error in the parser[PROSCAN-G3-230.in](/uploads/0f541b042bd39fdf2fe62688529cc406/PROSCAN-G3-230.in)
If I track the particles using a vector of time steps:
```
TRACK, LINE=BEAMLINE_TOT,
BEAM=BEAM_G3_LA1,
MAXSTEPS={5e+08,5e+08,5e+08},
...[PROSCAN-G3-230.in](/uploads/0f541b042bd39fdf2fe62688529cc406/PROSCAN-G3-230.in)
If I track the particles using a vector of time steps:
```
TRACK, LINE=BEAMLINE_TOT,
BEAM=BEAM_G3_LA1,
MAXSTEPS={5e+08,5e+08,5e+08},
DT={5*PICOSECONDS,1*PICOSECONDS,5*PICOSECOND},
ZSTOP={6.145,6.75,16}OPAL 1.6.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/123No stat-file output in case of MTS tracking2017-07-05T12:12:53+02:00frey_mNo stat-file output in case of MTS trackingRunning the regression test [RingCyclotronMTS](https://gitlab.psi.ch/OPAL/regression-tests/blob/master/RegressionTests/RingCyclotronMTS/RingCyclotronMTS.in) however with ```nsteps = 2000``` and ```SPTDUMPFREQ = 10``` -- as in the test [R...Running the regression test [RingCyclotronMTS](https://gitlab.psi.ch/OPAL/regression-tests/blob/master/RegressionTests/RingCyclotronMTS/RingCyclotronMTS.in) however with ```nsteps = 2000``` and ```SPTDUMPFREQ = 10``` -- as in the test [RingCyclotron](https://gitlab.psi.ch/OPAL/regression-tests/blob/master/RegressionTests/RingCyclotron/RingCyclotron.in) using RK-4 -- I get only one dump in the RingCyclotronMTS.stat.OPAL 1.9.xfrey_mfrey_mhttps://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/110PartBunch::get_bounds can produce NaNs2019-10-25T13:47:36+02:00snuverink_jjochem.snuverink@psi.chPartBunch::get_bounds can produce NaNsWhile trying to update the [PSI-Ring](https://gitlab.psi.ch/AMAS-BDModels/PSI-Ring) simulations to the master branch, I encountered the following running error:
```
OPAL> PartBunch.cpp: 1574 nan 2.000000e-02
Error>
Error> *** User...While trying to update the [PSI-Ring](https://gitlab.psi.ch/AMAS-BDModels/PSI-Ring) simulations to the master branch, I encountered the following running error:
```
OPAL> PartBunch.cpp: 1574 nan 2.000000e-02
Error>
Error> *** User error detected by function "PartBunch::boundp() "
Error> *** in line 311 of file "Ring.in":
Error> RUN,METHOD="CYCLOTRON-T",BEAM=BEAM1,FIELDSOLVER=FS1,DISTRIBUTION=DIST;
Error> h<0, can not build a mesh
```
The `nan` gets introduced in line 1521: `get_bounds(rmin_m, rmax_m);`
Printing out rmax and rmin before and after this line gives (ymmv):
before:
```
(i,rmax, rmin) 0 0.0000000000000000e+00 0.0000000000000000e+00
(i,rmax, rmin) 1 0.0000000000000000e+00 0.0000000000000000e+00
(i,rmax, rmin) 2 0.0000000000000000e+00 0.0000000000000000e+00
```
after
```
(i,rmax, rmin) 0 7.1153710538428058e-03 -6.9640951722910538e-03
(i,rmax, rmin) 1 4.0421699390708048e-02 -4.0512781208033796e-02
(i,rmax, rmin) 2 -nan -nan
```
I likely do something wrong with my input, but I believe the code should not get this far and produce a better error message.
This can be reproduced with OPAL master (0469d1ac), and the latest version of [PSI-Ring](https://gitlab.psi.ch/AMAS-BDModels/PSI-Ring) and executing `runOpal --nobatch`
**Edit 20 July:**
https://gitlab.psi.ch/OPAL/src/issues/110#note_1914: Simplified input file [Ring.in](https://gitlab.psi.ch/OPAL/src/uploads/ec9579a7c5009c1b7465266afe4373c0/Ring.in)
https://gitlab.psi.ch/OPAL/src/issues/110#note_1916: Regression test `RingCyclotron` has the same bug when one changes the distribution from gauss to either single particle or binomial. snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://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/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/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/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.0adelmannadelmann