The question I got most after telling people my major was “Do you like it?” Being an aerospace engineering student, I knew the horror stories: the sleepless nights and impossible exams. And in many cases, it was my lived experience, as my nights turned into days. But I loved it. Every problem I solved, every lecture I attended, fulfilled me and brought me closer to my goals.

So when I joined Strachan Group, it was a complete pivot of my academic career, from aerospace to materials science. Engineering had taught me to look at the big picture, how to make the parts an effective whole, to design a product section by section. But molecules (unfortunately) do not believe in such things, and thus I was hunched over a quantum mechanics textbook, trying to understand how atoms work.

What’s going on?

My project focuses on molecular modeling and understanding of colliding deflagration waves. Essentially, when energetic material is heated for combustion, structures called “hotspots” form. They are areas of localized energy and higher temperatures. When a hotspot reaches a certain size, it starts spreading forward to the material surrounding it, creating a deflagration wave.

Sometimes multiple hotspots can form at once, resulting in multiple deflagration waves spreading through the material. My job is to model and analyze what happens when those waves collide with each other, specifically in a material called HMX.

HMX is an energetic material used in explosives and rocket fuel. It consists of carbon, hydrogen, nitrogen, and oxygen (see Figure 1). Due to being “self-oxidzing”, the substance does not need oxygen to combust and will self-combust once it reaches 534°F. By understanding the phenomena occurring during detonation, we can develop munitions better suited to respective needs.

Figure 1: Molecular Structure of HMX

To accomplish this, I run simulations on LAMMPS (Large-scale Atomic/Molecular Massively Parallel Simulator), a molecular dynamics software, then analyze the data output using Python and visualize the data using OVITO (Open Visualization Tool).

The Input

My first official assignment was to run three cookoff simulations with 5000 molecules at 300K for 50ps, then verify and validate those simulations. A cookoff simulation is when you take a material (in this case HMX) and place it at a certain temperature for a certain amount of time to see how the molecule reacts. This allows us to understand how the simulation interacts with the material, if there are any errors, or anything we need to change in the input file.

The first was an NVT simulation, where the number of molecules (N), volume (V), and temperature (T) was kept constant. The second was an NPT simulation, where P is pressure. The last was an NVE simulation, where E is energy. All of which was kept constant like the first simulation.

However, to my shock, my professor had stated that the input files should be created with Claude. I had done some basic practice problems with LAMMPS with existing input files. I knew the commands that had to be used and understood that these files were relatively simple to create. But with only two months of research to go, the AI would expedite the speed at which I could work. Rather than spending the hours manually writing input files, I spent it understanding the very equations the simulations used, focusing on verification and validation.

The Output

To verify the accuracy of the simulation and the AI-generated input file, we analyzed the output of the simulation.

Figure 2: Characteristics of HMX at NVT (initialized at 300K)

Figure 3: Characteristics of HMX at NPT (initialized at 300K)

In both the above plots, though there are slight oscillations in the data, the differences are negligible. The volume in Figure 2 is completely constant. The temperature in both Figure 2 and 3 are approximately 300K throughout. And the pressure in Figure 3 is approximately constant as well.

Figure 4: Characteristics of HMX at NVE (initialized at 300K)

In Figure 4, though volume is constant, total energy is actively increasing in a non-negligible amount.

Back to our Roots

The suspicious increase in energy prompted many questions, whether it was an error in the simulation or a characteristic of the material used. Turning back to the fundamentals of molecular dynamics, in particular, quantum physics and conservation of energy, we observe Hamiltonian mechanics and the equipartition of energy.

Equation 1: Hamiltonian Mechanics Formula

Essentially, H is the total energy of the system (“The Hamiltonian”), made up of potential energy V and kinetic energy T. The potential energy depends on the force exerted by the molecule on itself, through bonds and the distance of those bonds, and its neighboring molecules. The kinetic energy is calculated through momentum p and mass m or using the reduced Planck constant h and gradient ⛛.

In the equipartition of energy, it states that a system remaining at a constant temperature will follow the equation:

Equation 1: Equipartition of Energy Formula

Where <E> is average energy, N is degree of freedom, k_B is Boltzmann’s constant, and T is temperature.

In Figure 4, we notice that in the total energy graph, energy increases by 100 kcal/mol. Assuming there are three degrees of freedom (three axes), the temperature would have to increase by approximately 33,000 K. However, as seen in the temperature plot, that is not occurring. Nonetheless, the plot is strange as well. The system was initialized at 300K but it spends the majority of its time at ~220K. And as per the equipartition of energy, if there is an increase in energy, there must be an increase in temperature.

