Re: [sympy] GSOC'25: Enhancing 2D & 3D Beam Solving System.

[Pratyksh Gupta]

Hello Jason,

I have just finished my proposal for my project on Extending Continuum 
Mechanics Module: Enhancement of 2D, 3D Beam and Arch Classes.

Here is the link 

 for 
the document.

Looking forward to your feedback and comments on it!

Best regards,
Pratyksh

On Saturday, March 22, 2025 at 8:04:53 AM UTC+5:30 moore...@gmail.com wrote:

> Hi Pratyksh,
>
> These are all nice ideas, but the scope is huge for a GSoC project. You 
> need to narrow the scope.
>
> Jason
> moorepants.info
> +01 530-601-9791 <(530)%20601-9791>
>
>
> On Thu, Mar 20, 2025 at 9:27 PM Pratyksh Gupta  
> wrote:
>
>> Hi Jason,
>>
>> After this PR #27130  merges, 
>> I propose the following enhancements to align with sympy’s development 
>> roadmap while expanding its beam analysis capabilities.
>>
>> *Refined Proposed Enhancements - *
>>
>> *1. Structure2d for More Structural Types : -*
>>
>> *Current Limitation:* Supports only single-span, non-branching beams.
>>
>> *Enhancements:*
>>
>>
>>- extend Structure2d for *multi-span beams*, *branched frames*, and 
>>*trusses*.
>>- modify apply_load() and apply_support() for *intersecting members*.
>>- implement *node connectivity graphs* for load distribution.
>>
>> *2. Cross-Sectional Geometry Integration : -*
>>
>> *Current Limitation:* No *cross-section support* for 2D beams.
>>
>> *Enhancements:*
>>
>>
>>- use *SymPy’s geometry package* for *I-beams, hollow cylinders, 
>>rectangular beams*.
>>- automate *second moment of area (I) calculations*.
>>- extend cross_section property for *variable geometries (tapered 
>>beams)*.
>>
>> *3. Robust Testing & Error Handling : - *
>>
>> *Current Limitation:* Lacks comprehensive unit tests & validation checks.
>>
>> *Enhancements:*
>>
>>
>>- add tests for *multi-span beams, trusses, support types*.
>>- validate *input errors, missing beam properties, unsupported 
>>geometries*.
>>- implement *exception handling* for unstable configurations.
>>
>> *4. Advanced Plotting & Visualization : -*
>>
>> *Current Limitation:* Basic plotting; lacks interactive features.
>>
>> *Enhancements:*
>>
>>
>>- extend Structure2d.draw() for *branched beams & multi-span 
>>structures*.
>>- add *interactive plotting (drag nodes, modify loads dynamically)*.
>>- implement *3D deformation rendering, bending moment & shear force 
>>overlays*.
>>- support *plot export (PNG, SVG, PDF)*.
>>
>> *5. Expanding Example Library : - *
>>
>> *Current Limitation:* Lacks real-world problems & benchmarks.
>>
>> *Enhancements:*
>>
>>
>>- add *statically indeterminate beams, variable cross-section 
>>problems*.
>>- create *Jupyter Notebook tutorial* with *step-by-step guides & 
>>interactive plots*.
>>
>> *6. Performance Optimization : -*
>>
>> *Current Limitations :* Redundant symbolic computations, no numpy 
>> optimizations.
>>
>> *Enhancements:*
>>
>>
>>- optimize solve_for_reaction_loads() with *NumPy-based matrix 
>>operations*.
>>- reduce memory usage via *lazy evaluation & efficient load storage*.
>>
>> Would these enhancements align with sympy's roadmap? I’m eager to 
>> contribute and explore implementation strategies.
>>
>> Looking forward to your response!
>>
>> Best regards,
>>
>> Pratyksh Gupta
>> On Tuesday, March 11, 2025 at 12:03:34 PM UTC+5:30 Pratyksh Gupta wrote:
>>
>>> Hi Jason, 
>>>
>>> Thank you for your response and for sharing PR and issue tracker. I will 
>>> review PR #27130  in detail 
>>> to understand its scope and how it expands capabilities to more structural 
>>> types. I will also go through the open issues in the 
>>> *physics.continuum_mechanics* module to identify areas where I can 
>>> contribute.
>>>
>>> Would you recommend focusing on integrating this PR first before 
>>> considering additional enhancements like 3D beam modeling and 
>>> cross-sectional geometry extensions?
>>>
>>> Looking forward to your insights!
>>>
>>> Best Regard,
>>>
>>> Pratyksh Gupta.
>>> On Monday, March 10, 2025 at 12:14:58 AM UTC+5:30 moore...@gmail.com 
>>> wrote:
>>>
 The most recent work on that module is: 
 https://github.com/sympy/sympy/pull/27130 which we would like to merge 
 and get it working more generally. This expands the capabilities to more 
 structure types. That would be my hope for any near future work.

 Fixing bugs seen in this list of issues is also priority: 
 https://github.com/sympy/sympy/issues?q=is%3Aissue%20state%3Aopen%20label%3Aphysics.continuum_mechanics

 Jason
 moorepants.info
 +01 530-601-9791 <(530)%20601-9791>


 On Sun, Mar 9, 2025 at 7:22 PM Pratyksh Gupta  
 wrote:

