Superconducting Supercollider HENRY J

Total Page:16

File Type:pdf, Size:1020Kb

Superconducting Supercollider HENRY J Proc. Natl. Acad. Sci. USA Vol. 90, pp. 9754-9757, November 1993 Colloquium Paper This paper was presented at a coUoquium entled "Images of Science: Science ofImages," organized by Albert V. Crewe, held January 13 and 14, 1992, at the National Academy of Sciences, Washington, DC. Pattern recognition at the Fermilab collider and Superconducting Supercollider HENRY J. FRISCH The Enrico Fermi Institute and Physics Department, University of Chicago, Chicago, IL 60637-1433 ABSTRACT In a colliding beam accelerator such as Fer- particles such as protons and neutrons. Strongly interacting milab or the Superconducting Supercollider (SSC) protons, or particles are called hadrons generically. antiprotons, collide at a rate between 105 (Fermilab) and 108 The Standard Model agrees with experimental data to (SSC) collisions per second. In real time experimentalists have exquisite precision. So what is the problem? First, we to select those events which are candidates for exploring the haven't seen the top quark yet (we haven't directly detected limit of known phenomena at a much lower rate, 1-100 per the tau neutrino either but seem more content about it). Also, second, for recording on permanent media. The rate of events there are indications from experiments detecting neutrinos from new physics sources is expected to be much lower, as low from the sun and from cosmic rays that we may not under- as a few per year. This is a severe problem in pattern stand the relationships among the three types of neutrinos. recognition: with an input data stream of up to 1015 potential However there are much more fundamental problems in bits per second in its images, we have to pick out those images the Standard Model that force us to the conclusion that it is that are potentially interesting in real time at a discrimination internally inconsistent and, hence, incomplete. Calculations level of 1 part in 106, with a known efficiency. I will describe of very high energy scattering of the W bosons give diver- the overall filtering strategies and the custom hardware to do gences-unphysical answers. Our experience has been that this event selection (a.k.a. pattern recognition). when this problem occurs in a theory the solution is that there are new effects at the energy regime where the problem is and that these new effects cancel or otherwise ameliorate the What Physics Problem Are We Trying to Solve? unphysical calculated effects. We therefore believe there is "new physics" in the TeV energy region; this is the basis for High-energy physics has evolved a fairly complete picture of the Superconducting Supercollider (SSC). In addition to this the fundamental forces, the underlying natural symmetries, inconsistency, there is the disturbing ad hoc nature of the and the fundamental particles. We call it "The Standard Standard Model-so much is "put in by hand." Why leptons Model" (model because much of it is ad hoc, and standard and quarks? Why the parallel structure ofthree pairs ofeach? slightly facetiously, but implying that it is the common core Why three? Why is the W boson left-handed, and why is there of belief that will be embellished as we theorize). [For an no corresponding right-handed boson? And so forth. introduction for the scientist not in high-energy physics, see, The strategy we have adopted, such as it is, is to probe to for example, Gottfried and Weisskopf(1). A detailed descrip- shorter and shorter distances by building bigger and bigger tion at the advanced undergraduate physics level is given in accelerators (microscopes). To search for the rare interac- one of the standard tions that may be the indication of "new physics" we go to textbooks used in the field (2).] higher interaction rates. And amid events that are more and The ingredients are the particles we consider elementary- more complicated we have to recognize the patterns ofthese i.e., not composite and hence point-like-which come in two new categories. Fermions have values of intrinsic spin that are interesting events. This is the subject of this talk. half-integer multiples of Fl, Planck's constant; bosons have Searching for a Few Good Events integer values. The elementary bosons are the carriers of the forces: the photon is the "carrier" of the electromagnetic Each collision of a proton in one beam with an antiproton force, the W and Z bosons are carriers ofthe weak force, and (Fermilab) or proton (SSC) in the other counter-rotating the gluon is the carrier of the strong force. beam converts the collision energy into particle production, The elementary fermions are themselves divided into two with typically 50-100 charged particles and 25-50 neutral classes with very different properties. One class is the particles produced initially. What kinds of particles (pions, leptons, consisting of the electron, the muon, the tau lepton, kaons, protons, charmed particles, top, electrons, neutrinos, each with its associated neutral partner neutrino. The second etc.) are produced, and what their distributions in angle and is the quarks, consisting also (we believe) of three pairs: the momentum are, vary from collision to collision with proba- up and down quarks, the charm and strange quarks, and the bilities determined by the underlying dynamics (forces) and top and bottom quarks. Two differences between quarks and kinematics (momentum and energy conservation, impact leptons are that leptons do not interact via the strong inter- parameter, etc.). Each collision thus has an equal a priori action while quarks do, and leptons have integral values of probability of producing something interesting; we therefore electric charge (0 or 1) while quarks are fractionally charged need to inspect as many as possible per unit time. (2/3 or -1/3!). Leptons exist freely in nature, but quarks Each collision is recorded as an electronic "snapshot" by seem to be required to be confined inside strongly interacting a custom-built detector. These detectors have now evolved to be mammoth objects, with many individual recording chan- The publication costs of this article were defrayed in part by page charge payment. This article must therefore be hereby marked "advertisement" Abbreviations: SSC, Superconducting Supercollider; CDF, Collider in accordance with 18 U.S.C. §1734 solely to indicate this fact. Detector at Fermilab. 9754 Downloaded by guest on October 2, 2021 Colloquium Paper: Frisch Proc. Natl. Acad. Sci. USA 90 (1993) 9755 nels that measure such quantities as the positions ofparticles Each time the bunches cross there is about a 20% chance that in space as they traverse the detector, or energies deposited a proton in the proton bunch hits an antiproton in the in calorimeters by particles that enter and interact in them. counter-rotating antiproton bunch at present intensities. At Fig. 1 shows the Collider Detector at Fermilab (CDF). The the SSC the bunches both will contain protons, and are only detector has approximately 150,000 channels of high-gain 16 nsec apart, with typically 1.6 collisions per bunch-crossing amplification and data recording. It stands 30 ft tall and and a total of 108 proton-proton collisions per second. weighs many thousands of tons. A collision recorded by the Each collision produces particles which leave tracks or detector is known as an "event." It is the images of billions deposit energy in the detector. The detector has to register ofevents per second, reconstructed from the electronic data, and store this information while a decision is made if the that we have to inspect to see ifwe have found anything new, event is of sufficient interest to keep; at this stage in the expected or unexpected. Fig. 2 shows a typical garden- selection only one event in 105 or so can be kept. If an event variety event, as reconstructed into an image by computer is kept several milliseconds are spent digitizing all of the from a fraction of the data in the event. Many different event information and transferring the information from the pictures can be made using different kinds ofdata supplied by detector elements into buffers in a farm of computers con- the detector; inferring what was the underlying physics (top quark? Higgs boson?) from the data is the art and science of nected to the data acquisition system. the analysis. The technical problem is that the detector must be ready for the next crossing in general; otherwise one is wasting Description of the Technical Problem beam time and sensitivity to rare events by being "dead" while dealing with an event one most likely will not keep. The The beams of protons (antiprotons) are bunched so that the situation is analogous to a camera: we take a snapshot of two beams collide at fixed places around the ring. At the every crossing with the detector, and have to be ready to take Tevatron at Fermilab, for example, there are six bunches of the next picture 3.5 usec (Fermilab) or 16 nsec (SSC) later. protons going clockwise (looking down) in the accelerator The "picture" generated by the detector has 105 separate and six bunches of antiprotons going counterclockwise. The pieces of information at Fermilab and about 106 at the SSC. bunches collide in six places in the ring, and those places are To summarize the technical problem, taking Fermilab as where one locates detectors (actually at Fermilab only three the example: of the six are used for detectors; the other three are used for (i) There is a new snapshot captured 286,000 times per accelerator-related purposes). second. At Fermilab the bunches are 3.5 ,usec apart, and there are (ii) Each snapshot has approximately 100,000 individual typically 105 to 106 proton-antiproton collisions per second.
Recommended publications
  • An Array-Oriented Language with Static Rank Polymorphism
    An array-oriented language with static rank polymorphism Justin Slepak, Olin Shivers, and Panagiotis Manolios Northeastern University fjrslepak,shivers,[email protected] Abstract. The array-computational model pioneered by Iverson's lan- guages APL and J offers a simple and expressive solution to the \von Neumann bottleneck." It includes a form of rank, or dimensional, poly- morphism, which renders much of a program's control structure im- plicit by lifting base operators to higher-dimensional array structures. We present the first formal semantics for this model, along with the first static type system that captures the full power of the core language. The formal dynamic semantics of our core language, Remora, illuminates several of the murkier corners of the model. This allows us to resolve some of the model's ad hoc elements in more general, regular ways. Among these, we can generalise the model from SIMD to MIMD computations, by extending the semantics to permit functions to be lifted to higher- dimensional arrays in the same way as their arguments. Our static semantics, a dependent type system of carefully restricted power, is capable of describing array computations whose dimensions cannot be determined statically. The type-checking problem is decidable and the type system is accompanied by the usual soundness theorems. Our type system's principal contribution is that it serves to extract the implicit control structure that provides so much of the language's expres- sive power, making this structure explicitly apparent at compile time. 1 The Promise of Rank Polymorphism Behind every interesting programming language is an interesting model of com- putation.
    [Show full text]
  • Compendium of Technical White Papers
    COMPENDIUM OF TECHNICAL WHITE PAPERS Compendium of Technical White Papers from Kx Technical Whitepaper Contents Machine Learning 1. Machine Learning in kdb+: kNN classification and pattern recognition with q ................................ 2 2. An Introduction to Neural Networks with kdb+ .......................................................................... 16 Development Insight 3. Compression in kdb+ ................................................................................................................. 36 4. Kdb+ and Websockets ............................................................................................................... 52 5. C API for kdb+ ............................................................................................................................ 76 6. Efficient Use of Adverbs ........................................................................................................... 112 Optimization Techniques 7. Multi-threading in kdb+: Performance Optimizations and Use Cases ......................................... 134 8. Kdb+ tick Profiling for Throughput Optimization ....................................................................... 152 9. Columnar Database and Query Optimization ............................................................................ 166 Solutions 10. Multi-Partitioned kdb+ Databases: An Equity Options Case Study ............................................. 192 11. Surveillance Technologies to Effectively Monitor Algo and High Frequency Trading ..................
    [Show full text]
  • Application and Interpretation
    Programming Languages: Application and Interpretation Shriram Krishnamurthi Brown University Copyright c 2003, Shriram Krishnamurthi This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 United States License. If you create a derivative work, please include the version information below in your attribution. This book is available free-of-cost from the author’s Web site. This version was generated on 2007-04-26. ii Preface The book is the textbook for the programming languages course at Brown University, which is taken pri- marily by third and fourth year undergraduates and beginning graduate (both MS and PhD) students. It seems very accessible to smart second year students too, and indeed those are some of my most successful students. The book has been used at over a dozen other universities as a primary or secondary text. The book’s material is worth one undergraduate course worth of credit. This book is the fruit of a vision for teaching programming languages by integrating the “two cultures” that have evolved in its pedagogy. One culture is based on interpreters, while the other emphasizes a survey of languages. Each approach has significant advantages but also huge drawbacks. The interpreter method writes programs to learn concepts, and has its heart the fundamental belief that by teaching the computer to execute a concept we more thoroughly learn it ourselves. While this reasoning is internally consistent, it fails to recognize that understanding definitions does not imply we understand consequences of those definitions. For instance, the difference between strict and lazy evaluation, or between static and dynamic scope, is only a few lines of interpreter code, but the consequences of these choices is enormous.
    [Show full text]
  • Chapter 1 Basic Principles of Programming Languages
    Chapter 1 Basic Principles of Programming Languages Although there exist many programming languages, the differences among them are insignificant compared to the differences among natural languages. In this chapter, we discuss the common aspects shared among different programming languages. These aspects include: programming paradigms that define how computation is expressed; the main features of programming languages and their impact on the performance of programs written in the languages; a brief review of the history and development of programming languages; the lexical, syntactic, and semantic structures of programming languages, data and data types, program processing and preprocessing, and the life cycles of program development. At the end of the chapter, you should have learned: what programming paradigms are; an overview of different programming languages and the background knowledge of these languages; the structures of programming languages and how programming languages are defined at the syntactic level; data types, strong versus weak checking; the relationship between language features and their performances; the processing and preprocessing of programming languages, compilation versus interpretation, and different execution models of macros, procedures, and inline procedures; the steps used for program development: requirement, specification, design, implementation, testing, and the correctness proof of programs. The chapter is organized as follows. Section 1.1 introduces the programming paradigms, performance, features, and the development of programming languages. Section 1.2 outlines the structures and design issues of programming languages. Section 1.3 discusses the typing systems, including types of variables, type equivalence, type conversion, and type checking during the compilation. Section 1.4 presents the preprocessing and processing of programming languages, including macro processing, interpretation, and compilation.
    [Show full text]
  • A Modern Reversible Programming Language April 10, 2015
    Arrow: A Modern Reversible Programming Language Author: Advisor: Eli Rose Bob Geitz Abstract Reversible programming languages are those whose programs can be run backwards as well as forwards. This condition impacts even the most basic constructs, such as =, if and while. I discuss Janus, the first im- perative reversible programming language, and its limitations. I then introduce Arrow, a reversible language with modern features, including functions. Example programs are provided. April 10, 2015 Introduction: Many processes in the world have the property of reversibility. To start washing your hands, you turn the knob to the right, and the water starts to flow; the process can be undone, and the water turned off, by turning the knob to the left. To turn your computer on, you press the power button; this too can be undone, by again pressing the power button. In each situation, we had a process (turning the knob, pressing the power button) and a rule that told us how to \undo" that process (turning the knob the other way, and pressing the power button again). Call the second two the inverses of the first two. By a reversible process, I mean a process that has an inverse. Consider two billiard balls, with certain positions and velocities such that they are about to collide. The collision is produced by moving the balls accord- ing to the laws of physics for a few seconds. Take that as our process. It turns out that we can find an inverse for this process { a set of rules to follow which will undo the collision and restore the balls to their original states1.
    [Show full text]
  • APL-The Language Debugging Capabilities, Entirely in APL Terms (No Core Symbol Denotes an APL Function Named' 'Compress," Dumps Or Other Machine-Related Details)
    DANIEL BROCKLEBANK APL - THE LANGUAGE Computer programming languages, once the specialized tools of a few technically trained peo­ p.le, are now fundamental to the education and activities of millions of people in many profes­ SIons, trades, and arts. The most widely known programming languages (Basic, Fortran, Pascal, etc.) have a strong commonality of concepts and symbols; as a collection, they determine our soci­ ety's general understanding of what programming languages are like. There are, however, several ~anguages of g~eat interest and quality that are strikingly different. One such language, which shares ItS acronym WIth the Applied Physics Laboratory, is APL (A Programming Language). A SHORT HISTORY OF APL it struggled through the 1970s. Its international con­ Over 20 years ago, Kenneth E. Iverson published tingent of enthusiasts was continuously hampered by a text with the rather unprepossessing title, A inefficient machine use, poor availability of suitable terminal hardware, and, as always, strong resistance Programming Language. I Dr. Iverson was of the opinion that neither conventional mathematical nota­ to a highly unconventional language. tions nor the emerging Fortran-like programming lan­ At the Applied Physics Laboratory, the APL lan­ guages were conducive to the fluent expression, guage and its practical use have been ongoing concerns publication, and discussion of algorithms-the many of the F. T. McClure Computing Center, whose staff alternative ideas and techniques for carrying out com­ has long been convinced of its value. Addressing the putation. His text presented a solution to this nota­ inefficiency problems, the Computing Center devel­ tion dilemma: a new formal language for writing clear, oped special APL systems software for the IBM concise computer programs.
    [Show full text]
  • Subsistence-Based Socioeconomic Systems in Alaska: an Introduction
    Special Publication No. SP1984-001 Subsistence-Based Socioeconomic Systems in Alaska: An Introduction by Robert J. Wolfe 1984 Alaska Department of Fish and Game Division of Subsistence Symbols and Abbreviations The following symbols and abbreviations, and others approved for the Système International d'Unités (SI), are used without definition in the reports by the Division of Subsistence. All others, including deviations from definitions listed below, are noted in the text at first mention, as well as in the titles or footnotes of tables, and in figure or figure captions. Weights and measures (metric) General Mathematics, statistics centimeter cm Alaska Administrative Code AAC all standard mathematical signs, symbols deciliter dL all commonly-accepted and abbreviations gram g abbreviations e.g., alternate hypothesis HA hectare ha Mr., Mrs., base of natural logarithm e kilogram kg AM, PM, etc. catch per unit effort CPUE kilometer km all commonly-accepted coefficient of variation CV liter L professional titles e.g., Dr., Ph.D., common test statistics (F, t, χ2, etc.) meter m R.N., etc. confidence interval CI milliliter mL at @ correlation coefficient (multiple) R millimeter mm compass directions: correlation coefficient (simple) r east E covariance cov Weights and measures (English) north N degree (angular ) ° cubic feet per second ft3/s south S degrees of freedom df foot ft west W expected value E gallon gal copyright greater than > inch in corporate suffixes: greater than or equal to ≥ mile mi Company Co. harvest per unit effort HPUE nautical mile nmi Corporation Corp. less than < ounce oz Incorporated Inc. less than or equal to ≤ pound lb Limited Ltd.
    [Show full text]
  • APL / J by Seung­Jin Kim and Qing Ju
    APL / J by Seung-jin Kim and Qing Ju What is APL and Array Programming Language? APL stands for ªA Programming Languageº and it is an array programming language based on a notation invented in 1957 by Kenneth E. Iverson while he was at Harvard University[Bakker 2007, Wikipedia ± APL]. Array programming language, also known as vector or multidimensional language, is generalizing operations on scalars to apply transparently to vectors, matrices, and higher dimensional arrays[Wikipedia - J programming language]. The fundamental idea behind the array based programming is its operations apply at once to an entire array set(its values)[Wikipedia - J programming language]. This makes possible that higher-level programming model and the programmer think and operate on whole aggregates of data(arrary), without having to resort to explicit loops of individual scalar operations[Wikipedia - J programming language]. Array programming primitives concisely express broad ideas about data manipulation[Wikipedia ± Array Programming]. In many cases, array programming provides much easier methods and better prospectives to programmers[Wikipedia ± Array Programming]. For example, comparing duplicated factors in array costs 1 line in array programming language J and 10 lines with JAVA. From the given array [13, 45, 99, 23, 99], to find out the duplicated factors 99 in this array, Array programing language J©s source code is + / 99 = 23 45 99 23 99 and JAVA©s source code is class count{ public static void main(String args[]){ int[] arr = {13,45,99,23,99}; int count = 0; for (int i = 0; i < arr.length; i++) { if ( arr[i] == 99 ) count++; } System.out.println(count); } } Both programs return 2.
    [Show full text]
  • Visual Programming Language for Tacit Subset of J Programming Language
    Visual Programming Language for Tacit Subset of J Programming Language Nouman Tariq Dissertation 2013 Erasmus Mundus MSc in Dependable Software Systems Department of Computer Science National University of Ireland, Maynooth Co. Kildare, Ireland A dissertation submitted in partial fulfilment of the requirements for the Erasmus Mundus MSc Dependable Software Systems Head of Department : Dr Adam Winstanley Supervisor : Professor Ronan Reilly June 30, 2013 Declaration I hereby certify that this material, which I now submit for assessment on the program of study leading to the award of Master of Science in Dependable Software Systems, is entirely my own work and has not been taken from the work of others save and to the extent that such work has been cited and acknowledged within the text of my work. Signed:___________________________ Date:___________________________ Abstract Visual programming is the idea of using graphical icons to create programs. I take a look at available solutions and challenges facing visual languages. Keeping these challenges in mind, I measure the suitability of Blockly and highlight the advantages of using Blockly for creating a visual programming environment for the J programming language. Blockly is an open source general purpose visual programming language designed by Google which provides a wide range of features and is meant to be customized to the user’s needs. I also discuss features of the J programming language that make it suitable for use in visual programming language. The result is a visual programming environment for the tacit subset of the J programming language. Table of Contents Introduction ............................................................................................................................................ 7 Problem Statement ............................................................................................................................. 7 Motivation..........................................................................................................................................
    [Show full text]
  • Frederick Phillips Brooks, Jr
    Frederick Phillips Brooks, Jr. Biography Frederick P. Brooks, Jr., was born in 1931 in Durham NC, and grew up in Greenville NC. He received an A.B. summa cum laude in physics from Duke and a Ph.D. in computer science from Harvard, under Howard Aiken, the inventor of the early Harvard computers. He joined IBM, working in Poughkeepsie and Yorktown, NY, 1956-1965. He was an architect of the Stretch and Harvest computers and then was the project manager for the development of IBM's System/360 family of computers and then of the Operating System/360 software. For this work he received a National Medal of Technology jointly with Bob O. Evans and Erich Bloch Brooks and Dura Sweeney in 1957 patented an interrupt system for the IBM Stretch computer that introduced most features of today's interrupt systems. He coined the term computer architecture. His System/360 team first achieved strict compatibility, upward and downward, in a computer family. His early concern for word processing led to his selection of the 8-bit byte and the lowercase alphabet for the System/360, engineering of many new 8-bit input/output devices, and introduction of a character-string datatype in the PL/I programming language. In 1964 he founded the Computer Science Department at the University of North Carolina at Chapel Hill and chaired it for 20 years. Currently, he is Kenan Professor of Computer Science. His principal research is in real-time, three-dimensional, computer graphics—“virtual reality.” His research has helped biochemists solve the structure of complex molecules and enabled architects to “walk through” structures still being designed.
    [Show full text]
  • KDB+ Quick Guide
    KKDDBB++ -- QQUUIICCKK GGUUIIDDEE http://www.tutorialspoint.com/kdbplus/kdbplus_quick_guide.htm Copyright © tutorialspoint.com KKDDBB++ -- OOVVEERRVVIIEEWW This is a complete quide to kdb+ from kx systems, aimed primarily at those learning independently. kdb+, introduced in 2003, is the new generation of the kdb database which is designed to capture, analyze, compare, and store data. A kdb+ system contains the following two components − KDB+ − the database kdatabaseplus Q − the programming language for working with kdb+ Both kdb+ and q are written in k programming language (same as q but less readable). Background Kdb+/q originated as an obscure academic language but over the years, it has gradually improved its user friendliness. APL 1964, AProgrammingLanguage A+ 1988, modifiedAPLbyArthurWhitney K 1993, crispversionofA + , developedbyA. Whitney Kdb 1998, in − memorycolumn − baseddb Kdb+/q 2003, q language – more readable version of k Why and Where to Use KDB+ Why? − If you need a single solution for real-time data with analytics, then you should consider kdb+. Kdb+ stores database as ordinary native files, so it does not have any special needs regarding hardware and storage architecture. It is worth pointing out that the database is just a set of files, so your administrative work won’t be difficult. Where to use KDB+? − It’s easy to count which investment banks are NOT using kdb+ as most of them are using currently or planning to switch from conventional databases to kdb+. As the volume of data is increasing day by day, we need a system that can handle huge volumes of data. KDB+ fulfills this requirement. KDB+ not only stores an enormous amount of data but also analyzes it in real time.
    [Show full text]
  • The Making of the MCM/70 Microcomputer
    The Making of the MCM/70 Microcomputer Zbigniew Stachniak York University, Canada MCM/70, manufactured by Micro Computer Machines (MCM), was a small desktop microcomputer designed to provide the APL programming language environment for business, scientific, and educational use. MCM was among the first companies to fully recognize and act upon microprocessor technology’s immense potential for developing a new generation of cost-effective computing systems. This article discusses the pioneering work on personal microcomputers conducted at MCM in the early 1970s and, in particular, the making of the MCM/70 microcomputer. Personal computing might have started as early forces met in the middle, they would bring as the 1940s, when Edmund Berkeley, a great about a revolution in personal computing.”1 enthusiast of computing and computer educa- Much has already been written about the tion, conceived his first small computing device timing of this convergence and about the peo- and named it Simon. Simon was a relay-based ple and events that were the catalysts for it. One device, and Berkeley published its design interpretation that has long ago filtered into the between 1950 and 1951 in a series of articles in folklore of the modern history of computing Radio Electronics. Alternatively, one might con- and into popular culture depicts the two forces sider personal computing’s time line to have rushing past each other in the period between begun with the Digital Equipment PDP-8 com- the introduction of the first 8-bit microproces- puter, the machine that brought about the era of sor and the announcement of the Altair 8800.
    [Show full text]