These were the questions I finished my second week with: why is the temperature lower than 300K? Why is the energy increasing when the temperature is not?

What’s Next?

Now that I know what issues there are in the simulation set up, I plan on reading papers similar to the work I’m doing. I hope to understand how their simulations work and what changes they made to ensure successful runs.

My work is so much more than what I originally thought. I expected to spend my hours focused on running simulations and writing code. Turns out, that takes the least time out of everything. Watching lectures, reading textbooks and research papers, is what research is about. You can’t make something new without knowing the past.

But when it came to my summer research, I was faced with something that I haven’t really gotten into: MCPs (short for Model-Context-Protocol).

What on earth is an MCP?

Well, don’t worry because that was exactly the same question I was thinking when my mentor JC mentioned it during onboarding. I’d spent two years getting comfortable with LLMs as a coding partner in languages like Python and R, but I’d never had to think about how an LLM actually reaches out and does something outside of a chat window. Turns out that’s the whole point of an MCP server: a standardized way for an AI agent to call external tools instead of everything being hardcoded inside one program. It sounded simple enough on paper. I nodded, wrote some details down, and moved on, fully convinced I’d revisit the concept once I actually started building.

The bigger problem was more basic than any of that. Before I could touch MCP at all, I needed to get the actual codebases onto my machine.

Let us commence forth! - Clon’ing? (if you got the reference, congrats)

When the onboarding week came to an end and JC assigned me with cloning AURA and AURAMCP repositories, I naturally assumed he was asking me to clone it using github. JC had given ample context that this was going to be a local sync using SSH, but this breezed past my head.

“Simple task,” I thought to myself. Little did I know, I was following a general protocol that had worked for me previously but was wrong in this instance, and I was in for a rude awakening.

No no no, I am not asking you to Clone via github.

I went looking for a repository link, ready to git clone my way to victory like I’d done a hundred times before. Instead, I got a whole bunch of permission errors, a blank window that didn’t upload anything on my Visual Studio Code, and a mentor patiently explaining, again, that while there is a GitHub repo for AURA, I was never supposed to clone using Github. I was instead instructed to specifically perform a SSH sync, which I should be able to learn how to do so with relative ease.

For one, I learned that these codebases didn’t live in some public remote I could just point to and that some of them even lived on Purdue’s clusters, behind authentication I didn’t have set up, accessible only through specific terminal commands.

Funny enough, after asking Gemini plenty of questions on performing an SSH sync and following its instructions, I arrived at yet another roadblock. At first, it seemed like I had done everything correctly: cloning from nanoHUB’s terminal directly, entering a handful of bash commands on VSCode’s terminal, inputting my nanoHUB credentials within VSCode, and most importantly, the main folder itself seemed to have uploaded to my local drive. However, this is where I ran into further problems; I discovered that I had no SSH access for any of nanoHUB’s repos in the first place.

When I submitted a ticket to nanoHUB, I was left with this short message from the support team:

“So, after hearing back for other support members it seems that SSH access is restricted to certain users but you should be able to SFTP into your home directory using your username and password.”

Fortunately, Gemini taught me the small changes I needed for my bash commands, and the process itself was somewhat similar to that of a SSH sync. But it did hit me that without LLMs like Gemini or Claude, this whole process-not just the troubleshooting part-but the whole process of just getting AURA and AURAMCP on my local drive probably would have taken double if not more the time. (While this may not look like a big deal because SSH/SFTP sync are just a few commands on the surface, this process took me 2 whole days because of all the troubleshooting involved. Genuinely, without LLMs I think this might taken me a full week—a couple dozen Google searches, digging through Stack Overflow posts, and begging for answers on Discord forums. Thank you, Gemini.)

Having done a SFTP sync, branching the repos was not all that different from a regular branching, putting an end to my wrestle with cloning.

Testing AURA, and Learning to Document Traces

Running AURA’s case study tasks sounded straightforward on paper: give it a research question, watch it orchestrate its agents, and evaluate the trace using LangSmith. In practice, a good chunk of my weeks 3 and 4 turned into something closer to manual testing than research, and I quickly learned that “it didn’t work” is not a sufficient bug report.

