GSoC 2026: Interest in Performance Profiling for Mechanics Equations of Motion

[shuvro bhattacharjee]

 My name is Shuvro Bhattacharjee. I’m a 4th-year Computer Science and Engineering student from Bangladesh, and I’m very interested in contributing to SymPy for GSoC 2026.

 I’ve been exploring the project ideas and the one that stands out to me is "Classical Mechanics: Efficient Equations of Motion Generation." I’m particularly interested in this because it combines my background in Python with my interest in performance optimization.

 I’ve been experimenting with the solver and noticed that some expressions (like those with high-degree float exponents) can take a long time to process. It made me curious about how we can use profiling to find bottlenecks in the Mechanics package, especially when generating Kane's or Lagrange's equations.  

Also I’ve been looking into the sympy.physics.mechanics module and how it handles Kane’s and Lagrange’s methods.

I would appreciate your guidance on how best to get started.

Thank you for your time . I look forward to contributing to Sympy.

  Best regards, 

  Shuvro Bhattacharjee  

1. Best regards,
   Shuvro Bhattacharjee

1. Best regards,
   Shuvro Bhattacharjee

[Peter Stahlecker]

I am a user of sympy.physics.mechanics, Kane's method only.

Just curiosity: you say, you have been experimenting with the solver.

What do you mean by solver?

Thanks1

[shuvro bhattacharjee]

" Hi Peter, thank you for the question! , by 'solver' I meant the high-level sympy.solve() function. Specifically, I’ve been investigating performance bottlenecks when equations contain floating-point exponents.

I recently opened an issue (#29180) regarding solve() hanging on expressions like $x^{5.43}$. I found that the 'hang' occurs because SymPy converts these to very high-degree rationals and attempts expensive symbolic factorization (Zassenhaus/Hensel lifting).

While my issue was noted as a duplicate of #11493, seeing this bottleneck firsthand is what motivates my interest in 'Efficient Equations of Motion Generation.' In multibody mechanics, empirical force models often use such exponents, and I want to ensure the Mechanics package can handle or bypass these core symbolic limitations to remain performant."

[peter.st...@gmail.com]

I am unaware of sympy.physics.mechanics Kane’s method using solve to set up the symbolic equations of motion for multibody systems. (no idea about Lagrange)

Of course I may be wrong.

Did you see any code where solve is used?

 

Peter

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sympy/86c58776-4b5d-4794-be18-440245e59dd5n%40googlegroups.com.

[shuvro bhattacharjee]

Thanks for correcting me.

my earlier mention of solve() was based on a separate line of experimentation I was doing outside the Mechanics module, where I encountered performance issues with expressions involving floating-point exponents. That investigation helped spark my interest in performance bottlenecks in symbolic workflows. 

and i also spent some time digging through the source code for both kane.py and lagrange.py to better understand  and found  both methods avoid sympy.solve() during equation generation   also verified that both default to LUsolve for the linear systems.  

If you have any suggestions on specific classes or types of systems .where you've noticed the most "hang," that direction would be incredibly helpful for my profiling.I’m actively digging into this as well.

best regards,
Shuvro

[Peter Stahlecker]

I think, somebody is looking actively at this already:

GSoC 2026 | EoM Performance: Profiling Results for KanesMethod (seeking feedback) · sympy/sympy · Discussion #29240

As I understand Kane, and i am just a user, it simply does not need solve(...)