Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “C CODES”

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.

At least 163 records · Page 9
All sourcesNASA NTRSDOE OSTI
NASA NTRS2024

Runtime Verification of Hard Realtime Systems With Copilot: A Tutorial

This presentation is a tutorial on RV using Copilot, a runtime verification framework for real-time embedded systems. Copilot monitors are written in a compositional, stream-based language with support for a variety of Temporal Logics (TL), which results in robust, high-level specifications that are easier to understand than their traditional counterparts. The framework translates monitor specifications into C code with static memory requirements, which can be compiled to run on embedded hardware.

runtime monitoring↗
NASA NTRSDate not supplied

Leveraging High-Level Synthesis to Migrate Motor Control Algorithms From Microcontroller to FPGA

As motor control algorithms become increasingly complex, traditional microcontroller-based implementations are reaching computational limits that prevent the controller from operating at the required speed. This paper presents a novel workflow leveraging High-Level Synthesis (HLS) to migrate motor control algorithms from a microcontroller implementation to a Field-Programmable Gate Array (FPGA) implementation. The proposed approach utilizes the free Vitis HLS software to automatically convert Embedded Coder-generated C code from a Simulink model into Hardware Description Language (HDL) code suitable for FPGA deployment.

FPGA↗
NASA NTRSDate not supplied

Leveraging High-Level Synthesis to Migrate Motor Control Algorithms From Microcontroller to FPGA

As motor control algorithms become increasingly complex, traditional microcontroller-based implementations are reaching computational limits that prevent the controller from operating at the required speed. This paper presents a novel workflow leveraging High-Level Synthesis (HLS) to migrate motor control algorithms from a microcontroller implementation to a Field-Programmable Gate Array (FPGA) implementation. The proposed approach utilizes the free Vitis HLS software to automatically convert Embedded Coder-generated C code from a Simulink model into Hardware Description Language (HDL) code suitable for FPGA deployment.

FPGA↗
DOE OSTI2023

Transient Efficiency, Flexibility, and Reliability Optimization of Coal-Fired Power Plants - Final Program Review

This program developed an advanced model-based monitoring and model-predictive control algorithms for a coal fired power plant (CFPP), and deployed these algorithms in a real-time platform to demonstrate performance benefits for transient flexibility and plant operation efficiency. More specifically, the objectives were successfully achieved through a combination of (i) developing a high-fidelity transient plant model in Apros, which was used as a high-fidelity plant simulation between $100-50\% TMCR$ where TMCR denotes the turbine maximum continuous rating, i.e., baseload, (ii) developing a very fast physics-based reduced-order model (ROM) of the plant, which ran more than $100\times$ faster than real-time, enabling its use as real-time embedded model for model-based estimation (MBE) and model predictive control (MPC) (iii) implementing a real-time MBE based on ROM using a robust unscented Kalman filter (UKF) to continuously tune the ROM to match the measurements from high-fidelity Apros plant model despite significant plant-model mismatch, and thus, obtain a Digital Twin of the plant (iv) designing and implementing a real-time MPC with dual objectives of transient plant load tracking with high ramp rates and minimizing coal consumption, i.e., improving plant efficiency in the baseload-partload operation range of $100-50\% TMCR$. Each key element above was developed and tested individually, and has been reported in corresponding Topical Reports. Finally, all the individual elements were integrated in an overall closed-loop system, that was successfully tested in desktop Simulink test harness simulations with ROM or high-fidelity model as the plant. Thereafter, the Simulink implementation was used to auto-generate C-code and deploy as real-time Docker microservice containers in Linux, and validate that they can run in real-time in the hardware-in-the loop (HIL) setup and produce the same results as in Simulink. The results of the integrated simulation tests in Simulink as well as the real-time HIL deployment are documented in this final report, showing good load tracking for load ramps at $3-4\%/min$ ramp rates, and achieving up to $5.5\%$ reduction in coal relative to baseline operation at $50\% TMCR$ load. The desktop and HIL simulations show successful performance of the overall model based estimation and control solution and achieve the key objectives of the program for flexible, efficient and reliable operation of sub-critical coal fired power plants.

