https://robertcarson.org/Recent content on Robert CarsonHugo -- gohugo.ioen© 2026 Robert CarsonSat, 25 Apr 2026 00:00:00 +0000https://robertcarson.org/about/Sat, 25 Apr 2026 00:00:00 +0000https://robertcarson.org/about/<p>Over the course of my career I have found myself following a consistent thread: building tools rigorous enough to actually predict how real materials behave, fast enough to be useful at scale, and open enough that others can build on them. That thread started in an undergraduate biomechanics lab, ran through a PhD developing new computational and experimental methods for characterizing how deformation evolves within crystal grains under cyclic loading, and has continued at Lawrence Livermore National Laboratory where I lead development of GPU-accelerated crystal plasticity software and drive material qualification efforts at exascale. Outside of work I take real pleasure in spending time with my family and pets, hiking, and shooting landscape photography.</p>https://robertcarson.org/papers/additive-manufacturing/Tue, 15 Apr 2025 00:00:00 +0000https://robertcarson.org/papers/additive-manufacturing/<h2 class="relative group">Overview <div id="overview" class="anchor"></div> <span class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none"> <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#overview" aria-label="Anchor">#</a> </span> </h2> <p>Metal additive manufacturing, particularly laser powder bed fusion (LPBF), creates a scientific challenge that most manufacturing processes do not: the mechanical properties of the resulting part depend on a cascade of physical processes spanning many orders of magnitude in scale, from the nanosecond laser-material interaction at the melt pool surface, through the solidification dynamics that determine grain nucleation and growth, to the part-scale stress distributions that determine structural performance. The microstructure and therefore the properties vary spatially as a function of local thermal history, which itself depends on laser parameters, scan strategy, part geometry, and proximity to other features.</p>https://robertcarson.org/papers/bcc-crystal-plasticity/Tue, 15 Apr 2025 00:00:00 +0000https://robertcarson.org/papers/bcc-crystal-plasticity/<h2 class="relative group">Overview <div id="overview" class="anchor"></div> <span class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none"> <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#overview" aria-label="Anchor">#</a> </span> </h2> <p>Body-centered cubic (BCC) metals are among the most mechanically interesting crystalline solids to model. Unlike FCC metals, where slip occurs on well-defined {111}⟨110⟩ systems and the dislocation physics is relatively well understood, BCC plasticity is governed by thermally activated screw dislocation motion with non-planar core structures. This produces strong temperature and strain-rate sensitivity, and a persistent debate about which slip planes are actually active under different loading conditions.</p>https://robertcarson.org/projects/rust_projects/Tue, 15 Apr 2025 00:00:00 +0000https://robertcarson.org/projects/rust_projects/<h2 class="relative group">Why Rust <div id="why-rust" class="anchor"></div> <span class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none"> <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#why-rust" aria-label="Anchor">#</a> </span> </h2> <p>Before any specific library, some context on the language. The motivation was not ideological. It was practical and rooted in a specific kind of pain: Fortran code that compiles and runs without complaint, but quietly passes array shapes that do not match what the calling code believes they are. No runtime check, no compiler error, just wrong numbers. That class of silent bug had bitten me enough times that when a new language showed up that made memory safety a first-class guarantee enforced at compile time, it was worth learning seriously. Rust became the language I reached for when exploring new ideas or building tools where correctness under the surface mattered as much as correctness of output. Over time it also became a practical choice for building fast Python libraries through PyO3 bindings, since you get native execution speed with an interface that scientific users can drive from notebooks and scripts without knowing anything about Rust.</p>https://robertcarson.org/projects/exacmech/Tue, 15 Apr 2025 00:00:00 +0000https://robertcarson.org/projects/exacmech/<h2 class="relative group">The Problem ExaCMech Solves <div id="the-problem-exacmech-solves" class="anchor"></div> <span class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none"> <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#the-problem-exacmech-solves" aria-label="Anchor">#</a> </span> </h2> <p>Crystal plasticity finite element codes spend a large fraction of their time doing one thing: the constitutive update. Given a material&rsquo;s current state (its crystal orientation, internal hardening variables, elastic strain) and a prescribed deformation over a time step, compute the resulting stress and update the material state. This has to be done at every quadrature point in the mesh, which in a production micromechanics simulation means evaluating physically complex, iterative nonlinear equations simultaneously at tens of millions of points. For the problem to be tractable at scale, those evaluations need to run on the GPU, and the models need to be structured in a way that maps naturally to how GPUs actually execute work.</p>https://robertcarson.org/projects/exaconstit/Tue, 15 Apr 2025 00:00:00 +0000https://robertcarson.org/projects/exaconstit/<h2 class="relative group">Where ExaConstit Came From <div id="where-exaconstit-came-from" class="anchor"></div> <span class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none"> <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#where-exaconstit-came-from" aria-label="Anchor">#</a> </span> </h2> <p>When I joined the ExaAM project at LLNL, the project needed a crystal plasticity finite element code that could run on GPUs at scale. ExaAM is a DOE Exascale Computing Project effort to model metal additive manufacturing from the melt pool all the way up to the part scale, and the part that connects microstructure to part-scale mechanical response requires simulating thousands of individual grains with their own crystal orientations, phases, and slip systems. At the time, no open-source code existed that could do this on GPUs in a serious way. Most comparable codes either had no GPU support or treated it as an experimental add-on that barely worked. So we built ExaConstit from scratch with GPU execution as a first-class target from day one.</p>https://robertcarson.org/papers/hpc-gpu-computing/Tue, 15 Apr 2025 00:00:00 +0000https://robertcarson.org/papers/hpc-gpu-computing/<h2 class="relative group">Overview <div id="overview" class="anchor"></div> <span class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none"> <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#overview" aria-label="Anchor">#</a> </span> </h2> <p>For roughly forty years, scientific codes got faster by waiting for the next hardware generation. That era ended. Peak floating-point throughput stopped scaling the way it used to, and the compute density now available in leadership-class machines comes almost entirely from GPU accelerators — thousands of streaming multiprocessors per node, operating under a fundamentally different programming model than the CPU clusters that most production scientific software was written for.</p>https://robertcarson.org/papers/intragranular-deformation/Tue, 15 Apr 2025 00:00:00 +0000https://robertcarson.org/papers/intragranular-deformation/<h2 class="relative group">Overview <div id="overview" class="anchor"></div> <span class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none"> <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#overview" aria-label="Anchor">#</a> </span> </h2> <p>Fatigue is one of the grand challenges in engineering. The first published study appeared in 1837 on mining conveyor chains that failed in service. By the end of the 20th century, over 100,000 papers had been written on the subject, and the problem is still not solved. The reason is that fatigue failure depends on a wide range of interacting factors: residual stress, thermal processing, surface condition, environment, and most fundamentally, the microstructure of the material itself. The Aloha Airlines Flight 243 accident, where fatigue cracks in fuselage lap joints caused a section of the cabin roof to separate in flight, is one example among many that drove enormous investment in understanding how cracks initiate and grow under cyclic loading.</p>https://robertcarson.org/projects/snls/Tue, 15 Apr 2025 00:00:00 +0000https://robertcarson.org/projects/snls/<h2 class="relative group">Where It Started <div id="where-it-started" class="anchor"></div> <span class="absolute top-0 w-6 transition-opacity opacity-0 -start-6 not-prose group-hover:opacity-100 select-none"> <a class="text-primary-300 dark:text-neutral-700 !no-underline" href="#where-it-started" aria-label="Anchor">#</a> </span> </h2> <p>SNLS predates both ExaCMech and ExaConstit. It was developed at LLNL specifically to solve the problem of running material model constitutive updates on the GPU, at a time when no existing nonlinear solver library was designed to do that. General-purpose solvers like MINPACK or PETSc are built for problems that live on the host. They carry significant overhead per call and are not structured for batched execution across millions of independent points simultaneously. In crystal plasticity specifically, every quadrature point in the mesh needs its own nonlinear solve to update stress and internal state at each time step, and those systems are dense, stiff, and need to run as fast as possible without any per-point failure being an option. That was the gap SNLS was built to fill.</p>