Real Time transformations for broken molecules in PBC [ GSOC 2025 Project Proposal ]

[FNNunes]

Dear all,

I am interested in proposing a project for the 2025 GSoC focused on implementing the algorithm described in doi 10.1021/acs.jcim.2c00823.

This algorithm provides a general solution for handling periodic boundary conditions (PBC) in any triclinic box, addressing a significant limitation in existing tools like gmx trjconv and the PBC handling methods in MDAnalysis (wrap and unwrap). The primary challenge arises when working with assemblies composed of multiple molecules—such as micelles, liposomes, or protein complexes—or when multiple components exist within a single simulation box (e.g., membrane simulations). Correctly translating all constituents into the unit cell can be difficult, but this algorithm offers a robust, general solution. Additionally, it gives users full control over PBC handling and the order in which constituents are assembled.

This implementation would integrate well with MDAnalysis' trajectory transformation framework, enabling real-time trajectory modifications without requiring multiple trajectory files or additional software. This could significantly improve workflow efficiency by saving both time and disk space.

To conclude I have three main questions:

• Is there interest from the development team in incorporating this feature into the MDAnalysis codebase?
• If so, would it be more appropriate as part of an mdakit or the core MDAnalysis package?
• What would be a suitable timeline for such a project?

Best Regards and Happy coding,
Fernando

[orbeckst]

An implementation of FixBox would be interesting.

What is the license of the original C code from https://www.itqb.unl.pt/labs/molecular-simulation/in-house-software ?

I would initially prototype it as a MDAKit. Given that there are a bunch of decisions that need to be made in advance (the contents of the definition file would probably become kwargs of the transformation), it would be good to figure out how to best organize all this information and what typical workflows would look like. We'd also like to understand the performance (it's possible that the code would be best written in e.g., cython).

This still leaves open the door to eventually incorporating your code as a transformation in mda.transformations.

I would also plan on including a number of challenging tests cases (perhaps from the original paper?).

I'd encourage you to submit a pre-proposal!

[orbeckst]

(P.S.: I fixed the DOI hyperlink in your original post – thank you for linking to the original paper: it helps a lot to know that we're talking about a published algorithm)

[FNNunes]

First of all I am very pleased to hear your feedback on the pre-pre-proposal.

Regarding your questions:

What is the license of the original C code from https://www.itqb.unl.pt/labs/molecular-simulation/in-house-software ?

If I am not mistaken it is a GNU GPL Version 2.

I would initially prototype it as a MDAKit. Given that there are a bunch of decisions that need to be made in advance (the contents of the definition file would probably become kwargs of the transformation), it would be good to figure out how to best organize all this information and what typical workflows would look like.

Thank you for your input!
In very early implementations I have put it all the definition file into a dictionary. But from using it I have found that to be confusing both in creating it and using it. So a better solution would need to be found. I would like to keep the definitions file, given that the original paper described its use.

We'd also like to understand the performance (it's possible that the code would be best written in e.g., cython).

From early implementations I have done, purely in Python it lacks in the perfomance area really badly (specially if compared directly to the original C code). And cython would definitely be a good way of moving forward.
I thought maybe a pyhton wrapper for pure C code would be interesting as well. Nonetheless I have no idea what that would implicate in compilations on the many OS'es.

[orbeckst]

If you use the C code in any way then you’ll have to make a MDAKit under GPL. It could never go into the core library because all of it has to be LGPL compatible.

Cython is probably the easiest way forward as it’s fairly easy to make it compile on all platforms. However, other approaches may also work.

In any case, it sounds that you should consider performance in your proposal.

[FNNunes]

Dear @orbeckst,
Sorry for the time I took to respond I was so excited with writing the pre-proposal I forgot to answer you.

I have spoken with the developer of the original code, and said that if needed for the implementation of FixBox in the core MDAnalysis library, there is wiggle room to discuss a License that would be compatible with LGPL.

Best regards,
Fernando

[FNNunes]

It is with great sadness, that I am unfortunately unable to merge code in a timely fashion to the 2025 GSoC. Some unseen timelines appeared and I was unable to give the attention needed to the project. One again, I am very sorry I hope that in the future I am able to contribute to MDAnalysis!

Once again, sorry!
Fernando