Skip to content

Conversation

@pnbabu
Copy link
Contributor

@pnbabu pnbabu commented Sep 24, 2025

The predefined functions ln() and log(), when used in the equations block in the ODEs, result in a compilation error when a numeric solver is selected.

Currently, the ln() function is passed as log() to the ode-toolbox, which results in the error. According to the sympy docs, log has an alias ln(). Thus, replacing log with ln in the ode-toolbox printer fixes the error.

@github-actions
Copy link

github-actions bot commented Sep 24, 2025

🐰 Bencher Report

Branch1250/merge
Testbedubuntu-latest

🚨 1 Alert

IterationBenchmarkMeasure
Units
ViewBenchmark Result
(Result Δ%)
Upper Boundary
(Limit %)
0tests/nest_continuous_benchmarking/test_nest_continuous_benchmarking.py::TestNESTContinuousBenchmarking::test_stdp_nn_synapseLatency
seconds (s)
📈 plot
🚷 threshold
🚨 alert (🔔)
3.84 s
(+12.86%)Baseline: 3.41 s
3.75 s
(102.60%)

Click to view all benchmark results
BenchmarkLatencyBenchmark Result
seconds (s)
(Result Δ%)
Upper Boundary
seconds (s)
(Limit %)
tests/nest_continuous_benchmarking/test_nest_continuous_benchmarking.py::TestNESTContinuousBenchmarking::test_stdp_nn_synapse📈 view plot
🚷 view threshold
🚨 view alert (🔔)
3.84 s
(+12.86%)Baseline: 3.41 s
3.75 s
(102.60%)

BenchmarkLatencyBenchmark Result
seconds (s)
(Result Δ%)
Upper Boundary
seconds (s)
(Limit %)
tests/nest_continuous_benchmarking/test_nest_continuous_benchmarking.py::TestNESTContinuousBenchmarking::test_stdp_nn_synapse📈 view plot
🚷 view threshold
🚨 view alert (🔔)
3.24 s
(-4.60%)Baseline: 3.40 s
3.74 s
(86.73%)

BenchmarkLatencyBenchmark Result
seconds (s)
(Result Δ%)
Upper Boundary
seconds (s)
(Limit %)
tests/nest_continuous_benchmarking/test_nest_continuous_benchmarking.py::TestNESTContinuousBenchmarking::test_stdp_nn_synapse📈 view plot
🚷 view threshold
🚨 view alert (🔔)
3.21 s
(-5.38%)Baseline: 3.40 s
3.74 s
(86.01%)

🐰 View full continuous benchmarking report in Bencher

@clinssen
Copy link
Contributor

clinssen commented Oct 2, 2025

Either log10 or ln should be used to avoid ambiguities about the base (see https://nestml.readthedocs.io/en/latest/nestml_language/nestml_language_concepts.html#predefined-functions). Does using log in a NESTML model (without a custom NESTML model function log being defined) not result in an error?

@pnbabu
Copy link
Contributor Author

pnbabu commented Oct 17, 2025

Either log10 or ln should be used to avoid ambiguities about the base (see https://nestml.readthedocs.io/en/latest/nestml_language/nestml_language_concepts.html#predefined-functions). Does using log in a NESTML model (without a custom NESTML model function log being defined) not result in an error?

The model has an ln() function, which gets translated to log while sending to ode-toolbox. The ode-toolbox returns the function as log as well. I checked that we do not have any models till now that use an ln() or log10() function inside the equations block. It is either used in the internals or the update block, or inside a user-defined function.

When the solver returned by the ode-toolbox is analytic, we do not see this error because the printers print the function as log, which is compiled by the C++ compiler. Whereas in the case of a numeric solver, the log is appended to the node. string, which results in a compilation error. Basically, the PredefinedFunctions check doesn't hold good here, as the function log doesn't match with ln or log10.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants