Resolve "Orbit threader throws an exception when TRACKBACK = TRUE and traveling wave structure present"

Closes #494 (closed)

changed milestone to %OPAL-2.2.0

added Bug OPAL-T + 1 deleted label

added 1 commit

• 5dccf6c1 - don't override the method trackOnAxisParticle

Compare with previous version

unmarked as a Work In Progress

This also needs to be applied to version 2.2.

The implementation of its parent class RFCavity clearly differs in the implementation. Is RFCavity::trackOnAxisParticle just a newer implementation and the behavior is the same?

I think that I adapted the method on the RFCavity side to be able to track back in time. It's also much simpler because it makes use of the applyToRefParticle.

approved this merge request

Very hard to judge if these methods are similar, but conceptually they seem to be. Did you test this, e.g. with the regression test ExternalFieldTest?

However, I see some differences between the two methods trackOnAxisParticle:

• TravelingWave uses the charge q (RFCavity doesn't)
• TravelingWave does not use RFCavity::startField_m, RFCavity::endField_m (which are used in trackOnAxisParticle), but its own members for this.

Especially the last one seems important to me. This might fixed by defining startField_m and endField_m in TravelingWave::initialise (and making them protected instead of private).

By the way, TravelingWave and RFCavity each have private members and initialise method that have the same name or are similar (length_m, fast_m, designEnergy_m, fieldmap_m vs CoreFieldmap_m, etc. ) . In a proper inheritance these members are shared from the parent and the TravelingWave::initialise would call the RFCavity::initialise.

I've tested it with the input file of Youna, see e-mail on mailing list.

• the RFCavity side doesn't use q in the method directly but uses an instance of the BorisPusher, which uses q.
• startField_m is indeed not set, so it probably just has the value zero. The method then would miss the entrance fringe field. Have to look into that.

At the moment I don't have the time to rewrite the two classes (have to watch the kids half the day and do my regular job the other half). They were two independent classes, that might explain why the TravelingWave class is currently not in such a good shape. But fieldmap_m isn't the same as CoreFieldmap_m. The field maps for TWS have three parts: the entrance, the exit and the core. The latter needs to be repeated N times and evaluate twice (shifted and at different phases). Once we have the general field map reader (#327) then we can simplify the TravelingWave class or get rid of it.

approved this merge request

added 1 commit

• 11939e7c - cleaning up a bit

Compare with previous version

added 1 commit

• 96e26bed - fix typo and error message for failed parsing of field maps

Compare with previous version

added 1 commit

• e3b41e65 - throw an exception if something isnt' right about the length of the field map

Compare with previous version

approved this merge request

added 1 commit

• 2a94b80e - Fix typo

Compare with previous version

resolved all discussions

approved this merge request

approved this merge request

mentioned in commit 0b72a1d4

merged