Dumping 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}> * 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().

@adelmann What was the purpose of distinguishing?

if (Options::psDumpFrame == Options::BUNCH_MEAN) {
    meanR = calcMeanR();
    meanP = calcMeanP();
} else {
    meanR = itsBunch_m->R[0];
    meanP = itsBunch_m->P[0];
}

Shouldn't we always use the whole bunch?

As far as i know the particle with id 0 should be the reference particle. In the future this should be replaced with a separate member such as in Opal-T.

Yes, the reference particle is the one with id 0. If dumping in global frame should take this particle, one would need to send this particle to the root core (if this core should do the work), otherwise it will be any particle sitting at index 0 of the root core.

I agree, the way it is implemented now is far from ideal.

I discussed it yesterday also with @adelmann. We need something similar what you implemented in OPAL-T in OPAL-Cycl. I say 'similar' because in our case we might have several bunches in a cyclotron, thus, each bunch would need a reference particle.

Then we change the type of RefPartR_m and RefPartP_m to std::vector<Vector_t>.

Yes, that would work. I'm not aware of how the reference particle is set / computed, but I assume it's the mean R and mean P -- at least that would make sense for me. In that case there's also additional work I / we have to do w.r.t. multibunch simulations. We might need another PartBunchBase attribute to identify the bunch a particle belongs to in order evaluate the reference particle. But this shouldn't be a topic in this thread.

In Opal-T it's not the centroid but a separate particle. If it's the centroid then you can't evaluate the effect of misaligned or otherwise faulty elements.

@winklehner_d: @kraus did a nice implementation of the reference particle for OPAL-T. @adelmann told me that you started with something similar, right? I'd like to modify the ParallelCyclotronTracker such that we can handle single and multi-bunch simulations and replace the calls itsBunch_m->R[0].

mentioned in issue #201 (closed)

@kraus: I discussed with @rizzoglio_v about the reference particle in OPAL-T and OPAL-Cyc, because she knows both trackers as a user. Since I'm in my AMR-world, I did not realize that you can specify an ID1 and ID2 particle as reference. In OPAL-1.6, those particles are used for writing a trackOrbit file, however, in OPAL-1.9/2.0 not. What's the reason for this change? I have another question about RefPartR_m. I did a grep on it to find how its values are set. I could only find that it's set to zero, i.e.

RefPartR_m = Vector_t(0.0);

or like this

RefPartR_m(0.0);

Did I overlook anything?

Concerning RefPartR_m: have a look at src/Algorithms/ParallelTTracker.cpp e.g. line 259 or line 308.

ID1 and ID2 used the same vector as the regular particles. In consequence we had to search for them on all nodes and then send the information to node 0. If we reimplement this feature then we have separate ID1 and ID2 from the regular particles.

Hmm, isn't RefPartR_m also only set to zero in TrackRun.cpp line 511, i.e.

Track::block->bunch->RefPartR_m = Vector_t(0.0);

Don't worry, I'll find out ...

ID1, ID2: Yes, I saw this sending around (what I do not like also). @adelmann told me (also written in an earlier message) that @winklehner_d started something with TracerParticles.

marked this issue as related to #287

added OPAL-cycl label

This works now!

closed