src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2020-07-18T18:31:32+02:00https://gitlab.psi.ch/OPAL/src/-/issues/569fitting bend angle in Bend2D may run indefinitely in some circumstances2020-07-18T18:31:32+02:00krausfitting bend angle in Bend2D may run indefinitely in some circumstancesThe variable `fieldStep` has to change its sign depending on the sign of the amplitude.The variable `fieldStep` has to change its sign depending on the sign of the amplitude.OPAL 2.4.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/568Autophasing broken when fieldmap starts at z < 02020-07-17T10:01:11+02:00krausAutophasing broken when fieldmap starts at z < 0### Summary
When a Astra1DDynamic fieldmap is used which starts at z < 0 then the interpolation algorithm throws an exception because a sampling point outside of the range was requested.
### Steps to reproduce
Run this input file: (f...### Summary
When a Astra1DDynamic fieldmap is used which starts at z < 0 then the interpolation algorithm throws an exception because a sampling point outside of the range was requested.
### Steps to reproduce
Run this input file: (file follows)
### What is the current *bug* behavior?
The interpolation algorithm in the field map reader Astra1DDynamic_fast throws an exception because a sampling point outside of the range was requested.
### What is the expected *correct* behavior?
The autophasing algorithm should run smoothly and yield the same results as before #515 was implemented.
### Relevant logs and/or screenshots
--
### Possible fixes
--OPAL 2.4.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/567Segmentation fault simulation2020-07-16T08:47:53+02:00ext-calvo_ppedro.calvo@ciemat.esSegmentation fault simulationAfter !395 I've got a segmentation fault
```
*** Process received signal ***
Signal: Segmentation fault (11)
Signal code: Invalid permissions (2)
Failing at address: 0x15c69b0
[ 0] /lib64/libpthread.so.0[0x30b520f130]
[ 1] opal(_ZTVN10_...After !395 I've got a segmentation fault
```
*** Process received signal ***
Signal: Segmentation fault (11)
Signal code: Invalid permissions (2)
Failing at address: 0x15c69b0
[ 0] /lib64/libpthread.so.0[0x30b520f130]
[ 1] opal(_ZTVN10__cxxabiv120__si_class_type_infoE+0x10)[0x15c69b0]
*** End of error message ***
ViolaciĆ³n de segmento (`core' generado)
```
The opal compilation was correct. I don't know the cause of the error
cc: @frey\_m @snuverink\_j https://gitlab.psi.ch/OPAL/src/-/issues/566Matched distribution not working with SCALABLE = FALSE2020-07-15T17:42:49+02:00frey_mMatched distribution not working with SCALABLE = FALSEThe matched distribution initializes too many particles if `SCALABLE = FALSE` and the number of cores > 1.The matched distribution initializes too many particles if `SCALABLE = FALSE` and the number of cores > 1.OPAL 2.4.0frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/564LONG-TRANSV-SHORT-RANGE wake not implemented2020-07-23T17:25:12+02:00snuverink_jjochem.snuverink@psi.chLONG-TRANSV-SHORT-RANGE wake not implemented### Summary
As discovered by @ext\-piot\_p the `LONG-TRANSV-SHORT-RANGE` wake is not implemented.
### Steps to reproduce
`WAKE` command with `TYPE=LONG-TRANSV-SHORT-RANGE`.
### What is the current *bug* behavior?
No warning message,...### Summary
As discovered by @ext\-piot\_p the `LONG-TRANSV-SHORT-RANGE` wake is not implemented.
### Steps to reproduce
`WAKE` command with `TYPE=LONG-TRANSV-SHORT-RANGE`.
### What is the current *bug* behavior?
No warning message, no wakefield.
### What is the expected *correct* behavior?
Correctly implemented wake, or exception thrown.
### Relevant logs and/or screenshots
```c++
} else if (Attributes::getString(itsAttr[TYPE]) == "LONG-TRANSV-SHORT-RANGE") {
//FIXME: NOT IMPLEMENTED YET!!!
} else {
wf_m = 0;
INFOMSG("no wakefunction attached" << endl);
}
```
### Possible fixes
An exception can be thrown, also in the case of a non-matching type (might be a typo).
The mention of `LONG-TRANSV-SHORT-RANGE` should be removed from the manual.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/563regression test Distribution-Binomial-1 and Quad-Simple-Test-1 are failing2020-07-10T15:18:37+02:00gsellregression test Distribution-Binomial-1 and Quad-Simple-Test-1 are failingThe regression tests `Distribution-Binomial-1` and `Quad-Simple-Test-1` are failing. Last successful run was on 2020-07-08. See http://amas.web.psi.ch/opal/regressionTests/master/.
I suspect commit 508cda4c4be97a4869784a85413df25bfc083f...The regression tests `Distribution-Binomial-1` and `Quad-Simple-Test-1` are failing. Last successful run was on 2020-07-08. See http://amas.web.psi.ch/opal/regressionTests/master/.
I suspect commit 508cda4c4be97a4869784a85413df25bfc083fc1 in MR !385.OPAL 2.4.0albajacas_aarnau.albajacas@psi.chalbajacas_aarnau.albajacas@psi.ch2020-07-24https://gitlab.psi.ch/OPAL/src/-/issues/559regression test MAP-Gantry2 is broken2020-07-08T10:20:55+02:00gsellregression test MAP-Gantry2 is brokenThe regression test 'MAP-Gantry2' is broken since July 6:
http://amas.web.psi.ch/opal/regressionTests/master/results_2020-07-06.xml
On July 1 the test still passed:
http://amas.web.psi.ch/opal/regressionTests/master/results_2020-07-01...The regression test 'MAP-Gantry2' is broken since July 6:
http://amas.web.psi.ch/opal/regressionTests/master/results_2020-07-06.xml
On July 1 the test still passed:
http://amas.web.psi.ch/opal/regressionTests/master/results_2020-07-01.xmlOPAL 2.4.0https://gitlab.psi.ch/OPAL/src/-/issues/558Particles get wrong charge if input file has different number of particles2020-07-06T16:47:55+02:00albajacas_aarnau.albajacas@psi.chParticles get wrong charge if input file has different number of particles### Summary
When inserting a distribution `FROMFILE`, if `NPART` is different from the number of lines in the input file, the total charge is wrongly modified.
This is because the charge-per-particle is set as `totalCharge / NPART` in ...### Summary
When inserting a distribution `FROMFILE`, if `NPART` is different from the number of lines in the input file, the total charge is wrongly modified.
This is because the charge-per-particle is set as `totalCharge / NPART` in `Beam.cpp` separately from `Distribution.cpp`, which simply gives an error:
```
if (numberOfDistParticles != numberOfParticles) {
*gmsg << "\n--------------------------------------------------" << endl
<< "Warning!! The number of particles in the initial" << endl
<< "distribution is " << numberOfDistParticles << "." << endl << endl
<< "This is different from the number of particles" << endl
<< "defined by the BEAM command: " << numberOfParticles << endl << endl
<< "This is often happens when using a FROMFILE type" << endl
<< "distribution and not matching the number of" << endl
<< "particles in the particles file(s) with the number" << endl
<< "given in the BEAM command." << endl << endl
<< "The number of particles in the initial distribution" << endl
<< "(" << numberOfDistParticles << ") "
<< "will take precedence." << endl
<< "---------------------------------------------------\n" << endl;
```
The simulation then continues, but you have more or less particles than `NPART`, and hence the charge-per-particle is too high or too low, and the total charge is different that what the user specified
### Steps to reproduce
For example if `initialDistro.in` has 5e5 particles, and you use
```
// INITIAL DISTRIBUTION
Dist: DISTRIBUTION, TYPE = FROMFILE, FNAME = "initialDistro.in",
EMITTED = FALSE;
// Electron Beam Definition
REAL beam_bunch_charge = 2e-9;
BEAM1: BEAM, PARTICLE = ELECTRON, GAMMA = gamma, NPART = 1e6,
BFREQ = rf_freq, BCURRENT = beam_bunch_charge * rf_freq * 1e6 , CHARGE = -1;
```
then you will get a warning, and the simulation will continue with a total charge of 1 nC instead of the 2 nC that the user specified.
### Possible fixes
I think the best solution is to simply output an error message and quit the simulation if `NPART != particles_in_file`.
The user can either correct `NPART` to be as in the file, or modify the file himself.OPAL 2.4.0albajacas_aarnau.albajacas@psi.chalbajacas_aarnau.albajacas@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/556missing include of Physics/Physics.h in tests/classic_src/AbsBeamline/SBend3D...2020-06-23T10:24:26+02:00gsellmissing include of Physics/Physics.h in tests/classic_src/AbsBeamline/SBend3DTest.cppOPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/546Bend without DESIGNENERGY gives infinite loop2020-07-09T10:48:48+02:00snuverink_jjochem.snuverink@psi.chBend without DESIGNENERGY gives infinite loop### Summary
Bend without DESIGNENERGY gives infinite loop
### Steps to reproduce
Define a bend without design energy
```
REAL bend_radius = 1;
REAL bend_angle = 0.1;
TLA_B : SBEND, ELEMEDGE=0.0, ANGLE = 25.0 / 180 * PI, FMAPFN = "1DP...### Summary
Bend without DESIGNENERGY gives infinite loop
### Steps to reproduce
Define a bend without design energy
```
REAL bend_radius = 1;
REAL bend_angle = 0.1;
TLA_B : SBEND, ELEMEDGE=0.0, ANGLE = 25.0 / 180 * PI, FMAPFN = "1DPROFILE1-DEFAULT", L = 2 * bend_radius * sin(bend_angle / 2.0), HAPERT = 2.2;
```
### What is the current *bug* behavior?
Infinite loop
### What is the expected *correct* behavior?
Either:
* Throw exception at parsing
* Track through with design energy zero
* Set design energy to initial energy of the beam
### Relevant logs and/or screenshots
```
OPAL[2]> Phase space dump frequency 1000 and statistics dump frequency 1 w.r.t. the time step.
SBend [2]> ======================================================================
SBend [2]> ===== TLA_B ==========================================================
SBend [2]> ======================================================================
SBend [2]> TLA_B using file 1DPROFILE1-DEFAULT (1D Profile type 1)
Warning> Warning: bend design energy is zero. Treating as drift.
^C
Program received signal SIGINT, Interrupt.
0x00000000008f10ee in Bend2D::calculateRefTrajectory(double&, double&) () at /home/scratch/OPAL/OPAL-fork/OPAL-src/ippl/src/PETE/PETE.h:800
800 PETE_DefineBinary(operator*, (a * b), OpMultipply)
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.212.el6.x86_64 infinipath-psm-3.0.1-115.1015_open.2.el6.x86_64 libnl-1.1.4-2.el6.x86_64 nss-pam-ldapd-0.7.5-20.el6_6.3.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) bt
#0 0x00000000008f10ee in Bend2D::calculateRefTrajectory(double&, double&) () at /home/scratch/OPAL/OPAL-fork/OPAL-src/ippl/src/PETE/PETE.h:800
#1 0x00000000008f2a4b in Bend2D::initialise(PartBunchBase<double, 3u>*, double&, double&) ()
at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/Classic/AbsBeamline/Bend2D.cpp:209
#2 0x000000000088ef8c in void OpalBeamline::visit<SBend>(SBend const&, BeamlineVisitor&, PartBunchBase<double, 3u>*) ()
at /home/scratch/OPAL/OPAL-fork/OPAL-src/src/Elements/OpalBeamline.h:107
#3 0x000000000087a7ee in ParallelTTracker::visitBeamline(Beamline const&) ()
```
### Cause
In `Bend2D::calculateRefTrajectory` and `RBend3D::trackRefParticleThrough` the stepSize is defined as follows:
```c++
const double stepSize = betaGamma / gamma * Physics::c * dt;
```
without `designenergy_m` = 0, `betaGamma` = `gamma` = 0.
Here a minimal step size could be set.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.ch2020-07-24https://gitlab.psi.ch/OPAL/src/-/issues/545Bend2D does not take particle charge into account2020-07-17T10:10:50+02:00snuverink_jjochem.snuverink@psi.chBend2D does not take particle charge into account### Summary
A `RBEND` or `SBEND` element does not take the particle charge into account.
This was discovered by Finn O'Shea, and posted to the OPAL mailing list.
### Steps to reproduce
Define two beams and a bend:
```
BEAM1: BEAM, P...### Summary
A `RBEND` or `SBEND` element does not take the particle charge into account.
This was discovered by Finn O'Shea, and posted to the OPAL mailing list.
### Steps to reproduce
Define two beams and a bend:
```
BEAM1: BEAM, PARTICLE=PROTON, PC=P0, NPART=1000, BCURRENT=2.0e-03, BFREQ=50, CHARGE=1;
BEAM2: BEAM, PARTICLE=ALPHA, PC=P0, NPART=1000, BCURRENT=2.0e-03, BFREQ=50, CHARGE=2, MASS=3.7274;
REAL switch_angle = 0.1;
REAL design_energy = 0.05;
SBEND, ANGLE = switch_angle,
FMAPFN = "1DPROFILE1-DEFAULT",
ELEMEDGE = 2.664,
DESIGNENERGY = design_energy,
L = 2 * switch_radius * sin(switch_angle / 2.0),
E1 = 0, E2 = 0, // make a "true" sector magnet
```
### What is the current *bug* behavior?
Same bend magnet strength for each beam.
### What is the expected *correct* behavior?
Different bending strength, reduced by a factor 2 for BEAM2.
### Relevant logs and/or screenshots
```c++
void Bend2D::setBendStrength() {
// Estimate bend field magnitude.
double mass = RefPartBunch_m->getM();
double gamma = designEnergy_m / mass + 1.0;
double betaGamma = sqrt(pow(gamma, 2.0) - 1.0);
double charge = RefPartBunch_m->getQ();
fieldAmplitude_m = ((charge / std::abs(charge)) * betaGamma * mass /
(Physics::c * designRadius_m));
```
This formula does only take the sign of the charge into account. It is repeated in `findIdealBendParameters`
### Possible fixes
The formulas should be adjusted such that the charge is taken into account properly. The following methods should be fixed:
* setBendStrength
* findIdealBendParameters
Possibly also:
* findBendStrength
* estimateFieldAdjustmentStepOPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/544Charge per macroparticle wrong for multicharged particles?2020-05-25T17:18:40+02:00snuverink_jjochem.snuverink@psi.chCharge per macroparticle wrong for multicharged particles?### Summary
The charge per macroparticle seems wrongly calculated in case of OPAL-T.
This was discovered by Finn O'Shea, and posted to the OPAL mailing list.
### Steps to reproduce
```
BEAM1: BEAM, PARTICLE=PROTON, PC=P0, NPART=1000,...### Summary
The charge per macroparticle seems wrongly calculated in case of OPAL-T.
This was discovered by Finn O'Shea, and posted to the OPAL mailing list.
### Steps to reproduce
```
BEAM1: BEAM, PARTICLE=PROTON, PC=P0, NPART=1000, BCURRENT=2.0e-03, BFREQ=50, CHARGE=1;
BEAM2: BEAM, PARTICLE=ALPHA, PC=P0, NPART=1000, BCURRENT=2.0e-03, BFREQ=50, CHARGE=2, MASS=3.7274;
```
### What is the current *bug* behavior?
BEAM1:
```
OPAL> * ************** B U N C H *********************************************************
OPAL> * NP = 1000
OPAL> * Qtot = 39.500 [pC] Qi = 39.500 [fC]
```
BEAM2:
```
OPAL> * ************** B U N C H *********************************************************
OPAL> * NP = 1000
OPAL> * Qtot = 79.000 [pC] Qi = 79.000 [fC]
```
### What is the expected *correct* behavior?
These two beams are expected to have the same charge per bunch and macroparticle (since `BCURRENT` and `FREQ` are constant).
### Relevant logs and/or screenshots
In TrackRun::setDistributionParallelT():
```c++
// Return charge per macroparticle.
return beam->getCharge() * beam->getCurrent() / (beam->getFrequency()*1.0e6) / numberOfParticles;
```
### Possible fixes
The factor `beam->getCharge()` should not be present in the formula. This is correctly calculated for OPAL-Cycl. Ideally the formula should be refactored to a separate function to reduce code duplication.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/542SAAMG: Wrong results with elliptic geometry2020-07-13T15:33:13+02:00frey_mSAAMG: Wrong results with elliptic geometry### Summary
The SAAMG solver with elliptic geometry yields wrong results. It behaves like a simulation without space-charge.
[SAAMG-FODO.in](/uploads/e9067345a2ef0e6684e4d8cc3a018696/SAAMG-FODO.in)
### Steps to reproduce
Run the atta...### Summary
The SAAMG solver with elliptic geometry yields wrong results. It behaves like a simulation without space-charge.
[SAAMG-FODO.in](/uploads/e9067345a2ef0e6684e4d8cc3a018696/SAAMG-FODO.in)
### Steps to reproduce
Run the attached file with either `INTERPL=CONSTANT` or `INTERPL=LINEAR`.
### What is the current *bug* behavior?
The simulation behaves as if space-charge is switched off (`FSTYPE = NONE`).
OPAL 2.4.0frey_mfrey_m2020-07-24https://gitlab.psi.ch/OPAL/src/-/issues/541SAAMG crashes after 1000 steps2020-05-19T19:31:56+02:00frey_mSAAMG crashes after 1000 stepsThe SAAMG solver crashes after 1000 steps since the matrices are deleted in `deletePtr` and the boolean `isMatrixFilled_m` is not reset.The SAAMG solver crashes after 1000 steps since the matrices are deleted in `deletePtr` and the boolean `isMatrixFilled_m` is not reset.OPAL 2.4.0frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/531including `cmath` required on macOS2020-04-30T13:29:10+02:00gsellincluding `cmath` required on macOS### Summary
On macOS we have to include `cmath` in several files otherwise compilation fails
### Steps to reproduce
Compile on macOS with current Xcode
### Relevant logs and/or screenshots
```
/Users/gsell/src/OPAL/src/src/Classic/...### Summary
On macOS we have to include `cmath` in several files otherwise compilation fails
### Steps to reproduce
Compile on macOS with current Xcode
### Relevant logs and/or screenshots
```
/Users/gsell/src/OPAL/src/src/Classic/Filters/RelativeFFTLowPass.cpp:28:12: error: call to 'abs' is ambiguous
if(std::abs(LD[i]) > max_four_coef) {
^~~~~~~~
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/stdlib.h:132:6: note:
candidate function
int abs(int) __pure2;
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/stdlib.h:110:44: note:
candidate function
inline _LIBCPP_INLINE_VISIBILITY long abs( long __x) _NOEXCEPT {return labs(__x);}
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/stdlib.h:112:44: note:
candidate function
inline _LIBCPP_INLINE_VISIBILITY long long abs(long long __x) _NOEXCEPT {return llabs(__x);}
(Paste any relevant logs - please use code blocks (```) to format console output,
logs, and code as it's very hard to read otherwise.)
```
### Possible fixes
include `cmath`
(If you can, link to the line of code that might be responsible for the problem)OPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/528Add missing ENABLE_AMR2020-04-29T10:10:14+02:00frey_mAdd missing ENABLE_AMRThere's a missing preprocessor directive causing the compilation to fail if AMR is not enabled (i.e. `ENABLE_AMR=FALSE`).
This error was introduced with !312.There's a missing preprocessor directive causing the compilation to fail if AMR is not enabled (i.e. `ENABLE_AMR=FALSE`).
This error was introduced with !312.frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/527runtime error on macOS: uncaught exception of type Teuchos::Exceptions::Inval...2020-07-06T13:48:05+02:00gsellruntime error on macOS: uncaught exception of type Teuchos::Exceptions::InvalidParameterType### Summary
Spiral inflector simulation crashes with uncaught exception (see below) on macOS. On Linux this error does **not** occur!
### Steps to reproduce
Run Daniel spiral inflector simulation
### Relevant logs and/or screenshots...### Summary
Spiral inflector simulation crashes with uncaught exception (see below) on macOS. On Linux this error does **not** occur!
### Steps to reproduce
Run Daniel spiral inflector simulation
### Relevant logs and/or screenshots
```
OPAL> * --------------------------------- Start tracking ------------------------------------ *
libc++abi.dylib: terminating with uncaught exception of type Teuchos::Exceptions::InvalidParameterType: Error! An attempt was made to access parameter "Nullspace" of type "Teuchos::RCP<Xpetra::MultiVector<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace> > >"
in the parameter (sub)list "ANONYMOUS->user data"
using the incorrect type "Teuchos::RCP<Tpetra::MultiVector<double, int, int, Kokkos::Compat::KokkosDeviceWrapperNode<Kokkos::Serial, Kokkos::HostSpace>, false> >"!
```OPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/526Runtime error on macOS: reduction MPI_SUM is not defined on MPI_INTEGER2020-04-29T09:51:03+02:00gsellRuntime error on macOS: reduction MPI_SUM is not defined on MPI_INTEGER### Summary
Runtime error on macOS: reduction MPI_SUM is not defined on MPI_INTEGER
### Steps to reproduce
Run spiral inflector simulation
### What is the current *bug* behavior?
run-time error
### Relevant logs and/or screenshots
...### Summary
Runtime error on macOS: reduction MPI_SUM is not defined on MPI_INTEGER
### Steps to reproduce
Run spiral inflector simulation
### What is the current *bug* behavior?
run-time error
### Relevant logs and/or screenshots
```
OPAL> * --------------------------------- Start tracking ------------------------------------ *
[Nimloth:21640] *** An error occurred in MPI_Scan: the reduction operation MPI_SUM is not defined on the MPI_INTEGER datatype
[Nimloth:21640] *** reported by process [922615809,0]
[Nimloth:21640] *** on communicator MPI_COMM_WORLD
[Nimloth:21640] *** MPI_ERR_OP: invalid reduce operation
[Nimloth:21640] *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
[Nimloth:21640] *** and potentially your MPI job)
```
### Possible fixes
`MPI_INTEGER` is a type for Fortran, use `MPI_INT` instead.OPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/524Distribution Unit Tests failing2020-05-27T09:44:41+02:00snuverink_jjochem.snuverink@psi.chDistribution Unit Tests failing### Summary
The distribution unit tests are failing. See also http://amas.web.psi.ch/opal/unitTests/master/results_2020-04-25.xml
### Steps to reproduce
compile OPAL with `BUILD_UNIT_TESTS`
```
./tests/opal_unit_tests --gtest_filter=...### Summary
The distribution unit tests are failing. See also http://amas.web.psi.ch/opal/unitTests/master/results_2020-04-25.xml
### Steps to reproduce
compile OPAL with `BUILD_UNIT_TESTS`
```
./tests/opal_unit_tests --gtest_filter=Binomial*
./tests/opal_unit_tests --gtest_filter=Gauss*
```
### What is the current *bug* behavior?
Segmentation fault
### What is the expected *correct* behavior?
Successful test
### Relevant logs and/or screenshots
```
Ippl> CommMPI: Parent process waiting for children ...
Ippl> CommMPI: Initialization complete.
Note: Google Test filter = Gauss*
[==========] Running 3 tests from 2 test suites.
[----------] Global test environment set-up.
[----------] 2 tests from GaussTest
[ RUN ] GaussTest.FullSigmaTest1
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00007fff92fdfa8d in __dynamic_cast ()
(gdb) bt
#0 0x00007fff92fdfa8d in __dynamic_cast ()
#1 0x0000000100567089 in Attributes::setString (attr=@0x105808a00, val=@0x7fff5fbfee80) at /Users/jsnuverink/Documents/OPAL/fork/src/src/Attributes/Attributes.cpp:363
#2 0x0000000100013301 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__is_long () at /opt/local/libexec/llvm-9.0/include/c++/v1/string:37
#3 0x0000000100013301 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::~basic_string () at /Users/jsnuverink/Documents/OPAL/fork/src/tests/opal_src/Distribution/GaussTest.cpp:2137
#4 0x0000000100013301 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::~basic_string () at /opt/local/libexec/llvm-9.0/include/c++/v1/string:2133
#5 0x0000000100013301 in GaussTest_FullSigmaTest1_Test::TestBody () at /Users/jsnuverink/Documents/OPAL/fork/src/tests/opal_src/Distribution/GaussTest.cpp:37
#6 0x0000000100b7ef03 in testing::internal::HandleSehExceptionsInMethodIfSupported<testing::TestSuite, void> () at gtest.cc:2433
#7 0x0000000100b63757 in testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void> (object=0x104600c80, method=not implemented: member type in c_val_print
) at gtest.cc:2469
#8 0x0000000100b23932 in testing::Test::Run (this=0x104600c80) at gtest.cc:2508
#9 0x0000000100b2533a in testing::TestInfo::Run (this=0x104414330) at gtest.cc:2684
#10 0x0000000100b263af in testing::TestSuite::Run (this=0x1044144a0) at gtest.cc:2816
#11 0x0000000100b3efe9 in testing::internal::UnitTestImpl::RunAllTests (this=0x104412ff0) at gtest.cc:5338
#12 0x0000000100b7fe73 in testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> (object=0x104412ff0, method=not implemented: member type in c_val_print
) at gtest.cc:2433
#13 0x0000000100b65bd7 in testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> (object=0x104412ff0, method=not implemented: member type in c_val_print
) at gtest.cc:2469
#14 0x0000000100b3e902 in testing::UnitTest::Run (this=0x100d863a0) at gtest.cc:4925
#15 0x0000000100003502 in RUN_ALL_TESTS () at /opt/local/include/gtest/gtest.h:2473
```
### Possible fixes
The Distribution attribute `TYPE` has been changed in !341 to uppercase. All setString methods should be changed in setUpperCaseString.
```
Attributes::setString(dist.itsAttr[Attrib::Distribution::TYPE], "GAUSS");
```
to
```
Attributes::setUpperCaseString(dist.itsAttr[Attrib::Distribution::TYPE], "GAUSS");
```OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/515Not all (Opal-T) field maps expect same origin for position2020-07-16T22:35:05+02:00krausNot all (Opal-T) field maps expect same origin for positionIn the method `getFieldstrength` some field maps expect the origin of the position at which the field should be evaluated to be at the beginning of the field map others at the origin of the element (`z = 0` in the field map).
All field ...In the method `getFieldstrength` some field maps expect the origin of the position at which the field should be evaluated to be at the beginning of the field map others at the origin of the element (`z = 0` in the field map).
All field maps should expect the position to be at the origin of the element.krauskraus