Search NASA⌕ Search

SEARCH · Search NASA

Results for “File Systems”

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 271 records · Page 15
All sourcesNASA NTRSDOE OSTI
DOE OSTI2020

Methods and apparatus to modify a binary file for scalable dependency loading on distributed computing systems

Methods and apparatus to modify a binary file for scalable loading on distributed computing systems are disclosed. An example method to modify a binary file for scalable loading on a distributed computing system includes identifying, by executing an instruction with a processor, in the binary file a file name for a shared file, determining, by executing an instruction with the processor, whether the shared file can be loaded based on a path name specified in the binary file, and, responsive to a determination that the shared file can be loaded, generating, by executing an instruction with the processor, an identifier that can be used to access a local file scalably copied from a global file system, and modifying, by executing an instruction with the processor, the binary file by replacing, in the binary file, the file name with the generated identifier.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2022

Accelerating shared file checkpoint with local burst buffers

A data management system and method for accelerating shared file checkpointing. Written application data is aggregated in an application data file created in a local burst buffer memory at a compute node, and an associated data mapping built index to maintain information related to the offsets into a shared file at which segments of the application data is to be stored in a parallel file system, and where in the buffer those segments are located. The node asynchronously transfers a data file containing the application data and the associated data mapping index to a file server for shared file storage. The data management system and method further accelerates shared file checkpointing in which a shared file, together with a map file that specifies how the shared file is to be distributed, is asynchronously transferred to local burst buffer memories at the nodes to accelerate reading of the shared file.

Gooding, Thomas↗
DOE OSTI2025

Leveraging Pre-Built Catalogs and Object-Level Scheduling to Eliminate I/O Bottlenecks in HPC Environments

Modern High-Performance Computing (HPC) environments face mounting challenges due to the shift from large to small file datasets, along with an increasing number of users and parallelized applications. As HPC systems rely on Parallel File Systems (PFS), such as Lustre for data processing, performance bottlenecks stemming from Object Storage Target (OST) contention have become a significant concern. Existing solutions, such as LADS with its object-level scheduling approach, fall short in large-scale HPC environments due to their inability to effectively address metadata I/O bottlenecks and the growing number of I/O processes. This study highlights the pressing need for a comprehensive solution that tackles both OST contention and metadata I/O challenges in diverse HPC workloads. To address these challenges, we propose SwiftLoad, an object-level I/O scheduling framework that leverages a metadata catalog to enhance the performance and efficiency of parallel HPC utilities. The adoption of the metadata catalog mitigates the metadata I/O bottlenecks that commonly occur in HPC utilities, a challenge that is particularly pronounced in object-level I/O scheduling. SwiftLoad addresses OST contention and the uneven distribution of I/O processes across different OSTs through mathematical modeling and incorporates a Loader Configuration Module to regulate the number of I/O processes. Evaluated with two representative utilities—data deduplication profiling and data augmentation—SwiftLoad achieved performance improvements of up to 5.63x and 11.0x, respectively, on a production supercomputer.

HPC↗
DOE OSTI2017

Dynamic File Striping and Data Layout Transformation on Parallel System with Fluctuating I/O Workload

As the number of compute cores on modern parallel machines increases to more than hundreds of thousands, scalable and consistent I/O performance is becoming hard to obtain due to fluctuating file system performance. This fluctuation is often caused by rebuilding RAID disk from hardware failures or concurrent jobs competing for I/O. We present a mechanism that stripes across a dynamically-selected subset of I/O servers with the lightest workload to achieve the best I/O bandwidth available from the system. We implement this mechanism into an I/O software layer that enables memory-to-file data layout transformation and allows transparent file partitioning. File partitioning is a technique that divides data among a set of files and manages file access, making data appear as a single file to users. Experimental results on NERSC’s Hopper indicate that our approach effectively isolates I/O variation on shared systems and improves overall I/O performance significantly.

Son, Seung Woo↗
DOE OSTI2015

SU-E-T-363: Error Detection Comparison of EPID and MLC Log File Based IMRT QA Systems

