Misinterpretation of function variables with parameters

[hemilpanchiwala]

This issue occurs when the bvars defined in the FunctionDefinition of the model are same as the defined ids for the parameters. The simulator misinterprets the function variables as the parameters and calculates the results by considering the values of the parameters.

This issue is encountered while running the SBML L3V2 model of the 1492 test case from the SBML Test Suite. Similar is the issue for the test case 1493.

In the test case 1492, function with id my_piecewise is defined as piecewise(x, y, z) where x, y, and z but simulator misinterprets them with the parameters defined with the same id.

Below is the screenshot of the result from the simulator for test case 1492 where z simply takes the value of parameter x (instead of some defined formula) as piecewise(x, y, z) => x if y > 0 else z.

[dyrpsf]

Hi @hemilpanchiwala, @funasoul, @draeger,
I’d like to work on this issue if it’s still open. I’ve gone through the problem description and the SBML test cases (1492/1493), and I believe I can help investigate and fix the variable–parameter name resolution issue in the function definition handling.

If it’s okay, please assign this issue to me. Thanks!

[dyrpsf]

Hi @hemilpanchiwala, @funasoul, @draeger,
I’ve opened a pull request to fix this issue: #96

The PR updates ASTNodeInterpreter so that when evaluating a FunctionDefinition, the function arguments (bvars) are stored in funcArgs before the function body is evaluated. This ensures that identifiers inside the function body correctly evaluate to the argument values, even if there are global parameters with the same ids. The previous funcArgs mapping is restored afterwards so nested function calls remain safe.

[draeger]

Excellent, thanks for the effort, @dyrpsf!

[dyrpsf]

Thank you very much for the kind words and the review, @draeger!

I’m really enjoying working on SBSCL and would like to keep contributing. I’m also a GSoC aspirant and was wondering whether this project (or the wider draeger-lab ecosystem) is likely to participate in GSoC 2026.

If you already have any rough plans or suggestions on how I could best prepare (e.g. particular areas of the codebase to focus on, types of issues to work on, or documentation to read), I’d really appreciate your guidance. In any case I’ll continue picking up issues and learning more about the library.

[draeger]

Thanks, @dyrpsf. I like how you split the function now and reduced redundant code to a minimum. I'll debate with contributors what the SBSCL project could be designed. A new SBML package for more sophisticated stochastic simulations is in development. SBSCL could provide a simulation facility for it early on, just as a thought. There are still other areas for improvement in this library as well.

[dyrpsf]

Thanks a lot, @draeger — I really appreciate the feedback!

The idea of a new SBML package for more sophisticated stochastic simulations sounds very interesting, and I’d be excited to help with that or with other improvements to SBSCL.

In the meantime I’ll keep looking for open issues to work on in this repository. I’m planning to apply for GSoC 2026 and would really like to continue contributing in a way that prepares me well for that.

If you (or colleagues you work with) mentor in any GSoC organisations — including SBSCL, if it ends up participating — I’d be very grateful for any pointers or suggestions about where I could get involved and what I should focus on.