Week 10: Starting Documentation and Polishing LSODA-Integrator

-

 Hi everyone,

This week was about moving from testing to outreach and deeper documentation.

  • I wrote a document for the SBSCL Wikipedia update, and incorporated suggestions from Dr. Draeger.
  • I added a default relative and absolute tolerance values for LSODA-Integrator, after discussing it with my mentors. 
  • We also agreed that some legacy files like LSODAFunctions and LSODACommonContext can now be removed.
  • I have now sent the announcement emails to relevant mailing lists.
  • I have now created a Pull Request with code from the testing phase, which primarily includes SBMLTestSuiteRunner wrapper and some documentation files along with few more changes to improve the readability.

We talked about the next major step which is writing detailed HTML documentation for LSODA, matching the style of SBSCL’s other solver docs.

What’s Next

  • Finalize and publish the updated SBSCL Wikipedia entry.

  • Write comprehensive HTML documentation for LSODA-Integrator.

  • Polish the codebase.

The LSODA-Integrator is now nearly complete from a functionality standpoint — the focus is shifting toward making it easy to use, easy to find, and well-documented for the community.

Till next time,
Bye! đŸ‘‹

Comments

  1. Lucian Smith11 August 2025 at 13:02

    In my work with assessing reproducibility of simulators across curated Biomodels, I discovered that default *single* absolute tolerance values are often inadequate. It turns out to be much better to have what we now call an 'absolute tolerance adjustment factor' which is converted into a vector of absolute tolerance values by multiplying by the initial value of all non-zero entries in the 'state vector' (all the values that the solver is solving for). For values with an initial value of zero, you just use the absolute tolerance adjustment factor directly. This is what COPASI did and what Roadrunner now does behind the scenes, and it made them both able to get reasonable values for simulations where before, roadrunner would fail and give nonsensical results.

    ReplyDelete
    Replies
    1. Ayush Baranwal12 August 2025 at 02:38

      Thank you Lucian for sharing this.
      Yes, I completely agree with you that having a vector of tolerances is much better than a single default tolerance value. Actually, we have already implemented a way where users can provide state vector specific tolerances (for both relative and absolute tolerances) while running simulations. You can see this document (https://github.com/baranwalayush/SBSCL/blob/testing/src/main/java/org/simulator/math/odes/LSODA/howToUse.md), refer to the 4th point under the usage with SBML models.
      Your point about the `absolute tolerance adjustment factor` for the default values sure is better, especially in the case of vast differences between state vector entries and I would be more than happy to implement something similar for the default case within this project.

      Delete

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