Purpose: In this study we will compare the ability of three QA methods (Delta4, MU-EPID, Dynalog QA) to detect specific errors. Methods: A Varian Novalis Tx with a HD120 MLC and aS1000 Electronic Portal Imaging Device (EPID) was used in our study. Multi-leaf collimator (MLC) errors, gantry angle and dose errors were introduced into 5 volumetric arc therapy (VMAT) plans. 3D dose distributions calculated with data from the EPID and Dynalog QA methods were compared with the planned dose distribution. The gamma passing percentages as well as percentage error of planning target volume (PTV) dose were used for passing determination. Baselines for gamma passing percentages and PTV dose were established by measuring the original plan 5 times consecutively. Standard passing thresholds as well as thresholds derived from receiver operator characteristic (ROC) analysis and 2 standard deviation (SD) criteria were used. Results: When applying the standard 95% pass rate at 3%/3mm gamma analysis 14, 21 and 8 of 30 errors were detected by the Delta4, MU-EPID and Dynalog QA methods respectively. Thresholds set at 2 SD from our base line measurements resulted in the detection of 18, 9 and 14 of 30 errors for the Delta4, MU-EPID and Dynalog QA methods respectively. When using D2 of the PTV as a metric the Dynalog QA detected 20 of 30 errors while the EPID method detected 14 of 30 errors. Using D98 of the PTV, Dynalog QA detected 13 of 30 while the EPID detected 3 of 30 errors. Conclusion: Although MU-EPID detected the most errors at the standard 95% cutoff it also produced the most false detections in the baseline data. The Dynalog QA was the most effective when the ROC adjusted passing threshold was used. D2 was more effective as a metric for detecting errors than D98.

60 APPLIED LIFE SCIENCES↗
DOE OSTI2018

Managing Rich Metadata in High-Performance Computing Systems Using a Graph Model

High-performance computing (HPC) systems generate huge amounts of metadata about different entities such as jobs, users, and files. Existing systems can efficiently record and manage part of these metadata, mainly the POSIX metadata of data files (e.g., file size, name, and permissions mode). But another important set of metadata, referred to as "rich" metadata in this study, which record not only wider range of entities (e.g., running processes and jobs) but also more complex relationships between them, are mostly missing in current HPC systems. Yet such rich metadata are critical for supporting many advanced data management functions such as identifying data sources and parameters behind a given result; auditing data usage; or understanding details about how inputs are transformed into outputs. To uniformly and efficiently manage the rich metadata generated in HPC systems, We propose to utilize a graph model in this study. We identify the key challenges of implementing such a graph-based HPC rich metadata management system and present GraphMeta, a graph-based rich metadata management system designed and optimized for HPC platforms, to tackle these challenges. In conclusion, extensive evaluations on both synthetic and real HPC metadata workloads show its advantages in both performance and scalability compared with existing solutions.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2016

Exe-Guard Project

The exe-Guard Project is an alliance between Dominion Virginia Power (DVP), Sandia National Laboratories (SNL), Dartmouth University, and Schweitzer Engineering Laboratories (SEL). SEL is primary recipient on this project. The exe-Guard project was selected for award under DE-FOA-0000359 with CFDA number 81.122 to address Topic Area of Interest 4: Hardened platforms and Systems. The exe-Guard project developed an antivirus solution for control system embedded devices to prevent the execution of unauthorized code and maintain settings and configuration integrity. This project created a white list antivirus solution for control systems capable of running on embedded Linux® operating systems. White list antivirus methods allow only credible programs to run through the use of digital signatures and hash functions. Once a system’s secure state is baselined, white list antivirus software denies deviations from that state because of the installation of malicious code as this changes hash results. Black list antivirus software has been effective in traditional IT environments but has negative implications for control systems. Black list antivirus uses pattern matching and behavioral analysis to identify system threats while relying on regular updates to the signature file and recurrent system scanning. Black list antivirus is vulnerable to zero day exploits which have not yet been incorporated into a signature file update. System scans hamper the performance of high availability applications, as revealed in NIST special publication 1058 which summarizes the impact of blacklist antivirus on control systems: Manual or “on-demand” scanning has a major effect on control processes in that they take CPU time needed by the control process (Sometimes close to 100% of CPU time). Minimizing the antivirus software throttle setting will reduce but not eliminate this effect. Signature updates can also take up to 100% of CPU time, but for a much shorter period than a typical manual scanning process. Control systems are vulnerable to performance losses if off-the-shelf blacklist antivirus solutions aren’t implemented with care. This investment in configuration in addition to constant decommissioning to perform manual signature file updates is unprecedented and impractical. Additionally, control systems are often disconnected or islanded from the network making the delivery of signature updates difficult. Exe-Guard project developed a white list antivirus solution that mitigated the above drawbacks and allows control systems to cost-effectively apply malware protection while maintaining high reliability. The application of security patches can also be minimized since white listing maintains constant defense against unauthorized code execution. Security patches can instead be applied in less frequent intervals where system decommissioning can be scheduled and planned for. Since control systems are less dynamic than IT environments, the feasibility of maintaining a secure baselined state is more practical. Because upgrades are performed in infrequent, calculated intervals, it allows a new security baseline to be established before the system is returned to service. Exe-Guard built on the efforts of SNL under the Code Seal project. SNL demonstrated prototype Trust Anchors on the project which are independent monitoring and control devices that can be integrated into untrustworthy components. The exe-Guard team started with the lessons learned under this project then designed commercial solution for white list malware protection. Malware is a real threat, even on islanded or un-networked installations, since operators can unintentionally install infected files, plug in infected mass storage devices, or infect a piece of equipment on the islanded local area network that can then spread to other connected equipment. Protection at the device level is one of the last layers of defense in a security-in-depth defense model before an asset becomes compromised. This project provided non-destructive intrusion, isolation and automated response solution, achieving a goal of the Department of Energy (DOE) Roadmap to Secure Control Systems. It also addressed CIP-007-R4 which requires asset owners to employ malicious software prevention tools on assets within the electronic security perimeter. In addition, the CIP-007-R3 requirement for security patch management is minimized because white listing narrows the impact of vulnerabilities and patch releases. The exe-Guard Project completed all tasks identified in the statement of project objective and identified additional tasks within scope that were performed and completed within the original budget. The cost share was met and all deliverables were successfully completed and submitted on time. Most importantly the technology developed and commercialized under this project has been adopted by the Energy sector and thousands of devices with exe-Guard technology integrated in them have now been deployed and are protecting our power systems today

