Dear Stelios, Thank you for your interest in OpenTRIM. Hope you had a smooth experience building the project! We will be happy to receive your application for GSoC 2026. Regarding your questions. For the Python bindings, I think that wrapping the mcdriver class as you suggest would be an ideal 1st step, so that one can setup and run a simulation from within python. There are many ways that we could proceed from there to a more advanced solution. We could discuss further if you are interested. For the 3D visualization, ideally we would like to have a Qt-based OpenGL window (using e.g. QOpenGLWidget or Qt3D) that displays the simulated volume with the ion tracks, using color coding or other means to display dynamically the particle type, energy or other relevant information. The aim is to have a visual tool to help the user (a) debug their simulation model, and (b) create interesting visualizations for dissemination. Please write directly to my email to discuss further. Best regards George Apostolopoulos On Tue, 2026-03-03 at 21:34 +0200, Stelios Synolakis wrote: Dear George, Michail and Eleni, My name is Stelios Synolakis, and I am a 4th year undergraduate Computer Science student at the National and Kapodistrian University of Athens with interest in simulation software. I recently explored the OpenTRIM repository and the proposed GSoC project, and I would be very interested in contributing. In terms of background, I have experience in modern C++ (including multi-threaded systems), numerical and data-intensive workloads, and OpenGL. I also have experience with Python in the context of machine learning and data analysis. Additionally, I worked on a complex join-pipeline optimization project inspired by the SIGMOD programming contest, which involved performance-oriented C++ design and careful data management. Over the past few days, I have built OpenTRIM from source, run some of the provided benchmark examples (e.g., 2 MeV Fe on Fe), and taken time to study the architecture of the codebase. In particular, I examined the interaction between mcconfig, mcdriver and mccore, as well as the HDF5 output structure and event/tally system. I found the separation between configuration handling, the Monte Carlo core, and I/O particularly clear and thoughtfully structured Before moving further, I would greatly appreciate your perspective on how you envision the Python bindings and real-time visualization components integrating with the existing architecture. For example, would you prefer the Python interface to primarily wrap mcdriver and rely on the existing HDF5 output for post-processing or do you see value in exposing parts of mccore (such as tallies or event streams) for more direct in-memory interaction? Regarding visualization, do you imagine extending the current Qt-based GUI? I would like to align my early exploration and potential contributions with your expectations so that I can focus on the most meaningful direction from the beginning. If there is a preferred communication channel for discussing development ideas (a Discord server, GitHub discussions, or another platform), I would be happy to join and continue the discussion there.Additionally, if there is a small task or issue that would be helpful for me to work on at this stage, I would be glad to start contributing right away. Thank you very much for your time and consideration. I look forward to your thoughts. Best regards, Stelios Synolakis ---- Λαμβάνετε αυτό το μήνυμα απο την λίστα: Λίστα αλληλογραφίας και συζητήσεων που απευθύνεται σε φοιτητές developers \& mentors έργων του Google Summer of Code - A discussion list for student developers and mentors of Google Summer of Code projects., https://lists.ellak.gr/gsoc-developers/listinfo.html Μπορείτε να απεγγραφείτε από τη λίστα στέλνοντας κενό μήνυμα ηλ. ταχυδρομείου στη διεύθυνση <gsoc-developers+unsubscribe [ at ] ellak [ dot ] gr<mailto:gsoc-developers+unsubscribe [ at ] ellak [ dot ] gr>>.
---- Λαμβάνετε αυτό το μήνυμα απο την λίστα: Λίστα αλληλογραφίας και συζητήσεων που απευθύνεται σε φοιτητές developers \& mentors έργων του Google Summer of Code - A discussion list for student developers and mentors of Google Summer of Code projects., https://lists.ellak.gr/gsoc-developers/listinfo.html Μπορείτε να απεγγραφείτε από τη λίστα στέλνοντας κενό μήνυμα ηλ. ταχυδρομείου στη διεύθυνση <gsoc-developers+unsubscribe [ at ] ellak [ dot ] gr>.