Friday, March 22, 2013

A beginner's journey through research


With 2 more months left before I have to finish my Dual Degree Project (DDP), I am now in a restless position. I have always been interested in my work, but I procrastinate a lot. My work is computational. I have written codes for two techniques, both part of my DDP, by January. Since then I have just been debugging my codes and modifying my approach. I now have proper codes and accurate results, but the results are not what I have expected. I'm now left with only one option- to tweak my approach in whatever ways I can till I can make some sense out of my results. If this were a textbook problem, I would have had some feel for the answer and tried to work towards that. But with my DDP, not even my guide knows what the answer would be, and so goes on my search for sense.

I have taken up a decent number of projects in my insti life- a few experiments and models for course work, some simulations, hazaar codes, and three big ones -
1) An SOE (Spirit of engineering) project (sems 2 - 5)
2) Internship at GE (Summer 2011)
3) DDP ( July 2012 - present)
And all of my course projects, I did myself.
As I'm now clueless about how to proceed, and pretty frustrated for being in such a situation, I was reflecting on the way I've approached my project so far and realized that there is a common trend among my approaches to projects. In this post, I'll outline that approach. It may help other beginners who are about to start taking on new projects, and hopefully I may realize something I've been missing as I put it in words.

Phase 1: Groundwork, reading
The most boring part. I'm very enthued to do something but I know very little about it. Sometimes, as in the case of my internship, I'm not even aware of the problem. I do know that reading some stuff will help me later. Reading things when needed has always been more appealing to me. I'd just glance through the textbooks, just to know what it is all about, without trying to remember anything. Later, when I am faced with the real problem, I come back to the textbook and read the relevant part thoroughly.

Phase 2: Let's do this s**t
The problem is introduced. I think I understand what the issue. I lay down a strategy to attack it and get to work. I would be quite sure about the outcome when I start working. This phase ends as quickly as it begins

Phase 3: Problems, problems
I get stuck. Sometimes I can't get results - code doesn't work, code gives infinity or NaN, experimental setup  does nothing, Simulation won't start, software won't install, software won't run, and so on and on... Sometimes I get results that are garbage. The strategy I was so confident about cups badly.

Phasae 4: Loss of enthu, infinite procrastination
After the initial enthu and the spectacular cupping, with no obvious route to take, I start losing enthu. I'm so pained with the cupping that I don't try to look for ways to make it work and desperately, but with huge time delays, keep trying the same thing over and over.

Phase 5: More reading, problem definition
After a lot of procrastination, I would lazily explore other options. When searching for new ways to attack the problem, I usually end up questioning my understanding of the problem itself. I would then set down to clearly define the problem itself and what I expect from it. This will be accompanied by a round of reading existing literature to see if I can relate my problem to something that already has been studied. At the end of this phase, I'd gain a better understanding of the problem and a better appreciation of the challenges it offers.
A lot of times, phase 5 is accelerated by talking to others- mentors, guides, colleagues, etc.. Most of the time, what I would realize in phase 5 is that I did not pay enough attention to detail- to the assumptions usually. Like in 11th or 12th I might have sometimes applied conservation of mechanical energy when there is friction in the system. In the context of my DDP, I usually work assuming that the system is close to a linear system without trying to verify that assumption. Or when I get results that don't seem to make sense, I do not analyze them properly.
Bad results tell a lot more about the system than results that seem meaningful. They usually tell us why the system is not ideal, or to which parameter it is most sensitive. Analyzing them is a very important part of research, but I rarely do that out of laziness.

Phases 2 to 5 repeat a few times, with each round giving me better insight into the problem (irrespective of whether I'm actually getting closer to solving the problem or not). Phase 5 usually ends prematurely. Once I realize that my previous approach was wrong and that there is another route I can take, I go back to phase 2 without completely considering the results of the previous round. That is usually a very big problem, but its very hard to fight the drive to try a new, promising, approach.
I do not know what comes after phase 5. I have just realized that in the last 5 years, I have never gotten past phase 5. I have never had problems with classroom problems or the simple tutorial questions. But I'm yet to solve a real problem. I had given up on my SOE project, left my internship before I could see the project through completition, and am still working on my DDP. There were several course assignments that were quite challenging. In my 9th sem, 2 courses required some computational assignments to be completed and another course required me to make an experimental measurement. Aerospace Engineering Department at IITM has some very good professors who give interesting assignments. My course projects gave results that were sufficiently satisfactory to earn a good grade. Throughout my coursework and with my 3 big projects, I have always ended up appreciating the problem far better than when I started working on it. But completely exploring the problem- that is something I haven't done yet.
With my DDP, I am now hopeful that I will see it to completion. I have already been through phases 2 to 5 atleast 5 times (I am using a technique called 'Dynamic Mode Decomposition'. Right now the code I'm running is called "dmd_mixlayer_ver7" - the 7th version since January). I believe I have a fair understanding of the problem. Hopefully I'll have explored it fully before I pass out.

No comments:

Post a Comment