<?xml version="1.0" encoding="UTF-8"?>
<rss  xmlns:atom="http://www.w3.org/2005/Atom" 
      xmlns:media="http://search.yahoo.com/mrss/" 
      xmlns:content="http://purl.org/rss/1.0/modules/content/" 
      xmlns:dc="http://purl.org/dc/elements/1.1/" 
      version="2.0">
<channel>
<title>Zachary Varley</title>
<link>https://zacharyvarley.github.io/research.html</link>
<atom:link href="https://zacharyvarley.github.io/research.xml" rel="self" type="application/rss+xml"/>
<description></description>
<generator>quarto-1.9.37</generator>
<lastBuildDate>Tue, 05 May 2026 00:00:00 GMT</lastBuildDate>
<item>
  <title>A Browser-Native Reformulation of Dynamical EBSD Simulation</title>
  <link>https://zacharyvarley.github.io/posts/browser-ebsd-simulator/</link>
  <description><![CDATA[ 




<section id="a-browser-native-reformulation-of-dynamical-ebsd" class="level1">
<h1>A browser-native reformulation of dynamical EBSD</h1>
<p><a href="../../ebsdsim.html"><strong>Launch the simulator →</strong></a></p>
<p>For dynamical EBSD simulation, the usual path has been local native software (for example EMsoftOO workflows) or vendor-provided machines. This project takes a different route: a browser-native implementation of the low-rank Lyapunov reformulation from my manuscript, designed to make large master-pattern calculations practical without a desktop install.</p>
<section id="what-is-new-here" class="level2">
<h2 class="anchored" data-anchor-id="what-is-new-here">What is new here</h2>
<p>The core numerical change is in depth integration. Instead of solving a dense Bloch-wave eigendecomposition (the classical ZGEEV-style path) for each direction and energy, the same dynamical quantity is computed through a Lyapunov equation with a rank-one right-hand side from single-channel incidence.</p>
<p>To my knowledge, this is the first application of that Lyapunov reformulation strategy to electron diffraction simulation.</p>
</section>
<section id="why-gpu-is-required-here" class="level2">
<h2 class="anchored" data-anchor-id="why-gpu-is-required-here">Why GPU is required here</h2>
<p>This implementation is intentionally WebGPU-only. There is no CPU-mode fallback in the app.</p>
<p>The purpose of GPU acceleration is not UI polish; it is computational tractability. Reformulating the solver turns repeated eigendecomposition work into a pattern that maps well to GPU batching:</p>
<ul>
<li>Instead of repeated eigendecompositions, each direction uses one LU factorization and then repeated triangular solves (Smith / single-shift ADI form).</li>
<li>Those solve steps are straightforward to execute in large batches.</li>
<li>The total runtime is governed by low-rank convergence behavior rather than full dense eigenvector machinery.</li>
</ul>
<p>In short, the reformulation and the GPU execution model are tightly coupled.</p>
</section>
<section id="what-the-web-app-exposes" class="level2">
<h2 class="anchored" data-anchor-id="what-the-web-app-exposes">What the web app exposes</h2>
<ul>
<li>CIF parsing with editable site-level thermal terms.</li>
<li>Beam and truncation controls (voltage, sigma, dmin, Lambert half-width, Bethe thresholds, chunk size, and energy-bin width).</li>
<li>Symmetry-aware north/south hemisphere viewing.</li>
<li>NPZ export of integrated outputs (with optional extra saved arrays).</li>
</ul>
<p>The compute path, CIF handling, and NPZ packaging all run locally in the browser session.</p>
</section>
<section id="current-limitations-and-next-steps" class="level2">
<h2 class="anchored" data-anchor-id="current-limitations-and-next-steps">Current limitations and next steps</h2>
<p>This is an active research implementation. Two caveats matter right now:</p>
<ul>
<li>More benchmarking is still needed for both speed and numerical accuracy across materials and parameter ranges.</li>
<li>The surrogate ML model used to replace Monte Carlo depth profiling has known errors. For example, Forsterite currently shows an incorrect marginal, and the surrogate needs improved retraining.</li>
</ul>
</section>
<section id="try-it" class="level2">
<h2 class="anchored" data-anchor-id="try-it">Try it</h2>
<p>Open the app, pick a preset (for example Ni), keep defaults, and press <strong>Run</strong>. Then adjust dmin and Bethe cutoffs to see how the pattern detail and runtime change.</p>
<p><a href="../../ebsdsim.html">Launch the EBSD simulator</a></p>


</section>
</section>

 ]]></description>
  <category>EBSD</category>
  <category>electron diffraction</category>
  <category>WebGPU</category>
  <category>numerical methods</category>
  <guid>https://zacharyvarley.github.io/posts/browser-ebsd-simulator/</guid>
  <pubDate>Tue, 05 May 2026 00:00:00 GMT</pubDate>
</item>
<item>
  <title>EBSD Orientation Maps</title>
  <link>https://zacharyvarley.github.io/posts/ebsd-orientation-maps/</link>
  <description><![CDATA[ 




<section id="ebsd-orientation-maps" class="level1">
<h1>EBSD Orientation Maps</h1>
<p>This post will collect notes on orientation mapping workflows, data cleanup, and visualization.</p>
<section id="planned-topics" class="level2">
<h2 class="anchored" data-anchor-id="planned-topics">Planned topics</h2>
<ul>
<li>Data preprocessing</li>
<li>Reference frame consistency checks</li>
<li>Plot styling for publication-quality figures</li>
</ul>


</section>
</section>

 ]]></description>
  <category>EBSD</category>
  <category>materials</category>
  <category>visualization</category>
  <guid>https://zacharyvarley.github.io/posts/ebsd-orientation-maps/</guid>
  <pubDate>Tue, 28 Apr 2026 00:00:00 GMT</pubDate>
</item>
</channel>
</rss>
