arXiv subjects

Neil Mitchell

Publications and source records attributed to Neil Mitchell.

6 recordsLinked to original sources

arXiv2026

Large Magnet Structures for Fusion Technology: Lessons from ITER

Over a period of 40 years, the ITER project has provided many examples in large magnet structures, from pre-concept to design to manufacture to delivery and assembly, from which lessons can be learned for the future. This presentation is divided into three parts. The first, 'Making and Assembling Large (steel) Cryogenic Structures for Magnets' is based on ITER Coil Structure experience, particularly the Central Solenoid (CS) and Toroidal Field (TF) structures and particularly on large 316LN forgings weighing about 50t individually, requiring then high accuracy machining and deep (up to 0.3m) welds with controlled distortion. New materials development is often proposed. This is easy on a laboratory scale, but often not transferable to an industrial large scale. Examples are provided. The issues to be considered (and solved) are large scale quality (and repair of defects), joining, tolerances and assembly. The second 'Designing Large Steel Support Structures for Magnets' is concerned with structural design codes & criteria, and modern analysis, especially of imperfect, but manufacturable structures. Points that are considered are typical critical issues with cyclically loaded thick components, analysis of partial penetration welds and other welds not permitted under normal American Society of Mechanical Engineers (ASME) welding procedures (including fillet welds and/or those volumetrically not inspectable by Non-Destructive Examinations (NDE)) and allowing for tolerance compensation (i.e. designing with overmetal or designing for shimming). The third 'Avoiding or Reducing Large Steel Support Structures for Magnets' shows how it is possible to choose other routes to include structural materials in magnets, for example (as in ITER TF coils) by using plates to contain the conductor, or by using a thick conductor jacket to at least share the loads with massive steel cases.

physics.acc-ph↗

arXiv2025

Code Improvement Practices at Meta

The focus on rapid software delivery inevitably results in the accumulation of technical debt, which, in turn, affects quality and slows future development. Yet, companies with a long history of rapid delivery exist. Our primary aim is to discover how such companies manage to keep their codebases maintainable. Method: we investigate Meta's practices by collaborating with engineers on code quality and by analyzing rich source code change history to reveal a range of practices used for continual improvement of the codebase. In addition, we replicate several aspects of previous industry cases studies investigating the impact of code reengineering. Results: Code improvements at Meta range from completely organic grass-roots done at the initiative of individual engineers, to regularly blocked time and engagement via gamification of Better Engineering (BE) work, to major explicit initiatives aimed at reengineering the complex parts of the codebase or deleting accumulations of dead code. Over 14% of changes are explicitly devoted to code improvement and the developers are given ``badges'' to acknowledge the type of work and the amount of effort. Our investigation to prioritize which parts of the codebase to improve lead to the development of metrics to guide this decision making. Our analysis of the impact of reengineering activities revealed substantial improvements in quality and speed as well as a reduction in code complexity. Overall, such continual improvement is an effective way to develop software with rapid releases, while maintaining high quality.

cs.SE↗

arXiv2023

Daml: A Smart Contract Language for Securely Automating Real-World Multi-Party Business Workflows

Distributed ledger technologies, also known as blockchains for enterprises, promise to significantly reduce the high cost of automating multi-party business workflows. We argue that a programming language for writing such on-ledger logic should satisfy three desiderata: (1) Provide concepts to capture the legal rules that govern real-world business workflows. (2) Include simple means for specifying policies for access and authorization. (3) Support the composition of simple workflows into complex ones, even when the simple workflows have already been deployed. We present the open-source smart contract language Daml based on Haskell with strict evaluation. Daml achieves these desiderata by offering novel primitives for representing, accessing, and modifying data on the ledger, which are mimicking the primitives of today's legal systems. Robust access and authorization policies are specified as part of these primitives, and Daml's built-in authorization rules enable delegation, which is key for workflow composability. These properties make Daml well-suited for orchestrating business workflows across multiple, otherwise heterogeneous parties. Daml contracts run (1) on centralized ledgers backed by a database, (2) on distributed deployments with Byzantine fault tolerant consensus, and (3) on top of conventional blockchains, as a second layer via an atomic commit protocol.

cs.PL↗

arXiv2022

Forward Build Systems, Formally

Build systems are a fundamental part of software construction, but their correctness has received comparatively little attention, relative to more prominent parts of the toolchain. In this paper, we address the correctness of \emph{forward build systems}, which automatically determine the dependency structure of the build, rather than having it specified by the programmer. We first define what it means for a forward build system to be correct -- it must behave identically to simply executing the programmer-specified commands in order. Of course, realistic build systems avoid repeated work, stop early when possible, and run commands in parallel, and we prove that these optimizations, as embodied in the recent forward build system \textsc{Rattle}, preserve our definition of correctness. Along the way, we show that other forward build systems, such as \textsc{Fabricate} and \textsc{Memoize}, are also correct. We carry out all of our work in \Agda, and describe in detail the assumptions underlying both \textsc{Rattle} itself and our modeling of it.

cs.PL↗

arXiv2020

Build Scripts with Perfect Dependencies

Build scripts for most build systems describe the actions to run, and the dependencies between those actions---but often build scripts get those dependencies wrong. Most build scripts have both too few dependencies (leading to incorrect build outputs) and too many dependencies (leading to excessive rebuilds and reduced parallelism). Any programmer who has wondered why a small change led to excess compilation, or who resorted to a "clean" step, has suffered the ill effects of incorrect dependency specification. We outline a build system where dependencies are not specified, but instead captured by tracing execution. The consequence is that dependencies are always correct by construction and build scripts are easier to write. The simplest implementation of our approach would lose parallelism, but we are able to recover parallelism using speculation.

cs.PL↗

arXiv2013

Certified HLints with Isabelle/HOLCF-Prelude

We present the HOLCF-Prelude, a formalization of a large part of Haskell's standard prelude in Isabelle/HOLCF. Applying this formalization to the hints suggested by HLint allows us to certify them formally.

cs.LO↗