ocelot-collab / ocelot

OCELOT is a multiphysics simulation toolkit designed for studying FEL and storage ring-based light sources.
GNU General Public License v3.0
85 stars 58 forks source link

Question #241

Closed laxmisubramanyam closed 5 months ago

laxmisubramanyam commented 5 months ago

Hi,

In tutorial 5, one of the command is

recalculate_ref_particle(p_array_csr)
recalculate_ref_particle(p_array_no)

Question: Why “recalculate_ref_particle” is used here ? This command is never used in any of the tutorial or another demo example. Is there any important reason ?

Thanks a lot.

st-walker commented 5 months ago

It's just to make the plots look nicer in this case, I would assume. Otherwise there will (presumably) be a vertical offset between the various scatter plots underneath. Try it without and have a look.

laxmisubramanyam commented 5 months ago

Hi @st-walker, Thanks for answering my query. Yes, in the case I don't use recalculate_ref_particle(p_array_csr) the beam distribution is shifted by some margin. I was wondering if this is the effect of CSR on the electron beam.

I have one more thing to bring to your notice. When I use only the space-charge effect navi.add_physics_proc(sc, lat.sequence[0], lat.sequence[-1]), then during calculation it always display on the terminal Applied: SpaceCharge.

Similarly, when I use only CSR effect navi.add_physics_proc(csr, lat.sequence[0], lat.sequence[-1]), then it always display Applied: CSR.

However, when I use both

navi.add_physics_proc(sc1, lat.sequence[0], lat.sequence[-1])
navi.add_physics_proc(csr, lat.sequence[0], lat.sequence[-1])

It only display Applied: SpaceCharge but nothing about CSR.

Does this behavior is normal ? Do I consider that the CSR is still applied even though not displayed on the terminal ?

st-walker commented 5 months ago

Both will be applied but I suspect any absence in the printout will be because of the carriage return in the printout meaning the shorter test is completely overwritten.

Try track(..., overwrite_progress=False) and I would imagine you can see both processes in the printout.

laxmisubramanyam commented 5 months ago

Hi @st-walker,

Thanks for clearing this doubt. But the frequency at which CSR is applied is not consistent with what I have given in the file. For example, I choose the space-charge step size and navigate unit step as:

sc = SpaceCharge()
sc.nmesh_xyz = [63, 63, 63]
sc.step = 0.01

csr = CSR(n_bin=300, m_bin=20, sigma_min=0.1e-6)

navi = Navigator(lat)

navi.unit_step = 0.01

navi.add_physics_proc(sc, lat.sequence[0], lat.sequence[-1])
navi.add_physics_proc(csr, lat.sequence[0], lat.sequence[-1])

The SpaceCharge is applied every time step, but CSR is not. There is a big gap between successive CSR application. Please, see in the attached text file a small part of the out-put on the terminal. Is it normal behavior ? How sc.step is different from navi.unit.step.

stdout.txt

sergey-tomin commented 5 months ago

Hi,

Regarding recalculate_ref_particle(): In this particular case, Stuart described reason correctly - it is just for comparison. However, this function can mess up your results if you do not know what this function is doing, so I suggest not using it at all.

Regarding applying collective effects: Navigator.unit_step defines your smallest step, let's take 0.1 m. The step for any collective effects should be an integer number. For example, csr.step = 1, sc.step = 5. So, CSR will be applied every time with a step of 0.1, while CS will be applied every 0.5 m.

laxmisubramanyam commented 5 months ago

Hi @sergey-tomin,

Thanks a lot for clearing the doubt.

Thanks to both of you (@sergey-tomin , @st-walker ).

It would be very nice if you could sometimes explain the arguments of CSR function and mesh size of space-charge. At the moment I am just following the tutorials and examples. The sc.nmesh_xyz is always given as [63, 63, 63]. And I am not able to decide how to choose the arguments of CSR n_bin, m_bin, sigma_min.

Best regards, Laxmi

st-walker commented 5 months ago

sigma_min is the kernel size of the Gaussian smoothing of the longitudinal current profile, I think. Because the CSR wake is proportional to the derivative of the longitudinal charge density, it is important not to not get some crazy wake just because you have some artificial local current spikes due to e.g. relatively lower macro particle number. I always set this to 0.1 the bunch length, but arguably, if you know a priori of some degree of fine structure then you should set it accordingly. But I always picked 0.1sigma_z.

n_bin and m_bin I never understood. Basically the CSR class was translated to Python from an old matlab code written by a now retired colleague. Sadly the original code never had any comments nor explanation nor was it written to be read by a human being and so it's what we've got to work with.

laxmisubramanyam commented 5 months ago

Hi @st-walker,

Thanks a lot. All these informations are very helpful for me to use Ocelot more confidently. About space charge mesh size sc.mesh_xyz = [63,63,63] may be I will seek your expert advice later.

Thanks once again to both of you.

Best regards, Laxmi

sergey-tomin commented 4 months ago

HI, sc.mesh_xyz = [63,63,63] is just the mash size in x, y and z direction, z direction is longitudinal direction here. you also can read this in doc string in space charge class.

sergey-tomin commented 4 months ago

About CSR: n_bin and m_bin are also a kind of filter. They represent the number of bins and sub-bins. The idea is that you first obtain the current profile using bins, and then you smooth it out with a Gaussian filter with sigma_min, and not the other way around.

laxmisubramanyam commented 4 months ago

Hi @sergey-tomin,

Thanks a lot for giving your precious time for explaining every single point.

Best regards, Laxmi