> Hello SymPy developers,
>
> I am excited to express my interest in contributing to SymPy by 
> enhancing

Re: [sympy] [Idea Prompts] Adding More Matrix Decomposition Methods to SymPy for GSOC 2025

[Temiloluwa]

Hello Oscar, I have  Added my *GSOC 2025 proposal : Implementation of 
Division based LU and Fraction-Free LU decomposition algorithms in sympy's 
DomainMatrix* on the wiki page 

I will appreciate your feedback/review on my proposal, if there are things 
that needs to be added or removed. 


Temiloluwa 
On Saturday, 22 March 2025 at 13:36:04 UTC+1 Temiloluwa wrote:

> Hello Oscar,  I have completed my GSoC 2025 proposal on *implementing 
> fraction-free and division based LU decomposition algorithms for 
> DomainMatrix*. Given your expertise and past feedback, I would really 
> appreciate it if you could review my proposal and share your feedback. 
>
> If you have any suggestions for improvements, I would be happy to refine 
> the proposal further.  Here is the link to my proposal. I have granted 
> your access to the document. 
>
>
> https://docs.google.com/document/d/1cOMl-zlFq9ocGBMD7zN0XHKKOAgLNvfrRDSG26X0IGw/edit?usp=sharing
>
> Looking forward to your feedback.
>
> Best regards,
> Temiloluwa
>
>
> On Fri, 7 Feb 2025 at 18:14, Oscar Benjamin  wrote:
>
>> Hi Temiloluwa,
>>
>> Yes, these kinds of things would be good to have in SymPy. More
>> important than adding many different factorisations though is having
>> good implementations of the most important ones. I would say that just
>> implementing fraction-free and division-based LU algorithms fully
>> would make a suitable GSOC project. I suspect that you currently
>> underestimate how much is involved in that even though you have a PR
>> that implements the algorithm already. The additional things that are
>> needed to complete the LU implementation are things like:
>>
>> - Both sparse and dense implementations of LU and FFLU for
>> DomainMatrix (consider if any very different sparse algorithms are
>> worth implementing).
>> - Make use of python-flint for FLINT's FFLU function when possible and
>> ensure that the outputs are comparable to the SymPy implementation.
>> - Numerically stable version of LU for floats.
>> - Matrix methods that call into the DomainMatrix methods making them
>> accessible to users and speeding up end user calculations.
>> - Upper and lower triangular solves for LU and fraction-free LU.
>> - Solving over/under determined systems.
>> - Make use of LU to compute other things like matrix inverse, RREF, 
>> nullspace.
>> - Lots of timings and benchmarks to compare performance of different
>> approaches for different domains, shapes, densities etc. Decide when
>> different algorithms should be used.
>> - Make it so that solve and Matrix.solve and other functions use
>> LU-based solve if it is better.
>>
>> See also this PR which I did not finish but was intended to make all
>> linear equation solving code go through a single place so that it
>> could be optimised for all cases:
>>
>> https://github.com/sympy/sympy/pull/26000
>>
>> Putting all of that sort of stuff together is more useful than adding
>> other less frequently used factorisations. A good implementation of LU
>> is a foundation for many other things so it is worth spending some
>> time to make it as good as possible. As you have seen other things
>> like QRD can be almost trivial to implement if they can leverage the
>> LU decomposition.
>>
>> In general not all matrix factorisations that can be defined
>> abstractly are actually suitable for exact or symbolic arithmetic
>> rather than floating point arithmetic and vice versa. For example I am
>> not sure that I have seen any implementation of the polar
>> decomposition for exact numbers. Unless SymPy could provide something
>> that is more useful than SciPy's polar function I'm not sure it is
>> worth adding. Note that a high precision implementation should be part
>> of mpmath rather than SymPy. The only value implementing this in SymPy
>> would be if it could be exact but I don't know how you would compute
>> the polar decomposition exactly or whether that is something that only
>> makes sense for very small matrices.
>>
>> On Fri, 31 Jan 2025 at 21:13, Temiloluwa  wrote:
>> >
>> > Hello SymPy Community,
>> >
>> > My name is Temiloluwa, and I would like to propose the addition of more 
>> matrix decomposition methods (Schur, Polar, and Hermite Decomposition) as 
>> my project idea for Google Summer of Code (GSoC) 2025.
>> >
>> > I have successfully gotten a PR in for a QR decomposition method for 
>> DomainMatrix and I am currently finalizing a PLDU decomposition and a 
>> fraction-free QR decomposition (QRD) pull request for DomainMatrix, aimed 
>> at improving the GramSchmidt process
>> >
>> > From my exploration of the SymPy codebase, I have observed that the few 
>> matrix decomposition methods that exist are LU, QR, Cholesky variants and 
>> some others to name a few. However, important methods like:
>> >
>> > Schur Decomposition

