The Thrill of Programming-- The Agony of Debugging
Explore the source record for details and available documents.
Ehrman, J.↗
SEARCH · Search NASA
Results for “Debugging”
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
Profiling and Debugging Support for Performance Portable Programming Models.
Abstract not provided.
Hammond, Simon David↗
The Path to Exascale Experiences porEng and debugging for Intel Xeon Phi.
Abstract not provided.
Hammond, Simon David↗
Hierarchic Parallelism Memory Management and Helpful Debugging Tools: Updates on Trilinos Discretization Packages.
Abstract not provided.
Pawlowski, Roger P.↗
Case Study: Debugging Other People?s Libraries via PRELOAD.
Abstract not provided.
Siefert, Christopher↗
Per-instruction energy debugging using instruction sampling hardware
A processor utilizes instruction based sampling to generate sampling data sampled on a per instruction basis during execution of an instruction. The sampling data indicates what processor hardware was used due to the execution of the instruction. Software receives the sampling data and generates an estimate of energy used by the instruction based on the sampling data. The sampling data may include microarchitectural events and the energy estimate utilizes a base energy amount corresponding to the instruction executed along with energy amounts corresponding to the microarchitectural events in the sampling data. The sampling data may include switching events associated with hardware blocks that switched due to execution of the instruction and the energy estimate for the instruction is based on the switching events and capacitance estimates associated with the hardware blocks.
Wei, Shijia↗
Deep functional analysis of synII, a 770-kilobase synthetic yeast chromosome
INTRODUCTION Although much effort has been devoted to studying yeast in the past few decades, our understanding of this model organism is still limited. Rapidly developing DNA synthesis techniques have made a “build-to-understand” approach feasible to reengineer on the genome scale. Here, we report on the completion of a 770-kilobase synthetic yeast chromosome II (synII). SynII was characterized using extensive Trans-Omics tests. Despite considerable sequence alterations, synII is virtually indistinguishable from wild type. However, an up-regulation of translational machinery was observed and can be reversed by restoring the transfer RNA (tRNA) gene copy number. RATIONALE Following the “design-build-test-debug” working loop, synII was successfully designed and constructed in vivo. Extensive Trans-Omics tests were conducted, including phenomics, transcriptomics, proteomics, metabolomics, chromosome segregation, and replication analyses. By both complementation assays and SCRaMbLE (synthetic chromosome rearrangement and modification by loxP -mediated evolution), we targeted and debugged the origin of a growth defect at 37°C in glycerol medium. RESULTS To efficiently construct megabase-long chromosomes, we developed an I- Sce I–mediated strategy, which enables parallel integration of synthetic chromosome arms and reduced the overall integration time by 50% for synII. An I- Sce I site is introduced for generating a double-strand break to promote targeted homologous recombination during mitotic growth. Despite hundreds of modifications introduced, there are still regions sharing substantial sequence similarity that might lead to undesirable meiotic recombinations when intercrossing the two semisynthetic chromosome arm strains. Induction of the I- Sce I–mediated double-strand break is otherwise lethal and thus introduced a strong selective pressure for targeted homologous recombination. Since our strategy is designed to generate a markerless synII and leave the URA3 marker on the wild-type chromosome, we observed a tenfold increase in URA3 -deficient colonies upon I- Sce I induction, meaning that our strategy can greatly bias the crossover events toward the designated regions. By incorporating comprehensive phenotyping approaches at multiple levels, we demonstrated that synII was capable of powering the growth of yeast indistinguishably from wild-type cells (see the figure), showing highly consistent biological processes comparable to the native strain. Meanwhile, we also noticed modest but potentially significant up-regulation of the translational machinery. The main alteration underlying this change in expression is the deletion of 13 tRNA genes. A growth defect was observed in one very specific condition—high temperature (37°C) in medium with glycerol as a carbon source—where colony size was reduced significantly. We targeted and debugged this defect by two distinct approaches. The first approach involved phenotype screening of all intermediate strains followed by a complementation assay with wild-type sequences in the synthetic strain. By doing so, we identified a modification resulting from PCRTag recoding in TSC10 , which is involved in regulation of the yeast high-osmolarity glycerol (HOG) response pathway. After replacement with wild-type TSC10 , the defect was greatly mitigated. The other approach, debugging by SCRaMbLE, showed rearrangements in regions containing HOG regulation genes. Both approaches indicated that the defect is related to HOG response dysregulation. Thus, the phenotypic defect can be pinpointed and debugged through multiple alternative routes in the complex cellular interactome network. CONCLUSION We have demonstrated that synII segregates, replicates, and functions in a highly similar fashion compared with its wild-type counterpart. Furthermore, we believe that the iterative “design-build-test-debug” cycle methodology, established here, will facilitate progression of the Sc2.0 project in the face of the increasing synthetic genome complexity. SynII characterization. ( A ) Cell cycle comparison between synII and BY4741 revealed by the percentage of cells with separated CEN2-GFP dots, metaphase spindles, and anaphase spindles. ( B ) Replication profiling of synII (red) and BY4741 (black) expressed as relative copy number by deep sequencing. ( C ) RNA sequencing analysis revealed that the significant up-regulation of translational machinery in synII is induced by the deletion of tRNA genes in synII.
Shen, Yue↗
Preventing Run-Time Bugs at Compile-Time Using Advanced C++
When writing software, we develop algorithms that tell the computer what to do at run-time. Our solutions are easier to understand and debug when they are properly modeled using class hierarchies, enumerations, and a well-factored API. Unfortunately, even with these design tools, we end up having to debug our programs at run-time. Worse still, debugging an embedded system changes its dynamics, making it tough to find and fix concurrency issues. This paper describes techniques using C++ to detect run-time bugs *at compile time*. A concurrency library, developed at Fermilab, is used for examples in illustrating these techniques.
43 PARTICLE ACCELERATORS↗
Automatic inspection of program state in an uncooperative environment
Abstract The program state is formed by the values that the program manipulates. These values are stored in the stack, in the heap, or in static memory. The ability to inspect the program state is useful as a debugging or as a verification aid. Yet, there exists no general technique to insert inspection points in type‐unsafe languages such as C or C++. The difficulty comes from the need to traverse the memory graph in a so‐called uncooperative environment. In this article, we propose an automatic technique to deal with this problem. We introduce a static code transformation approach that inserts in a program the instrumentation necessary to report its internal state. Our technique has been implemented in LLVM. It is possible to adjust the granularity of inspection points trading precision for performance. In this article, we demonstrate how to use inspection points to debug compiler optimizations; to augment benchmarks with verification code; and to visualize data structures.
Magalhães, José Wesley de Souza↗
Performance Analysis Tool for HPC and Big Data Applications on Scientific Clusters
Big data is prevalent in HPC computing. Many HPC projects rely on complex workflows to analyze terabytes or petabytes of data. These workflows often require running over thousands of CPU cores and performing simultaneous data accesses, data movements, and computation. It is challenging to analyze the performance involving terabytes or petabytes of workflow data or measurement data of the executions, from complex workflows over a large number of nodes and multiple parallel task executions. To help identify performance bottlenecks or debug the performance issues in large-scale scientific applications and scientific clusters, we have developed a performance analysis framework, using state-ofthe- art open-source big data processing tools. Our tool can ingest system logs and application performance measurements to extract key performance features, and apply the most sophisticated statistical tools and data mining methods on the performance data. It utilizes an efficient data processing engine to allow users to interactively analyze a large amount of different types of logs and measurements. To illustrate the functionality of the big data analysis framework, we conduct case studies on the workflows from an astronomy project known as the Palomar Transient Factory (PTF) and the job logs from the genome analysis scientific cluster. Our study processed many terabytes of system logs and application performance measurements collected on the HPC systems at NERSC. The implementation of our tool is generic enough to be used for analyzing the performance of other HPC systems and Big Data workows.
97 MATHEMATICS AND COMPUTING↗
The PhEDEx next-gen website
PhEDEx is the data-transfer management solution written by CMS. It consists of agents running at each site, a website for presentation of information, and a web-based data-service for scripted access to information. The website allows users to monitor the progress of data-transfers, the status of site agents and links between sites, and the overall status and behaviour of everything about PhEDEx. It also allows users to make and approve requests for data-transfers and for deletion of data. It is the main point-of-entry for all users wishing to interact with PhEDEx. For several years, the website has consisted of a single perl program with about 10K SLOC. This program has limited capabilities for exploring the data, with only coarse filtering capabilities and no context-sensitive awareness. Graphical information is presented as static images, generated on the server, with no interactivity. It is also not well connected to the rest of the PhEDEx codebase, since much of it was written before the data-service was developed. All this makes it hard to maintain and extend. We are re-implementing the website to address these issues. The UI is being rewritten in Javascript, replacing most of the server-side code. We are using the YUI toolkit to provide advanced features and context-sensitive interaction, and will adopt a Javascript charting library for generating graphical representations client-side. This relieves the server of much of its load, and automatically improves server-side security. The Javascript components can be re-used in many ways, allowing custom pages to be developed for specific uses. In particular, standalone test-cases using small numbers of components make it easier to debug the Javascript than it is to debug a large server program. Information about PhEDEx is accessed through the PhEDEx data-service, since direct SQL is not available from the clients browser. This provides consistent semantics with other, externally written monitoring tools, which already use the data-service. It also reduces redundancy in the code, yielding a simpler, consolidated codebase. In this talk we describe our experience of re-factoring this monolithic server-side program into a lighter client-side framework. We describe some of the techniques that worked well for us, and some of the mistakes we made along the way. We present the current state of the project, and its future direction.
Egeland, R.↗
The Kokkos EcoSystem: Comprehensive Performance Portability For High Performance Computing
State of the art Engineering and Science codes have grown in complexity dramatically over the last two decades. As a consequence application teams have adopted more sophisticated development strategies, leveraging third party libraries, deploying comprehensive testing and using advanced debugging and profiling tools. In todays environment of diverse hardware platforms, these applications also desire performance portability - avoiding the need to duplicate work for various platforms - which makes it necessary that these tools and libraries also work across the various systems. The Kokkos EcoSystem provides that portable software stack. Based on the Kokkos Core Programming Model, the EcoSystem provides math libraries, interoperability capabilities with Python and Fortran, and Tools for analysing, debugging, and optimizing applications. In this paper we will provide an overview of the components, discuss some specific use cases, and highlight how co-designing these components enables a more developer friendly experience.
42 ENGINEERING↗
Three-phase Four-leg Inverter LabVIEW FPGA Control Code [SWR-16-26]
In the area of power electronics control, Field Programmable Gate Arrays (FPGAs) have the capability to outperform their Digital Signal Processor (DSP) counterparts due to the FPGA’s ability to implement true parallel processing and therefore facilitate higher switching frequencies, higher control bandwidth, and/or enhanced functionality. National Instruments (NI) has developed two platforms, Compact RIO (cRIO) and Single Board RIO (sbRIO), which combine a real-time processor with an FPGA. The FPGA can be programmed with a subset of the well-known LabVIEW graphical programming language. The use of cRIO and sbRIO for power electronics control has developed over the last few years to include control of three-phase inverters. Most three-phase inverter topologies include three switching legs. The addition of a fourth-leg to natively generate the neutral connection allows the inverter to serve single-phase loads in a microgrid or stand-alone power system and to balance the three-phase voltages in the presence of significant load imbalance. However, the control of a four-leg inverter is much more complex. In particular, instead of standard two-dimensional space vector modulation (SVM), the inverter requires three-dimensional space vector modulation (3D-SVM). The candidate software implements complete control algorithms in LabVIEW FPGA for a three-phase four-leg inverter. The software includes feedback control loops, three-dimensional space vector modulation gate-drive algorithms, advanced alarm handling capabilities, contactor control, power measurements, and debugging and tuning tools. The feedback control loops allow inverter operation in AC voltage control, AC current control, or DC bus voltage control modes based on external mode selection by a user or supervisory controller. The software includes the ability to synchronize its AC output to the grid or other voltage-source before connection. The software also includes provisions to allow inverter operation in parallel with other voltage regulating devices on the AC or DC buses. This flexibility allows the Inverter to operate as a stand-alone voltage source, connected to the grid, or in parallel with other controllable voltage sources as part of a microgrid or remote power system. In addition, as the inverter is expected to operate under severe unbalanced conditions, the software includes algorithms to accurately compute real and reactive power for each phase based on definitions provided in the IEEE Standard 1459: IEEE Standard Definitions for the Measurement of Electric Power Quantities Under Sinusoidal, Nonsinusoidal, Balanced, or Unbalanced Conditions. Finally, the software includes code to output analog signals for debugging and for tuning of control loops. The software fits on the Xilinx Virtex V LX110 FPGA embedded in the NI cRIO-9118 FPGA chassis, and with a 40 MHz base clock, supports a modulation update rate of 40 MHz, user-settable switching frequencies and synchronized control loop update rates of tens of kHz, and reference waveform generation, including Phase Lock Loop (PLL), update rate of 100 kHz.
Martin, Gregory↗
Energy Exascale Earth System Model v2.0.1
First patch release of v2.0.0 Changes since v2.0.0 [Important change] Fix ocean threading bug seen in debug cases on Chrysalis with Intel 20.0.4. Was introduced around time of v2.0.0 tag. Does not change v2.0.0 answers on Chrysalis because those didn't use threading or debugging. [EAM] Add semi-lagrangian tracer transport for theta-l (F90 and C++), add new algorithm for finding tropopause, add DSCREAM to allow v2 and SCREAM settings in same code such as adjust_ps [EAM-MMF] 60L default, allow C++ back end of RRTMGP (EAM too). [EAMxx] add nu-top functionality, fix forcing functor, add ttype9 and dcmip2012 tests 2.1, 2.2, and 3 HOMME: remove obsolete remap algs, option to specify dynamics alg indep of tracer, new sponge layer, add imex tests [ELM] Add topography-based subgrid (topounits), add FATES-ELM Nitro., Phos. and CH4 coupling, add land-use ts for NARRM, add lulc for SSP3 RCP7, Fix nutrient fertilization exp test and carbon isotope flux, Fix xactive lnd dry deposition, add lake water storage option, fix plant hydraulics 2d params, fix carbon budget calc, fix soil nutrient conc. bug, fix mosart dam bug, add test for new ELM, MOSART features, fix bug in O3 dry dep stomatal resistances, fix plant hydraulics restart BFB error, update mkmapdata. [MOSART] fix bug for reading the latitude from an unstructured input file, fix oversat in bubble test. [MPAS-ocean] Add CFC11, CFC12 tracers, add 2D spherical transport tests, fix del4 tracer mixing, add MARBL ocean tracer mixing, modify harmonic analysis options, add GPU port of vmix routines, fix calc of ML-averaged BV freq. [MPAS-seaice] Change extents of initial polar disks for oRRS18to6v3 grid, fix ice BGC with MARBL, update spherical test cases, fix DON coupling, Remove Cf from sea ice constants. [MPAS-landice] add CRYO1850-4xCO2 compset [CIME] add GCP, ANL GCE, Spock, Perlmutter, deprecate config_compilers.xml, fix and clean-up cmake macros, fix slurm bindings, refactor CIME internal testing, cleanup SCORPIO perf data, allow position independent compset naming, [also] update v2 benchmarking suite, extend e3sm_prod with throughput and memory checks
E3SM Project, DOE↗
A three-phase workflow for general and expressive representations of nondeterminism in HPC applications
Nondeterminism is an increasingly entrenched property of high-performance computing (HPC) applications and has recently been shown to seriously hamper debugging and reproducibility efforts. Additionally, tools for addressing the nondeterministic debugging problem have emerged, but they do not provide methods for systematically cataloging the nondeterminism in a given application. We propose a three-phase workflow for representing executions of nondeterministic message passing interface programs as event graphs, quantifying their structural similarity with graph kernels, and applying machine learning techniques to investigate shared properties across applications. We present an empirical study comparing two graph kernels’ suitability for this task and propose future uses of the methodology.
97 MATHEMATICS AND COMPUTING↗
High-speed, multi-channel detector readout electronics for fast radiation detectors
In this project, we are developing a high speed digital spectrometer that a) captures detector waveforms at rates up to 500 MSPS b) has upgraded event data acquisition with additional data buffers for zero dead time operation c) moves energy calculations to the FPGA to increase spectrometer throughput in fast scintillator applications d) uses a streamlined architecture and high speed data interface for even faster readout to the host PC These features are in addition to the standard functions in our existing spectrometers such as digitization, programmable trigger and energy filters, pileup inspection, data acquisition with energy and time stamps, MCA histograms, and run statistics. In Phase I, we upgraded one of our existing spectrometer designs to demonstrate the key principle of fast waveform capture using a 500 MSPS, 12 bit ADC and a Xilinx Virtex-4 FPGA. This upgraded spectrometer, named P500, performed well in initial tests of energy resolution, pulse shape analysis, and timing measurements, thus achieving item (a) above. In Phase II, we are revising the P500 to build a commercial prototype with the improvements listed in items (b)-(d). As described in the previous report, two devices were built to pursue this goal, named the Pixie-500 and the Pixie-500 Express. The Pixie-500 has only minor improvements from the Phase I prototype and is intended as an early commercial product (its production and part of its development were funded outside the SBIR). It also allows testing of the ADC performance in real applications.The Pixie-500 Express (or Pixie-500e) includes all of the improvements (b)-(d). At the end of Phase II of the project, we have tested and debugged the hardware, firmware and software of the Pixie-500 Express prototype boards delivered 12/3/2010. This proved substantially more complex than anticipated. At the time of writing, all hardware bugs have been fixed, the PCI Express interface is working, the SDRAM has been successfully tested and the SHARC DSP has been booted with preliminary code. All new ICs and circuitry on the prototype are working properly, however some of the planned firmware and software functions have not yet been completely implemented and debugged. Overall, due to the unanticipated complexity of the PCI Express interface, some aspects of the project could not be completed with the time and funds available in Phase II. These aspects will be completed in self-funded Phase III.
46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗
High Performance Computing Productivity Study - Evaluation of Parallel Tools Platform (PTP) Eclipse Plug-In
This report is a DARPA funded Work For Others (WFO) evaluation of the Parallel Tools Platform (PTP) version 5.0.3 (Released October 18, 2011). PTP is currently being developed and supported as an open source product managed by Project Lead Greg Watson and team at IBM plus several other contributors. The tool has been in development since 2005 with a goal of providing an infrastructure for the integration of high performance computing tools. Basic functionality such as source code editing, compiling, launching, and debugging, plus more advanced features including performance monitoring and deployment have been bundled into an Eclipse Integrated Development Environment (IDE) plug-in to give parallel application programmers the features and improved productivity gained from using a common, well established development platform. The evaluation encompasses the basic aspects of using PTP, beginning with the installation and configuration of the plug-in, followed by code development and debugging. Each aspect is evaluated based on the expectations of my experience as an Eclipse user and is presented in the following format: • Feature description • User Experience • Evaluation The feature description is based on the provided documentation for PTP and the ‘generic’ expectations of what the feature should provide. The user experience reveals the actual use and exercise of the feature – specifically in the context and perspective of the evaluation platform provided by Lawrence Livermore National Laboratory. The evaluation of each feature includes the overall outcome of the user experience, along with the expectations that were not met, met, or exceeded along with any issues that were encountered.
97 MATHEMATICS AND COMPUTING↗