20 FOSSIL-FUELED POWER PLANTS↗
DOE OSTI2024

ECAR-6564 Rev 1 MARVEL Project Primary Coolant System ASME BPVC Section III Division 5 Design by Analysis

This report demonstrates that the MARVEL Reactor Primary Coolant Boundary (herein referred to as the Primary Coolant System, or PCS) is designed to meet ASME BPVC Section III Division 5 elevated temperature service design-by-analysis criteria. The analysis approach that delineates division of responsibilities to meet project objectives is discussed herein. In short, Design and Service Level A, B, and C code calculations are detailed in ECAR-6580 [9] for the majority of the PCS with complex geometry, while the Lower Downcomers, Bottom Head, and Reactor Core Barrel are analyzed in ANL-24/36. Service Level D code calculations are detailed in this document.

21 - SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLAN↗
NASA NTRS2016

ROS Hexapod

As an intern project for NASA Johnson Space Center (JSC), my job was to familiarize myself and operate a Robotics Operating System (ROS). The project outcome converted existing software assets into ROS using nodes, enabling a robotic Hexapod to communicate to be functional and controlled by an existing PlayStation 3 (PS3) controller. Existing control algorithms and current libraries have no ROS capabilities within the Hexapod C++ source code when the internship started, but that has changed throughout my internship. Conversion of C++ codes to ROS enabled existing code to be compatible with ROS, and is now controlled using an existing PS3 controller. Furthermore, my job description was to design ROS messages and script programs that enabled assets to participate in the ROS ecosystem by subscribing and publishing messages. Software programming source code is written in directories using C++. Testing of software assets included compiling code within the Linux environment using a terminal. The terminal ran the code from a directory. Several problems occurred while compiling code and the code would not compile. So modifying code to where C++ can read the source code were made. Once the code was compiled and ran, the code was uploaded to Hexapod and then controlled by a PS3 controller. The project outcome has the Hexapod fully functional and compatible with ROS and operates using the PlayStation 3 controller. In addition, an open source software (IDE) Arduino board will be integrated into the ecosystem with designing circuitry on a breadboard to add additional behavior with push buttons, potentiometers and other simple elements in the electrical circuitry. Other projects with the Arduino will be a GPS module, digital clock that will run off 22 satellites to show accurate real time using a GPS signal and an internal patch antenna to communicate with satellites. In addition, this internship experience has led me to pursue myself to learn coding more efficiently and effectively to write, subscribe and publish my own source code in different programming languages. With some familiarity with software programming, it will enhance my skills in the electrical engineering field. In contrast, my experience here at JSC with the Simulation and Graphics Branch (ER7) has led me to take my coding skill to be more proficient to increase my knowledge in software programming, and also enhancing my skills in ROS. This knowledge will be taken back to my university to implement coding in a school project that will use source coding and ROS to work on the PR2 robot which is controlled by ROS software. My skills learned here will be used to integrate messages to subscribe and publish ROS messages to a PR2 robot. The PR2 robot will be controlled by an existing PS3 controller by changing C++ coding to subscribe and publish messages to ROS. Overall the skills that were obtained here will not be lost, but increased.

Davis, Kirsch↗
NASA NTRS1994

Error coding simulations in C