[sympy] Regarding feedback on GSoC 2025 proposal.

[ABHISHEK KUMAR]

Dear SymPy,
I hope you are doing well, My name is Abhishek Kumar, and I'm reaching out
to express my desire to participate in the *Control Module* project this
upcoming summer. I had the opportunity to contribute to last year's
project, and I'm eager to continue improving upon our progress.

Can you please review my proposal once and suggest some improvements ?

Proposal Link :
https://docs.google.com/document/d/1JJqSZr5AVxulMWfsvSQp5pkw_JtudTZkoo___1CWNzM/edit?usp=sharing

Thanks,
Abhishek Kumar

-- 
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+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/sympy/CAHZvv1YdkMKk%2BANrfsAJ1Qaxiz__AgpiUfuVKeumsgaZeTxArg%40mail.gmail.com.

Re: [sympy] GSoC 2025: Seeking Feedback on Assumptions System Research & GSoC Project Choice

[Aaron Meurer]

On Sun, Mar 30, 2025 at 11:29 PM Tilo RC  wrote:

> Hi Krishnav,
>
> I recommend reading the following if you haven't already:
> https://github.com/sympy/sympy/wiki/Assumptions#the-aims-of-assumptions


Just be aware that this is a pretty old page. A lot of the stuff on it is
still relevant, but not all of it represents the thinking that has happened
since it was written.

For instance, when people started writing the "new assumptions" (ask, Q,
refine), the idea was that this would completely replace the old
assumptions (Symbol('x', positive=True), x.is_positive). However, the
thinking now is that this is a mistake, because the old assumption is
syntactically very useful. They are different in that one system attaches
assumptions to a Symbol and one system keeps them separate. The advantage
of attaching assumptions to a symbol is that you don't have to keep passing
assumptions to every function. The only other alternative is to have global
assumptions (which you can currently do with assume()), but this creates
global state, which is problematic. However, the advantage of keeping the
assumptions separate is that you can assume things on entire expressions,
not just symbols. The new assumptions system also has the advantage of
being based on predicate logic, which uses symbolic unevaluated predicate
expressions, whereas the old assumptions use 3-valued logic which doesn't
support unevaluated expressions, and thus is more buggy and harder to do
certain things with. Oscar and I talked a bit about these things (and
others) in our 2022 SageDays talk
https://www.youtube.com/watch?v=ujWoGQt7F5A (the talk starts at 1:46:30,
and there is also some discussion at the end of the video). Slides are at
https://docs.google.com/presentation/d/1SqV-Pcs_78z5oJItHafnystDr71AN1XBipP4FXEtjaA/edit?slide=id.p#slide=id.p

Aaron Meurer



