GSoC 2026: Query related to Project 1 for full proposal

[tani-dubey]

Hello, I have been working on full proposal for project 1: Dashboard for tracking MD simulation progress with the new streaming interface and I now have a near-final draft ready.

Before submitting, I wanted to clarify few things -

1. Project Scope (175 vs 350 hours)
Would you recommend keeping the scope as a 175-hour project or 350-hour project by adding the additional requirements mentioned in the projects description ( adding advance visualization, extended analysis support etc).

2. Error handling approach
In case the simulation crashed unexpectedly, I thought of:

• notifying the frontend
• storing partially calculated results in disk or Database.

Is this a good approach, or would you suggest a simpler strategy?

3. Handling frame vs analysis speed imbalance

I am thinking of these ways to deal:

• fixed interval sampling (processing only nth frame)
• adaptive interval based on analysis workload.

Which of the above do you prefer?

Thank you for your time and guidance!

[BradyAJohnston]

EDIT: Apologies - closed pre-emptively without checking that you had already submitted a pre-prposal!

The project scope can be changed part way through, but it's worth thinking about it and whether you'll want to try and work on the more advanced components. If the scope is looking larger than aiming for 350 hours is the way to go. The other points I am less versed with so defer to the expertise of others.

[tani-dubey]

Thank you for the clarification!

Based on this, I will expand my proposal towards a 350-hour scope, while ensuring that the core streaming and analysis system is completed in earlier phase.

[orbeckst]

Our project suggestions are just suggestions. You can expand to 350h. As for any proposal, the work you want to do should make sense for the allocated time. It's not always easy to figure out the scope but it's generally worse if you try to do too much. We want finished projects!

The work scope also needs to work with the rest of your life: For instance, if you work 8h per day only on GSOC, then 350h is 43.75 days or 8.75 weeks of solid work (5 work days per week). Project length can be 8-22 weeks, 12 weeks being the default. This means, during the default project length, you're spending ~73% of your work-week on GSOC. If that is not possible, then project cannot be 350h or you need to ask for an increase in project length by consulting with the mentors.

[tani-dubey]

Hi @orbeckst,
Thank you for the clarification, that helped me understand the expectations better.

I’m currently planning my proposal as a 350-hour project, but I also want to make sure that the workload remains realistic alongside my academic commitments. Based on this, I was considering structuring the project over an extended timeline (~ 20-22 weeks).

Would this be acceptable for this project or would you prefer that I adjust the scope to fit within 12-week period?

[orbeckst]

2. Error handling approach

Informing the user that a simulation that was supposed to be running is not running is important. I don't know if you can easily distinguish if it crashed or if it completed. The IMDv3 stream can shutdown when the MD code closes the socket and then imdclient raises an EOFError (see the IMDv3 protocol; the socket can be closed when the simulation finishes or when it crashes. Alternatively, a crash can lead to a lack of packages in the stream, and then imdclient ends after a timeout period (by default, currently 5 seconds, see IMDClient and also see issue Becksteinlab/imdclient#111 / PR Becksteinlab/imdclient#120 for ongoing discussions to extend this value to 600s).

If you are trying to connect to a port and nothing is answering then you don't know if the MD code crashed or finished cleanly.

storing partially calculated results in disk or Database.

I am not sure if this is needed for the crash scenario. If you generally want to provide some previous context when someone is reconnecting to a running simulation then it may be nice to be able to display the last N frames — that might be a nice feature.

[orbeckst]

3. Handling frame vs analysis speed imbalance

Start simple :-), which means fixed interval sampling. You can then always build something fancier as a stretch goal.

---

As a general principle for proposal writing: propose something that will work, then show how you could improve it if you have the time.

[amruthesht]

2. Error handling approach In case the simulation crashed unexpectedly, I thought of:

• notifying the frontend
• storing partially calculated results in disk or Database.

This behavior should be driven by how imdclient handles such situations. Right now, it would usually terminate the connection but continue to process the frames present in its internal buffer. Small correction to what @orbeckst mentioned, the timeout flag doesn't come into play here but the client will get a EOFError and the try to shut down normally. It would be good addition to have error parsed from imdclient and shown to the user.

3. Handling frame vs analysis speed imbalance

I am thinking of these ways to deal:

fixed interval sampling (processing only nth frame)
adaptive interval based on analysis workload.

As mentioned previously, it would be ideal for the dashboard system to handle any fixed streaming interval as set by the user when running the MD/simulation engine. Modifying or increasing that interval would defeat the purpose of streaming in certain cases.
I would suggest you to think more about how your dashboard interfaces with imdclient/MDAnalaysis and also how these packages themselves handle scenarios of speed imbalance.

[tani-dubey]

Thank you for the clarification!
I'll rethink about speed imbalance handling and focus on approaches that work with how Imdclient/Mdanalysis handle buffering and frame iteration.

I'll update my proposal accordingly.

[amruthesht]

I'll rethink about speed imbalance handling and focus on approaches that work with how Imdclient/Mdanalysis handle buffering and frame iteration.

As for the speed imbalance handling, it would be okay for the user to adjust the analysis sampling interval (using a fixed/adaptive scheme) via the dashboard - if that is what you meant. However, frames must still be available (for processing/analysis if needed) via streaming at the fixed streaming interval specified by the user when running the MD engine.

[tani-dubey]

I have updated my full proposal based on the feedback and submitted it on the GSoC portal. I would really appreciate it if you could review it and share any further suggestions.