Post 6 - Final Blog Post
Inital fetch API proposal slide during the first meeeting, June 2th, 2026
Intro
This post will summarize what I did for the Google Summer of Code (GSoC) 2026 for the MDAnalysis, and I serve as a final report for the final Work Product Submission. The primary idea was to add code that facilitates downloading information from various scientific databases. Since MDAnalysis, as the name suggested, primarily dealt with molecular dynamics simulations, it made sense to target various databases that contain various structural coordinates or positions. Building on my previous work on establishing the MDAnalysis’s fetch module, the primary idea was to extend this module via introducing general purpose classes with various utility functions that calls upon these general purpose classes in a predefined manner that is convenient.
The API that MDAnalysis uses to analyze trajectories primarily uses iteration (Example 1) to perform analysis on trajectories. Therefore, it makes sense to conceptualize two different classes that have two different use cases. A StaticFetcher Class that retrieve files and store files statically on disk, and a DynamicFetcher Class which yield a Python Generator that allows for what is essentially “live-streaming” of the trajectory . Through interacting with the REST API of various FAIR databases, these two classes would serve as general multipurpose Classes that any user can set for any generic database. By creating predefined convenience or utility functions, these Fetcher Classes are called in a predefined way for commonly held databases such as Protein Data Bank (PDB), the largest experimental source for biomolecular structures, and the AlphaFold Protein Structure Database, containing models generated by Google Deepmind’s Alphafold.
# Example 1
# Already Existing worflow
# File on disk
top = Path('top.pdb')
traj = Path('traj.xtc')
u = mda.Universe(top, traj)
for traj in u.trajectory:
calculate_interesting_thing()
# Example 2
# Using a convenience function (from_pdb) to
# download and do analysis on pdbs.
#
# This uses StaticFetcher under the hood.
# And is fully implemented
pdb_list = ['4AKE', '1AKE', '1ADX']
universe_generator = (mda.Universe(from_pdb(code)) for code in pdb_list)
for u in universe_generator:
calculate_interesting_thing()
# Example 3
# Proposed syntax of using DynamicFetcher to "live-stream" a trajectory
# Not yet implemented. Would be used in a future from_MDDB
generator = DynamicFetcher().fetch(
base_url='https://irb-dev.mddbr.eu/api',
file_name='top.xtc'
)
for frame in generator:
calculate_interesting_thing()
Development during the Summer of Code
My contribution towards this Google Summer of Code was coming up and implementing this Fetcher Class based vision of how the MDAnalysis’s fetch module should be expanded. Leveraging pooch as optional dependency from a prior pull request, I implemented the StaticFetcher Class with full database/registry support. Additionally, I implemented a few convenience functions such as from_PDB,
from_DOIfrom_ALPHAFOLD which connects to the PDB and Alphafold database respectively utilizing StaticFetcher.
Notably, the DynamicFetcher Class was not implemented on time, and this is really for one simple reason. Developing the logic for the registry in StaticFetcher was hard! In the pull request with StaticFetcher, it is possible to see that it took me roughly a month to get StaticFetcher in a state where the logic made sense for both practical and securely. In contrast, the DynamicFetcher would have been easier to implement. For context, a molecular dynamics trajectory contains 3*NUM_OF_ATOMS, one for every cartesian degree of freedom, for every frame in the trajectory. Thus, the memory buffer needs to store one frame is fixed and doesn’t need to be adjusted. With the fact that DynamicFetcher wouldn’t need to store the trajectory onto disk, thereby bypassing the need for the cache updating logic would have been in retrospective way faster to implement. However, the choice of choosing to implement StaticFetcher is a senseible one since from_PDB already predated this Summer of Code and backwards compabitiblu had to be maintained per the Semantic Versioning that MDAnalysis follows.
The major remaining thing on the checklist is to really finish up the DynamicFetcher Class, and some convenience functions that hooked up to some other well-known databases such as the European Union’s Molecular Dynamics Databank. For various reasons that I mentioned in the last paragraph, I foresee this being way faster than the implementation of StaticFetcher, and the fact the MDDB follows REST API under FAIR principles should in the most ideal case make its convenience function easy to implement.
Otherwise, this Google Summer of Code has been a really useful experience overall! I’m a Physics Ph.D student, and the code that we sterotypically produced as a demographic really incentives publishable results over good coding practices. And with the advent of generative AI tools, I feel like this stereotype has only gotten worse. So it is really refreshing to sit down and think from a top-down perspective and write quality code to do useful things!
Test doggo for image. I never had to do a blog until this!
