1 / 10

…. To allow asynchronous beam dump STUDIES

…. To allow asynchronous beam dump STUDIES . Luisella Lari Special thanks to R. Bruce BE/ATB/LCU CERN & IFIC CSIC SixTrack development meeting 27 th June 2013. Asynchronous dump: what is it?. Fast losses happens when one or all of MKDs firing not synchronously with the abort gap.

ronni
Download Presentation

…. To allow asynchronous beam dump STUDIES

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ….To allow asynchronousbeam dump STUDIES Luisella Lari Special thanks to R. Bruce BE/ATB/LCU CERN & IFIC CSIC SixTrack development meeting 27th June 2013

  2. Asynchronous dump: what is it? Fast losses happens when one or all of MKDs firing not synchronously with the abort gap. <3 ms extraction kicker rise time (abort gap)

  3. L.Lari …a modified SixTrack collimation routine • fort.3 modified to allow different angular values for each MKDs @ IP6 as input (2 lines added @ the end of the file, same logic 1 – 0 to activate this option sixve.f routine modified to read the input data by Sixtrack) • Intrack.f collimation subroutine modified  15 new vacuum TCSGs at the place of each MKDs. TURN 1  coll. set in nominal position as in CollDB TURN 2  angular kick in fort.3 applied to each MKD TURN 3  dump (i.e. max kick applied to each MKD) • In CollDB the TCSGs@MKDs are added, the “first” one met by the beam is closed to allow to recover all data in tracks2.dat output file 1st turn IP1 2nd turn IP8 IP1 3rd turn IP8 The collimator are put in place with respect to the optic scenario under study IP6 IP6

  4. Where in track.f? At the beginning at the THIN6D routine After the collimator name check

  5. Pre-Processing: Some additional features/infos… (1/2) For each kick data as reported in fort.3 (for Beam1 and Beam 2) • The track start from IP1 as usual… • Use 10 of the 50 different random input Gaussian distributions created at the first IP1 tracking element  MATLAB script created. • Data extracted from the MKD pulse form  bash scriptscreated to allow any combination of kick angles

  6. Pre-processing:Some additional features/infos… (2/2) • CASE 1: Studies of asynchronous dump tests  mapping on all the MKD pulse form for any angle  step of 50 or 25 ns [Ref: L. Lari et al., Simulations and Measurements of Beam Losses on LHC Collimators during Beam Abort Failures, Proc. IPAC13, Shanghai, China] • CASE 2: Studies of asynchronous dump for the most critical bunches angles [Ref: L. Lari et al., Studies of Thermal Loads on Collimators for HL-LHC Optics in case of Fast Losses, Proc. IPAC13, Shanghai, China] • CASE 3: Studies of optics errors [Ref: R. Bruce, Collimator hierarchy limits: assumptions and impact on machine protection and performance, MPP workshop, March 2013 ] “Between 2 NEXT” data from MADX file: fc.3

  7. Post-processing My LPI files were cleaned by the losses that were supposed to go in the dump line (i.e. at the 2nd turn for big kick and at the 3rd turn when it is supposed to dump)  not consider all the p+ after the last MKD and the TCDS. …Another script created

  8. How many particles? As reference CASE 1: INPUT • 4800 p+ (=64x75) for each of the 10 job per angle • Total per angle = 48000 p+ • Total per all the 142 angles = 6’816’000 p+ OUTPUT (all the case in average) • Tot primary p+ absorbed LPI 1’850’000 (~27% input p+) • Tot primary p+ absorbed coll 1’600’000 (~23% input p+)

  9. Bugs & Compatibility • Matlab script for random Gaussian distribution created since the distribution in Sixtrack/colltrack is not working. • Beam 2 simulations use the beam 4 MADX fc.2  no necessary to use the Beam 2 flag in fort.3. • The modified version of sixve.f requires that the 2 line in fort.3 with the asynchronous dump angles are present  however a check ‘if’ could be introduced to be compatible this version with the past one.

  10. Questions

More Related