User:Prao

A: An introduction

• Please describe yourself in three sentences, one of them regarding your current studies.
  • Which languages do you speak?
  • What's your overall background?

My name is Pooja Rao and I'm originally from Gurgaon, India but currently living in NY, USA. I am a PhD student in computational fluid dynamics at Stony Brook University, NY, specializing in fluid mixing in high Reynolds number regime. I speak Hindi and English fluently, and love to read and travel.

• Why do you want to participate in the Google Summer of Code? What do you hope to gain by doing so?

I love math and technology. It seems like a fun way to spend summer, learning cool math/tech oriented things (that could turn into something useful) and also, to get your feet wet in open-source world. It's also a very good way to observe and learn about how professionals coders code and communicate.

• Why are you choosing Octave?

I have used Octave a little before and found it a useful math tool. The project on IBVP parabolic-elliptic offers me the perfect opportunity to combine my numerical analysis, fluid dynamics(PDE solving) and coding skills. Plus, I could see myself using this tool for my own work.

C: Contact

• Please state the (unique and identical where possible) nick you use on IRC and any other communication channel related to Octave.

My nick is prao.

• Which time zone do you live in? Will that change over GSoC duration?

I live in UTC-5 and it's going to be UTC-4 for GSoC duration (daylight saving)

• Please state the timeframe (in UTC+0) when you feel most comfortable working during GSoC.

I am on a flexible schedule but on most days, I code between 14:00 hrs to 06:00 hrs(UTC).

E: Coding experience

• Please describe your experience with C++, Octave or Matlab m-scripts, OpenGL and Qt.

For my research we use C++, C to solve the Navier-Stokes numerically using a huge code that's been in development for a long time. The code development that I do is mostly in these languages.

I have used a lot of Matlab for writing scripts for post-processing data and to generate plots for research papers. In addition, I have also used Matlab for numerical analysis classes to generate movies and to do homework assignments on PDEs.

I don't have any experience with OpenGL and Qt.

• Please describe your experience with other programming languages.

I have used Python to test the complex code ideas before implementing them in C, C++. I've also used a few Python modules and libraries for my assignments. I am taking a Python based scientific computing class and as part of my coursework, I use IPython and notebook. I really like the IPython notebooks. I can make some simple GUIs using Tkinter.

• Please describe your experience with being in a development team.

For my Ph.D. research, I use and help develop a multi-physics, publically available code in C, FronTier[1], that's been in development for a couple of decades. I work in a big team that shares code, so in a way I'm familiar with the development environment, although I am totally new to open source development. [1] http://sitsec.ams.sunysb.edu/trac/wiki/FronTier

• Please describe the biggest project you have written code for and what you learned by doing so. Also describe your role in that project over time.

I started using FronTier as an end user, taking data output and writing scripts to answer specific research questions. As my research progressed, I needed to add more features to the code and I transitioned to being a developer. My biggest project was to adopt some parts from the old version of FronTier(in C) to a new C++ version. It involved reading a bunch of papers on dynamic subgrid scale modeling (small-scale turbulence modeling), understanding a big piece of code written by someone else and changing (also adding new features) it to C++, which I didn't know much of until I started working on this project. The complexity of the code and poor documentation, made it quite challenging to add new pieces of code that worked in sync with the rest of it. It taught me the value of having a clear plan of action before implementation and the importance of testing vigorously. I found it useful at times to discuss certain aspects with more experienced users and refining my thought process.

Being in a big team also was a good practice in improving my communication skills.

• Please state the commits and patches you already contributed to Octave.

I did a couple of small patches to get used to Mercurial and the source code. [1] [2]

F: Feeling fine

• Please describe (in short) your experience with the following tools:

• • IRC and mailing lists

I am comfortable using IRC and mailing lists. I found them useful during the installation process and getting answers for project related questions.

• • Mercurial or other source code management systems

I have a basic knowledge of Mercurial at this point.

• • Mediawiki or other wiki software

Yes, for the journal club at my University.

• • make, gcc, gdb or other development tools

Yes, I use them on a regular basis.

• What will make you actively stay in our community after this GSoC is over?