When data is transmitted through a noisy channel, errors are produced within the data rendering it indecipherable. Through the use of error control coding techniques, the bit error rate can be reduced to any desired level without sacrificing the transmission data rate. The Astrionics Laboratory at Marshall Space Flight Center has decided to use a modular, end-to-end telemetry data simulator to simulate the transmission of data from flight to ground and various methods of error control. The simulator includes modules for random data generation, data compression, Consultative Committee for Space Data Systems (CCSDS) transfer frame formation, error correction/detection, error generation and error statistics. The simulator utilizes a concatenated coding scheme which includes CCSDS standard (255,223) Reed-Solomon (RS) code over GF(2(exp 8)) with interleave depth of 5 as the outermost code, (7, 1/2) convolutional code as an inner code and CCSDS recommended (n, n-16) cyclic redundancy check (CRC) code as the innermost code, where n is the number of information bits plus 16 parity bits. The received signal-to-noise for a desired bit error rate is greatly reduced through the use of forward error correction techniques. Even greater coding gain is provided through the use of a concatenated coding scheme. Interleaving/deinterleaving is necessary to randomize burst errors which may appear at the input of the RS decoder. The burst correction capability length is increased in proportion to the interleave depth. The modular nature of the simulator allows for inclusion or exclusion of modules as needed. This paper describes the development and operation of the simulator, the verification of a C-language Reed-Solomon code, and the possibility of using Comdisco SPW(tm) as a tool for determining optimal error control schemes.

Noble, Viveca K.↗
NASA NTRS2016

Investigating the Simulink Auto-Coding Process

Model based program design is the most clear and direct way to develop algorithms and programs for interfacing with hardware. While coding "by hand" results in a more tailored product, the ever-growing size and complexity of modern-day applications can cause the project work load to quickly become unreasonable for one programmer. This has generally been addressed by splitting the product into separate modules to allow multiple developers to work in parallel on the same project, however this introduces new potentials for errors in the process. The fluidity, reliability and robustness of the code relies on the abilities of the programmers to communicate their methods to one another; furthermore, multiple programmers invites multiple potentially differing coding styles into the same product, which can cause a loss of readability or even module incompatibility. Fortunately, Mathworks has implemented an auto-coding feature that allows programmers to design their algorithms through the use of models and diagrams in the graphical programming environment Simulink, allowing the designer to visually determine what the hardware is to do. From here, the auto-coding feature handles converting the project into another programming language. This type of approach allows the designer to clearly see how the software will be directing the hardware without the need to try and interpret large amounts of code. In addition, it speeds up the programming process, minimizing the amount of man-hours spent on a single project, thus reducing the chance of human error as well as project turnover time. One such project that has benefited from the auto-coding procedure is Ramses, a portion of the GNC flight software on-board Orion that has been implemented primarily in Simulink. Currently, however, auto-coding Ramses into C++ requires 5 hours of code generation time. This causes issues if the tool ever needs to be debugged, as this code generation will need to occur with each edit to any part of the program; additionally, this is lost time that could be spent testing and analyzing the code. This is one of the more prominent issues with the auto-coding process, and while much information is available with regard to optimizing Simulink designs to produce efficient and reliable C++ code, not much research has been made public on how to reduce the code generation time. It is of interest to develop some insight as to what causes code generation times to be so significant, and determine if there are architecture guidelines or a desirable auto-coding configuration set to assist in streamlining this step of the design process for particular applications. To address the issue at hand, the Simulink coder was studied at a foundational level. For each different component type made available by the software, the features, auto-code generation time, and the format of the generated code were analyzed and documented. Tools were developed and documented to expedite these studies, particularly in the area of automating sequential builds to ensure accurate data was obtained. Next, the Ramses model was examined in an attempt to determine the composition and the types of technologies used in the model. This enabled the development of a model that uses similar technologies, but takes a fraction of the time to auto-code to reduce the turnaround time for experimentation. Lastly, the model was used to run a wide array of experiments and collect data to obtain knowledge about where to search for bottlenecks in the Ramses model. The resulting contributions of the overall effort consist of an experimental model for further investigation into the subject, as well as several automation tools to assist in analyzing the model, and a reference document offering insight to the auto-coding process, including documentation of the tools used in the model analysis, data illustrating some potential problem areas in the auto-coding process, and recommendations on areas or practices in the current Ramses model that should be further investigated. Several skills were required to be built up over the course of the internship project. First and foremost, my Simulink skills have improved drastically, as much of my experience had been modeling electronic circuits as opposed to software models. Furthermore, I am now comfortable working with the Simulink Auto-coder, a tool I had never used until this summer; this tool also tested my critical thinking and C++ knowledge as I had to interpret the C++ code it was generating and attempt to understand how the Simulink model affected the generated code. I had come into the internship with a solid understanding of Matlab code, but had done very little in using it to automate tasks, particularly Simulink tasks; along the same lines, I had rarely used shell script to automate and interface with programs, which I gained a fair amount of experience with this summer, including how to use regular expression. Lastly, soft-skills are an area everyone can continuously improve on; having never worked with NASA engineers, which to me seem to be a completely different breed than what I am used to (commercial electronic engineers), I learned to utilize the wealth of knowledge present at JSC. I wish I had come into the internship knowing exactly how helpful everyone in my branch would be, as I would have picked up on this sooner. I hope that having gained such a strong foundation in Simulink over this summer will open the opportunity to return to work on this project, or potentially other opportunities within the division. The idea of leaving a project I devoted ten weeks to is a hard one to cope with, so having the chance to pick up where I left off sounds appealing; alternatively, I am interested to see if there are any opening in the future that would allow me to work on a project that is more in-line with my research in estimation algorithms. Regardless, this summer has been a milestone in my professional career, and I hope this has started a long-term relationship between JSC and myself. I really enjoy the thought of building on my experience here over future summers while I work to complete my PhD at Missouri University of Science and Technology.

