Optimize molecule class

[kainszs]

As described in the issues #454 and #459, the molecule class can be optimized and unified with the AtomGroupInBlender class.

Goals:

• clean up s. Molecule class implementation #454
• write molecule class, with atomarraystruc as data object
• write molecule class, with mda.atomgroup as data object
• write MoleculeInBlender class

Further steps:

• test implementation
• optimize code, reduce redundancies
• integrate in code base

Regarding the Molecule class. Currently when structures are imported, a 3D model is created inside of Blender. The idea is that the Molecule will contain information about the file that this model came from, and provide an interface that the user can change the associated style and edit the underlying information of the structure through this class. The currently existing python API isn't setup well for interacting with molecular structures, or changing the Geometry Nodes tress that are associated with the models. The class will hopefully provide a neater interface for loading, editing and styling the model, in a way that is nice to script with inside of a Jupyter Notebook or similar script.

Originally posted by @BradyAJohnston in #459 (comment)

[kainszs]

@BradyAJohnston would you assign the issue to me?

[BradyAJohnston]

I just opened a PR with a new feature for 'live' MDA selection strings that update on each frame change in Blender #466

This is the sort of thing that I envision for adding more connections between Blender and the MDA Universe underneath, to enable more user-friendly interaction with it.

[kainszs]

That looks very cool. How does the data twin (#455) play into this? I would also like to implement it. Because that fits in with the molecule class.

I am currently working my way deeper into the existing code base and in my opinion, it would even make sense to have Molecule class from the code structure and a MoleculeInBlender class.

So far, all molecules that are parsed inherit from the molecule class, which is also an object in blender. What seems problematic about this is that different frameworks are used to read the different structure data and the data in the molecule object is duplicated. There seems to me to be no clear way to write the python methods. I therefore suggest that I implement a molecule class from which all parsed molecules inherit. This can then be converted into a blender object (MoleculeInBlender). This way we have a clear, concise workflow that allows us to treat all molecule objects the same, even if they come from different frameworks. If we write it well, this also includes the molecules from the MDA session.

What do you think? @BradyAJohnston @rbdavid

[rbdavid]

Firstly, my understanding of MN may be flawed so I defer to Brady.

But, the MoleculeInBlender class you are describing is already implemented as the bpy.types.Object created from the Molecule object. This blender object has data associated with the structure stored in verts and edges associated with atoms and bonds. These verts/edges are used to draw the meshes seen in the Blender viewport. The (bio)physical/chemical information associated with verts/edges are stored as attributes. In my analogy to a "data twin", the Blender object is the visualization twin so adding a MN class for MoleculeInBlender isn't necessary.

What I think deserves a bit more attention is dynamically updating/adding/deleting attributes based on (bio)physical/chemical information that is not feasibly implemented within a Blender object. The nature of attributes in Blender is fairly rigid as I understand it. For example, I want to visualize the solvation shell around an atom or molecule, which may change over a trajectory or when considering different atom selections. Blender attributes can't handle poorly-shaped data; really any data that does not fit into these data types. Instead, the "data twin" would be a data structure (in my opinion, a MDA Universe object) that can access more complex biophysical information, such as atom selections based on distance or radius. Then, a simple Boolean attribute field can be added to the Blender object and geonodes can be used to visualize that attribute. Brady is already halfway there on this front with #466!

[kainszs]

Thank you very much for taking the time to reply. @rbdavid

The oop approach in the PR #469 would enable intuitive handling of the Molecule objects in Blender.

mol = PDB._get_structure("tests/data/1cd3.pdb")
mib = MoleculeInBlender.from_molecule(mol)
mask = mol.sec_struct == 2

To apply the boolean mask you can either create a new molecule in blender:

mib = MoleculeInBleder.from_molecule(mol[mask])

or you apply the boolean mask directly to the molecule in Blender.

Through the getter and setter it also enables eg:

mol.coord = <some coords>

[kainszs]

Good morning,

Today I wanted to try my hand at unifying the AtomGroupInBlender class with the Molecule class. I noticed that the AtomGroup in MDA is very different from theAtomArrayStruc in Biotite. You want to strengthen the connection to MDA and include its analysis classes.

Right now the data object of the molecule class is still an AtomArrayStruc, but a universe seems more universal to me, but more cumbersome. At the moment, I can imagine two solutions:

1. We rewrite the molecule class into an MDA universe/atomgroup,
2. We write a second molecule class for MDA, which can be converted into MoleculeInBlender and from there to a molecule with an AtomArrayStruc and vice versa. In this way, we would make the functionality available to every molecule without the dependency on MDA.

[BradyAJohnston]

@kainszs Uniting import under a single parsing backend (all via MDAnalysis, rather than MDA / biotite), but MDAnalysis is missing some crucial functionality like reading .cif / .bcif / .mmtf, parsing biological assembly information and other general-purpose information from structure files. MDA is purpose-built for molecular dynamics trajectories, and biotite is a more general-purpose parser which gives access to secondary structure information / biological assembly information etc).

I don't think it would be possible to truly merge the two, a static cystral structure is exactly that (static) while the MDA universe is intended for a trajectory that can play back and change over time.

There would be potential for parsing a structure with biotite and then manually building a mda.Universe with the correct information, but I don't know if that would be the right approach.

I think the best approach would be altering / improving the MDA class implementation to better unify it with what ends up being the Molecule implementation. I think they should maybe still be different due to the different nature of the data underneath, but I'm sure they could share a lot of functionality.

[BradyAJohnston]

I'm wary of 'reinventing the wheel' though with this kind of approach at trying to unify them. It might be best just to be explicit that depending on the data type you are using, you interface with a completely different class and users can refer to documentation for biotite / MDA for technical implementations.

Open to suggestions and feedback from others around what might be best

[kainszs]

I agree with you that the 1st approach would miss the mark, but the 2nd merely restructures the existing code with the aim of getting more functionality.

[BradyAJohnston]

The second suggestion to have a similar 'Molecule' class for the MDA data I can see working. I don't think we should try to convert one data format to the other, but unifying the inputs could certainly work like you suggest.

[kainszs]

If you like the idea, I would work out a proposal for the mda class.

Then we can see how things go from there.

[kainszs]

Good morning,

why do you create a scene during the initialization of the MDAnalysisSession and not for PDB? Could other molecules also benefit from the functionality of the MDAnalysisSession?

[BradyAJohnston]

We aren't 'creating a scene', but Blender has a scene that scene that is always around, and is where the user is working. When the MDAnalysis session is loaded, it is appended to the scene, so that it is still accessible after the operator / function which created it is over. This allows for the session to be maintained and new coordinates to be updated as the frames changed.

A similar setup hasn't been a requirement for the static structures as most of the information is loaded into the scene in the form of 3D geometry, so the original files weren't required. It could still be useful to have a similar setup though, so that the Molecule class that is created can be maintained and can be accessed for different needs.

[kainszs]

Hi,

I wasn't selected for GSoC, but would you like to pursue the idea further? Otherwise I will close the Issue.

Best regards