[GSoC 2026] Proposal Inquiry: Extending physics.continuum_mechanics with Arbitrary Symbolic Loads

[Chidroopa Kanaparthy]

Hi SymPy Community,

I'm Chidroopa, and I'm working on a proposal to improve the physics.continuum_mechanics.beam module for GSoC 2026.My goal is to provide a high-level interface for arbitrary symbolic load distribution.

Problem: The existing Beam module is optimised for MacCauley's technique using SingularityFunction. Although this is ideal for point loads and constant distributed loads, applying a transcendental or non-polynomial symbolic load, such as q(x) = sin(x) or e^x, requires the user to manually create intricate singularity representations, which is counterintuitive and restricts the module's applicability for complex engineering problems.

My Proposed Solution: I am exploring a Symbolic-to-Singularity Transformer.

1. For polynomial loads, I plan to map them directly to singularity powers.

2. To handle non-polynomial equations, I'm considering adding a Taylor Series expansion fallback to the apply_load method. This would approximate complex loads as high-order polynomials that the current integration engine can handle without a core change.

My Question for Mentors:

Before finalising my approach, I wanted to ask:

• Is a more straightforward integration path for arbitrary functions within the SingularityFunction class itself preferred by the community, or is this Taylor-expansion approximation a better approach for complex symbolic loads?
• Are there any cases in the present beam solver that I should know about when using interval-based symbolic expressions?

I've begun getting acquainted with the codebase through recent PRs (#29411, #29449, #29339, #29332), and I would appreciate any feedback to make sure my idea aligns with the module's long-term goals.

Best regards,

Chidroopa Kanaparthy

[Tom van Woudenberg]

Hi Chidroopa,

I like your idea to support arbitrary loads. However, I'm not sure about the Taylor-expansion: it's not an exact representation and the expression become cluttered with many terms while a big benefit of the singularity function (for polynomial loads) is the compact notation. I think I'd prefer using a singularity fuction as 'activation' function with a <x-a>^0 mutiplier. However, that isn't perfect either: after integration/differentation the number of terms increase.

Tom

Op zaterdag 21 maart 2026 om 07:49:54 UTC+1 schreef chidro...@gmail.com:

[Chidroopa Kanaparthy]

Hi Tom,

Thanks for the feedback on the Series Expansion Idea. Like you said, the term inflation would make the output unreadable for anyone using complex loads.

i have worked out various alternatives using your suggestion, one of which is to to use  <x-a>^0 as an "activation" multiplier like you suggested. I think we can make that work well by using a lazy-rewrite approach. My idea is to keep the load stored in that compact form (f(x) . <x-a>^0) so the user-facing notation stays clean and follows the Macaulay style engineers expect. Only when we actually need to calculate the shear or bending moment, the internal methods (like _get_shear_force) would rewrite those specific terms as Piecewise or Heaviside expressions before calling integrate(). This lets us use the existing integration engine to get exact results (like keeping a sin(x) load as a cos(x) result) without the user ever having to see a wall of piecewise logic in the initial load definition.

In order to maintain the diagrams' continuity, I'm planning to handle the integration constants by zeroing out the antiderivative at the start point alpha. This should prevent any weird jumps at the load boundaries.

Does this Lazy-Rewrite direction sound like a solid path forward to you? I'd love to get your take on this before I finalize the implementation details for my GSoC proposal.

Best Regards,

Chidroopa

[Chidroopa Kanaparthy]

I’ve just worked through a few test cases (including trigonometric and partial distributed loads) to validate this logic . I noticed that the graphs are significantly more precise compared to the Taylor series method, which tended to drift or require too many terms for a clean plot.