Engineering topics

White, Michael

Publications and source records attributed to White, Michael.

5 records

DOE OSTI2024

Performance of PIP-II high-beta 650 cryomodule after transatlantic shipping

After shipment to the Daresbury Lab and return to Fermilab, the prototype HB650 cryomodule underwent another phase of 2K RF testing to ascertain any performance issues that may have arisen from the transport of the cryomodule. While measurements taken at room temperature after the conclusion of shipment indicated that there were no negative impacts on cavity alignment, beamline vacuum, or cavity frequency, testing at 2K was required to validate other aspects such as tuner operation, cavity coupling, cryogenic system integrity, and cavity performance. Results of this latest round of limited 2K testing will be presented.

43 PARTICLE ACCELERATORS↗

DOE OSTI2024

Optimization of static heat loads of the PIP-II cryomodules based on prototype HB650 cryomodule test results

During the first cool down of the prototype HB650 cryomodule (pHB650 CM), high static heat loads have been measured compared to the estimation. Several analysis and calculations have been performed to explain this difference which led to cool down this cryomodule two additional times. Before each cool down, repairs and upgrades have been done, and instrumentations were added to identify the issues and quantify their impact on the heat loads. Based on these findings, the production cryomodule design and assembly process have been updated to align the future heat loads measurements with the estimations.

43 PARTICLE ACCELERATORS↗

DOE OSTI2024

Integration of a new Cryogenic Liquefier into the IB-1 Cryogenic Test Facility

The increase over the last years of the testing activities related to quantum systems, SRF cavities for the PIP-II and the LCLS-II projects, as well as superconducting magnets for the HL-LHC project and Fusion research activities, has required the addition of a new Helium cryogenic plant into the existing IB-1 Industrial Cryogenic Test Facility. The new cryogenic plant is composed of a cryogenic liquefier (Cold Box) able to provide up to 340 L/h, a 4 kL Dewar and two Mycom ® compressors providing up to 120 g/s. AL-AT (Air Liquide Advanced Technologies) has taken part of this project by designing and manufacturing the cryogenic liquefier. This new cryogenic plant is connected through a cryogenic distribution system to a 10 kL Dewar, which is part of the existing cryogenic test facility, itself composed of another Cold Box and a Sullair ® compressor. The new cryogenic plant has two main operating modes: one allows to transfer liquid helium at 1.7 bar between the two Dewars, the other allows to transfer supercritical Helium at 2 bar or more between the new Cold Box and the 10 kL Dewar. The entire industrial cryogenic facility is handled by a common Inventory Control System, composed of three control valves, and 9 tanks giving a total buffer volume of more than 1000 m3. This paper presents the technical features of the new Helium cryogenic plant, as well as the main results of the liquefier commissioning phase and details of the helium transfer between the two Dewars, making the connection between the cryogenic plants at the IB-1 Industrial Cryogenic Test Facility.

43 PARTICLE ACCELERATORS↗

NASA NTRS2005

Program Computes Sound Pressures at Rocket Launches

Launch Vehicle External Sound Pressure is a computer program that predicts the ignition overpressure and the acoustic pressure on the surfaces and in the vicinity of a rocket and launch pad during launch. The program generates a graphical user interface (GUI) that gathers input data from the user. These data include the critical dimensions of the rocket and of any launch-pad structures that may act as acoustic reflectors, the size and shape of the exhaust duct or flame deflector, and geometrical and operational parameters of the rocket engine. For the ignition-overpressure calculations, histories of the chamber pressure and mass flow rate also are required. Once the GUI has gathered the input data, it feeds them to ignition-overpressure and launch-acoustics routines, which are based on several approximate mathematical models of distributed sources, transmission, and reflection of acoustic waves. The output of the program includes ignition overpressures and acoustic pressures at specified locations.

Ogg, Gary↗

NASA NTRS2000

Supporting Development of Satellite's Guidance Navigation and Control Software: A Product Line Approach

The NASA Goddard Space Flight Center Flight Software Branch (FSB) is developing a Guidance, Navigation, and Control (GNC) Flight Software (FSW) product line. The demand for increasingly more complex flight software in less time while maintaining the same level of quality has motivated us to look for better FSW development strategies. The GNC FSW product line has been planned to address the core GNC FSW functionality very similar on many recent low/near Earth missions in the last ten years. Unfortunately these missions have not accomplished significant drops in development cost since a systematic approach towards reuse has not been adopted. In addition, new demands are continually being placed upon the FSW which means the FSB must become more adept at providing GNC FSW functionality's core so it can accommodate additional requirements. These domain features together with engineering concepts are influencing the specification, description and evaluation of FSW product line. Domain engineering is the foundation for emerging product line software development approaches. A product line is 'A family of products designed to take advantage of their common aspects and predicted variabilities'. In our product line approach, domain engineering includes the engineering activities needed to produce reusable artifacts for a domain. Application engineering refers to developing an application in the domain starting from reusable artifacts. The focus of this paper is regarding the software process, lessons learned and on how the GNC FSW product line manages variability. Existing domain engineering approaches do not enforce any specific notation for domain analysis or commonality and variability analysis. Usually, natural language text is the preferred tool. The advantage is the flexibility and adapt ability of natural language. However, one has to be ready to accept also its well-known drawbacks, such as ambiguity, inconsistency, and contradictions. While most domain analysis approaches are functionally oriented, the idea of applying the object-oriented approach in domain analysis is not new. Some authors propose to use UML as the notation underlying domain analysis. Our work is based on the same idea of merging UML and domain analysis. Further, we propose a few extensions to UML in order to express variability, and we define precisely their semantics so that a tool can support them. The extensions are designed to be implemented on the API of a popular industrial CASE tool, with obvious advantages in cost and availability of tool support. The paper outlines the product line processes and identifies where variability must be addressed. Then it describes the product line products with respect to how they accommodate variability. The Celestial Body subdomain is used as a working example. Our results to date are summarized and plans for the future are described.

McComas, David↗