Dear Jason,
I would love to get feedback on the idea so far. I will be able to further 
refine my proposal and have a better direction to step in.
Please take a look at my above suggestions.
Thank you.
Best regards,
Rushabh Mehta

On Tuesday, 11 March 2025 at 16:52:53 UTC+5:30 Rushabh Mehta wrote:

> Hello Jason,
>
> Thanks for pointing me towards OpenSim. It is an interesting tool, and 
> I've spent some time researching it. I now have a much clearer 
> understanding of the types of wrapping geometries and pathways commonly 
> used in musculoskeletal models.
>
> OpenSim supports several standard wrapping geometries such as:
>
>    - *Cylinders* (for modeling wrapping around bones like the humerus) 
>    - *Spheres* (for smooth rounded surfaces) 
>    - *Double Cylinders* (for modeling wrapping around parallel bones, 
>    like the radius and ulna) 
>    - *Tori* (for curved wrapping surfaces like joint capsules) 
>    - *Ellipsoids* (for complex bone geometries like the hip joint) 
>
> In OpenSim, the shortest muscle path is calculated using a combination of 
> *points* and *wrapping geometries*. It doesn't solve for the geodesic 
> (shortest path on a curved surface) explicitly but instead uses a 
> combination of line segments and wrap points, and then numerically computes 
> everything needed.
> ------------------------------
>
> *How This Informs My Proposal* 
>
> Given this, I think SymPy Mechanics can be enhanced in the following ways:
>
> *1. Expand WrappingGeometry to Support More Surfaces* 
>
>    - I propose adding WrappingEllipsoid and WrappingTorus. These 
>    geometries will extend the existing WrappingGeometryBase class, allowing 
>    users to model more complex muscle-bone interactions. 
>    - This will align closely with OpenSim's existing wrap objects, making 
>    SymPy more compatible with existing biomechanical tools like OpenSim. 
>    - Additionally, once these geometries are supported, extending SymPy 
>    Mechanics to more complex biomechanical models would become more 
>    straightforward. 
>
> ------------------------------
>
> *2. Introduce GeodesicPathway for Shortest Path Calculation* 
>
>    - Instead of relying on discrete wrap points (like OpenSim), I propose 
>    implementing a GeodesicPathway class that computes the *exact shortest 
>    path* along the surface of a geometry using differential geometry. 
>    - For example: 
>       - On a sphere, the geodesic would be a great circle. 
>       - On an ellipsoid, the geodesic can be computed symbolically using 
>       SymPy's dsolve() to solve the geodesic differential equation. 
>       - On a cone, the geodesic would follow a logarithmic spiral path. 
>    - By computing the geodesic symbolically, we could potentially offer a 
>    higher level of accuracy and analytical insight for musculoskeletal 
>    simulations. 
>
> ------------------------------
>
> *3. Symbolic Force Calculation Along the Geodesic* 
>
>    - Another key advantage of a symbolic GeodesicPathway is that it can 
>    directly integrate with SymPy’s force calculation methods (to_loads()), 
>    allowing users to generate symbolic equations of motion using Kane or 
>    Lagrange methods. 
>    - This could make SymPy uniquely positioned to perform symbolic 
>    musculoskeletal simulations — something OpenSim does not currently offer. 
>
> ------------------------------
>
> *Queries* 
>
> My main concern at the moment is:
>               The feasibility of computing geodesics for non-trivial 
> surfaces (like ellipsoids or tori) using SymPy's dsolve(). Is it powerful 
> enough?
>
> If there are any particular limitations or design choices I should be 
> aware of, I would love to hear your feedback. 
> Thanks again for your guidance, and I’m excited to keep pushing this 
> proposal forward.
>
> Best regards,
> *Rushabh Mehta*
> On Tuesday, 11 March 2025 at 11:26:26 UTC+5:30 [email protected] wrote:
>
>> Dear Rushabh,
>>
>> Thanks for your interest. Have you researched what kinds of paths are 
>> often needed in musculoskeletal models? A starting point would be to see 
>> what OpenSim has and what is most commonly used in OpenSim models. If we 
>> support the most common types from OpenSim, that would be a good starting 
>> point.
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791 <(530)%20601-9791>
>>
>>
>> On Tue, Mar 11, 2025 at 6:47 AM Rushabh Mehta <[email protected]> 
>> wrote:
>>
>>> Hello everyone,
>>>
>>> I have been contributing to SymPy and engaging with the community for a 
>>> few months now. I’ve fixed bugs, participated in discussions, and opened 
>>> issues. Thus I have gained some familiarity with the codebase, also I have 
>>> been programming in Python for 2+ years.
>>>
>>> I'm interested in contributing to SymPy Mechanics for GSoC 2025, 
>>> specifically under the project *"Classical Mechanics: Implement 
>>> Wrapping Geometry and Pathways for Musculoskeletal Modeling" *as listed 
>>> on the ideas page.
>>>
>>> I've been exploring and studying the existing WrappingCylinder and 
>>> WrappingSphere classes, as well as the LinearPathway and ObstaclePathway. I 
>>> believe a valuable addition would be:
>>>
>>>    1. *WrappingEllipsoid* and *WrappingCone*: These can model more 
>>>    complex muscle wrapping geometries around bones/joints, extending the 
>>>    current wrapping surfaces. 
>>>    2. *GeodesicPathway*: This pathway would compute the shortest path 
>>>    along a curved surface (any instance of a wrapping geometry) between two 
>>>    attachment points, capturing more realistic muscle routing in 
>>> biomechanical 
>>>    models. 
>>>
>>> *Implementation Plan:* 
>>>
>>>    - *WrappingEllipsoid & WrappingCone:*
>>>       - Extend the existing WrappingGeometryBase class, ensuring all 
>>>       the required methods are implemented.
>>>       - Define parametric equations for the surfaces and add methods to 
>>>       compute geodesic lengths and end vectors.
>>>          - *GeodesicPathway:* 
>>>       - Implement a general GeodesicPathway class that computes the 
>>>       shortest path along a surface (geometry) given two attachment points. 
>>>       - Use differential geometry principles to compute geodesic 
>>>       equations and solve them symbolically using SymPy’s dsolve. 
>>>       - Integrate force calculation along the geodesic (similar to 
>>>       LinearPathway.to_loads method) so that it can be used to generate 
>>> equations 
>>>       of motion with Kane/Langrange method. 
>>>       - Ensure it can interact with any WrappingGeometry object.
>>>    
>>> As with any software development endeavor, these additions will be 
>>> accompanied by exhaustive tests, documentation and example usage.
>>>
>>> I think these additions could significantly enhance the biomechanics 
>>> modeling capabilities of SymPy, especially for musculoskeletal simulations.
>>>
>>> I'd love to hear any feedback, especially on:
>>>
>>>    - The feasibility of computing geodesics symbolically especially in 
>>>    more complicated scenarios using dsolve. 
>>>    - Anything I may have overlooked. 
>>>    - Any suggestions on aligning this work with SymPy's current design. 
>>>
>>> Would this contribution align well with SymPy's current roadmap? I'm 
>>> open to any guidance or suggestions to refine my approach.
>>>
>>> Thanks!
>>> 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 [email protected].
>>> To view this discussion visit 
>>> https://groups.google.com/d/msgid/sympy/48b5a2ee-ffe7-4085-811f-0139b583924dn%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/sympy/48b5a2ee-ffe7-4085-811f-0139b583924dn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>

-- 
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/ba2280c6-d591-4680-88f4-e48a09aeb397n%40googlegroups.com.

Reply via email to