Week 11: A Closer Look at the Latest PR

-

Hi everyone,

This week’s update is a little delayed, but I’ll focus here on walking you through the details of my latest Pull Request. I’ll cover the other activities separately in the next blog. 

Refactoring LSODAContext

One of the first changes I made was updating the odesystem member variable in LSODAContext. Previously, it was an object of DESystem interface, but since DESystem itself implements FirstOrderDifferentialEquations interface and also brings in methods not directly needed by LSODA (specifically for storing the ode system purpose), I switched the type to FirstOrderDifferentialEquations.

This simplifies the workflow significantly: when using SBSCL with a direct ODE system, users now only need to implement computeDerivative() and getDimension(). Everything else is handled automatically, making the integration smoother and more intuitive.

Default Tolerance Values

I added sensible default tolerances in LSODAOptions:

  • Relative tolerance (relTol): 1e-6

  • Absolute tolerance (absTol): now dynamically adjusted using an absoluteToleranceAdjustmentFactor. By default, this factor is set to 1e-12, and the absolute tolerance scales according to the entries in the state vector.

I also implemented the setRelTol() and setAbsTol() methods from the AdaptiveStepsizeIntegrator interface, ensuring greater flexibility for users to configure solver behavior.

Documentation & Usability Improvements

To make adoption easier, I introduced a howToUse.md file. This document explains the different ways the LSODA-Integrator can be used within SBSCL, complete with examples and additional notes.

Additionally, I cleaned up the codebase by removing unnecessary files such as LSODAFunctions, LSODACommonContext, and LSODAIntegrator_F, which improves overall readability and maintainability.

Enhancing the Algorithm

The most important change in this PR is the updated implementation of the computeChange() method within LSODAIntegrator. In a previous blog, I have already explained the control flow of this algorithm.

SBML Test Suite Integration

To test solver accuracy and robustness, I:

  • Wrote a wrapper class: SBMLTestSuiteRunnerWrapper_LSODA

  • Linked it with a shell script so that it integrates seamlessly with the SBML Test Suite runner.

I also added SBMLTestSuiteRunnerWrapper under the test directory, which allows running SBML Test Suite models directly from the terminal with any SBSCL-supported ODE solver such as RosenbrockSolver and DormanPrince853Solver.

System Improvements & Fixes

  • Removed unnecessary logging messages in LSODAIntegratorTest.

  • Fixed a subtle bug in softFailure() within LSODAIntegrator.

  • Added extra checks in getResult() and checkOpt() to guard against edge cases.

New Overloaded Methods

To improve flexibility, I overloaded both the prepare and lsoda methods to handle different use cases.

prepare Methods:

prepare(FirstOrderDifferentialEquations system, int ixpr, int itask, int state)
prepare(FirstOrderDifferentialEquations system, int ixpr, int itask, int state, int mxstep)
prepare(FirstOrderDifferentialEquations system, double hmin, double hmax, int ixpr, int itask, int state)
prepare(FirstOrderDifferentialEquations system, double hmin, double hmax, int ixpr, int itask, int state, int mxstep)

lsoda driver function for Direct ODE Systems:

lsoda(double[] y, double[] t, double[] tout)

I also added a few more system tests in LSODASystemTest to verify the behavior of direct ODE systems with these new methods.

That wraps up the main highlights of this PR. It introduces significant usability improvements, stronger testing integration, and important refinements to solver accuracy. Now, I'm waiting for this PR to get merged. In my next blog, I’ll share the other ongoing activities, including documentation, wiki contributions, and discussions around future enhancements.


Comments

Post a Comment

Popular posts from this blog

Week 7: Events, Exhaustion and Evaluations

-
Image
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...
Read more

My GSoC 2025 Journey Begins

-
Image
Hi,  I am Ayush Baranwal, a second-year engineering undergrad at Jawaharlal Nehru University, New Delhi, India. I am incredibly excited to share that I have been selected for the Google Summer of Code 2025 with the National Resource for Network Biology (NRNB) organization. This summer, I will be working on the project " Developing a highly efficient numerical ODE solver in Systems Biology Simulation Core Library (SBSCL). " I am incredibly thankful to my wonderful mentors, Prof. Dr. Andreas  Dräger , Dr. Akira Funahashi, Taichi Araki and Arthur Neumann, for their constant support and guidance throughout the proposal period. I am truly grateful for the trust they have put in me, and I am fully committed to making this project a success. What This Blog Series is About This blog series will document my journey throughout GSoC. Prof.  Dräger  suggested keeping a public log during our first meeting post-selection—more on that in the next blog! The goal is to keep my work ...
Read more

Week 1: Coding Period Begins

-
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...
Read more