My first flagged error was small: a py3Dmol import failing somewhere between the Supervisor and Code Execution agent, on a run that should have just visualized a structure. Then came a stranger one: asking AURA to pull up MeltHEAs kept failing with a “no inputs found for tool” error, even after giving it the exact nanoHUB URL. This was not a one time occurrence either; the same underlying getToolMetadata failure showing up across my runs, just triggered by different tools. That was oddly reassuring though, as it meant I hadn’t broken something myself, I’d found an actual crack in the system.

The one that ate the most time came near the end of week 4: asking AURA to run an elastic tensor calculation on h-BN with default settings, and watching the Supervisor’s command just... stop, right after acknowledging the request. Four attempts, four dead ends 😭😭😭😭, one of them not even throwing a visible runtime error on LangSmith 🥀; just silence where a result should’ve been.

Reporting all of this well mattered more than I expected. My research peer, Rachel, had already set up a Claude Skill that took AURA’s raw JSON traces and turned them into readable, color-coded transcripts, and a second skill that distilled those into short structured summaries: what was asked, how the agents responded, where compute got escalated, what came out the other end. Following someone else’s already-built protocol instead of inventing my own logging format was its own small lesson. I was experiencing the FAIR/reproducibility at its finest: a standardized way of capturing a run means Rachel and I could actually compare our failures side by side and realize we’d found the same bug, instead of each quietly assuming we were the only ones confused the software was not working as intended.

A Quick Comment on Agents and Agentic AI

Since AURA is an agentic system, it felt worth digging into what that word actually means, beyond the buzzword version I’d absorbed through media. An “agent,” in this context, isn’t simply just an LLM answering a question; it’s an LLM given a goal, a set of tools it’s allowed to call, and the ability to decide which tool to use and when, often across multiple steps, without a human specifying each action in advance. (The setup itself is usually manual, though.) AURA’s Supervisor agent is a clean example: it doesn’t run simulations or fetch materials data itself, it decides which of its specialized sub-agents should handle a given piece of a task and stitches their outputs together. “Agentic AI,” is really just this idea scaled up; it is essentially a bundle of systems built around that loop of reasoning, acting, observing the result, and reasoning again, rather than a single input-output pass. It’s also exactly why a bug like the h-BN failure is so hard to pin down for someone who didn’t actually build AURA: the error isn’t in one function, it’s somewhere in a chain of decisions the agent made about which tool to call next, which means debugging it means debugging reasoning, not just code.

1. Zhao, Guodong (Troy). "Model Context Protocol (MCP): A Guide to Unlock Seamless AI Experiences." Bootcamp, 10 Apr. 2025, medium.com/design-bootcamp/model-context-protocol-mcp-a-guide-to-unlock-seamless-ai-experiences-30bc27fa47c6.

2. Verduzco, Juan Carlos, et al. "Autonomous Universal Research Assistant (AURA): Agentic AI Meets nanoHUB's FAIR Workflows and Data." ChemRxiv, version 2, 27 Jan. 2026. ChemRxiv, doi:10.26434/chemrxiv-2025-rs07k/v2.

3. "SFTP File Transfer Protocol." GeeksforGeeks, 23 July 2025, www.geeksforgeeks.org/computer-networks/sftp-file-transfer-protocol/.

Read it here if you haven’t yet:

So What’s Going On?

My first couple of days with running real radiation cascades was a lot of figuring out what I didn’t know in order to even start learning. As such, my first runs weren’t very good, or very realistic. Although we used a Claude skill to make the input LAMMPS file, the skill checks if the inputs we submit are correct, not if we have all the necessary components to make a physically relevant simulation.

So, when I introduced 1keV worth of energy into a system around 10,000 atoms, and didn’t add any way for that extra energy to dissipate, my system went crazy. Thankfully, my ever so helpful partner Agustín shared a very helpful reference article that provided a methodology in implementing Langevin shells, a thermostat to regulate the temperature of the material, and could siphon away the extra energy and let the structure relax.1

To calculate how the system thermally responded to our energy spike, we did some good old white board deliberations (reference figure 1) to understand how the energy was distributed across the molecule. Professor Strachan told us to deliberately not use AI for this part, and this type of ballpark calculations were park of the intuition needed to be an effective researcher in your field.

By equipartition, a solid with N atoms has 3N kinetic degrees of freedom. That means its kinetic energy is

At first glance, you might think that all of the PKA energy becomes kinetic energy, which would predict

That was our first whiteboard estimate and it turns out to be wrong by exactly a factor of two.

The missing piece is that atoms in a crystal aren’t free particles. They’re connected by chemical bonds. According to the virial theorem, the energy on an harmonic solid is shared equally between kinetic and potential energy:

