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 programs, collectively known as the SDDS Toolkit[8,9], 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 quite successful, and is believed particularly suited to the constantly changing needs of research.
Unlike many other 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, instead 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[11] and top-up tracking[12] 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]. Clearly, use of automated postprocessing tools greatly increases the scale and sophistication of simulations possible. This stands in stark contrast to the current trend toward graphical user interfaces, which virtually force an inefficient one-job, one-computer, manual postprocessing way of working.