Skip to Content.
Sympa Menu

opal - Re: [Opal] opal finishes before ZSTOP value

opal AT lists.psi.ch

Subject: The OPAL Discussion Forum

List archive

Re: [Opal] opal finishes before ZSTOP value


Chronological Thread  
  • From: Philippe Piot <philippe.piot AT gmail.com>
  • To: "Adelmann Andreas (PSI)" <andreas.adelmann AT psi.ch>
  • Cc: Christof Metzger-Kraus <christof.j.kraus AT gmail.com>, "opal AT lists.psi.ch" <opal AT lists.psi.ch>, "Gsell Achim (PSI)" <achim.gsell AT psi.ch>
  • Subject: Re: [Opal] opal finishes before ZSTOP value
  • Date: Fri, 17 Sep 2021 08:57:37 -0500
  • Authentication-results: mc3.ethz.ch; iprev=pass (mail-pf1-f172.google.com) smtp.remote-ip=209.85.210.172; spf=pass smtp.mailfrom=gmail.com; dkim=pass header.d=gmail.com header.s=20210112 header.a=rsa-sha256; dmarc=pass header.from=gmail.com

Christof, Andreas,
  Thank you for your help. For now, I just rotated the field and coordinate system by hand before importing them in OPAL and it all works fine.
  All the best, -- Philippe.

On Wed, Sep 15, 2021 at 7:26 AM Adelmann Andreas (PSI) <andreas.adelmann AT psi.ch> wrote:
Hoi Christof do you have time and check if the new option solves
the problem of Philippe? If so, we maybe can include https://gitlab.psi.ch/OPAL/src/-/issues/673 
in the  2021.1 release. 

We are anyway late …. with 2021.1 :) !

Cheers A
------
Dr. sc. math. Andreas (Andy) Adelmann
Head a.i. Labor for Scientific Computing and Modelling 
Paul Scherrer Institut OHSA/ CH-5232 Villigen PSI
Phone Office: xx41 56 310 42 33 Fax: xx41 56 310 31 91
Zoom ID: 470-582-4086 Password: AdA
Zoom Link: https://ethz.zoom.us/j/4705824086?pwd=dFcvT1pMMGY0bHg0dTNncUNZZTJkZz09

-------------------------------------------------------
Friday: ETH HPK G 28   +41 44 633 3076
============================================
The more exotic, the more abstract the knowledge, 
the more profound will be its consequences.
Leon Lederman 
============================================

On 15 Sep 2021, at 13:40, Christof Metzger-Kraus <christof.j.kraus AT gmail.com> wrote:

Hoi Philippe,

I think the reason is that all particles are deleted when they exit on the side of an element. Simon had a similar problem (alpha magnet). I’ve implemented an option to switch this behavior off a few weeks ago (
https://gitlab.psi.ch/OPAL/src/-/issues/673). This should help. However this feature didn’t make it into release 2021.1. You could reorder the field sampling, wait for the next release or build the executable.

I could help you reorder the field sampling.

Christof

Philippe Piot <philippe.piot AT gmail.com> schrieb am Mi. 15. Sept. 2021 um 12:57:
Thank you, Andreas, Simon, and Christof. Unfortunately, none of the suggestions worked:
- adding the ELEMEDGE to the drifts did not change anything
- I had looked at the particle trajectories; see below and they seem like following the trajectory I would expect in a deflecting cavity with a vertical deflection kick.
- I set my field to very low values and try to remove my -Pi/2 rotation and the simulation runs all the way. So I suspect something to do with the rotation.

The fields I was given were dumped on an (x,y,z) with x being the cavity axis hence my rotation by -Pi/2 around the y axis (by the way in orientation the {Theta, Phi, Psi} Theta is the rotation along the y-axis) I use the L=0.032 corresponding to the length of the cavity (which corresponds to the direction in the original CST file).

In case somebody wants to check I made a tar-ziped file attached. Thank you very much. All the best, -- Philippe.

<image.png>


On Tue, Sep 14, 2021 at 7:18 AM Christof Metzger-Kraus <christof.j.kraus AT gmail.com> wrote:
Hi Philippe,

could you create the outline of the beamline (python data/deflector_ElementPositions.py --project-to-plane), plot it with gnuplot and check that everything looks fine? If it does look fine then you could also plot the path of the reference particle (in data/deflector_DesignPath.dat columns 4 and 2).

I've tried a similar scenario with the Slit-2 regression test (https://gitlab.psi.ch/OPAL/regression-tests/-/tree/master/RegressionTests/Slit-2) by replacing ELEMEDGE with ORIGIN. It worked fine.

Christof

On Tue, Sep 14, 2021 at 12:58 PM Philippe Piot <philippe.piot AT gmail.com> wrote:
Dear All,
  I have a very simple beamline as follows:

TDC:   RFCavity, L = 0.032, VOLT = 1*Vtdc, ORIGIN = {0,0,0.016},
       ORIENTATION = {-Pi/2.,0.0, 0.0}, TYPE = "STANDING",
       FMAPFN = "./xBandDeflector.T7", FREQ = 11700.0, LAG = tdcPhi;
DR1: DRIFT, L = 1.0, ORIGIN = {0., 0., 0.0};
MyLine: Line = (TDC, DR1);

combined with the track command
TRACK, LINE = MyLine, BEAM = BEAM1, MAXSTEPS = 1900000, DT = 1.0e-13, ZSTOP=0.15;

  Somehow OPAL always end at 0.032 (which appears to coincide with the end of the RFCavity element) and the output ends with

OPAL {0}[2]> * Wrote beam phase space.
ParallelTTracker {0}[2]> Dump phase space of last step
Ippl{0}[3]> DR1 gone off
Ippl{0}[3]> DR2 gone off
Ippl{0}[3]>
Ippl{0}[3]> * ************ I N F O *********************************************************
Ippl{0}[3]> * freed fieldmap './xBandDeflector.T7'                                         *
Ippl{0}[3]> * ******************************************************************************
Ippl{0}[3]>
Ippl{0}[3]>
Ippl{0}[3]> TDC gone off
OPAL{0}> done executing ParallelTTracker at 05:54:44
OPAL{0}> * End of input stream "deflector.in".
  Somehow it claims (I think the "gone off" meaning) there is no more element after the RFCavity?
    I also tried different combinations with drift but it did not help. Thank you, -- Philippe.





Archive powered by MHonArc 2.6.19.

Top of Page