Since temperature only reflects kinetic energy, only half of the injected energy contributes to the temperature rise. The correct prediction is therefore

For a 500 eV cascade, that predicts a temperature increase of about 19 K in a large simulation (~100,000 atoms) and about 154 K on a small one (~12,600 atoms). The deposited energy is identical in both cases, the only difference is the number of atoms sharing it. With eight times fewer atoms, the heating is eight times larger. But will the simulation meet the theory? We will get back on that.

Solving Problems is Our Job Description

And boy, did we have a lot of problems.

The goal of the simulations is to induce a cascade in our cell, where atoms knock each other off their crystal lattice and create an amorphous blob near the origin of the cascade. Refer to Video 1 below to see what a typical cascade and subsequent amorphization looks like.

^{Video 1: Job ID (11099261) shows a cascade emerging from an induced PKA creating an amorphized pocket. Only atoms that have moved a minimum of 2 Angstroms are shown, and the PKA was selected to be Tellurium in the 135 direction. Atoms are color coded from red (most KE) to dark blue (least KE), with yellow arrows indicating displacements. Visualized in OVITO.}

A good way to quantify the amount of amorphization (the transition from the cubic rock salt to this liquid-like phase) is to use the radial distribution function, represented in Figure 2 below. At a 1.0 g(r), the distribution of atoms inside your simulation (either at a specific point or throughout all of it) are functionally random. Higher g(r)’s mean that atoms are appearing at those radii at frequencies higher than random and lower g(r)’s mean they appear less frequently.

Problem 1: The above graph indicates very little amorphization because the zones where we measured the radial distribution function are close to the baseline, crystal distribution, which means that even after the PKA was induced, the structure was still crystalline.

Problem 2: This happened because of another issue known with MD, which is called channeling. Due to how we arrange the atoms initially to emulate the FCC of the solid GST-C, channels that are devoid of atoms emerge (refer to Figure 3 below), where the initial PKA can travel long distances without interacting with another atom, creating non-physical reactions.

Problem 3: Another problem we have ran into as a result of channeling is the cascade leaking outside of the periodic boundaries and invalidating the simulation’s integrity as something that represents the world around us. Reference Video 2 below to see atoms leaking across the cell boundary and reappearing on the other side of the cell.

^{Video 2: Job ID (11092766) Another 1keV PKA that is TE, but in a random, partially channeling direction that causes it to move further and leak outside of the white boundary, causing some atoms to reappear at the bottom.}

All of these problems were human-identified, but fixed with AI, which has become a trend with our time in the lab. Our knowledge geared toward these specific, niche circumstances is needed in order for AI to properly be implemented and help in a way that is productive. We might not be able to fix the problems as efficiently or as quickly as AI can, but we are the ones that are able to identify these problems in the first place, allowing our artificial assistants to help instead of lead.

These fixes led to the radial distribution graph below (Figure 3), which represents the g(r) of Video 1 referenced earlier in the blog. In the image, the cascade zone lines deviate from the baseline to trend toward a g(r) of 1, especially as they get further away, indicating a more random distribution, and thus a more amorphous distribution.

Theory Meets Simulation

We suspected the Langevin shell is a crutch you only need when the box is too small to hold the damage. In a big box the heat dissipates on its own; in a small one it reflects off the periodic boundaries and stays trapped. So we ran four simulations: two box sizes, thermostat on and off.

Figure 4 (above) is a grid. The top row is the 6*6*6, the bottom row is 3*3*3. Left column has the thermostat on, right column off. The green line is our whiteboard prediction, 19 Kelvin above 300 K.

The thermostat-off panels are the clean test, and they land almost exactly on the prediction: the large box (Run B) settles at +20 K against +19 K predicted, the small box (Run D) at +150 K against +154 K. Our validation calculation from earlier suggests we should be optimistic about the veracity of these results, as they are accurate within a few percent.

The thermostat barely matters in the large box: Run A and Run B differ by less than ten degrees, because the damage stays far from the boundaries, transferring its energy to the surrounding particles. In the small box it is the whole story. Without it, Run D sits 150 K hot for the entire run; with it, Run C drops back to room temperature, because the shell drains the heat that would otherwise reflect back into the box particles.

The pattern is: A ≈ B ≈ C ≠ D. Meaning, when the box size is large, there is no need for shell. On the contrary, when the box is small (related to the damage of course) the shell makes a difference on the systems ‘global warming’.