Gualdoni, Matthew J.↗
NASA NTRS2011

Coded Modulation in C and MATLAB

This software, written separately in C and MATLAB as stand-alone packages with equivalent functionality, implements encoders and decoders for a set of nine error-correcting codes and modulators and demodulators for five modulation types. The software can be used as a single program to simulate the performance of such coded modulation. The error-correcting codes implemented are the nine accumulate repeat-4 jagged accumulate (AR4JA) low-density parity-check (LDPC) codes, which have been approved for international standardization by the Consultative Committee for Space Data Systems, and which are scheduled to fly on a series of NASA missions in the Constellation Program. The software implements the encoder and decoder functions, and contains compressed versions of generator and parity-check matrices used in these operations.

Hamkins, Jon↗
NASA NTRS1986

Software issues involved in code translation of C to Ada programs

It is often thought that translation of one programming language to another is a simple solution that can be used to extend the software life span or in rehosting software to another environment. The possible problems are examined as are the advantages and disadvantages of direct machine or human code translation versus that of redesign and rewrite of the software. The translation of the expert system language called C Language Integrated Production System (CLIPS) which is written in C, to Ada, will be used as a case study of the problems that are encountered.

Hooi, Robert↗
DOE OSTI2020

Development of a Conditioned System-Level Groundwater Model to Evaluate Long-Term Groundwater Impacts within a Performance Assessment - 20115

