src issueshttps://gitlab.psi.ch/OPAL/src/-/issues2020-07-24T12:51:42+02:00https://gitlab.psi.ch/OPAL/src/-/issues/565Code duplication in Domains2020-07-24T12:51:42+02:00frey_mCode duplication in DomainsThe following discussion from !372 should be addressed:
- [x] @snuverink_j started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/372#note_24147): (+3 comments)
> The first part of this function is now duplicated thr...The following discussion from !372 should be addressed:
- [x] @snuverink_j started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/372#note_24147): (+3 comments)
> The first part of this function is now duplicated three times: once here, once in `BoxCornerDomain::constantInterpolation` and once in `EllipticDomain::constantInterpolation`.
>
> I think a helper method in the base class would be good to reduce the duplication.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/562General elements for electrostatitic and magnetostatic fields2021-06-10T17:47:02+02:00krausGeneral elements for electrostatitic and magnetostatic fields### Summary
Currently not every element can be modeled with a specific element in Opal. Instead one has to use 3D field maps and either a solenoid (only for magneto static fields) or an rf cavity. This isn't very intuitive. Instead we c...### Summary
Currently not every element can be modeled with a specific element in Opal. Instead one has to use 3D field maps and either a solenoid (only for magneto static fields) or an rf cavity. This isn't very intuitive. Instead we could provide "blank" elements for the general case, e.g. GENERALELECTROSTATIC and GENERALMAGNETOSTATIC.https://gitlab.psi.ch/OPAL/src/-/issues/561run.time of GreenWakeFunctionTest unit-test2020-07-08T11:20:09+02:00gsellrun.time of GreenWakeFunctionTest unit-testThe `GreenWakeFunctionTest` runs longer than 240 seconds on my (pretty new Macbook). This is a bit long for a unit-test. Would it be possible to make this test faster?The `GreenWakeFunctionTest` runs longer than 240 seconds on my (pretty new Macbook). This is a bit long for a unit-test. Would it be possible to make this test faster?OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://gitlab.psi.ch/OPAL/src/-/issues/560`Util/Util.cpp` always compiled (Follow-up from "Resolve "better solution to ...2020-07-07T13:37:48+02:00snuverink_jjochem.snuverink@psi.ch`Util/Util.cpp` always compiled (Follow-up from "Resolve "better solution to create/update src/OPALrevision.h")The following discussion from !381 should be addressed:
- [x] @kraus started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/381#note_23778): (+1 comment)
> The downside of the current method is that `Util/Util.cpp` i...The following discussion from !381 should be addressed:
- [x] @kraus started a [discussion](https://gitlab.psi.ch/OPAL/src/merge_requests/381#note_23778): (+1 comment)
> The downside of the current method is that `Util/Util.cpp` is compiled every time `make` is called. It is compiled even if there are no other files that have to be compiled, e.g. when calling `make` twice without changing anything inbetween.OPAL 2.4.0snuverink_jjochem.snuverink@psi.chsnuverink_jjochem.snuverink@psi.chhttps://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/554Unused classes in src2020-07-21T10:31:37+02:00ext-calvo_ppedro.calvo@ciemat.esUnused classes in srcThere are some unused classes in opal that should be removed.
| class | @kraus | @adelmann | @frey\_m | @snuverink\_j | @ext\-rogers\_c |
| ------ | ---- | ---- | ---- | ---- | ---- |
| Alg...There are some unused classes in opal that should be removed.
| class | @kraus | @adelmann | @frey\_m | @snuverink\_j | @ext\-rogers\_c |
| ------ | ---- | ---- | ---- | ---- | ---- |
| Algorithms/ParallelTTracker | :x: | :x: | :x: | :x: | :x: |
| AbstractObjects/Editor | :+1: | :+1: | :+1: | :+1: | :+1: |
| Algorithms/AbstractMapper | :+1: | :+1: | :+1: | :+1: | :+1: |
| Algorithms/LinearMapper | :+1: | :+1: | :+1: | :+1: | :+1: |
| Algorithms/Mapper | :+1: | :+1: | :+1: | :+1: | :+1: |
| Algorithms/rbendmap | :+1: | :+1: | :+1: | :+1: | :+1: |
| Algorithms/Surveyor | :+1: | :+1: | :+1: | :+1: | :+1: |
| Algorithms/ThinMapper | :+1: | :+1: | :+1: | :+1: | :+1: |
| Algorithms/ThinTracker | :+1: | :+1: | :+1: | :+1: | :+1: |
| BasicActions/Dump | :+1: | :+1: | :+1: | :+1: | :+1: |
| BasicActions/Save | :+1: | :+1: | :+1: | :+1: | :+1: |
| BasicActions/Show | :+1: | :+1: | :+1: | :+1: | :+1: |
| BasicActions/What | :+1: | :+1: | :+1: | :+1: | :+1: |
| BeamlineGeometry/OffsetGeometry | :+1: | :+1: | :+1: | :+1: | :+1: |
| BeamlineGeometry/SRotatedGeometry | :+1: | :+1: | :+1: | :+1: | :+1: |
| Construction/ElementFactory | :+1: | :+1: | :+1: | :+1: | :+1: |
| Construction/Factory | :+1: | :+1: | :+1: | :+1: | :+1: |
| Elements/AttCell | :+1: | :+1: | :+1: | :+1: | :+1: |
| Elements/OpalHMonitor | :+1: | :+1: | :+1: | :+1: | :+1: |
| Elements/OpalVMonitor | :+1: | :+1: | :+1: | :+1: | :+1: |
| Elements/OpalInstrument | :+1: | :+1: | :+1: | :+1: | :+1: |
| Elements/OpalParallelPlate | :+1: | :+1: | :+1: | :+1: | :+1: |
| Elements/OpalPatch | :+1: | :+1: | :+1: | :+1: | :+1: |
| Elements/OpalSplineTimeDependence | :x: | :x: | :+1: | :+1: | :x: |
| Elements/OpalSRot | :+1: | :+1: | :+1: | :+1: | :+1: |
| Elements/OpalYRot | :+1: | :+1: | :+1: | :+1: | :+1: |
| Elements/OpalSeparator | :+1: | :+1: | :+1: | :+1: | :+1: |
| Fields/Interpolation/ConstEField | :+1: | :+1: | :+1: | :+1: | :+1: |
| Fields/Interpolation/EDipoleField | :+1: | :+1: | :+1: | :+1: | :+1: |
| Fields/Interpolation/TwoDGrid | :x: | :x: | :+1: | :+1: | :x: |
| FixedAlgebra/FNormalForm | :+1: | :+1: | :+1: | :+1: | :+1: |
| FixedAlgebra/FStaticFP | :+1: | :+1: | :+1: | :+1: | :+1: |
| FixedAlgebra/LinearMath | :+1: | :+1: | :+1: | :+1: | :+1: |
| FixedAlgebra/TransportMath | :+1: | :+1: | :+1: | :+1: | :+1: |
| Tables/AttList | :+1: | :+1: | :+1: | :+1: | :+1: |
| Tables/AttWriter | :+1: | :+1: | :+1: | :+1: | :+1: |
| Tables/Flatten | :+1: | :+1: | :+1: | :+1: | :+1: |
| Tables/Insertion | :+1: | :+1: | :+1: | :+1: | :+1: |
| Tables/Period | :+1: | :+1: | :+1: | :+1: | :+1: |
| Tables/Survey | :+1: | :+1: | :+1: | :+1: | :+1: |
| Tables/Twiss | :+1: | :+1: | :+1: | :+1: | :+1: |
| Track/TrackStart | :+1: | :+1: | :+1: | :+1: | :+1: |
| Track/TrackSave | :+1: | :+1: | :+1: | :+1: | :+1: |
| AbsBeamline/BeamBeam | :+1: | :+1: | :+1: | :+1: | :+1: |
| AbsBeamline/Diagnostic | :+1: | :+1: | :+1: | :+1: | :+1: |
| AbsBeamline/ElementImage | :+1: | :+1: | :+1: | :+1: | :+1: |
| AbsBeamline/Integrator | :+1: | :+1: | :+1: | :+1: | :+1: |
| AbsBeamline/Lambertson | :+1: | :+1: | :+1: | :+1: | :+1: |
| AbsBeamline/ParallelPlate | :+1: | :+1: | :+1: | :+1: | :+1: |
| AbsBeamline/Patch | :+1: | :+1: | :+1: | :+1: | :+1: |
| AbsBeamline/RFQuadrupole | :+1: | :+1: | :+1: | :+1: | :+1: |
| AbsBeamline/Separator | :+1: | :+1: | :+1: | :+1: | :+1: |
| Algorithms/NilTracker | :+1: | :+1: | :+1: | :+1: | :+1: |
| Algorithms/ThickMapper | :+1: | :+1: | :+1: | :+1: | :+1: |
| BeamlineCore/BeamBeamRep | :+1: | :+1: | :+1: | :+1: | :+1: |
| BeamlineCore/ParallelPlateRep | :+1: | :+1: | :+1: | :+1: | :+1: |
| BeamlineCore/PatchRep | :+1: | :+1: | :+1: | :+1: | :+1: |
| BeamlineCore/SeparatorRep | :+1: | :+1: | :+1: | :+1: | :+1: |
| BeamlineCore/XMonitorRep | :+1: | :+1: | :+1: | :+1: | :+1: |
| BeamlineCore/YMonitorRep | :+1: | :+1: | :+1: | :+1: | :+1: |
| Expressions/ARefAttr | :+1: | :+1: | :+1: | :+1: | :+1: |
Please have a look at these files and please give your ok, if the files can be deleted.OPAL 2.4.0frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/552Replacing variables containing strings2020-06-08T16:58:39+02:00krausReplacing variables containing stringsCurrently replacing variables in strings, e.g. `FIELDMAP="${test}"` only works with variables containing reals. However users also try to replace variables of strings. Booleans could also replaced although I see no use for that yet.Currently replacing variables in strings, e.g. `FIELDMAP="${test}"` only works with variables containing reals. However users also try to replace variables of strings. Booleans could also replaced although I see no use for that yet.krauskraushttps://gitlab.psi.ch/OPAL/src/-/issues/551remove unused code for secondary emission2020-06-09T17:07:06+02:00gsellremove unused code for secondary emissionThe secondary emission code is not used, not supported and should be removed.The secondary emission code is not used, not supported and should be removed.OPAL 2.4.0gsellgsellhttps://gitlab.psi.ch/OPAL/src/-/issues/550Replace hardcoded data directory with OpalData function2020-06-08T16:58:39+02:00frey_mReplace hardcoded data directory with OpalData functionIn MR https://gitlab.psi.ch/OPAL/src/merge_requests/376 we introduced the function `getAuxiliaryOutputDirectory` in order to avoid hard-coded directory names. All `data` need to be replaced.In MR https://gitlab.psi.ch/OPAL/src/merge_requests/376 we introduced the function `getAuxiliaryOutputDirectory` in order to avoid hard-coded directory names. All `data` need to be replaced.frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/549Output format of electric field with DBG_SCALARFIELD=TRUE2020-06-03T16:24:25+02:00frey_mOutput format of electric field with DBG_SCALARFIELD=TRUEWhen enabling `DBG_SCALARFIELD=TRUE` OPAL prints the scalar and vector fields to files. In case of a vector field the brackets and commas a written, making it unnecessarily difficult to parse with Python. An example is the electric field...When enabling `DBG_SCALARFIELD=TRUE` OPAL prints the scalar and vector fields to files. In case of a vector field the brackets and commas a written, making it unnecessarily difficult to parse with Python. An example is the electric field with
following output format:
```bash
x y z ( Ex , Ey , Ez )
```
I discussed it with @winklehner\_d and he okayed to change it.frey_mfrey_mhttps://gitlab.psi.ch/OPAL/src/-/issues/548Remove MapIntegrator and TrackIntegrator classes2020-07-06T13:48:31+02:00krausRemove MapIntegrator and TrackIntegrator classesThe class `MapIntegrator` is the only derived class of `TrackIntegrator` and both have the pure virtual function `clone`. I don't see how they should be used if no class is derived that implements this function.The class `MapIntegrator` is the only derived class of `TrackIntegrator` and both have the pure virtual function `clone`. I don't see how they should be used if no class is derived that implements this function.OPAL 2.4.0krauskraushttps://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/543SAAMG: Enable RectangularDomain2020-07-21T13:53:57+02:00frey_mSAAMG: Enable RectangularDomainThe rectangular domain is currently not added to the SAAMG.The rectangular domain is currently not added to the SAAMG.OPAL 2.4.0frey_mfrey_mhttps://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-24