We have plans to run the above simulation at a variety of box sizes and energy sizes to quantify a cutoff for where we don’t need a Langevin border. Additionally, starting next week and the week after, we will be making heavy strides into pursuing the end goal of the project, creating a device-scale simulation in the environments it would be in.

Stay tuned as your favorite problem solvers keep banging their heads against the proverbial wall! See y’all next week!

I’m a mechanical engineering student, and most of my world is classical physics and the satisfying logic of things you can touch and take apart. So when I was matched with Professor Strachan’s project on atomistic modeling of MXenes for electronic applications, I knew I would be out of my depth. The first thing I was told to do was run a relaxation simulation in a program called Quantum ESPRESSO.

I nodded like I understood. I did not understand, and I knew I would be doing a lot of Googling in my near future.

What Is a K-Point, Actually?

When you model a crystal, you’re working with a structure that repeats periodically, the same unit of atoms tiling out infinitely in every direction. Physicists found it’s often cleaner to work in a transformed version of physical space called reciprocal space, where the relevant region for a single unit cell is called the Brillouin zone.

To calculate properties like total energy or electron behavior, you need to integrate over the entire Brillouin zone. Since doing that continuously is computationally impossible, you instead sample it at discrete points. Those are your k-points.

The more k-points means a more accurate picture, but it also takes longer. The goal is finding the sweet spot, enough points that your results are trustworthy, without waiting forever for the calculation to finish.

Why Does This Matter for My Simulation?

The material I was studying is Ti4C3O2, a MXene with properties interesting for electronic applications. The simulation type is called vc-relax (variable-cell relaxation), where both atomic positions and the shape of the unit cell are free to change until the system finds its most stable configuration. For those results to mean anything, the k-point sampling needs to be accurate. Too coarse a grid and you’re not finding the true minimum energy structure, you’re finding an artifact. Verifying that your grid is dense enough to produce stable results is called a k-point convergence test.

Running the Convergence Tests: What I Actually Did

I ran vc-relax simulations across a range of k-point grids and tracked total energy, lattice parameters, and stress. My first round used a kinetic energy cutoff (ecutwfc) of 60 Ry, testing grids at multiples of three: 6x6x1, 9x9x1, 12x12x2, 15x15x2, 18x18x2, and so on up to 27x27x3. The energy converged cleanly. The stress components, particularly σ_zz, did not. They oscillated instead of settling (see below).

My first instinct was that the kinetic energy cutoff was the problem. Higher ecutwfc means more precise wavefunction descriptions, so I reran everything at 80 Ry hoping it would smooth things out. The energy converged even better, but the oscillation in stress and lattice parameters was still there. Same alternating pattern, different cutoff. That told me the issue wasn’t numerical precision. Something else was going on.

The Even-Odd Problem (A.K.A. When Your Data Confuses You)

After ruling out the cutoff, I started digging through papers and Quantum ESPRESSO documentation. Eventually something clicked.

By testing multiples of three, I had been alternating between even and odd grid values without realizing it, and that distinction matters a lot for a hexagonal structure like Ti4C3O2. In hexagonal systems, the Brillouin zone has high-symmetry points (labeled K and M) at specific geometric positions. Even grids sample those points differently than odd grids, creating a systematic alternating error that shows up as oscillation in the output. General rule of thumb is to only compare even numbers to each other, or odd numbers to get cleaner convergences. However, either result will be biased to sampling some sort of high symmetry point. Alternatively, you could just use prime numbers.

I chose the switch to prime number grids: 5x5x1, 7x7x1, 11x11x2, 13x13x2, 17x17x2, 19x19x3. Primes break the even-odd cycling, and the results from those grids were much better behaved. I hadn’t expected a convergence test to turn into a lesson in Brillouin zone symmetry, but here we are.

So What Did I Learn?

Convergence testing helps us earn the right to trust the quality of our results. The other thing I learned is how to navigate being lost. AI tools helped lower the barrier, having something explain reciprocal space at 11pm is genuinely useful. But I learned to always ask for references and cross-check everything. AI got me past the software learning curve of QE, learning SLURM commands, and creating python parsing scripts so I could focus on actually thinking about the physics, which is the part that matters to me.

What’s Next

Now that I have a converged k-point grid and a relaxed structure for Ti4C3O2, the plan is to apply the same setup to a series of related MXene structures and build out a dataset of properties. The longer-term vision is a computational MXene database, similar to what researchers like Kat Nykiel and Professor Strachan built for MAX phases.

I came into this summer expecting to learn some software. I didn’t expect to spend a week on the geometry of reciprocal space because one stress component wouldn’t behave. But that’s research. It makes you care about problems and concepts you never realized existed.

And honestly? That’s exactly why I’m here.

Some examples:

• Energy conservation in NVE MD simulations to learn about Hamiltonian dynamics and numerical integration.

• The temperature of an NVE MD simulation starting from a relaxed structure can be used to learn about statistical mechanics & equipartition of energy.

• Convergence tests in DFT calculations are used to learn reciprocal space and plane wave basis sets.

Check out the posts from the students to learn all about our experiment!

For a little bit of background, I am a rising sophomore at Arizona State University studying Electrical Engineering and have done filled skutterudite and III-V semiconductor DFT work. Agustín is a senior at Instituto Sabato (Argentina) studying Materials Engineering and has done research on semiconductor devices under radiation and also computational methods on MSE projects such as FEM, MonteCarlo, and MDs.

This week consisted of a lot of setting up high performance computing environments, reading articles to understand the scope of our project, and getting Claude Pro. Yes, one of these things is different from the others, but from the start, Professor Strachan emphasized the need of becoming AI-first researchers in this new landscape, using the amazing tools and opportunities in a responsible manner, verifying its results, while not blindly trusting it.

We will first discuss what we have done throughout our time here so far and then explain how we used AI in those processes in order to achieve our results. So be sure to read all the way to the end in order to get the full context! Also, an extra picture of our group watching the World Cup while working!

Our Interest

We want to investigate GST-C (see figure 1), a Ge-Sb-Te system doped with a small percentage of Carbon is a phase-change material that can rapidly transition between crystalline and amorphous phases under suitable external stimuli. 1 This unique ability to reversibly switch between phases with markedly different electrical properties makes GST-C attractive for several emerging technologies.

_{Figure 1: A fcc cubic structure of GST-C visualized in OVITO.}2

Potential applications include radiation-tolerant memories, where information is stored in the material’s structural phase rather than in electronic charge, making it potentially resistant to single-event upsets (SEUs).3 The large conductivity contrast between crystalline and amorphous GST also enables concepts such as focused-ion-beam-defined nanocircuits4 and multilevel memory devices, where controlled irradiation-induced defects can create multiple stable resistance states for neuromorphic and non-binary computing applications.5

Previously, this material has been studied with density functional theory (DFT) based molecular dynamics simulations.6 Additionally, this material has been shown to be compatible with ACE, a highly efficient, highly scalable machine-learned potential. 7 To break new ground, we want to investigate GST-C within the effects of a radiation environment, seeing how radiation can affect the structure of the GST-C and the phase it occupies.

The Strachan Group at Purdue (who we are interning with) have trained an Allegro8 machine learning potential, a potential more suited for local interactions than ACE, for us to use in our project. We aim to simulate radiation with a molecular dynamics simulation using LAMMPS9 through a pka (primary knock on atom), giving one of the atoms in our material box an excess of energy and a directing it into our simulation to create a cascade.

Our Work

The first task was to perform a pair of scaling simulations on the Gilbreth cluster here on the Purdue high performance computing (HPC) system. I (Aryan) did strong scaling, whereas Agustín did the weak scaling simulations. We used the crystalline phase (reference figure 1) of GST-C, creating a cubic supercell containing 466 atoms (102 Ge, 103 Sb, 256 Te, and 5 C) in a 24.62 Å cubic box, corresponding to ~1.07 at.% carbon. Larger systems were generated by periodic replication of this unit cell.

All simulations use the NVE (microcanonical) ensemble with a 1 fs timestep (timestep 0.001 in LAMMPS metal units). NVE was chosen deliberately: it avoids the overhead of thermostat or barostat algorithms, so the measured wall-time reflects only force evaluation and time integration, giving the cleanest possible scaling signal. Initial velocities are assigned at 300 K. The GPUs used were A100-80gb.

Strong Scaling:

Strong scaling increases the amount of resources you provide the simulation (in terms of nodes, GPUs, and CPUs) while keeping the amount of atoms the same. While the ideal is that 100% of your hardware is focused on simulating your system, unfortunately, that isn’t the case. There are tradeoffs, with part of the processing power being dedicated to communicating between the dozens of CPUs handling how atoms interact with each other when they go into the boundary of another CPU (see figure 2). Additionally, your system is only as fast as your weakest link, so if even one GPU takes a couple of extra milliseconds, then all the other GPUs idle waiting for it to finish.

The concept above, about how strong scaling works, was first taught to me through the use of Claude. However, AI wasn’t used to create that blurb, that all came from my own personal understanding of strong scaling. And in my opinion, this contrast between AI learning paired with human execution highlights the line between being replaced by AI and being proficient with AI. The article that Figure 2 was pulled from came up as a result in one of our AI web searches, but us interns still had to know what the figure meant and if it conveyed what we wanted it to convey. Using AI with intention, knowing what results are expected and how you expect to use them are of utmost importance when learning to use it responsibly.

_{Figure 2: The picture represents a 2D simulation box partitioned in 3x3 cells. Each cell represents the area a single CPU controls. In the red rectangle are the CPUs own particles. In the blue rectangle are the external particles the cell in the center needs to keep track of. Figure extracted from}10

4 batches of simulations were conducted, at ~60k, ~119k, ~239k, and ~477k atoms, with each doubling the previous amount. For each of these batches, I ran that atom count at 1, 2, 4, 8, and 16 GPUs. Below (Figure 3) of the results from the strong scaling simulation. There are four colors of lines, for the four amounts of atoms described above. The dotted line represents the ideal, a doubling of resources leading to a doubling of compute power. At higher amounts of atoms and higher amounts of GPUs, the trend is much closer to the ideal compared to when there are way less atoms.

Initially, that wouldn’t seem to make sense. If there are more processors working on a smaller problem, wouldn’t that lead to the problem being closer to the ideal? Table 1, shown below, shows us the reason why. As the number of atoms and GPUs increases, the percentage of time spent on communicating between processors proportionally decreases.

While there might be more time spent on communication as a whole, that section is a smaller percentage of the total time spent on the simulation. That happens because as volume grows (which happens as the amount of atoms grow), the surface area (where the communication happens) decreases proportionally, so overall, the communication fraction should drop as the time spent on pair simulations grows.

Weak Scaling:

Weak scaling increases both the number of GPUs and the system size simultaneously, keeping the number of atoms assigned to each GPU approximately constant. Unlike strong scaling, where a fixed problem is distributed across more hardware, weak scaling evaluates how well the simulation framework handles increasingly large systems as additional computational resources are added.

The ideal outcome is that the wall-clock time per simulation step remains constant as both the system size and GPU count grow. In that case, the simulation would exhibit 100% weak-scaling efficiency. Any increase in runtime indicates that parallel overheads, such as inter-GPU communication, synchronization, or load imbalance, are beginning to compete with the actual force calculations. Weak scaling is therefore a useful measure of a code’s ability to tackle larger and larger atomistic systems efficiently.

Four scaling points were measured: 1, 2, 4, and 8 GPUs, spanning 1 to 4 nodes and 59,648 to 477,184 atoms. Efficiency remained within 1.1% of the ideal across all points, indicating near-ideal weak-scaling performance over the range of system sizes and GPU counts examined.

Weak-scaling efficiency was defined based on timesteps-per-second, taking the ratio between the performance at N GPUs and the single-GPU reference case, and reporting it as a percentage.

Wall-Time Breakdown: Why Efficiency is Flat

Table 2 shows the LAMMPS per-section timing breakdown for the measured block at each scaling point in the weak scaling simulations.

The key observation is that the Pair section (the Allegro neural-network forward pass on the GPU) dominates at 95–97% of total loop time throughout. The Comm section (MPI ghost-atom exchange) grows as GPUs are added, but remains very small in absolute terms. “Other” column includes Modify + Other + Output. Modify is the time spent executing LAMMPS fixes such as thermostats, constraints, and other user-defined operations. Other is internal LAMMPS overhead that is not assigned to a specific calculation. Output is the time spent writing results to files, such as logs, trajectories, or restart files.

Interpretation and Comparison

The weak-scaling results indicate that Allegro is strongly compute-dominated, with nearly constant Pair cost per GPU and minimal communication overhead thanks to its short interaction range. The practical lesson is that adding GPUs is worthwhile: because the Pair cost dwarfs communication, more GPUs let us run proportionally larger systems with almost no efficiency penalty.

In strong scaling, where a fixed system is divided across more GPUs, the trade-off runs the other way. Adding GPUs to the same problem reduces the work each one does, and the efficiency falls away from ideal once each GPU is left with too few atoms to keep it busy. More hardware does not come for free here: past a point, the coordination between GPUs costs more than the time it saves.

Both studies also run into the same hardware ceiling: per-GPU memory. Each A100-80GB GPU holds a finite number of atoms, and the largest systems simply do not fit on a single card. This is a real limitation for our goals, and it is what forces the largest systems to be split across multiple GPUs in the first place.

Taken together, the two studies frame the same decision from opposite sides. Weak scaling shows that more GPUs are the path to larger systems with near-ideal efficiency; strong scaling shows that throwing GPUs at a fixed system yields diminishing returns; and both are ultimately bounded by how many atoms fit in GPU memory.

Letting the Robot Help (But Watching It Closely)

Claude generated that title. I bet you could tell that it wasn’t exactly the same format as the rest of the blog. AI is amazing at many tasks, but it can’t be human just yet.

We (the guinea pigs at Strachan lab) are not expected to be on par with domain experts with dozens of years of experience in our two month summer program. However, we are still expected to operate at a high level and contribute meaningful research to the group. For that goal, Artificial Intelligence has been great in closing the gap and supporting us as we navigate our new environment.

A Claude skill was used to generate the input files for both the strong and weak scaling simulations. It was written by our mentors here at the Strachan Lab, so you go check the paper out!11 They built a pipeline that normalizes, parses, and test-runs LLM-generated scripts so you can catch these errors before burning compute on a bad simulation.

Additionally, AI has been used mainly in creating parsing scripts, graph synthesis, and learning about the specifics of our input files and runs. Our motto is to have AI do as much as possible, but to make sure that we humans know what is going on at all times. While I may have Claude create the input files for my simulations, it is my responsibility to verify that the information is right and actually fulfills our objectives.

All the interpretations and conclusions drawn from the empirical data stemmed from the brilliant neurons organically grown in human brains, not mathematical models that attempt to emulate one of the most complex structures in the universe. That little blurb under LLM chat boxes acknowledging that they are AI and can make mistakes is the exact reason that humans need to look over everything they do. AI only gets as much power as we let it have.

That’s all we have for this week! It was a bit lengthier as we had to condense two weeks of content into one, so next week will be a little shorter. See you then!

One of the challenges facing our field is how to best use AI to accelerate research and the associated implications for education and workforce development. There are many open questions: What fundamental knowledge and skills should future researchers have? What tasks do we fully delegate to AI systems? What tasks are delegated but still require human sign-off? What should be done collaboratively or kept 100% human? And how can novice researchers develop intuition and domain expertise when a growing number of tasks are delegated to AI?

In the Strachan group, we have the first generation of AI-first guinea pigs—I mean… research undergrads. 😊 This blog will document their summer research, focusing on how they use AI in their computational projects. Our goal is to use AI to accelerate their work and help them learn the fundamentals. We have designed a set of tasks to accomplish both: accelerating innovation without cutting corners.

Looking forward to seeing the results of this program and what the students accomplish.

This introductory post explains the hows, whats, and whys of our blog, specifically how it will work, and how to navigate it in the future. The following posts will document our week-to-week journey of being “AI-first researchers” who are using AI as a tool to teach and guide us in our fields as we attempt to become domain experts. While we will talk about how we use AI in our blogs, we will also detail our experience working in this group over the summer as well!

Our Group

Agustín and I (Aryan) will be working on radiation modeling simulations of GST-C. Samiya and Sahana will be focusing on MXene simulations. Likhita will study high-energy materials. Mike will develop autonomous scientific workflows! And Rachel will be making AI-assisted research trustworthy and FAIR.

There will be 5 posts coming out each week, giving every project a chance to spotlight progress and discoveries. So exciting! For all the PhD mentors supporting us and the other projects going on in our group, please visit the Strachan group website!

For some faces you can associate these names to, here is one of the pictures we took at a local farmers market!

^{For members pictured: Rightmost in the white is Aryan, next to him in the blue hat is Mike, in front of Aryan and to his left is Likhita, and next to Mike in the hat and sunglasses is Agustín. On the center-left, in the orange skirt is Rachel. And the rest of the people are friends we have met during SURF!}

In one of our future posts, we will put a group picture with the entire group, so our readers can see everyone!

We are already nearly through Week 2, so look forward to our belated (but still exciting) project highlights from the first two weeks soon. Our program runs until July 31st, so you can expect consistent updates from us until then! From here on out, you can pick your own adventure — whether you focus on MXenes or explore all of them. Feel free to leave comments and questions on these posts as we would love to hear your thoughts.

Thank you for reading and see you on the other side!

SURF Undergraduates

Leave a comment