src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2018-01-09T06:41:26+01:00https://gitlab.psi.ch/OPAL/src/-/issues/199Rethink catching of exceptions2018-01-09T06:41:26+01:00krausRethink catching of exceptionsCurrently all exceptions are caught by the OpalParser. Whe it catches exceptions then it calls exit. This is a problem for the optimizer since it's very likely that an individual (optimization perspective) failes while the others run smo...Currently all exceptions are caught by the OpalParser. Whe it catches exceptions then it calls exit. This is a problem for the optimizer since it's very likely that an individual (optimization perspective) failes while the others run smoothly.
OpalParser shouldn't catch any exceptions except ParseErrors.krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/198Distribution-Binomial regression test is broken2019-02-15T08:51:23+01:00snuverink_jjochem.snuverink@psi.chDistribution-Binomial regression test is brokenThe binomial distribution regression test is broken.
According to the nightly tests this happened between [21 July](http://amas.web.psi.ch/opal/regressionTests/master/results_2017-07-21.xml), when the test was failing by a bit, and [23 ...The binomial distribution regression test is broken.
According to the nightly tests this happened between [21 July](http://amas.web.psi.ch/opal/regressionTests/master/results_2017-07-21.xml), when the test was failing by a bit, and [23 July](http://amas.web.psi.ch/opal/regressionTests/master/results_2017-07-23.xml), when the test was off much more.
So between commits b884784 and 3655140:
* 3655140 lift restriction on CORR[X|Y|Z] for binomial distributions
* e331e8b fixing issue with convertion to eV when ratio is small
* 6b08a26 add silencer to all tests
* 1a5bff8 fixing few issues binomial distribution and cleaning up
* acaf84b whitespaces
* 1c0fa9a further improve CMake files for opt-pilot: remove #define GIT_VERSION since already defined in OPAL
* df1840a (tag: OPAL-dev, tag: OPAL-1.9.0) fixing CMake files
* 85bc105 cleaning up Gauss distribution unit test; improve SilenceTest class to print output if tests fail
Of these 1a5bff8 is the most likely culprit. Assigning to @kraus who did all of those commits.krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/196Dumping phase space in global frame (Cyclotron-Tracker)2020-04-22T11:27:56+02:00frey_mDumping phase space in global frame (Cyclotron-Tracker)When dumping the phase space in global frame one obtains bad results if a core does not have particles, e.g.
```
OPAL{0}> * Integration step 0 (no phase space dump for <= 2 particles)
OPAL{0}> * T = 0 ns, Live Particles: 80640000
OPAL{0...When dumping the phase space in global frame one obtains bad results if a core does not have particles, e.g.
```
OPAL{0}> * Integration step 0 (no phase space dump for <= 2 particles)
OPAL{0}> * T = 0 ns, Live Particles: 80640000
OPAL{0}> * E = 71.6 MeV, beta * gamma = 0
OPAL{0}> * Bunch position: R = 0 mm, Theta = 0 Deg, Z = 0 mm
OPAL{0}> * Local Azimuth = -90 Deg, Local Elevation = -nan Deg
```
The reason is the usage of
```
meanR = itsBunch_m->R[0];
meanP = itsBunch_m->P[0];
```
in ```bunchDumpPhaseSpaceData()``` and ```bunchDumpStatData()```.frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/188C version of FFTPACK segfaults2017-12-21T09:52:44+01:00snuverink_jjochem.snuverink@psi.chC version of FFTPACK segfaultsOpalRingTest and RingCyclotron-Tests segfault as [found by Christoph]
(https://gitlab.psi.ch/OPAL/src/commit/ee8a32ba55683d5dea34e7522e3c2cba2384d4d8#note_3812) with:
```
[pc12290:01336] Signal: Segmentation fault (11)
[pc12290:01336] S...OpalRingTest and RingCyclotron-Tests segfault as [found by Christoph]
(https://gitlab.psi.ch/OPAL/src/commit/ee8a32ba55683d5dea34e7522e3c2cba2384d4d8#note_3812) with:
```
[pc12290:01336] Signal: Segmentation fault (11)
[pc12290:01336] Signal code: (128)
[pc12290:01336] Failing at address: (nil)
[pc12290:01336] [ 0] /lib64/libpthread.so.0[0x3ab660f7e0]
[pc12290:01336] [ 1] opal(rffti1_+0x1c)[0x25b43ac]
[pc12290:01336] [ 2] opal(rffti_+0x24)[0x25b4374]
[pc12290:01336] [ 3] opal(_ZN3FFTI11RCTransformLj3EdEC1ERK7NDIndexILj3EES5_RKbi+0x2c7)[0x13109d7]
[pc12290:01336] [ 4] opal(_ZN16FFTPoissonSolverC1EP16UniformCartesianILj3EdEP19CenteredFieldLayoutILj3ES1_4CellENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESC_+0xf5c)[0x130428c]
[pc12290:01336] [ 5] opal(_ZN11FieldSolver10initSolverEP13PartBunchBaseIdLj3EE+0x7c5)[0x1038d35]
[pc12290:01336] [ 6] opal(_ZN8TrackRun16setupFieldsolverEv+0x1ef)[0x13efb6f]
[pc12290:01336] [ 7] opal(_ZN8TrackRun21setupCyclotronTrackerEv+0xbb)[0x13f3c2b]
[pc12290:01336] [ 8] opal(_ZN8TrackRun7executeEv+0x632)[0x13f5d02]
[pc12290:01336] [ 9] opal(_ZNK10OpalParser7executeEP6ObjectRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x35)[0xff7f35]
```gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/179opt-pilot CONSTRAINT command not known2017-11-07T10:03:58+01:00snuverink_jjochem.snuverink@psi.chopt-pilot CONSTRAINT command not knownA opt-pilot constraint such as:
```
c1: CONSTRAINT, EXPR="fabs(rms_x)<1.5e-2";
constrs: CONSTRAINTS = (c1);
```
gives:
```
Error>
Error> *** Parse error detected by function "OpalParser::parseDefine()"
Error> *** in line 46 of file "...A opt-pilot constraint such as:
```
c1: CONSTRAINT, EXPR="fabs(rms_x)<1.5e-2";
constrs: CONSTRAINTS = (c1);
```
gives:
```
Error>
Error> *** Parse error detected by function "OpalParser::parseDefine()"
Error> *** in line 46 of file "RingOpt.in" before token ",":
Error> The object "CONSTRAINT" is unknown.
```
This is because the keyword CONSTRAINT is not skipped in [AbsFileStream](https://gitlab.psi.ch/OPAL/src/blob/master/src/Classic/Parser/AbsFileStream.cpp#L42).
I will fix this there.
One concern is that CONSTRAINT is also a keyword in the match routine: https://gitlab.psi.ch/OPAL/src/blob/master/src/Match/MatchParser.cpp.
However, as far as I can see this is currently not in OPAL? Quoting the manual: "Please note this is not yet available in: `DOPAL-t` and `DOPAL-cycl`." @adelmann can you confirm?snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://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/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/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/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/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/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/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/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/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/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_c