src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2021-05-26T12:54:27+02:00https://gitlab.psi.ch/OPAL/src/-/issues/574P3M solver declaration is missing2021-05-26T12:54:27+02:00ext-calvo_ppedro.calvo@ciemat.esP3M solver declaration is missingP3M solver is missing as FieldSolver type (`FSTYPE`) in FieldSolver.cpp. In addition, it is not documented in the manual (OPAL/documentation/manual#41)P3M solver is missing as FieldSolver type (`FSTYPE`) in FieldSolver.cpp. In addition, it is not documented in the manual (OPAL/documentation/manual#41)OPAL-3.0https://gitlab.psi.ch/OPAL/src/-/issues/573Broken tests due to #5092020-07-22T16:32:17+02:00krausBroken tests due to #509OPAL 2.4.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/572Source elements should delete particles that are pushed back into it2020-07-21T09:52:51+02:00krausSource elements should delete particles that are pushed back into itThe current if statement doesn't detect any particle that has a negative z-component of the momentum and are pushed into it.The current if statement doesn't detect any particle that has a negative z-component of the momentum and are pushed into it.OPAL 2.4.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/571Option MINBINEMITTED and MINSTEPFORREBIN not working2020-07-20T11:45:16+02:00krausOption MINBINEMITTED and MINSTEPFORREBIN not workingThese options just give the default values instead of the ones provided by the user.These options just give the default values instead of the ones provided by the user.OPAL 2.4.0krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/570segmentation fault in unit-test Field.PeriodicBC2020-07-22T15:09:16+02:00gsellsegmentation fault in unit-test Field.PeriodicBC### Summary
Segmentation fault in unit-test `Field.PeriodicBC` on Merlin with the following toolchain:
```
module load cmake/3.15.5
module load gnuplot/5.2.7
module load Python/3.6.3
module load gcc/8.4.0
module load gsl/2.6
module lo...### Summary
Segmentation fault in unit-test `Field.PeriodicBC` on Merlin with the following toolchain:
```
module load cmake/3.15.5
module load gnuplot/5.2.7
module load Python/3.6.3
module load gcc/8.4.0
module load gsl/2.6
module load OpenBLAS/0.3.10
module load gtest/1.10.0
module load openmpi/3.1.6
module load amrex/18.07_3d
module load boost/1.70.0
module load hdf5/1.10.6
module load parmetis/4.0.3
module load H5hut/2.0.0rc6
module load trilinos/12.18.1
```
Same problem on macOS and Clang/10 instead of gcc/8.4.0.
But no problem on `opalrunner.psi.ch`!
### Steps to reproduce
Login to one of the login-node of Merlin, compile OPAL with above modules and run unit.tests or run on macOS 10.15 with current Xcode.
### What is the current *bug* behavior?
Segmentation fault in `Field.PeriodicBC`
```
[ RUN ] Field.PeriodicBC
[merlin-l-002:20033] *** Process received signal ***
[merlin-l-002:20033] Signal: Segmentation fault (11)
[merlin-l-002:20033] Signal code: Address not mapped (1)
[merlin-l-002:20033] Failing at address: 0xffffffffffffffe8
[merlin-l-002:20033] [ 0] /lib64/libpthread.so.0(+0xf630)[0x7fbc1aa4b630]
[merlin-l-002:20033] [ 1] /opt/psi/Programming/gcc/8.4.0/lib64/libstdc++.so.6(_ZNSo6sentryC2ERSo+0x16)[0x7fbc18a479c6]
[merlin-l-002:20033] [ 2] /opt/psi/Programming/gcc/8.4.0/lib64/libstdc++.so.6(_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l+0x28)[0x7fbc18a47fd8]
[merlin-l-002:20033] [ 3] /opt/psi/Programming/gcc/8.4.0/lib64/libstdc++.so.6(_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc+0x27)[0x7fbc18a483e7]
[merlin-l-002:20033] [ 4] opal_unit_tests(_ZN15FieldDebugPrintIdLj3EE5printER9BareFieldIdLj3EERK7NDIndexILj3EER6Informb+0x8fb)[0x136ef7b]
[merlin-l-002:20033] [ 5] opal_unit_tests(_Z4sfp3IdEvR9BareFieldIT_Lj3EEiiiiiiiiib+0x2dc)[0x136ff9c]
[merlin-l-002:20033] [ 6] opal_unit_tests(_Z3fp3IdEvR9BareFieldIT_Lj3EEb+0x75)[0x13705f5]
[merlin-l-002:20033] [ 7] opal_unit_tests(_ZN21Field_PeriodicBC_Test8TestBodyEv+0x996)[0x13960b6]
[merlin-l-002:20033] [ 8] opal_unit_tests(_ZN7testing8internal35HandleExceptionsInMethodIfSupportedINS_4TestEvEET0_PT_MS4_FS3_vEPKc+0x3a)[0x370176a]
[merlin-l-002:20033] [ 9] opal_unit_tests(_ZN7testing4Test3RunEv+0xba)[0x36f69ca]
[merlin-l-002:20033] [10] opal_unit_tests(_ZN7testing8TestInfo3RunEv+0x118)[0x36f6b18]
[merlin-l-002:20033] [11] opal_unit_tests(_ZN7testing8TestCase3RunEv+0xb5)[0x36f7135]
[merlin-l-002:20033] [12] opal_unit_tests(_ZN7testing8internal12UnitTestImpl11RunAllTestsEv+0x44c)[0x36f855c]
[merlin-l-002:20033] [13] opal_unit_tests(_ZN7testing8UnitTest3RunEv+0x51)[0x36f8651]
[merlin-l-002:20033] [14] opal_unit_tests(main+0xa8)[0xeb9a98]
[merlin-l-002:20033] [15] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7fbc18367545]
[merlin-l-002:20033] [16] opal_unit_tests[0xeec448]
[merlin-l-002:20033] *** End of error message ***
./run-tests: line 305: 20033 Segmentation fault ${tests_bin} "${unittests_args[@]}"
```OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.ch2020-07-24https://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/557Optimizer gets stuck2021-06-10T19:16:54+02:00snuverink_jjochem.snuverink@psi.chOptimizer gets stuckAs reported by Finn O'Shea: the optimizer get stuck from time to time with the following example:
[fdopt.in](/uploads/e8ef7cb47cc60dcfbb8daab723b461df/fdopt.in)
[fdopt.data](/uploads/2f965a6b27a71ba36ab64519a5d8c74d/fdopt.data)
[fdopt.t...As reported by Finn O'Shea: the optimizer get stuck from time to time with the following example:
[fdopt.in](/uploads/e8ef7cb47cc60dcfbb8daab723b461df/fdopt.in)
[fdopt.data](/uploads/2f965a6b27a71ba36ab64519a5d8c74d/fdopt.data)
[fdopt.tmpl](/uploads/6e7dc37c7fe54832e01c0d7a41755e2f/fdopt.tmpl)snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@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_m