GSOC 2025: Enhancing PDE Support in SymPy (Quasilinear, Nonlinear, and Second-Order PDEs)

201 views
Skip to first unread message

Jatin Bhardwaj

unread,
Feb 5, 2025, 8:41:20 AM2/5/25
to sympy
Hello SymPy developers,


I am interested in improving SymPy's PDE-solving functionality, particularly for quasilinear first-order PDEs, general first-order nonlinear PDEs, and second-order PDEs. Currently, SymPy has strong support for linear PDEs, but handling nonlinear cases—especially quasilinear and fully nonlinear PDEs—remains limited.


My primary question is: Does expanding PDE support in these areas align with SymPy’s current development roadmap and priorities?


If this aligns with SymPy’s goals, I would be enthusiastic about contributing to this effort. I have a strong foundation in calculus and differential equations, which I believe will be valuable in tackling this challenge. I’m prepared to delve into the computational implementation of these features and develop a concrete plan of action.

To facilitate this process, I would greatly appreciate any guidance on:
1. Recommended resources for proposed features.
2. Any potential challenges or considerations unique to implementing nonlinear PDE solvers.


Thank you for your time and consideration. I look forward to your response


Best regards,

Jatin Bhardwaj

Oscar Benjamin

unread,
Feb 5, 2025, 4:42:17 PM2/5/25
to sy...@googlegroups.com
Hi Jatin,

SymPy does not have a broadly agreed development roadmap and list of
priorities. Rather different people have different things that they
are working on and would prioritise. I will answer in terms of my own
sense of a roadmap and priorities.

SymPy has various solver functions e.g. solve for algebraic equations,
dsolve for ODEs and pdsolve for PDEs and many more. The usefulness of
these functions is often questionable. Even in the case of solve it
would often be better to use something else such as to compute
numerical solutions rather than analytic solutions. For dsolve, only
quite simple ODEs can be solved. The implementation can be improved to
handle more DEs but there would still be a tiny subset of problems
where analytic solutions can be computed and a vast array of practical
problems that realistically can only be handled numerically. When you
go to pdsolve and PDEs the set of cases that can be solved
analytically is so small that a function like pdsolve is almost
useless. It would be much more useful to users if SymPy just provided
something like an ndsolve function that could solve differential
equations numerically using SciPy's solvers rather than making them go
through lambdify.

That does not mean that we can't do useful things with symbolics when
solving these different types of equations. Often though the useful
thing is to do some symbolic manipulation that then helps with a
subsequent approximate or numeric calculation e.g. we could compute a
series solution or transform the equations somehow. Some symbolic
manipulation is needed even just to set up a numeric solution to a PDE
so you could imagine something useful where SymPy can do that and then
set things up so that the problem could be solved numerically with
e.g. FEniCS.

All of these are also things that could be built on top of SymPy
though so e.g. someone could make a library that depends on SymPy and
that uses it to do useful things with PDEs and FEniCS etc. The
capabilities that such a library would provide would be the same if it
was part of SymPy or just a separate library. Its capabilities would
be limited though by the capabilities of the core parts of SymPy. When
I look at GSOC proposals I am much more interested in proposals that
improve existing core functionality that would provide a good
foundation for other things to be built on top.

If SymPy did not have pdsolve and someone proposed it in a GSOC
project now then I would say that we should reject the proposal. The
only way that I would be happy to add pdsolve is if the code was
already written, comprehensive, well tested, with a well defined scope
and had already been proven to be useful. As it is we have a function
that is not that useful and would still not be that useful even if
someone improved it a bit. I'm not interested in having a GSOC project
that tries to improve pdsolve rather than some other project that
improves some core part of SymPy.

It is possible that someone else would be interested in supervising a
project around pdsolve but personally I would not and I would not
consider it to be any kind of priority for SymPy's roadmap. The
priorities from my perspective are more things like core algebra,
polynomials and matrices, functions like solve, limits, series, code
generation, performance, etc. If these parts of SymPy are good then it
provides a good foundation for someone to make a symbolic PDE library
but if we don't have the resources to handle the core things then we
should not spend those resources on things that could just be in other
libraries that depend on SymPy.

Oscar

Jatin Bhardwaj

unread,
Feb 6, 2025, 10:07:44 AM2/6/25
to sympy

Hi Oscar,


Thank you for your detailed response. I understand your perspective on prioritizing core functionalities. It makes sense that improving algebra, polynomials, matrices, and core solvers would provide a stronger foundation for symbolic computations.

I appreciate your insights and keep these priorities in mind while considering future contributions to SymPy. While waiting for more reviews, I’ve begun looking into other core functionalities within SymPy that could be enhanced to improve the library further and make it a better fit for the project.


Best regards,

Jatin

Nicolas Guarin

unread,
Feb 7, 2025, 9:44:50 AM2/7/25
to sympy
Hello,

I am in a different position than Oscar. Differential equations (and PDEs) have a place in the symbolic world. And the solution of them is one part. SymPy is far from doing what is possible with Maple regarding PDE solutions, for example. We are also lacking approximation done symbolically, as well. Asymptotic approximations, for example.

I have used this kind of thing for benchmarking my numerical solutions using finite element methods, and consider that they are helpful.

I have never been a mentor in GSOC in the past, but maybe I could try to if someone gives me a hand.

Best regards,
Nicolás

Aaron Meurer

unread,
Feb 27, 2025, 3:41:09 AM2/27/25
to sy...@googlegroups.com
I would also argue that symbolic PDE solvers are relevant and in-scope
for SymPy. However, I also do agree with Oscar that as far as
priorities go, many other things such as polynomials and matrices are
much more important, as they affect virtually all parts of SymPy,
whereas a PDE solver is not going to be used by any other part of
SymPy.

Aaron Meurer
> --
> 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/a7da6fc0-874b-449d-bee3-8aed9f526ad9n%40googlegroups.com.

Ashutosh Rajora

unread,
Feb 27, 2025, 4:21:00 AM2/27/25
to sy...@googlegroups.com
Hello,

Thank you for your insights on SymPy's priorities. Following your discussion about PDE solver, I'd like to inquire about SymPy's current direction regarding Computational Group Theory.

I'm considering a project proposal focused on implementing Quotient Groups, Automorphism Groups, and algorithms for Infinite Groups. Could you please guide if this aligns with SymPy's current priorities and whether mentors would be available for such a project?

I've taken relevant Abstract Algebra ( Group,Ring, Field, Galois Theory) courses at university, and have started with the reference mentioned on the ideas page :  Handbook of Computational Group Theory 
Before proceeding further, I wanted to confirm if this area would be considered of any value and relevance for SymPy's development at this time.

Best regards,
Ashutosh Rajora


Jatin Bhardwaj

unread,
Feb 28, 2025, 1:21:36 AM2/28/25
to sympy

Hi Aaron,


Thank you for your feedback.

I have also shifted my focus toward FPS (Formal Power Series), rings, and domains, as I believe these areas align more closely with core SymPy improvements. The open issue gh-26957 provides valuable information and guidance on this topic. Additionally, I have opened a discussion to gather feedback on this direction and hope mentors can provide further insights to refine the scope and approach.


Best regards,

Jatin

Reply all
Reply to author
Forward
0 new messages