24 POWER TRANSMISSION AND DISTRIBUTION↗
DOE OSTI2017

A comparison of different database technologies for the CMS AsyncStageOut transfer database

AsyncStageOut (ASO) is the component of the CMS distributed data analysis system (CRAB) that manages users transfers in a centrally controlled way using the File Transfer System (FTS3) at CERN. It addresses a major weakness of the previous, decentralized model, namely that the transfer of the user’s output data to a single remote site was part of the job execution, resulting in inefficient use of job slots and an unacceptable failure rate. Currently ASO manages up to 600k files of various sizes per day from more than 500 users per month, spread over more than 100 sites. ASO uses a NoSQL database (CouchDB) as internal bookkeeping and as way to communicate with other CRAB components. Since ASO/CRAB were put in production in 2014, the number of transfers constantly increased up to a point where the pressure to the central CouchDB instance became critical, creating new challenges for the system scalability, performance, and monitoring. This forced a re-engineering of the ASO application to increase its scalability and lowering its operational effort. In this contribution we present a comparison of the performance of the current NoSQL implementation and a new SQL implementation, and how their different strengths and features influenced the design choices and operational experience. We also discuss other architectural changes introduced in the system to handle the increasing load and latency in delivering output to the user.

71 CLASSICAL AND QUANTUM MECHANICS, GENERAL PHYSIC↗
DOE OSTI2016

Cloud object store for checkpoints of high performance computing applications using decoupling middleware

Cloud object storage is enabled for checkpoints of high performance computing applications using a middleware process. A plurality of files, such as checkpoint files, generated by a plurality of processes in a parallel computing system are stored by obtaining said plurality of files from said parallel computing system; converting said plurality of files to objects using a log structured file system middleware process; and providing said objects for storage in a cloud object storage system. The plurality of processes may run, for example, on a plurality of compute nodes. The log structured file system middleware process may be embodied, for example, as a Parallel Log-Structured File System (PLFS). The log structured file system middleware process optionally executes on a burst buffer node.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2025

WorkJournalMaker (WJMaker) v0.5

The software generates and maintains daily work journal entries in text format, via a web browser. The journal entries are saved in a structured directory file tree on the system running the software. The software also incorporates a database so that it can track the location of files in the file system and various other metadata. The software allows the users to access their journal entries either through the browser or as discrete text files, facilitating sharing and open science. Additionally, to assist with the yearly PMP process, this tool connects to LLM APIs to provide summarization of the journal entries on a month-by-month or weekly basis. The advantage over similar technologies such as Apple Notes (extremely popular for notetaking) is that the instant software does not force the user to stay inside the Apple ecosystem, since it allows for export of the user's text files. This facilitates open science, so that researchers who use the tool can easily transfer their research notes to any other system. The WebJournalMaker repository is here: https://github.com/lbnl-science-it/WorkJournalMaker The WebJournalMaker repository is forked from the JournalSummarizer: https://github.com/tyfong-lbl/JournalSummarizer and builds on its code. I wrote the code for both of these software repos, using generative AI.

