Somewhere between a free-body diagram and a stack trace
From turning beam problems into Python objects to exploring AI in thermal and fluid sciences.
My first year of college was online. COVID hadn’t quite let go yet, so my introduction to IIT Kharagpur happened through a screen.
Most of our courses came from different departments, giving us a taste of the various engineering fields. Basic Engineering Mechanics was pretty much my only introduction to mechanics that year.
Meanwhile, I was learning Python. I made a couple of projects, got comfortable with the language, and started discovering how much I could do with relatively little code.
I didn’t have a clear plan for connecting that interest to my degree yet. That part came later.
Bengaluru weather had spoiled me
When I finally got to campus, I had a few complaints about KGP’s humidity. Okay, more than a few. Going from Bengaluru’s weather to Kharagpur’s was an adjustment I was very vocal about.
But I was excited too. I could finally meet people I’d only known virtually, attend classes in person, and have the college life I’d been imagining. Something along the lines of Chhichhore, ideally.
It was my first semester on campus, and I was attending almost every class. I did actually enjoy showing up. 🙂
One subject I was particularly excited about was Mechanics of Solids, taught by Professor Jeevanjyoti Chakraborty. I’d already watched his YouTube videos, so I was looking forward to seeing him teach in person.
The professors in my department made the subject interesting enough that I started wondering what I could build with it. I enjoyed writing code. Here were mechanical problems I was learning to solve. There had to be some overlap.
“Could I do something with Python?”
Sometime after mid-semester, Professor Jeevanjyoti invited students to work with him on projects related to mechanics of solids.
I was interested, but a little hesitant about taking on a project on the mechanical side. So I spoke to him about where my interests were and whether there was a way I could fit in.
He understood what I was looking for. He’d also seen that I was getting comfortable with Python.
During our conversation, he showed me his GitHub repository, where he had used code to solve beam problems from the course tutorials. He wanted a more general system: something that could represent different beam configurations and calculate quantities such as shear force and bending moment along the beam, with the broader goal of analysing its behaviour.
That gave me a problem I could get excited about.
A beam was already an object
By then, I was also working with the codebase at KRSSG. That exposure helped me see a possible object-oriented design almost immediately.
What was a beam if not an object with a length, supports, and a collection of loads acting on it?
The mechanics problem already had things I could represent in code. I needed to work out what each one should know and what it should be able to do.
Here’s the sort of textbook problem I had in mind:
I wanted to describe a configuration like this through reusable objects, then let the code handle the calculations. Changing the loading or the kind of beam should mean describing a different problem, rather than writing a separate solution from scratch.
Professor Jeevanjyoti found the approach intriguing too, and I started working on the design.
Giving the mechanics somewhere to live
The design used a base Beam class, with SimplySupportedBeam and CantileverBeam representing different beam types. Loads had their own representations: PointLoad, DistributedLoad, and EquationLoad. Supports were represented separately too.
A load could carry the information needed to describe itself and provide the mathematical operations relevant to it. The beam could collect those loads and expose methods for calculating and plotting shear force and bending moment.
That separation was the part I found satisfying. I could look at a mechanical problem, identify its components, and give those components responsibilities in the software.
It also made the design feel useful beyond the particular tutorial question I was working on. Point loads, distributed loads, different supports—the same structure could represent a range of problems I was encountering in class.
I was still learning the mechanics and the software design as I went. Having a concrete problem made both easier to work through.
From a course project to a package someone could install
Eventually, I had a command-line utility that could solve beam tutorial problems and generate shear-force and bending-moment diagrams.
I wanted other people to be able to use it too.
That introduced me to another set of tasks: testing the class methods, explaining how to use the code, and packaging it for distribution. I used pytest to check the methods and provide examples of how the pieces worked together.
Professor Jeevanjyoti was encouraging about open source throughout the process. Sharing the project and exploring how to contribute to other projects became part of the experience.
I published the library on PyPI, so someone else could install it with:
pip install Lib-mechsolids-abhinavThat was a nice moment. Something that had started with a conversation about coursework was now a package another person could install from their terminal.
The source code and usage instructions are on GitHub.
The overlap kept getting bigger
A couple of years later, I took Data Analysis and Visualization for Mechanical Sciences, taught by Professor Aditya Bandopadhyay.
The course brought programming into more of the subjects I was studying: visualizing fluid flow with Matplotlib, working with thermodynamic properties through CoolProp and PYroMat, and analysing audio and video of mechanical phenomena.
The beam project had given me one way to connect Python with mechanics. This course showed me many more.
Professor Bandopadhyay also motivated me to aim higher in the work I did. For juniors considering the course, I really appreciated that he taught the programming foundations along the way. You didn’t have to arrive already knowing everything before you could start exploring the applications.
And then there was AI
I also took Data-Driven Methods in Thermal and Fluid Sciences, taught by Professor Rajaram Lakkaraju, who was also my B.Tech project advisor.
That introduced me to applications of AI in mechanical engineering that I hadn’t previously known much about.
We encountered ideas such as using autoencoders to compress large simulation datasets, neural networks for modelling physical systems, and explainable AI to investigate predictions in turbulent-flow problems.
One example that stayed with me involved planetary evolution, where material can be modelled as a highly viscous fluid over very long timescales. It was a very different setting from the beam problems I had started with, but it was another place where computation could help us study mechanics.
I was also introduced to the idea of incorporating governing equations, such as the Navier–Stokes equations, into a neural network’s loss function. The model could be trained to account for physical constraints as well as data.
These were topics I was learning about through the course. They widened my sense of what was possible at the intersection of the fields I was interested in.
I’m grateful that my department gave me that exposure. Being a mechanical engineering student gave me opportunities to explore some very current questions in software and AI through physical problems.
Following the overlap
Looking back, the beam library was an important starting point for me.
I approached my professor wondering whether there was room for someone who liked Python in a mechanics project. I came away with a problem that let me learn object-oriented design, testing, packaging, and open source while working with the material from my own course.
Later courses made that overlap much wider. There were simulations to analyse, physical behaviour to visualize, and machine-learning methods to understand.
I didn’t arrive at college knowing how those interests would fit together. Following the projects and classes that caught my attention helped me find out.
Somewhere along the way, a free-body diagram and a stack trace started feeling like perfectly reasonable things to have open next to each other.