GSoC 2025: High level structure to start with

[PardhavMaradani]

Hi @BradyAJohnston and @yuxuanzhuang ,

I will get started with the GSoC 2025 project tomorrow when the official coding begins. Here is a high level structure I had in mind to start with. Could you review these and let me know if this is ok.

Base class for MDAnalysis visualization

Following upon Yuxuan's idea of having a separate base class for MDAnalysis visualization (similar to how it is in ggmolvis), which can be extended upon, I was thinking of something like the following:

from molecularnodes.mda.base import MDAVis

vis = MDAVis()

This way, all the MDA related stuff will reside in the mda folder namespace. Similar to how other classes in MN are pulled up, this will also be accessible in any of the following ways:

from molecularnodes.mda import MDAVis

from molecularnodes import MDAVis

import molecularnodes as mn

vis = mn.MDAVis()

Having a high level class like this will allow APIs for top level universe management as well like:

vis.list_universes()  # To list universes
vu1 = vis.add_universe(... # To add a universe
vu2 = vis.get_universe(... # To get a universe object
vis.delete_universe(... # To delete a universe
vis.universes[... # Both subscriptable and iterable universes data (similar to bpy data)
...

in addition to universe level APIs for styles, annotations, components etc later. This will also keep the API structure in sync with the GUI (see below). Extending the Trajectory class (like what OXDNA does) or directly working with the Trajectory class will not allow all of the above and will be limiting.

Separate namespace for Blender property data

As described in the proposal, all data will reside in Blender properties, which is required for the GUI and will keep both APIs and GUI in sync.

I was thinking of having a separate mda namespace for MDA vis related properties. For example:

bpy.types.Scene.mn.mda.[...] # For scene level properties (like universes, etc)
bpy.types.Object.mn.mda.[...] # For object level stuff (i.e., within universe)

This will make it easy to manage and have a clean hierarchy that matches the UI.

GUI structure

Along the lines of the prototype as seen here:

I was thinking of creating a new MDAnalysis tab in the n-panel (in the 3D viewport) starting with the universes and then adding trajectory, styles, annotations etc as we progress. I intend to get started and build the GUI at the same time as the APIs.

PRs into main branch?

As seen above, the GUI will slowly evolve over time along with the APIs. With this in mind, are you ok with PRs to the main branch or do you want to create a separate gsoc branch? I am fine either way.

---

Can I start with the approach outlined above? Please let me know if you have any thoughts, feedback or changes you'd like to see. Thanks

[BradyAJohnston]

I like the description and idea for the universe manager, same with the name-spaced properties. Better name spacing of properties is something that I could look at doing for more inside of MN as well.

For PRs, I think a GSoC branch for new developing UI. Anything that is more general could go into main and once the UI is 'stable' it could go into main as well.

[BradyAJohnston]

I'll create a GSoC branch that you can point the PRs to. If we get to a somewhat stable / mature place then we can merge into main and you can continue pointing PRs there.

For example notebook files, currently I have a few already and they exist as Quarto .qmd files. They remain a simple text file for git purposes, but can be rendered into html via a .ipynb. They can live under the api/ folder. I'll create an example file when I create the branch / PR.

[BradyAJohnston]

Having them as .qmd ensures that that the file is executed each time the docs are built as well, which act as another layer of tests to ensure the reported API is still working.

[PardhavMaradani]

Having them as .qmd ensures that that the file is executed each time the docs are built as well, which act as another layer of tests to ensure the reported API is still working.

Hi Brady, do these have to be as .qmd files? If they are as .qmd files, I am unable to open them in Jupyter Lab. They also seem to recommend using .ipynb (in the first paragraph) so that Jupyter Lab can be used as an editor. Even these seem to get executed during build (depending on the notebook options). So, can I use .ipynb files as is?

[BradyAJohnston]

Happy for them to be .ipynb for convenience, as long as they are still freshly executed when the docs are rendered.

[BradyAJohnston]

Some of the more complex notebooks where you are interacting with a Blender session might not be able to be executed so that's understandable but when possible I'd like to make sure everything is re-rendered each time.

[PardhavMaradani]

Closing this to continue further discussion as part of PR #877 review

[PardhavMaradani]

I am re-opening this discussion because of the changes to what we agreed upon at the beginning of this discussion initially and to keep this up to date.

From the comments in #877, we want to go the MNSession and Trajectory route.

I will make the following changes:

• Add a add_trajectory method to MNSession - this will at least make it a single step process to add a trajectory
• Add a delete_trajectory method to MNSession - to delete by trajectory instance or name
• Trajectory listing is already available under the trajectories property in MNSession, so I will not add any new method for it
• Add a get_trajectory method to MNSession - to get a trajectory instance by the trajectory name (same as object name)
• Adding a trajectory is already available in the MN UI under the Import tab, so I will not add anything new
• Trajectories are already listed in the Session tab, so I will not add anything new. The remove is currently broken, so I will fix it

Please let me know if I can go ahead with the above. Thanks

[PardhavMaradani]

We cannot store arbitrary object data in Blender properties (unless they are converted to strings, which is not ideal). So, I think we need picking if we need to restore our entity objects and what we have now seems to work well.

I tried fixing the issues I mentioned in the previous post and now added a UI listing of entities in a new panel in the 3D viewport. I left the Session tab as is and instead used this new panel for the UIList of entities as it seemed more natural and what you wanted for styles as well (similar to my previous examples).

All the entities are currently listed, instead of breaking them up into separate sections - this seemed more natural and we could later have filtering etc if needed. The context of the panels below them depend on the entity type. I disabled the add button because I wasn't sure if we want to duplicate the add functionality - I can remove it based on your feedback. The delete etc is reusing the same operators.

Here is a quick video that shows this in action:

entities-gui.mp4

I created PR #887 which has these changes. Could you please review and let me know if you have any feedback.

[BradyAJohnston]

Just add a comment to the PR, but the demo is looking good.

[BradyAJohnston]

We can probably also remove the session tab that already exists. I created that a while back before I knew how to handle UILists properly. If you wanted to remove that tab as part of this PR I'd be happy with that also.

[PardhavMaradani]

About the Session tab, it still seems to have some value because it has a create object operator available for cases when the object is missing etc. Entities are also grouped together. I don't want to remove any existing functionality at this point. Maybe we could review at a later time after more progress and then make a call - hope that is ok.

[BradyAJohnston]

Yep totally fine to leave for now. Will address in future design and PRs.

[PardhavMaradani]

Closing this discussion as #882 and #887 are merged.