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 On Thursday, February 6, 2025 at 10:07:44 AM UTC-5 [email protected] wrote: > 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 > On Thursday, 6 February 2025 at 03:12:17 UTC+5:30 Oscar wrote: > >> On Wed, 5 Feb 2025 at 13:41, Jatin Bhardwaj <[email protected]> >> wrote: >> > >> > 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. >> >> 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 >> > -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/sympy/a7da6fc0-874b-449d-bee3-8aed9f526ad9n%40googlegroups.com.