I think I've learned a few things just by hanging around in IRC, reading mailing digests regularly and submitting small patches. I view it as an experience which not only improves the coding skills, but the intangible ones as well. Other members seem helpful and welcoming. Besides I use Matlab pretty frequently, but I'am trying to switch to Octave. It's a very helpful tool for my research (which is not going to change any time soon). A combination of all these things makes me want to stick around after GSoC is over.

O: Only out of interest

• Did you ever hear about Octave before?

Yes, I had heard about Octave before via my professor. I am still exploring it.

• What was the first question concerning Octave you could not find an answer to rather quickly?

Installing Fem-Fenics on my Ubuntu 12.04 LTS was a little more consuming than I thought. The reason was I had to use trial-and-error method to fix the error messages. There were some mailing archives and wiki-pages that were tangentially helpful but ultimately google turned out to be my friend.

P: Prerequisites

• Please state the operating system you work with.

I have 24x7 access to Ubuntu 12.04 as my personal computer and CentOS 6.3 as a school server, available remotely.

• Please estimate an average time per day you will be able to (if separated) access

• • an internet connection

Always

• • a computer

Always

• • a computer with your progressing work on

Always

• Please describe the degree up to which you can install new software on computers you have access to.

I have the root permissions and enough RAM to install the needed software.

S: Self-assessment

• Please describe how useful criticism looks from your point of view as committing student.

Constructive criticism is extremely important for improvement both as a coder and as a person. There is always value in getting an objective view of your work, general or specific, and working on your weak points. Having said that, I don't find vague feedback very helpful.

• How autonomous are you when developing?

I'd say fairly autonoumous. I usually refer to online resources to resolve problems. But I'd say I'm also good at recognizing roadblocks that might need a little nudge in the right direction, especially if there is time constraint.

• • Do you like to discuss changes intensively and not start coding until you know what you want to do?

For me discussions are more productive when I've already spent some time thinking about the problem. I like to think long and hard before I start implementation so I know what I am doing. This helps me avoid confusion and writing messy code.

• • Do you like to code a proof of concept to 'see how it turns out', modifying that and taking the risk of having work thrown away if it doesn't match what the project or original proponent had in mind?

I usually don't follow this technique for large projects as there is too much at stake in terms of effort and time. I like to have a clear vision before I start coding. But for small problems with enough time, I think it's okay to to get the feel of things via coding.

Y: Your task

• Did you select a task from our list of proposals and ideas?

• • If yes, what task did you choose? Please describe what part of it you especially want to focus.

Yes, I would like to implement the IVBP for parabolic-elliptic PDEs in 1D. Besides being compatible with Matlab's pdepe function, I want to make sure it has comparable performance too.

• Please provide a rough estimated timeline for your work on the task.

I am working on a more detailed outline that deals with the specifics. Any ideas, comments on this schedule will be much appreciated!
Community bonding period
I'd like to know the source code and community better by getting more involved in help-forums, IRC, etc. I wouldn't have my research commitments in May and that should help. I'd also like to discuss the frequency and means of communication with my mentor. I have set up a blog and would like to put my weekly/fortnightly progress on it. Also, I think this project is more math-intensive than coding-intensive, so it's important I know the theory behind implementation well.
Coding period (tentative schedule)
Overall goal: Implement Matlab compatible pdepe function
Midterm goal: Implement pdepe for non-singular case
Second Half goal: Implement pdepe for singular case
Week 1 Initialization & error catching of input parameters
Week 2/3 Implement Galerkin for non-singular case: taking initialization, discretizing and setting up ODE system
Week 4 Use DASPK to solve ODE system
Week 5 Testing Non-singular cases & buffer time for debugging; coexistence of above two
Week 6 Implement Petrov-Galerkin
Week 7/8 Testing, validation, timing studies and performance analysis
Week 9 Documentation, clean up/finish
Week 10,11 If there's extra time and possibility, then work on imrpoving ode15s implementation
Week 12 Pencil-in time

I don't have any exams or other commitments during GSoC period and the problem seems a good match for my skill set, so I expect to have no issues completing it in the time frame allotted.