A preliminary performance assessment (PA) of single-shell tank Waste Management Area (WMA) A-AX located at the U.S. Department of Energy (DOE)'s Hanford Site in southeastern Washington is being conducted to satisfy the requirements of DOE Order 435.1 [1] as it relates to closure of the single-shell radioactive waste tanks in the WMA A-AX tank farms. A PA assesses the fate, transport, and impacts of radionuclides within a low-level radioactive waste disposal facility in its assumed closure configuration and the subsequent potential doses to humans over a 1,000-year compliance period and a 10,000-year performance evaluation period. The WMA A-AX preliminary PA evaluation is structured around the complementary use of process-level and system-level models to calculate the facility performance against established DOE Order 435.1 [1] performance objectives. Process-level models are those that represent a detailed phenomenological representation of processes of concern in the PA. Process models typically only represent one or a few of the components of the PA, such as groundwater flow and transport, and must be integrated with other modeling elements to perform PA calculations. System-level models are those that are abstracted from the process models, retaining the essential features of the process model, while allowing integration of all aspects of the PA in a single modeling framework. System-level models are often characterized by coarser numerical discretization, lower dimensionality, or other similar simplifications compared to the process-level model. Traditionally, a three-dimensional (3-D) process-level model is utilized primarily to evaluate the long-term impact on groundwater and the potential doses to individuals who consume contaminated groundwater. System-level models are also utilized to evaluate the groundwater pathway in PAs. These models typically have reduced dimensionality (1-D) and are conditioned utilizing flow fields (Darcy fluxes) and moisture content distributions that are abstracted from the process level models. The abstraction approach assures that the flow field in both models is consistent for a specific set of input parameters for flow, differing only in the discretization and dimensionality of the two models. The preliminary WMA A-AX PA incorporates a detailed representation of the geological system and hydraulic properties within the 3-D model STOMP{sup C} numerical code so that the effects of relevant features and processes on water flow and radionuclide transport in the subsurface can be evaluated. The complementary system-level model is developed utilizing the GoldSim{sup C} code to implement a simplified, 1-D equivalent model to represent the groundwater pathway. Contaminant transport through the vadose zone and unconfined aquifer for Tc-99 and I-129 were evaluated in each of the models. Adjustments to the saturated portion of the GoldSim{sup C} 1-D model were required to mimic the dispersion effect captured with the 3-D STOMP{sup C} model. Once this conditioning was conducted, highly similar results for the transport of Tc-99 and I-129 were achieved at the point of calculation, located 100 m downgradient from the WMA A-AX fenceline. These radionuclides represent elements that are regarded as primary dose drivers in the PA groundwater pathway analysis. The high degree of conformance between the two models suggests that the use of the equivalent 1-D system model is suitable for evaluating the full suite of radionuclides that will be released from the tank sources within WMA A-AX over the 1,000-year compliance period and over the 10,000-year evaluation period. (authors)

12 MANAGEMENT OF RADIOACTIVE AND NON-RADIOACTIVE W↗
NASA NTRSDate not supplied

Spectral Analysis of Integrated Pressures on Patches with Unsteady Pressure-Sensitive Paint Measurements

The technique of Pressure-Sensitive Paint (PSP) is commonly used in the aerospace industry to measure surface pressures on the model of launch vehicles and airplanes in the wind tunnel test. Recent research has demonstrated that Unsteady Pressure-Sensitive Paint (uPSP) can be an essential tool for the assessment of the unsteady, aerodynamic phenomena. The work described in this paper is a part of NASA’s development of a new state-of-the-art uPSP capability in production wind tunnels. This paper describes the spectral analysis of integrated pressures on patches of the scale model of the Space Launch System (SLS) Block 1 cargo vehicle with the uPSP measurements, which were collected in the Ascent Transient Aerodynamics Test (ATAT) with the Unitary Plan Wind Tunnel 11-by-11-foot Transonic Wind Tunnel in September 2019 at NASA Ames Research Center. The patches are defined with x station values, indicating the position along length of the SLS vehicle, and azimuth angles of the scale model. For each patch, the polygons are determined from the surface cells of the grid of the model, clipped with the edges of the patch, and each of the polygons is divided into triangles. The integrated pressure of the patch is determined as the ratio of the sum of the forces on the triangles over the sum of the areas of the triangles. For each run of the test, the Cross Power Spectral Density (CPSD) and magnitude squared coherence are computed from the time series of the integrated pressures on the patches. The pressure integration is coded in C++ and the spectral analysis is coded in MATLAB. The results were generated with the execution of the compiled C++ and MATLAB codes in parallel on the NASA Pleiades supercomputer. The results of pressure integration and spectral analysis are presented in this paper, and the data consistency of the test is also demonstrated. Funding for this research was provided by the NASA Aerosciences Evaluation and Test Capabilities Project.

Pressure-Sensitive Paint↗
NASA NTRS2003

Comparison of the AUSM(+) and H-CUSP Schemes for Turbomachinery Applications

