elegant.pdf加速器粒子动力学软件模拟专业软件elegant说明书1.8 Known Bug

文件名称: elegant.pdf

所属分类: 专业指导

开发工具:

文件大小: 2mb

下载次数: 0

上传时间: 2019-07-14

提供者: wangtia********

下载 (2mb)

不能下载？报告错误

详细说明：加速器粒子动力学软件模拟专业软件elegant说明书1.8 Known Bugs, Problems, and limitations o The reFerenCE_- CORRECTION feature of the Csbend element is ignored while performing cal- culations related to the moments_output command etting CHANGE_T=1 on RFCA and rFCW elements can give invalid results when tracking beams with very large time spread compared to the bunch length Twiss output contains entries for the higher-order dispersion, tune shifts with amplitude higher-order chromaticity, and tune spreads due to chromaticity and amplitude even when these are not calculated, which is potentially misleading. The values are zero when the calcu lation is not requested Computation of closed orbits and Twiss parameters will not always include the effects of synchrotron radiation losses when these are imposed using SREFFECTS elements. See the documentation for sreffects for details Computation of beam moments does not include synchrotron radiation effects from UKICKMAP elements The file created with the parameters field of run_setup does not contain any non-numerical parameters of the lattice Computation of radiation integrals does not include the effect of steering magnets There is a bug related to using ilmatrix that will result in a crash if one does not request computation of the twiss parameters. If you encounter this problem, just add the following statement after the run_setup command &twiss_output matched 1 gend The OUTPUT_FILE feature of the TFBDRIVER will produce a file with missing data at the end of the buffer if the OUTPUT_INTERVAL parameter is not a divisor of the number of passes When the KQUAd clcmcnt was split (with the divide_elements command or element_divisions any edge multipoles get evaluated at the interior boundaries. In addition, the LEFFECTIVE cannot be used Cr edits Contributors to elegant include M. Borland, M. Carla,,N. Carnnignani, M. Ehrlichman, L Emery W. Guo, R. Lindberg, V. Sajacv, R. Soliday, Y.P. Sun, C.X. Wang, Y. Wang, Y. Wu, and A Xiao. Contributors to related programs and scripts include m. borland, R. Dejus, I. Emery, A Petrenko, H. Shang, Y. Wang, A. Xiao, and B. Yang. R. Soliday is responsible for multi-platform builds and distribution. Of course, we also appreciate the many suggestions, comments, and bug reports froIn users If you use elegant in your research, we appreciate a citation. For elegant, the citation is M. Borland, clcgant: A Flcxiblc SDDS-Compliant Codc for Accclcrator Simulation, Advanccd Photon Source Ls-287, September 2000 Additional contributors for the parallel version include Y. Wang and H. Shang. The additional citation for Elegant is Y. Wang and M. Borland, "Pelegant: A Parallel Accelerator Simulation Code for Electron Generation and Tracking,", Proceedings of the 12th Advanced Accelerator Concepts Workshop AIP Conf. Proc. 877, 241(2006) Additional contributors for the gPu version include K. Amyx, J. R. King, and I. V. Pogorelov The additional citation for the gPu version is I.V. Pogorelov, J. R. King, K. M. Amyx, M. Borland, and R. Soliday, "Current status of the GPU-accelerated ELEGANT, Proceedings of 2015 International Particle Accelerator Conference 623(2015) 3 Introduction elegant stands for "ELEctron Generation ANd Tracking, a somewhat out-of-date description of a fully 6D accelerator program that now does much more than generate particle distributions and track then. elegant, wrilten entirely in the C progralllining language l, uses a variant of thc MAD2 input format to describe accelerators, which may be cither transport lincs, circular machines, or a combination thereof. Program execution is driven by commands in a namelist. format This document describes the features available in elegant, listing the commands and their arguments. The dierences between elegant and MAD formats for describing accelerators are listed. A scrics of cxamples of elegant input and output arc givcn. Finally, appendices arc included describing the post-processing programs 3.1 Program Philosophy For all its complexity, elegant is not a stand-alone program. For example, most of the output is not human-readable, and elegant itself has no graphics capabilities. These tasks are handled by a suite of post-processing programs that serve both elegant and other physics programs. These pro- grams, collectively known as the SDDs Toolkit89, provide sophisticated data analysis and display capabilities. They also serve to prepare input for elegant, supporting multi-stage simulation Setting up for an elegant run thus involves more than creating input files for elegant per se A complicated run will typically involve creation of a post-processing command file that processes elegant output and puts it in the most useful form, typically a series of graphs. Users thus have the full power of the SDDS Toolkit, the resident command interpreter(e.g, the UNIX Shell), and their favorite scripting language(e.g, TCl/Tk) at their disposaL. The idea is that instead of continually rewriting the physics code to, for example, make another type of graph or squeeze another item into a crowded table, one should allow the user to tailor the output to his specific needs using a set of generic post-processing programs. This approach has been quile successful, and is believed particularly suited to the constantly changing needs of research Unlike many ot her programs, elegant allows one to make a single run simulating an arbitrary number of randomizations or variations of an accelerator By using the Sdds toolkit to postprocess the data, the user's postprocessing time and effort do not depend on how many random seeds or situations are chosen. Hence, inslead of doing a few simulations with a few seed numbers or values the user can simulate hundreds or even thousands of instances of one accelerator to get an accurate representation of the statistics or dependence on parameters. with no more work invested than in doing a few simulations In addition, complex simulations such as start-to-end jitter simulations 1l and top-up tracking12 can be performed involving hundreds or thousands of runs, with input created by scripts depending on the sdds toolkit. These simulations make use of concurrent computing on about 20 workstation using the Distributed Queueing System 10. Another example is the elegantRingAnalysis script which allows using many workstations for simulation of storage ring dynamic and momentum aper ture frequency maps, and so on. Clearly, use of automated postprocessing tools great ly increases the scale and sophistication of simulations possible In passing, we note another "philosophicalpoint about elegant, namely, the goal of complete backward compatibility. We consider it unacceptable if a new version of the prograln gives diflerent answers than an old version, unless the old version was wrong. Hence, there are sometimes less- than-ideal defa.. settings in elegant, incorrect, spelling of parameters, etc, that are never fixed because doing so would break old input files. It helps to read the manual pages carefully for the more complex features to ensure that the defaults are understood and appropriate 3.2 Capabilities of elegant elegant started as a tracking code, anld it is still well-suiled to this task. elegant tracks in the 6-dimensional phase space(x,x,y, y, s,), where x(y) is the horizontal(vertical)transverse coordinate, primed quantities are slopes, s is the total, equivalent distance traveled, and d is the ractional momentum deviation 3. Note that these quantities are commonly referred to as(x, xp y, yp, s, dp) in the namelists, accelerator element parameters, and output files.("dp"is admittedly confusing-it is supposed to remind the user of AP/Po. Sometimes this quantity is referred to as “ delta. Tracking may be performed using matrices(of selectable order), canonica.l kick elements, numer ically integrated elements, or any combination thereof. For most elements, second-order matrices are available, matrix concatenation can be done to any order up to third. Canonical kick ele ments are available for bending magnets, quadrupoles, sextupoles, and higher-order multipoles; all of these elements also support optional classical synchrotron radiation losses. Among the numer ically integrated elements available are extended-fringe- field bending magnets and traveling-wave accelerators. A number of hybrid elements exist that have first-order transport with exact time dependence, e.g., RF cavities. Some of the more unusual elements available are third-order alpha- magnets 5, 4, time-dependent kicker magnets, voltage-ramped RF cavities, beam scrapers, and beam- analysis“ screens.” Several elements support simulation of collective effects, such as short- and long-range wake fields, resonator impedances, intra-beam scattering, coherent synchrotron radiation, and the longi- tudinal space charge impedance a wide variety of output is available from tracking, including centroid and sigma-matrix output along the accelerator, phase space output at arbitrary locations, turn-by-turn moments at arbitrary locations, histograms of particle coordinates, coordinates of lost particles, and initial coordinates of transmitted particles. In addition to tracking internally generated particle distributions, elegant can track distributions stored in external files, which can either be generated by other programs or by previous elegant runs. Because elegant uses SDDs format for reading in and writing out particle coordinates, it is relatively easy to interface elegant to other programs using files that can also be used with SDDs to do post-processing for the programs l, elegant allows the addition of random errors to virtually any parameter of any accelerator ment.One can correct the orbit (or trajectory), tunes, and chromaticity after adding er rror rs then compute Twiss parameters, track, or perform a number of other operations. elegant makes it easy to evaluate a large number of ensembles(seeds?") in a single run. Alternatively, different ensembles can be readily run of different CPUs and the sdds output files combined In addition to randomly perturbing accelerator elements, elegant allows one to systematically vary any number of elements in a multi-dimensional grid. As before, one can track or do other computations for each point on the grid. This is a very useful feature for the simulation of experi- ments, e.g., emittance measurements involving beam-size measurements during variation of one or more quadrupoles囿 Like many accelerator codes, elegant does accelerator optimization. It will optimize a user defined function of the transfer matrix elements(up to third-order), beta functions, tunes, chro- Inauicilies, radiation integrals. natural eillance, loor coordinales, beaIn moments, etc. It also has the ability to optimize results of tracking using a user-supplied function of the beam parameters at one or more locations. This permits solution of a wide variety of problems, from matching a kicker bump in the presence of nonlinearities to optimizing dynamic aperture by adjusting sextupoles elegant provides several methods for determining accelerator aperture, whether dynamic or physical. One imlay do straightforward tracking of an ensemble of particles Chial occupies al uniform grid in(x, y) space. One may also invoke a search procedure that finds the aperture boundary. A related feature is the ability to determine the frequency map for an accelerator, to help identify aperture-llmiting resonances In addition to using analytical expressions for the transport matrices, elegant supports compu Lalion of the first-order matrix and linear optics properties of a circular machine based on tracking A common application of this is to compute the tune and beta-function variation with momentum offset by single-turn tracking of a, series of particles This is much more efficient than for example tracking and performing FFTs(though elegant will do this also). This both tests analytical ex- pressions for the chromaticity and allows computations using accelerator elements for which such expressions do not exist(e. g, a lulnerically integraled bending magnet with extended fringe fields) A common application of random error simulations is to set tolerances on magnet strength and alignment relative to the correctability of the closed orbit. A more efficient way to do these calculations is to use correct-orbit amplification factors 6. elegant the computes amplification factors and functions for corrected and uncorrected orbits and trajectories pertaining to any element that produces an orbit or trajectory distortion. It simultaneously computes the amplification unctions for the steering magnets, in order to determine how strong the steering magnets will need to be 4 Digression on the Longitudinal Coordinate definition A word is in order about the definition of s, which we've described as the total, equivalent distance Traveled. First, by lolal distance we mean Chal s is nol measured relalive to the bunch center or a fiducial particlc. It is cntircly a, propcrty of the individual particlc and its path through the accelerator To explain what we mean by equivalent distance, note that the relationship between s and arrival time t at the observation point is, for each particle, s- Bct, where Bc is the instantaneous velocity of the particle. Whenever a particle's velocity changes, elegant recomputes s to ensure that this rclationship holds. s is thus the"cquivalent'distancc the particle would havc traveled at the present velocity to arrive at the observation point at the given time. This book-keeping is required because elegant was originally a matrix-only code using s as the longitudinal coordinate Users should keep the meaning of s in mind when viewing statistics for s, for example, in the sigma or watch point output files. A quantity like Ss is literally the rms spread in s. It is not defined as ot/(B)c. A nonrelativistic beam with velocity spread will show no change in Ss in a drift space, because the distance traveled is the same for all partic 5 Fiducialization in elegant In some tracking codes, there is a" fiducial particle"that is tracked along with the beam. This particle follows the ideal trajectory or orbit, with the ideal noinentu, and at the ideal phase Thcrc is no fiducial particlc in elegant. Instcad, fiducialization is typically bascd on statistical properties of the bunch. This can be performed on a bunch-by-bunch basis, or for the first bunch seen in a run. The latter method must be used if one wants to look at the effects of changing phase, voltage, or magnets relative to some nominal configuration Internally, elegant liducializes each element in the beanline. Fiducializing an elenent means dctermining the rcfcrcncc momcntum and arrival timc (or phasc) for that clcmcnt. If the rofcrcnco momentum does not, change along a beamline and no time-dependent elements are involved, ther fiducialization is irrelevant. all elements are fiducialized at the central momentum defined in run_setup. A nunber of commands have paraineters for controlling liducializalion The always_change_po parameter of run_setup causes elegant to re-establish the central momentum after each element when fiducializing. This may be more convenient than setting the ChaNGE_PO parameter on the elements themselves. However, it can have unexpected consequences, such as changing the central momentum to match changes in beam momentum due to synchrotron radiation o run_control has four parameters that affect fiducialization, which come into play when multi- step runs are made. Typically, these are runs that involve variation of elements, addition of errors, or loading of multiple sets of parameters reset__for-each_step- If nonzero, the rf phases are re-established for each beam tracked. If this is 1(the default), the time reference is discarded after each bunch is tracked. This means that bunch-to-bunch phasing errors due to time-of-flight differences would be lost first_is_fiducial- The first bunch seen is taken to establish the fiducial phases and Illoinentuin profile. If one is simulating, for example, successive beans in a fixed accclcrator. this should bc sct to 1. Othcrwisc thc momcntum rcfcrcncc is discarded aftcr each bunch is tracked. N.B. as of version 27.0.1, setting first_is_fiducial=1 does not imply always_change_p0=1. You must set this separately, or use the CHANGE_PO parameter on various elements(e.g, RFCA) to further specify how to set the fiducial InOinentuin profile restrict_fiducialization- If nonzero, then momentum profile fiducialization oc curs only after elements that are known to possibily change the momentum. It would not occur. for example, after a scraper that changes the average beam momentum by removing a low-momentum tail. This is a convenience that, essentially, allows modifying the impact of setting always_change_p0=1 n_passes_fiducial- If positive, sets the number passes used for fiducial tracking to bc diffcrcnt from thc n_passes valuc. For ring fiducialization, should probably always be set to 1 The bunched_ beam command has a first_is_fiducial parameter that is convenient for use with the first_is_fiducial mode established by run_control. If nonzero, this parameter causes elegant to generate a first bunch with only one particle. This is very useful if one wants to track with many particles but doesn't want to waste time fidicializing with a many particle bunch Hcrc arc somc cxamples that may bc helpful ScaTTing a phase error in a linac wilh a burch compressor: The scall is performed using the vary_element command. For this to work properly, it is ncccssary to fidcualizc the system with zero phase error. Hence, one must use the enumeration feature of vary_element to provide an input file with the phase errors and the file must be sorted so that the row with zero phase error is first. Further, one must set reset_rf_for_each_step=0 and first_is_fiducial =1 in run_control, and CHANGE_P0=1 on all rf cavity elements.(See the bunchComp/phase Sweep and bunchComp/dtSweep cxamples Scanning the voltage of a linac to simulate different operating energy choices at the compres soT: In this case, one scans the linac voltage, but wants to fiducialize the system for each volt age.(It's a change in design, not an error or perturbation )One again uses vary_element but nothing special needs to be done about the order of the voltage values. One must set reset_rf_for_eachstep =1 and first_is_fiducial =0 in in run_control, and CHANGE_PO=1 on all rf cavity elements. (See the bunchComp/energy Sweep example. Simalation of phase and voltage jitter: In this case, one uses the error_elements command to impart errors to the Phase and volt parameters of rf cavity elements. llowever, th first beam through the system must not see any errors. This is accomplished by setting no_errors_for_first_step=1 in error_control. One can also(optionally) use a 1-particle beam for fiducialization by setting first_is_fiducial=1 in bunched_beam. In addition, one must set reset-rf-for-_each_step=0 and first_is_fiducial 1 in run_control, and CHANGE_PO=1 on all rf cavity elements.(See the bunchCompJitter/jitter example. 6 Preparing beams for bunch-mode simulations Certain collective-effects elements in elegant can operate under the assumption that the bea. m is organized into bunches. This includes the FRFMODE, FTRFMODE, LRWAKE, RFMODE, WAKE, TRFMODE TRWAKE, ZLONGIT, and ZTRANSVERSE elements. At present, this behavior is only available when Loading a beam from an external file using the sdds_beam command. a typical sequence is to run elegant once to generate a beam file using bunched_beam, then load that beam into a subsequent run This beam file may either contain the entire beam (all the bunches) or it may contain a single bunch. In the latter case, the single bunch must be duplicated using the n_duplicates and duplicate_stagger parameters of sdds_beam. Otherwise, in the beam-generation run, the run-control command must be used to specify both the number of bunches(using n_steps) and the bunch frequency (using bunch_frequency ). The beamline for this run would typically consist simply of a zero-length drift space, so that the output file from the run_setup command contains the coordinates for each bunch as generated, with no modifications. Once the beam is generated, it can be used as the input file for sdds_beam with track_pages_separately=0 and use bunched mode=1 For those who prepare beams using other programs, it may be helpful to understand how the organization of the beam into bunches is specified. The relevant data from the beam file are the values in the IDSlotsPerBunch parameter and particleID column. The particleid is generally a unique positive integer for each particle. When S=IDSlotsPer Bunch is non-zero, the bunch index is computed as L(I-1)/s, where I is the particle ID For example, with IDSlotsPerBunch-=1000, particle IDs from 1 to 1000 would be in bunch 0, from 2001-3000 would be bunch l, and so on This mechanism allows specifying the bunch structure without adding columns to the beam file and also handles particle loss aut.tica lly ote that although in the case of beams generated with bunched_beam the individual bunches appear in separate pages of the beam file, this is not necessary. 7 Namelist Command Dictionary The main input filc for an elegant run consists of a scrics of namclists, which function as commands Most of the namelists direct elegant to set up to run in a certain way. A few are"action" commands that begin the actual simulation. fortran programmers should note that, unlike FOrTRaN namelists, these namelists need not come in a predefined order; elegant is able to detect which namelist is next in the file and react appropriately. 7.1 Commandline Syntax The commandline syntax for elegant is of the form elegant finputfilel-pipe=in) [-rpnDefns-filename] [-configuration=filename L-macro=tag1=vaLwelL, tag2=value2.J inputfile is the name of the command input file, which is a series of namelist commands directing the calculations. Alternatively, one may give the -pipe=in option, allowing elegant to be fed a stream of commands by another program or script. The -rpnDefns option allows providing the namc of the rpn dcfinitions filc as an alternative to defining the RPN_DEFNS cnvironment variable The -configuration option allows providing the name of an input file to be read prior to inputfile this can be used for configuring elegant using, e. g, the global_settings command; this is an alternative to using the ELEGANT_CONFIGURATION environment variable. The -macro option allows performing text substitutions in the command stream. Multiple -macro options may be given Usagc is dcscribcd in morc dctail bclow 7.2 General Command Syntax fach namelist, has a number of variables associated with it. which are used to control details of the run. These variables come in three data types:(1)long, for the C long integer type.(2) double for the C double-precision floating point type.(3)STRING, for a character string enclosed in double quotation marks. All variables have default values, which are listed on the following pages. STRING variables oftcn havc a default valuc listed as NULL, which mcans no data; this is quitc diffcrcnt from the va lue ", which is a zero-length character string. long variables are often used as logical flags with a zero value indicating false and a non-zero value indicating true On the following pages the reader will find individual descriptions of each of the namelist coIninands anld their variables. Each description contains a sequence of the forIm & = gend This summarizes the paramctcrs of the namelist. Notc, however that the namclists arc invoked in the form & k=, L[]=[, ..],J send The square-brackets enclose an optional component. Not all namelists require variables to be given the defaults may be sufficient. However, if a variable name is given, it must have a value. values for STRING variables must be enclosed in double quotation marks. Values for double variables may be in floating-point, exponential, or integer format(exponential format uses the 'e'character to introduce the exponent) Array variables take a list of values, with the first value being placed in the slot indicated by the subscript. As in C, the first slot of the array has subscript 0, not 1. The namelist processor does not check to ensure that one does not put elements into nonexistent slots beyond the end of the array; doing so may cause the processor to hang up or crash Wildcards are allowed in a nunber of places in elegant and the SDDs Toolkit. The wildcard format is very similar to that used in UNIX .*-stands for any number of characters, including none ?-stands for any single character []- stands for any single character from the list. The list may include ranges, such as a-z, which includes all characters between and including a. and7 in the ascii character table The special characters *,? [, and are entered literally by preceeding the character by a backslash e. g I n man y places where a filename is required in an elegant namelist, the user may supply a SO-called"incomplete"filename. An incomplete filename has the sequence os"imbedded in it, for which is substituted the"rootname. The rootname is by default the filename(less the extension) of the lattice file. The most common use of this feature is to cause elegant to create names for all output files that sharc a common filename but differ in thcir extensions. Post-processing can be greatly simplified by adopting this naming convention, particularly if one consistently uses the same extension for the same type of output. Recommended filename extensions are given in the lists below Nole Chat this substitution fealure is not generally available for input liles, though there are somc exceptions(c g, load_parameters). Anothcr convcnicncc for input filc organization is the search-path feature, which can be set from the run_setup command. By default, elegant assumes

(系统自动生成,下载前可以参看下载内容)