>
> Tilo Reneau-Cardoso
>
> On Saturday, March 29, 2025 at 4:05:24 PM UTC-7 bajoria...@gmail.com
> wrote:
>
>> Hi Tilo,
>>
>> Thank you for your feedback and for pointing out these issues.
>>
>> Regarding the paraphrasing and referencing, I understand my mistake.
>> Moving forward, I'll be more clear when distinguishing between your
>> original content and my own thoughts by adding footnotes. Additionally,
>> when paraphrasing content from specific issues, I'll include links to those
>> issues in the reference section for better traceability. I apologize for
>> the lack of clarity in the previous version and will correct this in my
>> next revision.
>>
>> As for the distinction between Q.gt(x, 0) and Q.positive(x), I realize I
>> misunderstood the difference. You're right—Q.positive(x) does indeed
>> imply that x is real, whereas Q.gt(x, 0) allows for x to be extended
>> real, which might include infinite values. I'll revise the proposal to
>> accurately reflect this distinction.
>>
>> Thanks again for your observation and guidance. I'll make sure the next
>> version addresses these points properly.
>>
>> Best regards,
>> Krishnav Bajoria.
>> On Sun, Mar 30, 2025 at 4:24 AM Tilo RC  wrote:
>>
>>> Hi Krishnav,
>>>
>>> I skimmed through your proposal. Could you make it more clear when
>>> you're paraphrasing something I wrote vs your own original thoughts? It
>>> would be good if you added footnotes for this sort of thing. Also, if
>>> you're paraphrasing stuff I wrote in particular issues, you should add
>>> links to those issues in the reference section.
>>>
>>> One more thing: Q.gt(x, 0) and Q.positive(x) are not supposed to be
>>> equivalent. Q.positive(x) implies that x is real whereas Q.gt(x, 0) implies
>>> x is extended real (it might not be finite).
>>>
>>> Tilo Reneau-Cardoso
>>>
>>> On Sat, Mar 29, 2025 at 3:11 PM Krishnav Bajoria 
>>> wrote:
>>>
>> Dear SymPy Community,

 I have completed the first draft of my GSOC 2025 proposal titled 
 *"Improving
 Relational Reasoning and Introducing Quantifier Support in SymPy's
 Assumptions Framework." Y*ou can find the proposal at this link
 
 .

 I would greatly appreciate it if you could review the proposal and
 share any suggestions or feedback on how I can make it better. Your
 insights would be invaluable in refining the proposal further.

 Thank you for your time and support!

 Best regards,


   Krishnav Bajoria.

 --
 You received this message because you are subscribed to a topic in the
 Google Groups "sympy" group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/sympy/XSJuvibPOro/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 sympy+un...@googlegroups.com.
 To view this discussion visit
 https://groups.google.com/d/msgid/sympy/CAF0TZutDGaxUcgVK71ZzokOWN_87%3DwVzFA4F%2BaJXyNBhkpy3Sw%40mail.gmail.com
 

Re: [sympy] Efficient Equations of Motion Generation

[LUIS ANGEL MELENDEZ CHAVERO]

Hi,

I hope you're doing well.

I just wanted to follow up on my GSoC 2025 proposal for the SymPy project 
(Efficient Equations of Motion Generation). Based on your previous 
feedback, I’ve made some improvements to both the proposal and the 
contribution itself.

I ran some profiling to identify bottlenecks, made a focused optimization 
in lagrange.py, and also put together a Jupyter notebook with the results.

Here’s the updated patch:
🔗 https://github.com/sympy/sympy/pull/27870

If you have a moment to take another look, I’d really appreciate any 
additional thoughts or suggestions—especially if there’s anything else I 
should refine or explore further.

Thanks again for your time and support!

Best,
Luis



On Sunday, March 30, 2025 at 11:38:54 PM UTC-6 moore...@gmail.com wrote:

Dear Luis,

Thank you for your interest. I scanned your PR and proposal. Unfortunately, 
these ideas are not well aligned with the needs of the SymPy Mechanics 
package. I suggest doing more research on what the issues are regarding 
efficient equation generation and reworking your proposal. To improve the 
generation you would need to profile the code in slow examples and find 
ways to speed them up. Using simplification routines will most likely 
always slow them down.

Jason
moorepants.info
+01 530-601-9791


On Mon, Mar 31, 2025 at 7:34 AM LUIS ANGEL MELENDEZ CHAVERO <
dreaml...@gmail.com> wrote:

Hello everyone,

I'm applying for GSoC 2025 with SymPy and would like to share my draft 
proposal for feedback.

Project: Efficient Generation of Equations of Motion
GitHub Notebook: 
https://github.com/LuisOfL/GSoC2025-SymPy/blob/main/GSoC.ipynb
Pull Request:  https://github.com/sympy/sympy/pull/27858

I welcome any feedback to improve my proposal before I officially submit it.

Thanks in advance! 

-- 
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/4ac5826c-841a-4e41-9751-6f7828aa2ad3n%40googlegroups.com
 

.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/sympy/a4599617-f8e8-471d-9990-8015dbad05f8n%40googlegroups.com.

RE: [sympy] Efficient Equations of Motion Generation

[peter.stahlecker]

Dear Luis,

 

likely my python / sympy knowledge is not good enough, but I do not see any 
difference in 27870 between what was and what you did.

Yet you get 25% speed improvement.

 

Best regards,

 

Peter

 