Many turbomachinery CFD codes use second-order central-difference (C-D) schemes with artificial viscosity to control point decoupling and to capture shocks. While C-D schemes generally give accurate results, they can also exhibit minor numerical problems including overshoots at shocks and at the edges of viscous layers, and smearing of shocks and other flow features. In an effort to improve predictive capability for turbomachinery problems, two C-D codes developed by Chima, RVCQ3D and Swift, were modified by the addition of two upwind schemes: the AUSM+ scheme developed by Liou, et al., and the H-CUSP scheme developed by Tatsumi, et al. Details of the C-D scheme and the two upwind schemes are described, and results of three test cases are shown. Results for a 2-D transonic turbine vane showed that the upwind schemes eliminated viscous layer overshoots. Results for a 3-D turbine vane showed that the upwind schemes gave improved predictions of exit flow angles and losses, although the HCUSP scheme predicted slightly higher losses than the other schemes. Results for a 3-D supersonic compressor (NASA rotor 37) showed that the AUSM+ scheme predicted exit distributions of total pressure and temperature that are not generally captured by C-D codes. All schemes showed similar convergence rates, but the upwind schemes required considerably more CPU time per iteration.

Chima, Rodrick V.↗
DOE OSTI2020

C HIMERA : A Massively Parallel Code for Core-collapse Supernova Simulations

Herein we provide a detailed description of the C HIMERA code, a code developed to model core collapse supernovae (CCSNe) in multiple spatial dimensions. The CCSN explosion mechanism remains the subject of intense research. Progress to date demonstrates that it involves a complex interplay of neutrino production, transport, and interaction in the stellar core, three-dimensional stellar core fluid dynamics and its associated instabilities, nuclear burning, and the fundamental physics of the neutrino–stellar core weak interactions and the equations of state of all stellar core constituents—particularly, the nuclear equation of state associated with core nucleons, both free and bound in nuclei. C HIMERA , by incorporating detailed neutrino transport, realistic neutrino–matter interactions, three-dimensional hydrodynamics, realistic nuclear, leptonic, and photonic equations of state, and a nuclear reaction network, along with other refinements, can be used to study the role of neutrino radiation, hydrodynamic instabilities, and a variety of input physics in the explosion mechanism itself. It can also be used to compute observables such as neutrino signatures, gravitational radiation, and the products of nucleosynthesis associated with CCSNe. The code contains modules for neutrino transport, multidimensional compressible hydrodynamics, nuclear reactions, a variety of neutrino interactions, equations of state, and modules to provide data for post-processing observables such as the products of nucleosynthesis, and gravitational radiation. C HIMERA is an evolving code, being updated periodically with improved input physics and numerical refinements. We detail here the current version of the code, from which future improvements will stem, which can in turn be described as needed in future publications.

79 ASTRONOMY AND ASTROPHYSICS↗
NASA NTRS1997

Parallelization of Rocket Engine Simulator Software (PRESS)

Parallelization of Rocket Engine System Software (PRESS) project is part of a collaborative effort with Southern University at Baton Rouge (SUBR), University of West Florida (UWF), and Jackson State University (JSU). The second-year funding, which supports two graduate students enrolled in our new Master's program in Computer Science at Hampton University and the principal investigator, have been obtained for the period from October 19, 1996 through October 18, 1997. The key part of the interim report was new directions for the second year funding. This came about from discussions during Rocket Engine Numeric Simulator (RENS) project meeting in Pensacola on January 17-18, 1997. At that time, a software agreement between Hampton University and NASA Lewis Research Center had already been concluded. That agreement concerns off-NASA-site experimentation with PUMPDES/TURBDES software. Before this agreement, during the first year of the project, another large-scale FORTRAN-based software, Two-Dimensional Kinetics (TDK), was being used for translation to an object-oriented language and parallelization experiments. However, that package proved to be too complex and lacking sufficient documentation for effective translation effort to the object-oriented C + + source code. The focus, this time with better documented and more manageable PUMPDES/TURBDES package, was still on translation to C + + with design improvements. At the RENS Meeting, however, the new impetus for the RENS projects in general, and PRESS in particular, has shifted in two important ways. One was closer alignment with the work on Numerical Propulsion System Simulator (NPSS) through cooperation and collaboration with LERC ACLU organization. The other was to see whether and how NASA's various rocket design software can be run over local and intra nets without any radical efforts for redesign and translation into object-oriented source code. There were also suggestions that the Fortran based code be encapsulated in C + + code thereby facilitating reuse without undue development effort. The details are covered in the aforementioned section of the interim report filed on April 28, 1997.

