130 likes | 261 Views
Current status on Headtail multibunch. N. Mounet, G. Rumolo and E. Metral Acknowledgements: B. Salvant. General changes made to the code. All electron cloud suppressed (by Giovanni). Dynamic allocations:
E N D
Current status on Headtail multibunch N. Mounet, G. Rumolo and E. Metral Acknowledgements: B. Salvant
General changes made to the code • All electron cloud suppressed (by Giovanni). • Dynamic allocations: • Now most of the arrays are dynamically allocated with values from the input file (except for NDC=128 – number of grid points for distribution functions – for “_bunchds.dat” file), • New lines in input file, to fix NPR, nbunch and nbin: Number_of_macroparticles_per_bunch: 1000000 Number_of_slices_in_each_bunch: 500 Also NPR1 (max. number of macroparticles per slice) is determined during the binning and not anymore fixed.
General changes made to the code • Lost of obsolet i_pipe options suppressed (by Giovanni), e.g. all the “frozen fields”; some other i_pipe were changed. • Longitudinal resonant kick was suppressed from the resistive wall or resistive wall with inductive bypass i_pipe options. • All “0.3” replaced by “0.299792458” … (nothing can go faster than the speed of light even by 0.07%) • Bug in “sample” output file fixed, “trk” ouptut file also changed (3 columns: distance z, transverse wake and longitudinal wake, except when wake tables are loaded (then z + all the 7 wake components) • "Multiplication_factor_for_pipe_axes" in the input file replaced by the actual beam pipe semiaxes (x and y) in m (instead of in number of sigmas). Those are the parameters rpipex and rpipey. The former input parameters ielsizex and ielsizey are obtained from those. • LHC octupole current can be provided in input, separately for focusing and defocusing ones. • Hdtl output file: bunch traces only for certain turns specified in input.
General changes made to the code • Significant changes in the management of the wake tables: • Now in the input file the "Switch_for_wake_table" (i_waketb) can take any value between 0 and 7, which indicates the number of wake components to be provided in the wake file: 0: no wake file, other i_pipe case used (not i_pipe=8) 1: 1 wake component (longitudinal): wake file should have two columns, one with the distance and one with the longitudinal wake field (Z), 2: id. but three columns: distance, Xdip, Ydip 3: id. but four columns: distance, Xdip, Ydip, Z 4: id. but five columns: distance, Xdip, Ydip, Xquad, Yquad 5: id. but six columns: distance, Xdip, Ydip, Xquad, Yquad, Z 6: id. but seven columns: distance, Xdip, Ydip, Xquad, Yquad, XYdip, XYquad (the two latter are the coupled terms. i.e. a force in the Y direction proportional to X and vice-versa, but still linear) 7: id. but eight columns: distance, Xdip, Ydip, Xquad, Yquad, XYdip, XYquad, Z
General changes made to the code • Some optimizations: • When using wake tables: optimization of the search of the right position in the wake table when computing the wake at a certain distance, using a classic dichotomy algorithm, • When there is a quadrupolar impedance: loop computing the wake is decoupled from the one applying the kick, instead of being one inside the other (the loop on the number of macroparticles must be really optimized) • Some bug fixes: • case isyn=41: distribution was not initialized; strange line suppressed, “p0 *= (1+dpturn)” in function update_bvalues (evaluated each turn) • dnprdz (derivative of the longitudinal profile) calculation was wrong at end points with the smoothing (sm_value>0), • ! changed all the” %d” format to “%ld” (long int) in read_data() when reading files (fscanf commands) !
Changes for the multibunch version • Really a lot of changes, new variables, new loops, etc… but you don’t care about this, and I already forgot… • What is (possibly) of interest for you: • New lines in input file: Number_of_bunches: 72 Spacing_between_consecutive_bunches_centroids_[RF_bkts]: 5 Switch_for_bunch_table: 0 • If the switch for bunch table is activated (=1), the file [cfgfilename.bunch] should be there, which is a one column file with 0 or 1 on each line, which indicates if the bunch is there or not (each line represents a possible position for a bunch; those possible positions are separated by the number of RF buckets indicated in the input file – see above).
Multibunch version • MPI parallelization: • Separated version of the code, • Parallelization with respect to bunches. Works with any number of processors, even if it’s not a divider of the number of bunches, • Works now only on EPFL cluster (callisto). • With 72 bunches, 10 slices and 30000 macroparticles per bunch (SPS):
Tests done: single-bunch • Of course the code must give the same results as the previous version in single-bunch, but the parameters needs to be exactly the same (including the initial random distribution…). • With isyn=4, tested all possible i_pipe (0 1 2 3 4 5 6 7 30 40 60 61 601 70 700), with both 1 turn and 10 turns of wake memory (ntwake). • With isyn=4, i_pipe=3, ntwake=10, tested all possible i_shift, i_rot and i_spc. • With isyn=4, i_pipe=3, ntwake=0, tested almost all possible i_loss (0,1 & 3). • With ipipe=3, ntwake=1, tested all possible isyn (0 1 2 3 4 5 6 7 8 9 30 40 50 501 60 80 81 90). • Also tried one case with lots of stuff in: coupling, sextupoles, dispersion, octupoles, wake tables and second order chromaticity.
Tests done: multibunch • In parallel: tested that result independent of number of processors. • Comparison of the “old” multibunch version (isyn=600, no synchrotron motion, fixed rigid bunches and frozen wake fields) with the new version in similar condition (one slice per bunch, no synch. motion):
For info, comparison with 5 slices and synchrotron motion in the new code:
Tests done: multibunch • Test on 2 bunches with a short-range wake (broad band resonator), comparing to single-bunch: