Runcard

• 

  Main page

• 

  System 1

• 

  System 2

Inspiration

I had somehow come across the field of Molecular Dynamics through a summer project, and gained experience with AMBER through building an LLM orchestration engine around it. The biggest thing on my mind was just the lack of guardrails that this software had. It was like working with Assembly. It got me thinking a lot more about the experiences of those working in MD, and how I can build software that lowers the barrier to entry.

What it does

Sharing a MD simulation with someone usually means just giving your entire directory. I guess it works, but it's very hard to decode, and with hundreds of literal text files as the input, it's just not a very friendly way to share results. Runcard is essentially GitHub for MD simulations. A prepared system is like a repo, a run is like a commit, and users can "fork" runs, adding their own changes to someone else's work. Runcard turns your MD directory into a shareable, validated record, with analysis tools not just invocable by users, but directly invocable by agents through WebMCP.

How we built it

I was already quite familiar with building AMBER validators, and I used that knowledge to process .in files to ensure that the records were physically sound. That's the "validated record" part of things.

I knew along the way that I wanted to do something analogous to Github, which helped with a lot of design work. If a run was a commit, and a rerun was a fork, many more things became clear. Proposals became like pull requests, which had to be approved by the user.

Primarily, I had to work on creating functions that converted the raw files into the data presented in the website, and the analysis tools that drove both user/agent interaction. One table drives both users and agent interactions, so both sides are getting the exact same functions. At this point, most of the work was done, the rest just went into presenting it in a way that was intuitive to the user.

Challenges we ran into

Some of the things we have agents watch out for (like assuming spread as error) were lessons I had learned when generating the bundles in the first place. Some of the runs were with different engines (PMEMD vs Sander), and also had different total times (2 ps vs 30 ps) yet we treated them the same. AMBER is just very tricky to get right, so many of the challenges we had, despite my previous experience, were with honest our results were.

Accomplishments that we're proud of

To be honest, I'm just proud that I was able to finish this as a final product. Getting to the finish line means a lot to me, since I've never done hackathons all the way through before.

On the product side, I was really proud of how the agent performed given these tools. I first asked it to check the math of a calculation with the tools, and it insisted on refusing to give an error score, because only 2 of 3 matched runs exist. Then, I asked it after to consider the system with 310K temperature instead of 300. It not only did that experiment correctly, but noticed that the missing 3rd matched run in the original run was also missing in this 310K run, and automatically proposed a fix. The tools made this possible, and agents kind of did the rest, which was cool to see

What we learned

I think I've reinforced the idea that the biggest failure modes are silent. Things that are confidently wrong. Both in AI's hallucinating, but also in molecular dynamics where things look ok, but are secretly messed up on the inside.

What's next for Runcard

I think the obvious answer is to a second person's runs onto the website. If we're really going to be the Github of MD, then we need collaboration and people. I want people to be able to share their results, and iterate on each other's work with much more ease.

Built With

• 3dmol
• amber
• bun
• fflate
• python
• react
• typescript
• vercel
• vite
• webmcp