LLMs reproduce CCP4 AceDRG… #401
Replies: 5 comments 3 replies
|
I think this is a great idea. How large are the AceDRG tables in comparison to the monomer library? |
|
Amazing stuff. Where can I track progress / take a look at your implementation? |
|
Update. Things were moving quickly forward initially, but some problem were taking forever.
Claude was making changes to fix one monomr, then reverting them when I reported it broke 5 other monomers. |
|
The project of reproducing the The process |
|
One issue I see (that I didn't see mentioned in my scan of the comments) is that the AceDRG tables would need to be redone if a novel atom type appears in the COD. There appears to be a complicated process for adding new atom types to the tables that would hinder updating tables. See section 4 in Long, F., Nicholls, R. A., Emsley, P., Grazulis, S., Merkys, A., Vaitkus, A. & Murshudov, G. N. (2017). Acta Cryst. D73, 103-111. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Let's kill the Monomer Library
I'll describe here why and how I'm developing
gemmi drgwhich aims to exactly reproduce part of AceDRG's functionalityHere is how restraints are prepared and used in CCP4 as of 2025:
AceDRG distills the COD into a set of tables that are then used by AceDRG to generate restraints. These restraints (for thousands of monomers and some links) are then distributed as the CCP4 Monomer Library (ML).
As an alternative, gemmi could read AceDRG tables directly and calculate restraints on the fly into topology.
Good and bad sides of having the ML:
✅restraints as files are easy to inspect and modify (but in the alternative approach we'd have an option to add requested monomers as files to the library)
❌it's 35,658 files, which makes CCP4 installation bigger and slower
❌ the ML is always lagging behind the CCD
❌ for new ligands and non-standard links, users need to manually generate and pass CIF files. This step is an extra hoop for monomers and is usually ignored for links. Which results in:
❌ worse geometry around LINKs
Having such a capability in gemmi, would allow us:
to reduce the ML to a few files (like
mon_lib_list.cif+ manual overwrites for cases that are not handled well by AceDRG)The implementation in gemmi would make the maintenance easier. It'd be more compact, because it'd re-use gemmi functions for reading and writing CIF files.
A new, more compact implementation would make things easier for a new maintainer who will be necessary when Garib and Fei retire (they plan to do it in a couple of years)
But reimplementing the AceDRG algorithms is a big, serious and tedious project. Here is how it's going.
Are LLMs smart and cheap enough to do it?
yes, LLMs are smart enough since about Q4 2025 as described, for example, by Andrej Karpathy
For this task, we can easily test our implementation by comparing the values in output cif files
with mondiff
A couple of weeks ago another renowned and respected developer (antirez) described eloquently the current state of things. In short "writing the code yourself is no longer sensible, if not to have fun", and I agree.
LLMs can be used for coding through:
I find the last option most convenient. I started with Claude Code (and €20 Pro plan). But it quickly hit the weekly token limit.
So I started also using Codex (with~€25 Plus plan) both are good and good value, and with two different models one can review the work of the other.Also they both seem to know the chemistry by heart, which helps when investigating discrepancies. I know neither chemistry nor the Acedrg algorithm, so when LLM asks me how things should work, I reply "no idea, go figure". If it tells me something about chemistry, I can't tell if it's true.
We were wondering,why we get different restraints for HIS. Codex had a hypothesis,which I pasted into Discord and I got a few Paul-tokens confirming that it makes sense:
But soon I started hitting usage limits in both CC and Codex. So I tried also Gemini CLI (free).It didn't work well for this project (which was unexpected) So I tried qwen-code (free, using Qwen3-Coder model). It worked faster than other LLMs, and better than Gemini, but not as good as CC and Codex. I was tired of testing, so I skipped DeepSeek CLI and kimi-cli, and just upgraded Claude to the
€100 Max plan. It's still good value. I suppose the prices will go up at least 10× if the AI companies choose to start covering all the costs and be sustainable.
OK, at this point CC worked neatly (in YOLO mode). Editing code -> compiling it -> running->testing output against acedrg output -> moving on to the next difference, editing code again, and so on. When it gets stuck, it asks questions about acedrg that I relay through Discord to Cambridge colleagues :
but it's not always efficient this way:
One way to organize multiple agents, is to assign different task to each instance, so while CC (agent 1) was improving gemmi,
I started agent 2 (Codex, to use up its tokens) in the acedrg repo,asked it to read the AceDRG paper and familiarize with the codebase and then it could explain the rules used by AceDRG. I still needed to copy-paste between terminals. I'm aware it could be automated, but at least I was kept in the loop. It resembles Clean-room design
Here is an example conversation
it's never ending:
All reactions