Cezzar, Ruknet↗
DOE OSTI2020

Analysis of MHD stability and active mode control on KSTAR for high confinement, disruption-free plasma

Long-pulse plasma operation at high normalized beta, $β_N$, above the $\textit{n}$= 1 ideal MHD no-wall stability limit in KSTAR is presently limited by tearing instabilities rather than resistive wall modes. H-mode plasma operation during the recent KSTAR device campaign produced discharges having strong $\textit{m/n}$= 2/1 tearing instabilities at $β_N$ lower than the ideal MHD no-wall beta limit. The unstable tearing mode consequently reduced plasma confinement and toroidal plasma rotation significantly. We report the experiment confirmed that an extended duration of electron cyclotron heating (ECH) at the initial phase of the discharge plays a critical role in mode destabilization. To study destabilizing mechanisms that affect the mode growth, the stability of the observed tearing modes from plasmas with significantly different $β_N$ is computed by using the resistive DCON code and the M3D-C 1 code. Equilibrium reconstructions that include constraints from internal profile diagnostics, and computed fast particle pressure are used as input for reliable computation of stability. The classical tearing stability index, Δ', from resistive DCON is computed to be unstable when the island is fully saturated with large amplitude, while the unstable mode is not computed by M3D-C 1 . The modified Rutherford equation (MRE) describing the evolution of the island width has been constructed for KSTAR plasmas by using plasma parameters computed by the TRANSP code. The MRE model estimates a saturated island width corresponding to ~10% of the plasma minor radius for equilibrium at high $β_N$ 3 having a stable Δ' from the resistive DCON. In preparation for long-pulse plasma operation at higher beta utilizing increased plasma heating power, a resistive wall mode (RWM) active feedback control algorithm has been completed and enabled on KSTAR. To accurately determine the $\textit{n}$= 1component produced by RWMs, an algorithm has been developed that includes magnetic sensor compensation of the prompt applied field and the field from the induced current on the passive conductors. Use of multiple toroidal sensor arrays is enabled by modifying the sensor toroidal angles assumed in mode decomposition to include the effect of varied mode helicities in the outboard region where the mode measurement is made. This analysis on stability, transport, and control provides the required foundation for disruption prediction and avoidance research on KSTAR.

resistive wall mode (RWM)↗
NASA NTRS2003

Traceability Through Automatic Program Generation

Program synthesis is a technique for automatically deriving programs from specifications of their behavior. One of the arguments made in favour of program synthesis is that it allows one to trace from the specification to the program. One way in which traceability information can be derived is to augment the program synthesis system so that manipulations and calculations it carries out during the synthesis process are annotated with information on what the manipulations and calculations were and why they were made. This information is then accumulated throughout the synthesis process, at the end of which, every artifact produced by the synthesis is annotated with a complete history relating it to every other artifact (including the source specification) which influenced its construction. This approach requires modification of the entire synthesis system - which is labor-intensive and hard to do without influencing its behavior. In this paper, we introduce a novel, lightweight technique for deriving traceability from a program specification to the corresponding synthesized code. Once a program has been successfully synthesized from a specification, small changes are systematically made to the specification and the effects on the synthesized program observed. We have partially automated the technique and applied it in an experiment to one of our program synthesis systems, AUTOFILTER, and to the GNU C compiler, GCC. The results are promising: 1. Manual inspection of the results indicates that most of the connections derived from the source (a specification in the case of AUTOFILTER, C source code in the case of GCC) to its generated target (C source code in the case of AUTOFILTER, assembly language code in the case of GCC) are correct. 2. Around half of the lines in the target can be traced to at least one line of the source. 3. Small changes in the source often induce only small changes in the target.

Richardson, Julian↗