GSoC 2025: Developing a highly efficient numerical ODE solver in SBSCL

Hi all, Okay, Continuing our story from last blog. So, after spending the past week chasing down the issue with SBML Test Suite failures (which I elaborated on in my last blog post ), I finally got a breakthrough that brought us closer to a robust and reliable LSODA integration in SBSCL. Revisiting the SBML Test Suite Challenges Previously, around 12% of the tests were failing and 2% were throwing outright errors. After narrowing the root cause down to event handling discrepancies, I spent this entire week diving deeper into tackling this challenge. Dr. Dräger shared a fantastic resource ( link ), which not only confirmed my theory but also revealed that previous developers had faced similar problems while implementing the Rosenbrock solver in SBSCL. It turns out that precise event time detection is a non-trivial challenge when dealing with SBML models. When events are triggered between timepoints (say at tτ , which lies between tτ−1 and tτ+1 ), evaluating events only at thos...

Hi all, This week has probably been the toughest one yet. Not just mentally, but also in terms of hours spent chasing bugs that I had no idea about. I’ve logged over 50 hours on the project, and ironically, there’s not much “visible” progress to show. But deep down, I know this is part of the process, and what matters is that I’ve been able to get to the root of a tricky problem, more on that below. Updates From This Week Made the PR changes suggested by Dr. Dräger and Taichi. Ran the SBMLTestSuite using the wrapper program I wrote last week. I had already shared the test results with the team on Slack. Results? Mixed bag: Passed: ~85% of the test cases (Happy somewhat!) Wrong Output: ~12–13% Error: ~2% (No idea, why?) Results Map from SBMLTestRunner So naturally, I spent the entire week narrowing down those failed and wrong output cases. And guess what? I’ve finally figured out what's going wrong in most of the wrong output cases. The Issue: Event Timin...

Hello again! Week 6 of my GSoC 2025 journey has been all about refinement, feedback, and forward momentum . I finally opened my long-standing pull request with the work done over the past three weeks. Here are more details around it. The Pull Request On July 7th, 2025 , I submitted a pull request that encapsulated all the major changes and improvements I’ve worked on since Week 3. This included: The updated LSODA package A clean interface supporting both SBML input and direct ODEs Multiple system-level tests for validation Detailed exception handling for edge cases Detailed method-level docstrings  Once opened, the PR served as a starting point for deeper discussions with my mentors — not just about what’s working, but how things can be made even better. SBMLTestSuite: Building the Test Bridge As part of verifying LSODA’s reliability in a broader context, I started my work on testing the solver against the  SBML Test Suite . I read the documentation and l...

 Hi readers, This week marked a subtle shift in focus — from writing core components to understanding and aligning LSODA with SBSCL’s broader infrastructure. It wasn’t my most productive week in terms of code commits, but it was certainly rich in learning and architectural clarity . Understanding SBML The week began with me diving deep into SBML (Systems Biology Markup Language) — not just from a theoretical perspective, but also to understand how it flows through SBSCL. I read the document shared by Dr. Funahashi  (translated it to English from Japanese first, thanks to Google Translate). I also watched the  video shared by Dr. Dräger . Both were really helpful. I explored SBMLSimulator , which provided concrete examples of how SBML models are parsed and simulated. Thanks to these resources, I finally got a clear picture of how: SBMLInterpreter   parses the SBML file and constructs the mathematical model. Multitable stores the simulation results and pr...

Hi readers, It’s week 4 of my GSoC journey, and this week was all about building bridges — between code and interface ,   and initial testing . As I move from core algorithm development into integration, things are getting both more exciting and more layered. What I did this week? After completing the lsoda driver function last week, I began working on the integration mechanism — i.e., how users will interact with the solver, and how models will be parsed, solved, and tested. Here’s what I’ve done so far: I implemented the computeChange abstract method which is the go to method for AbstractDESolver for solving the ODE systems. It is the single most important method for the integration mechanism. I created a new test class LSODASystemTest , specifically to validate how LSODA handles various   ODE systems  and error scenarios in an end-to-end manner. I’ve designed the LSODA solver to work in two different modes : Direct ODE system input – where users can d...

Hi readers, Today, I’m feeling the calm after a storm—serene, but only after some serious turbulence. And yes, I have some great news to share. As you know, this week I focused on implementing the  lsoda driver function . But what I didn’t expect was the wild debugging journey it would take me on. So... Fasten your seatbelts—and lets dive right into it. The Plan: Refactor and Implement  I started the week by refactoring the lsoda() driver function block by block, and designing three supporting methods: allocMemory() lsodaFree() lsodaPrepare() For  allocMemory() , after much thinking, I decided to use a constructor-like approach  to initialize all necessary LSODACommon variables. This function is called via lsodaPrepare() at the beginning of any solve operation, with the required arguments. For lsodaFree() —thanks to the JVM's garbage collector , I didn’t need to do anything explicit. Yay, Java! Feeling optimistic, I wrote two integration tests: a line...

Hi everybody, It's that time of the week again —here’s my latest update on the progress I’ve made. Let’s dive right into it! What I did this week As I mentioned in my previous blog , this week’s focus was on implementing the two helper functions: methodSwitch() and orderSwitch() functions, which is what I did.  Here's the link to the PR involving this : Pull Request Here’s a quick summary: Implemented the methodSwitch() and orderSwitch() functions. Added detailed docstrings for both to enhance readability and future maintainability. Refactored the stoda() method to include calls to these helpers where necessary. Developed and added unit tests for both methods to ensure correctness and coverage. Meeting with Mentors This week I had two meetings.       1-on-1 with Arthur – June 10, 2025 Arthur and I finally had our long-overdue 1-on-1 call! We’d been planning this since the application phase, but it kept getting postponed—so it was nice to finally cat...

Hi everyone, The official coding period has now begun, and I've diving deeper into the LSODA internals. Continuing from the last blog post, I focused primarily on refactoring helper methods within the LSODA package, while also  setting the foundation for a robust and modular design.   After reading some of the core literature on LSODA, I decided to examine the libLSODA codebase—the C library of LSODA translated from its original Fortran implementation in ODEPACK. My first step was to outline the overall program flow of the LSODA algorithm , which helped me visualize where and how different components fit together.   Upon exploring the main lsoda function, I chose to start by implementing and refining the helper functions , as they form the building blocks of the algorithm. I thoroughly reviewed the SBSCL LSODA implementation so far and identified areas for improvement. Here's a more detailed  explanation of my work ( PR ),  followed by wha...