From: sympy@googlegroups.com  On Behalf Of LUIS ANGEL 
MELENDEZ CHAVERO
Sent: Tuesday, April 1, 2025 11:02 PM
To: sympy 
Subject: Re: [sympy] Efficient Equations of Motion Generation

 

Hi,

I hope you're doing well.

I just wanted to follow up on my GSoC 2025 proposal for the SymPy project 
(Efficient Equations of Motion Generation). Based on your previous feedback, 
I’ve made some improvements to both the proposal and the contribution itself.

I ran some profiling to identify bottlenecks, made a focused optimization in 
lagrange.py, and also put together a Jupyter notebook with the results.

Here’s the updated patch:
🔗 https://github.com/sympy/sympy/pull/27870

If you have a moment to take another look, I’d really appreciate any additional 
thoughts or suggestions—especially if there’s anything else I should refine or 
explore further.

Thanks again for your time and support!

Best,
Luis

 

 

On Sunday, March 30, 2025 at 11:38:54 PM UTC-6 moore...@gmail.com 
  wrote:

Dear Luis,

 

Thank you for your interest. I scanned your PR and proposal. Unfortunately, 
these ideas are not well aligned with the needs of the SymPy Mechanics package. 
I suggest doing more research on what the issues are regarding efficient 
equation generation and reworking your proposal. To improve the generation you 
would need to profile the code in slow examples and find ways to speed them up. 
Using simplification routines will most likely always slow them down.

 

Jason

moorepants.info  
+01 530-601-9791

 

 

On Mon, Mar 31, 2025 at 7:34 AM LUIS ANGEL MELENDEZ CHAVERO 
 wrote:

Hello everyone,

I'm applying for GSoC 2025 with SymPy and would like to share my draft proposal 
for feedback.

Project: Efficient Generation of Equations of Motion
GitHub Notebook: https://github.com/LuisOfL/GSoC2025-SymPy/blob/main/GSoC.ipynb
Pull Request:    
https://github.com/sympy/sympy/pull/27858

I welcome any feedback to improve my proposal before I officially submit it.

Thanks in advance! 

-- 
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/4ac5826c-841a-4e41-9751-6f7828aa2ad3n%40googlegroups.com
 

 .

-- 
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+unsubscr...@googlegroups.com 
 .
To view this discussion visit 
https://groups.google.com/d/msgid/sympy/a4599617-f8e8-471d-9990-8015dbad05f8n%40googlegroups.com
 

 .

-- 
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+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/sympy/000901dba387%2478423940%2468c6abc0%24%40gmail.com.

Re: [sympy] GSoC 2025: Seeking Feedback on Assumptions System Research & GSoC Project Choice

[Krishnav Bajoria]

Dear SymPy Community,

I would like to inform you that I have taken into account Tilo’s comments
regarding paraphrasing, adding footnotes, and properly referencing the
sources of certain content in my GSoC 2025 proposal.

I have now uploaded the *revised version* of my proposal, titled:
*"Improving Relational Reasoning and Introducing Quantifier Support in
SymPy’s Assumptions Framework"*, to the SymPy Wiki. The link to my revised
proposal for convenience can be found here
.

Please feel free to review it and share any further feedback. I appreciate
your time and guidance throughout this process.

Best regards,


Krishnav Bajoria.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/sympy/CAF0TZuvfevHCaEKzvwU8PhMW%2BNmYttBToDJ37VH4NNRCP%2BTc%3DA%40mail.gmail.com.

[sympy] Feedback on GSoC Proposals for sympy.mechanics

[Rushabh Mehta]

Dear Sympy community,
I hope you all are doing well. My name is Rushabh Mehta, a computer 
engineering sophomore from VJTI, Mumbai. 

I have spent the past couple of weeks working on 2 project proposals which 
aim to enhance the mechanics module in sympy. I found these projects doable 
for a beginner contributor like me and hence I have given my best to them.

Project 1: Classical Mechanics: Implement Specific Forces and Torques 
.
 
A natural extension of Hwayeon Kang's project last year 
,
 
and adding new force models.

Project 2: Classical Mechanics: Implement Wrapping Geometry and Pathways 
for Musculoskeletal Modeling 
.
 
Proposed enhancements in sympy.mechanics (more towards biomechanics) which 
will make sympy at par with tools like OpenSim for biomechanical modeling.

I would be immensely grateful if any possible mentor could look at my 
proposals and give me feedback to improve them in terms of their project 
scope, direction or wording.



I have also added both to the Wiki 
.

Hoping for constructive feedback.
Best Regards, 
Rushabh Mehta

-- 
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+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/sympy/db29f47e-52bb-448c-892d-b641a0ad4f75n%40googlegroups.com.