Slow simulations when apertures enables

[jonasbjorklundsvensson]

Hi,

I'm trying to run simulations with apertures enabled to simulate some expected particle loss in the beam pipe, but I'm encountering some unexpected behavior. I'm running the latest version of Ocelot from the dev branch.

Firstly, I tried following the tutorial in https://nbviewer.org/github/ocelot-collab/ocelot/blob/dev/demos/ipython_tutorials/small_useful_features.ipynb for the implementation of the apertures. This approach seems to be deprecated, as defining the apertures in this way does absolutely nothing in the simulations.

When I instead define the apertures as a physics process through

ap = EllipticalAperture( xmax=ad10/2, ymax= ad10/2 )
navi.add_physics_proc( ap , sequence[2] , sequence[-2] )

The simulation time is 86 times (!!!) longer, going from about 0.12 s to 10.4 s if I have a navi unit step of 1 cm, 11 times longer if I have 10 cm steps. The optics functions in this section vary relatively quickly since the quads are quite strong and closely spaced, so I'd not like to have more than 10 cm step sizes.

This is with a test beam of 1e4 particles. I eventually want to run with many times more particles (up to about 1e6 or so), but am getting a little bit worried about the length of these simulations as I will be doing parameter scans at many different working points.

Is this large leap in simulation time expected? Am I implementing the apertures the wrong way still, or is the scaling to more particles perhaps good (such that little additional time will be added when adding more particles)?

Best regards, Jonas

[st-walker]

Hello, I think @sergey-tomin is currently on holiday, and he wrote that code I believe, but all I can suggest (at least until he is back) is that you profile the code and see where the slowdown could be. If there is a problem with the implementation then I can try to help you optimise it. I don't think it should be 100x slower, no.

[st-walker]

@jonasbjorklundsvensson

Did you profile the code?

[jonasbjorklundsvensson]

Hi @st-walker,

No, I have had to prioritize completely different things lately (and will have to for the next little while), and I also don't know how to profile a code since I'm terrible at programming.

• Jonas

[sergey-tomin]

Hi, tutorial is working. maybe you forgot to activate apertures with navi.activate_apertures()

the use of physics process is also correct. obviously I can't see all your code, but the way you define adding a physical process "navi.add_physics_proc( ap , sequence[2] , sequence[-2] )" I can assume that EllipticalAperture is applied to the whole beam line with some step. If the step is small and the beamline is long, you should expect a dramatic slowdown.

[jonasbjorklundsvensson]

Hi,

I didn't forget to activate them, I even tried putting the activation bit in several various locations, even at multiple locations at the same time, but with no effect. It's unclear what's going wrong in that case. I'd prefer to have the apertures as part of the lattice and not as a physical process.

The beamline section is about 8 m long, and I was originally running with a 0.01 m step since the optics can vary quite a bit over short distances in that section depending on settings. I increased that to 0.1 m to reduce the time. Once I have time to look at this again, I'm going to try again with 0.5 m and see if I see a difference.

• Jonas

[sergey-tomin]

I even tried putting the activation bit in several various locations, even at multiple locations at the same time, but with no effect

how do you define the effect? maybe you do not have losses? try to use very small apertures.

[jonasbjorklundsvensson]

Hi,

Yes, I tried reducing the apertures to something like 50-100 um, still saw no effect. When I used the same aperture size but enabled apertures as a physical process I lost ~70 % of the particles.

• Jonas