https://robertcarson.org/tags/nonlinear-solvers/Recent content in Nonlinear-Solvers on Robert CarsonHugo -- gohugo.ioen© 2026 Robert CarsonTue, 15 Apr 2025 00:00:00 +0000https://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/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>