Code indexing in gitaly is broken and leads to code not being visible to the user. We work on the issue with highest priority.

Skip to content
Snippets Groups Projects

Resolve "Variables of incident particles in OPAL-t elements"

Merged Resolve "Variables of incident particles in OPAL-t elements"
683-variables-of-incident-particles-in-opal-t-elements into master
1 unresolved thread
Merged ext-calvo_p requested to merge 683-variables-of-incident-particles-in-opal-t-elements into master
1 unresolved thread

Closes #683 (closed)

Edited by ext-calvo_p

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
src/Classic/AbsBeamline/FlexibleCollimator.cpp
102 102 bool FlexibleCollimator::apply(const size_t &i, const double &t, Vector_t &/*E*/, Vector_t &/*B*/) {
103 103 const Vector_t &R = RefPartBunch_m->R[i];
104 104 const Vector_t &P = RefPartBunch_m->P[i];
105 105 const double &dt = RefPartBunch_m->dt[i];
106 const double recpgamma = Physics::c * dt / std::sqrt(1.0 + dot(P, P));
106 const Vector_t singleStep = Physics::c * dt * Util::getBeta(P);
107 107 bool pdead = isStopped(R);
108 108
109 109 if (pdead) {
110 110 if (lossDs_m) {
111 double frac = -R(2) / P(2) * recpgamma;
111 double frac = -R(2) / singleStep(2);
112 112 lossDs_m->addParticle(OpalParticle(RefPartBunch_m->ID[i],
113 R, P,
113 R + frac * singleStep, P,
114 114 t + frac * dt,
  • snuverink_j
    snuverink_j @snuverink_j ·
    Developer

    FLEXIBLECOLLIMATOR records one step after the element input

    Why do we do this?

    And what does frac represent here? I would have expected R + singleStep and t + dt?

  • ext-calvo_p
    ext-calvo_p @ext-calvo_p ·
    Author Developer

    frac is the fraction of a step the particle is away from the edge. It is introduced to establish the storing of particles in the physical boundary of the element. Currently, the particles are being stored in the position corresponding to the subsequent step once the edge has been crossed.

  • snuverink_j
    snuverink_j @snuverink_j ·
    Developer

    okay thanks for clarifying. But is the frac calculation correct in all cases? What if the particles enter transversely?

  • kraus
    kraus @kraus ·
    Developer

    Particles that enter a collimator transversely doesn't make much sense, does it? I know, I've introduced the option to avoid deletion of particles entering elements transversely and adapted also the FlexibleCollimator class but I think I should revert it (only changes in FlexibleCollimator).

    Edited by kraus
  • snuverink_j
    snuverink_j @snuverink_j ·
    Developer

    It depends, there are some collimators that have a cone-like shape to distribute the losses more evenly along the collimator. I don't know if such collimators are supported in OPAL. Also if the beam is diverging in this area, transverse particles could happen occasionally.

    But if you both think it is fine, I don't mind and I am fine with the changes.

  • Please register or sign in to reply
  • snuverink_j
  • ext-calvo_p added 1 commit

    added 1 commit

    Compare with previous version

  • ext-calvo_p added 1 commit

    added 1 commit

    Compare with previous version

  • ext-calvo_p added Cleanup label

    added Cleanup label

  • ext-calvo_p added 1 commit

    added 1 commit

    Compare with previous version

  • snuverink_j approved this merge request

    approved this merge request

  • kraus approved this merge request

    approved this merge request

  • ext-calvo_p merged

    merged

  • ext-calvo_p mentioned in commit 140193bd

    mentioned in commit 140193bd

    • Please register or sign in to reply