Fong, Timothy [Lawrence Berkeley National Laborato↗
DOE OSTI2016

SU-F-T-172: A Method for Log File QA On An IBA Proteus System for Patient Specific Spot Scanning Quality Assurance

Purpose: The use of log files to perform patient specific quality assurance for both protons and IMRT has been established. Here, we extend that approach to a proprietary log file format and compare our results to measurements in phantom. Our goal was to generate a system that would permit gross errors to be found within 3 fractions until direct measurements. This approach could eventually replace direct measurements. Methods: Spot scanning protons pass through multi-wire ionization chambers which provide information about the charge, location, and size of each delivered spot. We have generated a program that calculates the dose in phantom from these log files and compares the measurements with the plan. The program has 3 different spot shape models: single Gaussian, double Gaussian and the ASTROID model. The program was benchmarked across different treatment sites for 23 patients and 74 fields. Results: The dose calculated from the log files were compared to those generate by the treatment planning system (Raystation). While the dual Gaussian model often gave better agreement, overall, the ASTROID model gave the most consistent results. Using a 5%–3 mm gamma with a 90% passing criteria and excluding doses below 20% of prescription all patient samples passed. However, the degree of agreement of the log file approach was slightly worse than that of the chamber array measurement approach. Operationally, this implies that if the beam passes the log file model, it should pass direct measurement. Conclusion: We have established and benchmarked a model for log file QA in an IBA proteus plus system. The choice of optimal spot model for a given class of patients may be affected by factors such as site, field size, and range shifter and will be investigated further.

60 APPLIED LIFE SCIENCES↗
DOE OSTI2016

TH-CD-207A-12: Impacts of Inter- and Intra-Fractional Organ Motion for High-Risk Prostate Cancer Stereotactic Body Radiation Therapy

Purpose: We are conducting a clinical trial on stereotactic body radiation therapy (SBRT) for high-risk prostate cancer. Doses to three targets, prostate, intra-prostatic lesion, and pelvic lymph node (PLN) region, are escalated to three different levels via simultaneous integrated boost technique. Inter-/intra-fractional organ motions deteriorate planned dose distribution. This study aims at developing a dose reconstruction system to comprehensively understand the impacts of organ motion in our clinical trial. Methods: A 4D dose reconstruction system has been developed for this study. Using a GPU-based Monte-Carlo dose engine and delivery log file, the system is able to reconstruct dose on static or dynamic anatomy. For prostate and intra-prostatic targets, intra-fractional motion is the main concern. Motion trajectory acquired from Calypso in previously treated SBRT patients were used to perform 4D dose reconstructions. For pelvic target, inter-fractional motion is one concern. Eight patients, each with four cone beam CTs, were used to derive fractional motion. The delivered dose was reconstructed on the deformed anatomy. Dosimetric parameters for delivered dose distributions of the three targets were extracted and compared with planned levels. Results: For prostate intra-fractional motion, the mean 3D motion amplitude during beam delivery ranged from 1.5mm to 5.0mm and the average among all patients was 2.61mm. Inter-fractional motion for the PLN target was more significant. The average amplitude among patients was 4mm with the largest amplitude up to 9.6mm. The D95% deviation from planned level for prostate PTVs and GTVs are on average less than<0.1% and this deviation for intra-prostatic lesion PTVs and GTVs were more prominent. The dose at PLN was significantly affected with D{sub 95}% reduced by up to 44%. Conclusion: Intra-/inter-fractional organ motion is a concern for high-risk prostate SBRT, particularly for the PLN target. Our dose reconstruction approach can also serve as the basis to guide treatment adaptation.

60 APPLIED LIFE SCIENCES↗
DOE OSTI2024

NbZr_BCC_SolidSolution_128atoms_VASP6

We performed density functional theory (DFT) calculations for body-centered-cubic (BCC) structures with 128 lattices sites of solid solution binary alloys niobium-zirconium (Nb-Zr). The electronic structures of alloys have been calculated using Vienna Ab initio Simulation Package (VASP). Within this package the DFT approach is used to reduce many-body Schrodinger equation to set of single particle Kohn-Sham (KS) equations. The generalized electronic exchange-correlation functional is described by generalized gradient approximation with the Perdew-Burke-Ernzerhof parametrization. The electron-ion interactions is described by pseudopotentials developed within the plane-wave basis projector augmented-wave (PAW) approach \cite{PAW}. These pseudopotentials are available at the VASP portal (http://cms.mpi.univie.ac.at/vasp/). Our calculations have been run with the pseudopotentials treating s and p semi-core states as valence in case for the elements Nb and Zr. The electronic densities and potentials are expanded over plane-waves with energy cutoff of 350 eV. 2x2x2 k-mesh and normal precision were used. The alloys were modeled by supercell containing 128 randomly distributed atoms. At initial step the atoms occupy perfect bcc lattice cites. This initial structure was optimized until energy changes less than 1e-6 eV, while forces acting on atoms don't exceed 1e-2 eV/angstrom. The electron-ion interaction is described by PAW pseudopotentials. The calculations have been collected by sampling chemical compositions across the entire compositional range. The chemical compositions have been sampled by progressively changing the number of atoms per constituent by 4. For each chemical composition of binaries and ternaries, the first-principle calculations have been run for 100 randomized arrangements of the constituents on the BCC lattice sites. We collected data for a total of 3,100 randomized atomic structures over 31 chemical compositions. The calculations have been collected on NERSC-Perlmutter and OLCF-Summit using the VASP 6.3.2. The VASP calculations for every atomic structure have been performed in 2 main steps: 1. Starting from an ideal body-centered-cubic (BCC) structure, geometry optimization with low precision has been executed to perform a preliminary optimization of the atomic structure. The output for this calculations is available in the files 0.CONTCAR, 0.OUTCAR, rlx1.out. 2. Using the atomic structure resulting from the preliminary geometry optimization, a second geometry optimization has been performed using normal precision. The output for this calculations is available in the files CONTCAR, OUTCAR, rlx2.out, vaspout.h5, and vasprun.xml. Cases 1-10 have been run without generating the file 'vaspout.h5'. Every chemical composition sampled across the composition range in the dataset has its own directory. The convention used to name the directories for binary alloys is AXBY, where A and B refer to the constituents, whereas X and Y are positive integers that represent the number of atoms for each constituent and their values still sum up to 128. Each atomic structure associated with a specific chemical composition has its own sub-directory within the directory of the corresponding chemical composition. The sub-directories for each atomic structure for each chemical composition are named 'case-*', where * is a positive integer that spans all the values from 1 through 100, extremes included. The files contained in each sub-directory 'case-*' for each atomic structure are as follows: FILES contained in each subdirectory with name "case-N" where N ranges between 11 and 100, extremes included: 1. INCAR: input file that contains various parameters and settings for controlling the behavior of the electronic structure calculations 2. KPOINTS: input file that specifies the Bloch vectors (k points) used to sample the Brillouin zone 3. 0.POSCAR: input file that defines the atomic structure of a system 4. 0.CONTCAR: output file that provides the atomic positions and cell parameters after the first geometry optimization has been run with the precision variable set to PREC=Low in the INCAR file 5. 0.OUTCAR: output file that contains detailed information about the progress of a calculation after the first geometry optimization has been run with the precision variable set to PREC=Low in the INCAR file 6. rlx1.out: file with diagnostic information about the execution of the first geometry optimization with precision variable set to PREC=Low in the INCAR file 7. POSCAR: input file that defines the atomic structure of a system after the first geometry optimization has been run at low precision. This represents the input for the second geometry optimization run with the precision variable set to PREC=Normal in the INCAR file 8. CONTCAR: output file that provides the atomic positions and cell parameters after the second geometry optimization has been run with the precision variable set to PREC=Normal in the INCAR file 9. OUTCAR: output file that contains detailed information about the progress of a calculation after the second geometry optimization has been run with the precision variable set to PREC=Normal in the INCAR file 10. rlx2.out: file with diagnostic information about the execution of the second geometry optimization with precision variable set to PREC=Normal in the INCAR file 11. vaspout.h5: hierarchical HDF5 file containing the inputs and outputs of a VASP calculation. To analyze the data in this file we recommend using py4vasp. This file is only produced if the VASP version used is compiled with HDF5 support 12. vasprun.xml: contains similar information to OUTCAR, but in an xml format. 13. CHGCAR: contains the charge density data of a system. This data is crucial for analyzing electronic structures, calculating electrostatic potential, and studying the distribution of charge in a crystal or molecular system FILES contained in each subdirectory with name "case-N" where N ranges between 1 and 10, extremes included: 1. INCAR: input file that contains various parameters and settings for controlling the behavior of the electronic structure calculations 2. KPOINTS: input file that specifies the Bloch vectors (k points) used to sample the Brillouin zone 3. {ID}.POSCAR: input file that defines the atomic structure of a system at the beginning of ID execution of geometry optimization with PREC=LOW 4. {ID}.CONTCAR: output file that provides the atomic positions and cell parameters at the end of ID execution of geometry optimization with PREC=LOW in the INCAR file 5. {ID}.OUTCAR: output file that contains detailed information about the progress of a calculation after the ID execution of geometry optimization that has been run with the precision variable set to PREC=Low in the INCAR file 6. rlx1.{ID}.out: file with diagnostic information about the execution of the ID execution of the geometry optimization with precision variable set to PREC=Low in the INCAR file 7. N{ID}.POSCAR: input file that defines the atomic structure of a system after the geometry optimization run at low precision. This represents the input for the ID execution of the second geometry optimization run with the precision variable set to PREC=Normal in the INCAR file 8. N{ID}.CONTCAR: output file that provides the atomic positions and cell parameters after the ID execution of the geometry optimization run with the precision variable set to PREC=Normal in the INCAR file 9. N{ID}.OUTCAR: output file that contains detailed information about the progress of a calculation after the ID execution of the geometry optimization run with the precision variable set to PREC=Normal in the INCAR file 10. rlx2.{ID}.out: file with diagnostic information about the ID execution of geometry optimization with precision variable set to PREC=Normal in the INCAR file 11. vaspout.h5: hierarchical HDF5 file containing the inputs and outputs of a VASP calculation. To analyze the data in this file we recommend using py4vasp. This file is only produced if the VASP version used is compiled with HDF5 support 12. vasprun.xml: contains similar information to OUTCAR, but in an xml format. 13. CHGCAR: contains the charge density data of a system. This data is crucial for analyzing electronic structures, calculating electrostatic potential, and studying the distribution of charge in a crystal or molecular system This research is sponsored by the Artificial Intelligence Initiative as part of the Laboratory Directed Research and Development (LDRD) Program of Oak Ridge National Laboratory, managed by UT-Battelle, LLC, for the US Department of Energy under contract DE-AC05-00OR22725. This work used resources of the Oak Ridge Leadership Computing Facility, which is supported by the Office of Science of the U.S. Department of Energy under Contract No. DE-AC05-00OR22725, under Directorate Discretionary awards MAT025 (Materials Science) and LRN026 (Machine Learning), and INCITE award MAT201. This work also used resources of the National Energy Research Scientific Computing Center, which is supported by the Office of Science of the U.S. Department of Energy under Contract No. DE-AC02-05CH11231, under award ERCAP0025216. REFERENCES (1) Kresse, G. & Hafner, J. Ab initio molecular dynamics for liquid metals. Phys. review B 47, 558 (1993). (2) Kresse, G. & Hafner, J. Ab initio molecular-dynamics simulation of the liquid-metal–amorphous-semiconductor transition in germanium. Phys. Rev. B 49, 14251 (1994) (3) Kresse, G. & Furthmüller, J. Efficiency of ab-initio total energy calculations for metals and semiconductors using a plane-wave basis set. Comput. materials science 6, 15–50 (1996) (4) Kresse, G. & Furthmüller, J. Efficient iterative schemes for ab initio total-energy calculations using a plane-wave basis set. Phys. review B 54, 11169 (1996) (5) Kresse, G. & Joubert, D. From ultrasoft pseudopotentials to the projector augmented-wave method. Phys. review b 59, 1758 (1999)

36 MATERIALS SCIENCE↗
DOE OSTI2024

TaZr_BCC_SolidSolution_128atoms_VASP6

We performed density functional theory (DFT) calculations for body-centered-cubic (BCC) structures with 128 lattices sites of solid solution binary alloys tantalum-zirconium (Ta-Zr). The electronic structures of alloys have been calculated using Vienna Ab initio Simulation Package (VASP). Within this package the DFT approach is used to reduce many-body Schrodinger equation to set of single particle Kohn-Sham (KS) equations. The generalized electronic exchange-correlation functional is described by generalized gradient approximation with the Perdew-Burke-Ernzerhof parametrization. The electron-ion interactions is described by pseudopotentials developed within the plane-wave basis projector augmented-wave (PAW) approach \cite{PAW}. These pseudopotentials are available at the VASP portal (http://cms.mpi.univie.ac.at/vasp/). Our calculations have been run with the pseudopotentials treating s and p semi-core states as valence in case for the elements Ta and Zr. The electronic densities and potentials are expanded over plane-waves with energy cutoff of 350 eV. 2x2x2 k-mesh and normal precision were used. The alloys were modeled by supercell containing 128 randomly distributed atoms. At initial step the atoms occupy perfect bcc lattice cites. This initial structure was optimized until energy changes less than 1e-6 eV, while forces acting on atoms don't exceed 1e-2 eV/angstrom. The electron-ion interaction is described by PAW pseudopotentials. The calculations have been collected by sampling chemical compositions across the entire compositional range. The chemical compositions have been sampled by progressively changing the number of atoms per constituent by 4. For each chemical composition of binaries and ternaries, the first-principle calculations have been run for 100 randomized arrangements of the constituents on the BCC lattice sites. We collected data for a total of 3,100 randomized atomic structures over 31 chemical compositions. The calculations have been collected on NERSC-Perlmutter and OLCF-Summit using the VASP 6.3.2. The VASP calculations for every atomic structure have been performed in 2 main steps: 1. Starting from an ideal body-centered-cubic (BCC) structure, geometry optimization with low precision has been executed to perform a preliminary optimization of the atomic structure. The output for this calculations is available in the files 0.CONTCAR, 0.OUTCAR, rlx1.out. 2. Using the atomic structure resulting from the preliminary geometry optimization, a second geometry optimization has been performed using normal precision. The output for this calculations is available in the files CONTCAR, OUTCAR, rlx2.out, vaspout.h5, and vasprun.xml. Cases 1-10 have been run without generating the file 'vaspout.h5'. Every chemical composition sampled across the composition range in the dataset has its own directory. The convention used to name the directories for binary alloys is AXBY, where A and B refer to the constituents, whereas X and Y are positive integers that represent the number of atoms for each constituent and their values still sum up to 128. Each atomic structure associated with a specific chemical composition has its own sub-directory within the directory of the corresponding chemical composition. The sub-directories for each atomic structure for each chemical composition are named 'case-*', where * is a positive integer that spans all the values from 1 through 100, extremes included. The files contained in each sub-directory 'case-*' for each atomic structure are as follows: FILES contained in each subdirectory with name "case-N" where N ranges between 11 and 80, extremes included: 1. INCAR: input file that contains various parameters and settings for controlling the behavior of the electronic structure calculations 2. KPOINTS: input file that specifies the Bloch vectors (k points) used to sample the Brillouin zone 3. 0.POSCAR: input file that defines the atomic structure of a system 4. 0.CONTCAR: output file that provides the atomic positions and cell parameters after the first geometry optimization has been run with the precision variable set to PREC=Low in the INCAR file 5. 0.OUTCAR: output file that contains detailed information about the progress of a calculation after the first geometry optimization has been run with the precision variable set to PREC=Low in the INCAR file 6. rlx1.out: file with diagnostic information about the execution of the first geometry optimization with precision variable set to PREC=Low in the INCAR file 7. POSCAR: input file that defines the atomic structure of a system after the first geometry optimization has been run at low precision. This represents the input for the second geometry optimization run with the precision variable set to PREC=Normal in the INCAR file 8. CONTCAR: output file that provides the atomic positions and cell parameters after the second geometry optimization has been run with the precision variable set to PREC=Normal in the INCAR file 9. OUTCAR: output file that contains detailed information about the progress of a calculation after the second geometry optimization has been run with the precision variable set to PREC=Normal in the INCAR file 10. rlx2.out: file with diagnostic information about the execution of the second geometry optimization with precision variable set to PREC=Normal in the INCAR file 11. vaspout.h5: hierarchical HDF5 file containing the inputs and outputs of a VASP calculation. To analyze the data in this file we recommend using py4vasp. This file is only produced if the VASP version used is compiled with HDF5 support 12. vasprun.xml: contains similar information to OUTCAR, but in an xml format. 13. CHGCAR: contains the charge density data of a system. This data is crucial for analyzing electronic structures, calculating electrostatic potential, and studying the distribution of charge in a crystal or molecular system FILES contained in each subdirectory with name "case-N" where N ranges between 1 and 10 and between 81 and 100, extremes included: 1. INCAR: input file that contains various parameters and settings for controlling the behavior of the electronic structure calculations 2. KPOINTS: input file that specifies the Bloch vectors (k points) used to sample the Brillouin zone 3. {ID}.POSCAR: input file that defines the atomic structure of a system at the beginning of ID execution of geometry optimization with PREC=LOW 4. {ID}.CONTCAR: output file that provides the atomic positions and cell parameters at the end of ID execution of geometry optimization with PREC=LOW in the INCAR file 5. {ID}.OUTCAR: output file that contains detailed information about the progress of a calculation after the ID execution of geometry optimization that has been run with the precision variable set to PREC=Low in the INCAR file 6. rlx1.{ID}.out: file with diagnostic information about the execution of the ID execution of the geometry optimization with precision variable set to PREC=Low in the INCAR file 7. N{ID}.POSCAR: input file that defines the atomic structure of a system after the geometry optimization run at low precision. This represents the input for the ID execution of the second geometry optimization run with the precision variable set to PREC=Normal in the INCAR file 8. N{ID}.CONTCAR: output file that provides the atomic positions and cell parameters after the ID execution of the geometry optimization run with the precision variable set to PREC=Normal in the INCAR file 9. N{ID}.OUTCAR: output file that contains detailed information about the progress of a calculation after the ID execution of the geometry optimization run with the precision variable set to PREC=Normal in the INCAR file 10. rlx2.{ID}.out: file with diagnostic information about the ID execution of geometry optimization with precision variable set to PREC=Normal in the INCAR file 11. vaspout.h5: hierarchical HDF5 file containing the inputs and outputs of a VASP calculation. To analyze the data in this file we recommend using py4vasp. This file is only produced if the VASP version used is compiled with HDF5 support 12. vasprun.xml: contains similar information to OUTCAR, but in an xml format. 13. CHGCAR: contains the charge density data of a system. This data is crucial for analyzing electronic structures, calculating electrostatic potential, and studying the distribution of charge in a crystal or molecular system This research is sponsored by the Artificial Intelligence Initiative as part of the Laboratory Directed Research and Development (LDRD) Program of Oak Ridge National Laboratory, managed by UT-Battelle, LLC, for the US Department of Energy under contract DE-AC05-00OR22725. This work used resources of the Oak Ridge Leadership Computing Facility, which is supported by the Office of Science of the U.S. Department of Energy under Contract No. DE-AC05-00OR22725, under Directorate Discretionary awards MAT025 (Materials Science) and LRN026 (Machine Learning), and INCITE award MAT201. This work also used resources of the National Energy Research Scientific Computing Center, which is supported by the Office of Science of the U.S. Department of Energy under Contract No. DE-AC02-05CH11231, under award ERCAP0025216. REFERENCES (1) Kresse, G. & Hafner, J. Ab initio molecular dynamics for liquid metals. Phys. review B 47, 558 (1993). (2) Kresse, G. & Hafner, J. Ab initio molecular-dynamics simulation of the liquid-metal–amorphous-semiconductor transition in germanium. Phys. Rev. B 49, 14251 (1994) (3) Kresse, G. & Furthmüller, J. Efficiency of ab-initio total energy calculations for metals and semiconductors using a plane-wave basis set. Comput. materials science 6, 15–50 (1996) (4) Kresse, G. & Furthmüller, J. Efficient iterative schemes for ab initio total-energy calculations using a plane-wave basis set. Phys. review B 54, 11169 (1996) (5) Kresse, G. & Joubert, D. From ultrasoft pseudopotentials to the projector augmented-wave method. Phys. review b 59, 1758 (1999)

36 MATERIALS SCIENCE↗
DOE OSTI2021

Malware analysis and recovery

A system and method detects malware by processing notifications from an intrusion detection system and baseline snapshots from an image capture utility. The image capture utility constructs an image of the suspected malware intrusion and links the suspected malware intrusion to the baseline snapshots. The system and method propagates the image of the suspected malware intrusion across multiple networks before it distinguishes malicious code, device state, and files from benign code, device state, and files. Some systems and methods include a malware recovery system that executes machine learning instructions and heuristics to revert a client and/or a remote server to one or more baseline snapshots.

Smith, Jared M.↗
DOE OSTI2023

Isolated data processing modules

This disclosure relates to computer systems that isolate data processing modules and methods of operating the same. In one embodiment of a method, a computer system receives a first data processing request for a first data file. The computer system may determine that a first data type of the first data file is supported by an encapsulated data processing module and determine a first communication protocol from a set of communication protocols that can be used to receive the first data file. The computer system can then receive the first data file from the first storage location in accordance with the first communication protocol and the encapsulated data processing module may be executed to convert the first data file in the first data format into second data in a second data format.

Penton, Joshua Michael↗
DOE OSTI2015

Cloud object store for archive storage of high performance computing data using decoupling middleware

Cloud object storage is enabled for archived data, such as checkpoints and results, of high performance computing applications using a middleware process. A plurality of archived files, such as checkpoint files and results, generated by a plurality of processes in a parallel computing system are stored by obtaining the plurality of archived files from the parallel computing system; converting the plurality of archived files to objects using a log structured file system middleware process; and providing the objects for storage in a cloud object storage system. The plurality of processes may run, for example, on a plurality of compute nodes. The log structured file system middleware process may be embodied, for example, as a Parallel Log-Structured File System (PLFS). The log structured file system middleware process optionally executes on a burst buffer node.

97 MATHEMATICS AND COMPUTING↗