How time flies…

I plan to conduct a smallish FDP (Faculty Development Program), for junior faculty, covering the basics of CFD sometime soon (may be starting in the second-half of February or early March or so).

During my course, I plan to give out some simple, pedagogical code that even non-programmers could easily run, and hopefully find easy to comprehend.


Don’t raise difficult questions right away!

Don’t ask me why I am doing it at all—especially given the fact that I myself never learnt my CFD in a class-room/university course settings. And especially given the fact that excellent course materials and codes already exist on the ‘net (e.g. Prof. Lorena Barba’s course, Prof. Atul Sharma’s book and Web site, to pick up just two of the so many resources already available).

But, yes, come to think of it, your question, by itself, is quite valid. It’s just that I am not going to entertain it.

Instead, I am going to ask you to recall that I am both a programmer and a professor.

As a programmer, you write code. You want to write code, and you do it. Whether better code already exists or not is not a consideration. You just write code.

As a professor, you teach. You want to teach, and you just do it. Whether better teachers or course-ware already exist or not is not a consideration. You just teach.

Admittedly, however, teaching is more difficult than coding. The difference here is that coding requires only a computer (plus software-writing software, of course!). But teaching requires other people! People who are willing to seat in front of you, at least faking listening to you with a rapt sort of an attention.

But just the way as a programmer you don’t worry whether you know the algorithm or not when you fire your favorite IDE, similarly, as a professor you don’t worry whether you will get students or not.

And then, one big advantage of being a senior professor is that you can always “c” your more junior colleagues, where “c” stands for {convince, confuse, cajole, coax, compel, …} to attend. That’s why, I am not worried—not at least for the time being—about whether I will get students for my course or not. Students will come, if you just begin teaching. That’s my working mantra for now…


But of course, right now, we are busy with our accreditation-related work. However, by February/March, I will become free—or at least free enough—to be able to begin conducting this FDP.


As my material for the course progressively gets ready, I will post some parts of it here. Eventually, by the time the FDP gets over, I would have uploaded all the material together at some place or the other. (May be I will create another blog just for that course material.)

This blog post was meant to note something on the coding side. But then, as usual, I ended up having this huge preface at the beginning.


When I was doing my PhD in the mid-naughties, I wanted a good public domain (preferably open source) mesh generator. There were several of them, but mostly on the Unix/Linux platform.

I had nothing basically against Unix/Linux as such. My problem was that I found it tough to remember the line commands. My working memory is relatively poor, very poor. And that’s a fact; I don’t say it out of any (false or true) modesty. So, I found it difficult to remember all those shell and system commands and their options. Especially painful for me was to climb up and down a directory hierarchy, just to locate a damn file and open it already! Given my poor working memory, I had to have the entire structure laid out in front of me, instead of remembering commands or file names from memory. Only then could I work fast enough to be effective enough a programmer. And so, I found it difficult to use Unix/Linux. Ergo, it had to be Windows.

But, most of this Computational Science/Engineering code was not available (or even compilable) on Windows, back then. Often, they were buggy. In the end, I ended up using Bjorn Niceno’s code, simply because it was in C (which I converted into C++), and because it was compilable on Windows.

Then, a few years later, when I was doing my industrial job in an FEM-software company, once again there was this requirement of an integrable mesh generator. It had to be: on Windows; open source; small enough, with not too many external dependencies (such as the Boost library or others); compilable using “the not really real” C++ compiler (viz. VC++ 6); one that was not very buggy or still was under active maintenance; and one more important point: the choice had to be respectable enough to be acceptable to the team and the management. I ended up using Jonathan Schewchuk’s Triangle.

Of course, all this along, I already knew about Gmsh, CGAL, and others (purely through my ‘net searches; none told me about any of them). But for some or the other reason, they were not “usable” by me.

Then, during the mid-teens (2010s), I went into teaching, and software development naturally took a back-seat.

A lot of things changed in the meanwhile. We all moved to 64-bit. I moved to Ubuntu for several years, and as the Idea NetSetter stopped working on the latest Ubuntu, I had no choice but to migrate back to Windows.

I then found that a lot of platform wars had already disappeared. Windows (and Microsoft in general) had become not only better but also more accommodating of the open source movement; the Linux movement had become mature enough to not look down upon the GUI users as mere script-kiddies; etc. In general, inter-operability had improved by leaps and bounds. Open Source projects were being not only released but also now being developed on Windows, not just on Unix/Linux. One possible reason why both the camps suddenly might have begun showing so much love to each other perhaps was that the mobile platform had come to replace the PC platform as the avant garde choice of software development. I don’t know, because I was away from the s/w world, but I am simply guessing that that could also be an important reason. In any case, code could now easily flow back and forth both the platforms.

Another thing to happen during my absence was: the wonderful development of the Python eco-system. It was always available on Ubuntu, and had made my life easier over there. After all, Python had a less whimsical syntax than many other alternatives (esp. the shell scripts); it carried all the marks of a real language. There were areas of discomfort. The one thing about Python which I found whimsical (and still do) is the lack of the braces for defining scopes. But such areas were relatively easy to overlook.

At least in the area of Computational Science and Engineering, Python had made it enormously easier to write ambitious codes. Just check out a C++ code for MPI for cluster computing, vs. the same code, written in Python. Or, think of not having to write ridiculously fast vector classes (or having to compile disparate C++ libraries using their own make systems and compiler options, and then to make them all work together). Or, think of using libraries like LAPACK. No more clumsy wrappers and having to keep on repeating multiple number of scope-resolution operators and namespaces bundling in ridiculously complex template classes. Just import NumPy or SciPy, and proceed to your work.

So, yes, I had come to register in my mind the great success story being forged by Python, in the meanwhile. (BTW, in case you don’t know, the name of the language comes from a British comedy TV serial, not from the whole-animal swallowing creep.) But as I said, I was now into academia, into core engineering, and there simply wasn’t much occasion to use any language, C++, Python or any other.

One more hindrance went away when I “discovered” that the PyCharm IDE existed! It not only was free, but also had VC++ key-bindings already bundled in. W o n d e r f u l ! (I would have no working memory to relearn yet another set of key-bindings, you see!)

In the meanwhile, VC++ anyway had become very big, very slow and lethargic, taking forever for the intelli-sense ever to get to produce something, anything. The older, lightweight, lightening-fast, and overall so charming IDE i.e. the VC++ 6, had given way, because of the .NET platform, to this new IDE which behaved as if it was designed to kill the C++ language. My forays into using Eclipse CDT (with VC++ key-bindings) were only partially successful. Eclipse was no longer buggy; it had begun working really well. The major trouble here was: there was no integrated help at the press of the “F1” key. Remember my poor working memory? I had to have that F1 key opening up the .chm helpf file at just the right place. But that was not happening. And, debug-stepping through the code still was not as seamless as I had gotten used to, in the VC++ 6.

But with PyCharm + Visual Studio key bindings, most my concerns got evaporated. Being an interpreted language, Python always would have an advantage as far as debug-stepping through the code is concerned. That’s the straight-forward part. But the real game-changer for me was: the maturation of the entire Python eco-system.

Every library you could possibly wish for was there, already available, like Aladdin’s genie standing with folded hands.

OK. Let me give you an example. You think of doing some good visualization. You have MatPlotLib. And a very helpful help file, complete with neat examples. No, you want more impressive graphics, like, say, volume rendering (voxel visualization). You have the entire VTK wrappped in; what more could you possibly want? (Windows vs. Linux didn’t matter.) But you instead want to write some custom-code, say for animation? You have not just one, not just two, but literally tens of libraries covering everything: from OpenGL, to scene-graphs, to computational geometry, to physics engines, to animation, to games-writing, and what not. Windowing? You had the MFC-style WxWidgets, already put into a Python avatar as WxPython. (OK, OpenGL still gives trouble with WxPython for anything ambitious. But such things are rather isolated instances when it comes to the overall Python eco-system.)

And, closer to my immediate concerns, I was delighted to find that, by now, both OpenFOAM and Gmsh had become neatly available on Windows. That is, not just “available,” i.e., not just as sources that can be read, but also working as if the libraries were some shrink-wrapped software!

Availability on Windows was important to me, because, at least in India, it’s the only platform of familiarity (and hence of choice) for almost all of the faculty members from any of the e-school departments other than CS/IT.

Hints: For OpenFOAM, check out blueCFD instead of running it through Dockers. It’s clean, and indeed works as advertised. As to Gmsh, ditto. And, it also comes with Python wrappers.

While the availability of OpenFOAM on Windows was only too welcome, the fact is, its code is guaranteed to be completely inaccessible to a typical junior faculty member from, say, a mechanical or a civil or a chemical engineering department. First, OpenFOAM is written in real (“templated”) C++. Second, it is very bulky (millions of lines of code, may be?). Clearly beyond the comprehension of a guy who has never seen more than 50 lines of C code at a time in his life before. Third, it requires the GNU compiler, special make environment, and a host of dependencies. You simply cannot open OpenFOAM and show how those FVM algorithms from Patankar’s/Versteeg & Malasekara’s book do the work, under its hood. Neither can you ask your students to change a line here or there, may be add a line to produce an additional file output, just for bringing out the actual working of an FVM algorithm.

In short, OpenFOAM is out.

So, I have decided to use OpenFOAM only as a “backup.” My primary teaching material will only be Python snippets. The students will also get to learn how to install OpenFOAM and run the simplest tutorials. But the actual illustrations of the CFD ideas will be done using Python. I plan to cover only FVM and only simpler aspects of that. For instance, I plan to use only structured rectangular grids, not non-orthogonal ones.

I will write code that (i) generates mesh, (ii) reads mesh generated by the blockMesh of OpenFOAM, (iii) implements one or two simple BCs, (iv) implements the SIMPLE algorithm, and (v) uses MatPlotLib or ParaView to visualize the output (including any intermediate outputs of the algorithms).

I may then compare the outputs of these Python snippets with a similar output produced by OpenFOAM, for one or two simplest cases like a simple laminar flow over step. (I don’t think I will be covering VOF or any other multi-phase technique. My course is meant to be covering only the basics.)

But not having checked Gmsh recently, and thus still carrying my old impressions, I was almost sure I would have to write something quick in Python to convert BMP files (showing geometry) into mesh files (with each pixel turning into a finite volume cell). The trouble with this approach was, the ability to impose boundary conditions would be seriously limited. So, I was a bit worried about it.

But then, last week, I just happened to check Gmsh, just to be sure, you know! And, WOW! I now “discovered” that the Gmsh is already all Python-ed in. Great! I just tried it, and found that it works, as bundled. Even on Windows. (Yes, even on Win7 (64-bit), SP1).

I was delighted, excited, even thrilled.

And then, I began “reflecting.” (Remember I am a professor?)

I remembered the times when I used to sit in a cyber-cafe, painfully downloading source code libraries over a single 64 kbps connection which would shared in that cyber-cafe over 6–8 PCs, without any UPS or backups in case the power went out. I would download the sources that way at the cyber-cafe, take them home to a Pentium machine running Win2K, try to open and read the source only to find that I had forgot to do the CLRF conversion first! And then, the sources wouldn’t compile because the make environment wouldn’t be available on Windows. Or something or the other of that sort. But still, I fought on. I remember having downloaded not only the OpenFOAM sources (with the hope of finding some way to compile them on Windows), but also MPICH2, PetSc 2.x, CGAL (some early version), and what not. Ultimately, after my valiant tries at the machine for a week or two, “nothing is going to work here” I would eventually admit to myself.

And here is the contrast. I have a 4G connection so I can comfortably seat at home, and use the Python pip (or the PyCharm’s Project Interpreter) to download or automatically update all the required libraries, even the heavy-weights like what they bundle inside SciPy and NumPy, or the VTK. I no longer have to manually ensure version incompatibilities, platform incompatibilities. I know I could develop on Ubuntu if I want to, and the student would be able to run the same thing on Windows.

Gone are those days. And how swiftly, it seems now.

How time flies…


I will be able to come back only next month because our accreditation-related documentation work has now gone into its final, culminating phase, which occupies the rest of this month. So, excuse me until sometime in February, say until 11th or so. I will sure try to post a snippet or two on using Gmsh in the meanwhile, but it doesn’t really look at all feasible. So, there.

Bye for now, and take care…


A Song I Like:

[Tomorrow is (Sanskrit, Marathi) “Ganesh Jayanti,” the birth-day of Lord Ganesha, which also happens to be the auspicious (Sanskrit, Marathi) “tithee” (i.e. lunar day) on which my mother passed away, five years ago. In her fond remembrance, I here run one of those songs which both of us liked. … Music is strange. I mean, a song as mature as this one, but I remember, I still had come to like it even as a school-boy. May be it was her absent-minded humming of this song which had helped? … may be. … Anyway, here’s the song.]

(Hindi) “chhup gayaa koi re, door se pukaarake”
Singer: Lata Mangeshkar
Music: Hemant Kumar
Lyrics: Rajinder Kishan

 

Advertisements

An evening by a candle light

Yesterday, it rained in Pune. The newspaper reports today suggested a heavy downpour; 102 mm in 1.5 (or 3) hours. But in the parts of the city where I live, it couldn’t possibly have been 10 cm; by my rough estimates, it seemed like, may be, about 5–6 cm, at the most, about 7–8 cm.

But closer to the point at hand, as is usual in Pune after about 0.00001 cm of rainfall anywhere within a 100 km radius of the city any time within a preceding 1 hour, the electricity was gone.

It was evening, and the clouds had made it a bit darker than what it usually would be at this time of the evening—about 7:30 PM or so. And so, I first stumbled around a bit to find a candle, then realized that I had a cell phone, and so, using its light, I searched for and found the candle, and lit it—I mean the candle.

But as soon as I brought the lit candle to my room, the stronger winds in my room blew it out.

I then remembered a certain gift that my Idea Cellular subscription had generated for me on my birth-day this year (or on the day the last year). It was a scented candle jar. It’s a nice little jar of glass, say about 6–7 cm in diameter and height, with wax filled up to, say, half way through. The jar is thus a nice little thing, and the color of the wax is very beautiful: a faint yellow. It’s actually more or less the same yellow as what Idea Cellular’s brand carries. On a computer monitor (or on the plastic-coated printed paper they un-necessarily insert in the newspapers) it sometimes looks almost pierceingly bright. But a more or less the same hue, now used for the wax, had become, may be due to the dullness of the wax, a very pleasantly soft yellow shade to look at. And, the scent they used for the wax also is nice. (Being a male, both my sense of scent and vocabulary come to an end right at this level of resolution discrimination.) So, all in all, a pretty and neat gift, it was. And, precisely for that reason, I had not yet used it thus far. In the middle-class India, we naturally develop this habit of procrastinating when it comes to using up beautiful things like that.

However, in the faint light of my cell-phone, I now noticed that the level of the wax was such that if the candle were to be lit, its flame would rise up to a level that is only so slightly below the open top end of the jar. If a strong wind were to blow horizontally over its top, how would the flame behave? How fast would it flicker? Would it go out?

To preserve the battery of the cell-phone, I switched it off, and then decided to spend a little time trying hard to very carefully consider the decision: whether to use this candle in the jar right away or not. I could not succeed in it—I mean, in pursuing a nice, prolonged, fair, even-handed, two-sided, balanced, etc. kind of a vacillation about it. There were issues of engineering importance here, and about a minute had already been wasted by now. Thusly, I assured myself to my entire satisfaction that I had waited for a sufficiently long time in very carefully considering the decision. And so, I grabbed that candle-in-the-jar, lit it up, and brought it to my room.

The flame fluttered. But, no, not even the relatively strong winds would put it off.

The lights (I mean the electricity) came back a little while later. But, a couple of ideas for student projects had been born, in the meanwhile. I mean, projects at the master’s level; in particular, in mechanical engineering; and in more particular, in CFD. Here I am going to share these with you.

No, I no longer much care whether I divulge such ideas on the ‘net or not. If someone on the ‘net steals my ideas, he/his work would sure come up during my regular searches, and then I would make him feel ashamed. At least, I would bring out the theft to the notice of the research community. That would be enough for me.

Just one more point before we proceed. While reading the project descriptions, if you catch yourself thinking whether these are serious projects in mechanical engineering proper or not, do one exercise after you finish reading their descriptions: (i) note down the more advanced features of the equipment and experiments, and especially of the CFD simulations/software development, (ii) note down the ranges of the parameters involved in these experiments, perform some dimensional analysis, and then, (iii) think, do ‘net searches, discuss with other people, and thereby come up with at least three separate industrial applications for each.

If you cannot do the last bit, then the next course of action depends on who you are:

(A) If you are a student, then realize that you can always do a project under some other professor, but not with me.

(B) If you are a professor of mechanical engineering yourself, send your resume to the engineering colleges in the Savitribai Phule University of Pune, including COEP; they always very highly appreciate professors like you.

Ok. Let’s now move on to the project ideas themselves.

Project Idea 1:

(2–4 PG students)

Build a longish channel of rectangular cross section out of perspex. Place it horizontally on a table top. Divide the volume of the channel into a few (say 3–4) sections, by inserting vertical perspex walls mounted at the bottom/side-ways, and going up to some 80% of the height of the channel. Let water run through the channel, say from left to right, at various controllable speeds. Sprinkle some tracers in the water, shine some bright light on it, and make a video of the flow. Image process the individual video frames and thus experimentally determine the local flow velocities. Extend and refine the experiment a bit. For instance, think of using a converging channel, channels with uneven thicknesses and depths, inclined obstacle plates, water with suspended particles, or using precision sensors for local water flow, etc. Perform a CFD analysis of all such flows, starting with modeling just one compartment as the lid-driven (but not oscillatory) flow, and then build in the increasing complexity in a step-by-step manner. Some students may focus entirely on writing/adapting software, whether in C++ or Python. Compare the simulations with the experiments. For instance, can you accurately predict the pressure drops across the successive chambers? Can you accurately predict the amount of precipitation of the sediments in the various compartments of the channel? Their location profiles?

Project Idea 2:

(1–2 PG students)

Take a glass jar of roughly the same dimensions as the one mentioned above (some 8–10 cm dia, and roughly the same height). Take some white candle wax, melt it, pour the wax into the jar, introduce some die in it, and let the melt solidify. The solidified wax should continue to show some die streaks. (If the die thingie doesn’t work, sprinkle some bright shiny particles such as the one they use at the time of the Ganapati decorations.) Take a thin copper rod (say 5–10 mm dia) and using the ordinary funnel-holding stand they use in the XI–XII chemistry labs, hold the rod vertically such that its bottom tip pierces the top wax surface to a measured depth (say 5 mm). Now, use a resistance heater (e.g. a circuit similar to that used in the ordinary soldering iron) to heat the copper rod at some distance below the holder. Attach a few thermocouples over the length of the rod between the heater and the wax; also insert a few at various places in the wax, and a few on the outer surface of the jar. Switch on the power supply and continuously record the temperatures at various places, using data-logging cards on a computer. Also, make a video of the wax undergoing melting. During image-processing, the streaks (or the embedded shiny particles) are expected to help locate the molten front. Make careful measurements, and model this process using CFD techniques.

One of the students may focus just on writing a custom-built software to simulate the process (or adapting existing Open Source software). In case you think this is a very easy problem, the answer is both yes and no. Yes, because simulations of melting and flow were done in the computer graphics field more than a decade ago; include in your ‘net search strings such as: “melting” + “flowing” + “Stanford bunny.” The answer is also a no, because as a mechanical engineering software, accuracy is of primary importance to us; mere attractive or realistic looking graphics with fluid dynamical approximations wouldn’t be enough. And, the problem is, in a way, challenging: multiple phases, transient heat transfer with phase change, and a moving interface.

Project Idea 3:

(3–4 PG students)

Design and build a working machine to experimentally study how a toothpaste fills a mould cavity. The mould cavity should be made in some transparent material. In real experiments, for reasons of costs, it would be just a simple chalk-paste, not a bought out tooth-paste. Also design and build apparatus for, or otherwise conduct, suitable experiments to accurately characterize variables/parameters such as: viscosity, wall friction, surface tension, etc. The mould-filling machine itself should allow for variations in the geometry of the inlet, the ram velocity, etc. Make videos of the filling process. Model the process using CFD software and compare with experiment. Once again, the CFD simulation here is complicated: multi-phase flow, moving boundaries, and, more importantly, non-Newtonian fluid (and flow).

Additional possibility: use a shear-thinning material such as the tomato ketchup. Pursuade some one in the food-processing industry that this is worth-while project, and obtain a large supply of the ketchup for free. As to pursuading the faculty of engineering that this is not a research in agricultural engineering alone, leave that worry alone. As with the other projects here, if our results are good, we will publish them only in the mechanical engineering journal(s).

Some of the students may focus just on writing a custom-built software. The problem again is challenging because there is a multi-phase flow, with complex boundary conditions (wall-friction is variable and important, and surface tension is important), and also, there are both moving and coalescing boundaries.

Compare the simulation with the experiment.

* * * * *  * * * * *   * * * * *

Note: Each of the above projects could also use 2–4 undergraduate students. The mix is approximate; the depth of research and the intricacy and accuracy of experiments is always a variable: sometimes, conducting even simplest-looking experiments, or building a working software, can take students a long time to complete. It all depends, on a lot of factors—including the ability of the student and the amount of hard work he puts in.

* * * * *  * * * * *   * * * * *

A Song I Like:

[Yeah, sure, Mumbaikars, go ahead and say it: “angrez gaye to zaroor, lekin jaane se pahele, apani aulaad yahaan pe chhoD gaye.” Yes, the language is not a limitation at such times; Hindi, too, is perfectly acceptable at such times, even though, the same thing can of course be expressed also in “assal” Marathi: “ingraz ithun gele tar khare, paN (or better still, pan), jaataanna aapli aulaad maatr ithech soDoon gele.” Also laugh and/or heavily clap thereafter, or exchange friendly slaps with each other, in your typical style(s).]

(Western Classical)
Composer: Mozart
Work: The Piano Concerto no. 21 in C-major (k. 467)

[Esp. andante, esp. its opening part, e.g. as in here [^]. I have given this link because it appeared on the first page in a Google search. However, I now remember, I have also listened to some other recordings that I had liked even better (though I had not noted down their particulars back then). And, yes, I have in the past listened to the full concerto, too; it has… and how do I put it… an amazing variety of “texture” at different points. … Incidentally, though popular culture makes this tune all too familiar in the Western countries, and in fact these days also in India, the fact of the matter is, the first time I heard this piece of music was when I was in twenties (about three decades ago), and at that time, it had not yet appeared everywhere. In any case, I had not heard it in a bare-bones format any time earlier, until I listened to it on a cassette. And, I remember, it was a tune I had liked the very first time I had heard it. When it comes to the Western Classical music, that’s very rare for me. In fact, speaking off-hand, this tune is one of about only two tunes of Western Classical music that I had immediately liked right on my first listening. As far as the other tune is concerned, I don’t remember its name, nor do I any longer have the cassette where I had heard it, nor have I found it during my infrequent random searches of the Western classical music on the ‘net. Some day, I will make a recording of my humming of it, and put it on the ‘net just to be able to locate it. Anyway, enjoy this piece, and bye for now; guess I won’t bother much with this post any more.]

[E&OE]

Hail Python well MATE

Hail Python! (Yes, I have converted):

As you know, I’ve been using Ubuntu LTS (currently 14.04.01). These days it has even become the OS of my primary usage. I like the current Ubuntu as much as I had liked NT4 and Win2K when they were in vogue.

I began moving away from the Windows mainly because the one IDE that I really loved, viz. VC++ 6, got superseded by a series of software that were, increasingly, unusable by me. For instance, increasingly too complex. And, increasingly too sluggish.

There then followed a period of a kind of quantum mechanical-ness: I didn’t find either Windows + Visual Studio suitable, nor did I find any of the alternatives (e.g. RedHat + vi/emacs/whatever + configure + make + GDB + …) attractive enough.

And, for some reasons unknown to me, I’ve never found Java as “my” platform.

As to Java, no, neither the personality of Scott McNealy nor the institution of the DoJ in USA had anything to do with it. In many ways, Java is a very good language, but somehow I never found the non-C++ features of it attractive even an iota: be it the lack of genericity, or the idea of downloading the bytecodes and the flakinesses of the VMs supporting it (owing mainly to the complexity of the language), or the excessive reliance on the ‘net and the big SUN servers that it implied, or, as may be shocking to you, even the famous Java reflection! (Given the other design features of Java, and the way it was handled, I thought that it was a feature for the clueless programmer—which Java programmers anyway tend to be (even if IMO the Visual Basic programmers very strongly compete with them in that department).)

And thus, I was in a state of QM-like superposition, for a long, long, time.

Partial measurements began to occur when, sometime as late as in the ‘teens, Eclipse IMO improved to the point that it wouldn’t leave a previous instance of the debug image sneakily lurking in the OS even after you thought you had terminated it. Sometime in between, Eclipse also had begun honouring the classic keyboard short-cuts of VC++: F11 would really step into a C++ function; F10 would really execute a function call without stepping into it; etc. Good!

Still, by this time, C++ “libraries” had already become huge, very huge. A code-base of a half-million LOC was routine; some exceeded millions of LOC. Further, each library assumed or required a different make system, a different version of the GCC etc., and perhaps much more importantly, none was equally well-supported on both Linux and Windows; for examples on one or more on these counts, cf. OpenFOAM, PetSc, Boost, CGAL, ParaView, QT, TAUCS, SuperLU, et al., just to name a few. The C++ template classes had become so huge that for writing even very simple applications, say a simple dialog box based GUI doing something meaningful on the numerical side, you began drowning in countless template parameters if not also namespaces. And, of course, when it came to computational engineering, there was this permanent headache of having to write wrappers even for as simple a task as translating a vector or a matrix from one library to another, just to give you an example.

I thus had actually become a low productivity C++ programmer, despite the over-abundance of the in-principle “reusable” components and packages. … I pined for the good old days of VC++ 6 on Win2K. (Last year or so, I even tried installing VC++ 6 on Win7, and then found that forget having “support”, the IDE wouldn’t even install i.e. work on Win7.)

In the meanwhile, I had noticed Python, but as they (for instance the folks painting the backsides of auto-rickshaws and trucks) in India say, (Hindi) “samay se pahele aur bhaagya se jyaadaa/adhik…” …

… Even if you allow an innovative new idea to take root in your mind, it still has to ripen a bit before it begins to make sense.

Then, this week (as you might have guessed), I happened to have an epiphany of sorts.

And, yes, as a result, I have converted!

I have become Pythonic. Well, at least Pythetic! … Pythonewbie! (Fine. This should work.)

As you know, I was going to convert my check-dams C++ code into Python. As I said in the last update of my last post, I initially began learning the language the hard way [^]. However, being a fairly accomplished C++ programmer—apart from a professional working experience of about a decade, I had also written, e.g., a yacc-like front-end taking EBNF grammar for LALR1 languages and spitting out parser-tables, just as hobby pursued on evenings—I soon got tired of learning Python the hard way, and instead opted for a softer way. I did a lot of search, downloaded `n’ number of tutorials, codes, etc., went through the Google education [^], and quickly became, as I said, a Pythonewbie.

Let me first jot down what all the components of the Python ecosystem I have downloaded and have begun already trying: wxPython, PyQT, PyOpenGL, Pyglet, VPython, matplotlib, and of course, NumPy and SciPy. I also drool at the possibilities of using the Python bindings for OpenFOAM, VTK/ParaView, CGAL, FENICS, and many, many, many others.

Why did I convert only now? Why not earlier?

Apart from (Hindi) “samay se pahele aur bhaagya se jyaadaa/adhik,” here are some more mundane reasons, listed in no particular order:

1. I was led to believe (or at least thought) that Python was a scripting language, that it is a good alternative to, say, the shell scripts.

False.

Python is—at least at this stage of development of the language and of the entire eco-system—not a language per say, but rather an ingenious tool to glue together massive but fast C/C++/FORTRAN libraries together.

2. I was also led away from Python because it lacked the cozy, secure, protective, nurturing, etc. environment of the C/C++ “{}” blocks.

I had come to like and rely on this K&R innovation so much, that a lack of the braces was one very definite (but eventually very minor) reason that Visual BASIC (and OO FORTRAN) had turned me away. As to Python, I felt plain insecure. I had a very definite fear of the program crashes any time I made a simple mistake concerning a mere indentation. … Well, that way, the C++ code I myself wrote never had the highly irritating sloppiness of the unevenly spaced indentations. But I anyway did carry this fear. (For the same reason, I found the design of the OpenFOAM input files far more comfortable than it actually is: you see, it uses a lot of braces!)

But now, I came to realize that while the fear of going block-less isn’t without reason, practically speaking, it also is largely unfounded. … Even if in Python you don’t have the protection of the C/C++ blocks, in practice, you still can’t possibly make too many mistakes about scopes and object lifetimes for the simple reason that in Python, functions themselves become so very short! (I said scope and lifetime, not visibility. Visibility does remain a different game, with its own subtleties, in Python.)

Another virtue of Python:

Another thing. Python is small. Translation: Its interpreters are sturdy. This is one count on which Java, IMO, truly floundered, and as far as I gather from others, it still does.

(No, don’t try to convince me otherwise. I also see Java’s bugs on my own. …. Just fix, for instance, that bug in the Java VM which leads to this Eclipse CDT bug. Suppose you are working on a C++ project, and so, there are a bunch of C++ files open in various tabs of the Eclipse editor. Suppose that you then open a text file, e.g. the OutputData.txt file, in an additional Eclipse tab. Then, you go to some C++ file, edit it, build it, and debug/run the program so that the OutputData.txt file on the disk changes. You switch the tab to the text file. Naturally, the tab contents needs to refreshed. Eclipse, being written in Java, is stupid enough not to refresh it automatically; it instead tells you go to the menu File/Refresh this page. That’s what happens if the text file tab isn’t the active one. [Eclipse is in version 3.8+. [Yes, it is written in Java.]] Now, if you repeatedly do this thing (even just a couple of times or so), the menu item File/Refresh is found painted in a way as if it were disabled. As far as I can make it out, it seems to be a Java VM bug, not an Eclipse bug; it also occurs in some other Java programs (though I can’t tell you off-hand which ones). In any case, go ahead San Francisco Bay-Area i.e. Java-Loving Programmer(s), fix Your Platform first, and then think of trying to convert me.)

Python becomes reliably sturdy precisely because it recognizes that it can’t and hence shouldn’t try to be good at too many things.

Python doesn’t pretend to give you any GUI or graphics capability—not even to the extent to which TurboC/C++ did. On the other hand, Java/C# tried to be masters of everything: GUI, network, graphics…. You know where they end(ed) up. And where C and even FORTRAN continue chugging along even today. (In case you didn’t know: both remain within top 5 languages, after some 50+ and 40+ years, respectively.)

The question to pose (but usually not posed) to a recent convert:

Since I am a recent convert, you may now be tempted to probe me: “Any downside to Python?”

My answer: You are right, there are downsides. It’s just that they don’t matter to me, because they aren’t relevant to me—either my personal background or my present purposes.

Python might make learning “programming” incredibly easy and fast. But if you are going to be a serious, professional programmer, there are so many principles and rules that you must additionally learn, and far too many of these are simply not accessible while working within the Python environment. Just to give you some examples: Type safety. Object life-time management, including programmer-controlled dynamic (de)allocation. Static vs. dynamic binding. Pointer arithmetic. (As to pointers: Both God and the actual hardware use it. (That’s another point against Java, and in favour of C/C++)). Stack frames. Finite memory. Etc.  Yet, at the same time, Python also merrily exposes system calls. Think of a script-kiddie delinking a file or a folder!

Yes, Python is better (much, much better) than BASIC for teaching some of the ideas of computers and programming to kids (e.g. to CBSE Std. XI kids in India). But taken as an independent language, and for the routine programming use, it would have to rank much below average.

… But then, Python shouldn’t at all be seen that way in the first place.

As I said, Python should be seen not as a language but simply as a powerful and sturdy tool for integration of an incredible variety of the super-fast C++ (even FORTRAN) libraries, in the simplest possible manner, and with cleanest—i.e., most readable kind of—source code.

Ok. Enough about Python. … I don’t say you should become a Python programmer. I merely told you the reasons why I converted.

* * * * *   * * * * *   * * * * *

What about the MATE?

Now, a word about the MATE part of the title.

I have installed the UbuntuMATE 1.8 shell on my Ubuntu 14.04.01 LTS, replacing the Gnome Unity shell.

Good riddance!

And, I have also taken this opportunity to disable the overlaying of the scroll-bars [^] (even though doing so would have been possible also on Unity, I learned only now (“samay se pahele…”)).

I feel light. Yes. Light. … Lighter. … Lightest.

The theme I run is Redmond. This way, I get the same Windows experience which I liked and still do. [No, thanks, but I won’t like to try the tiles environment even for free, let alone out of piracy.]

MATE is neat. It should be included in the official Ubuntu distro as early as possible. (I gather that they do have a definite plan to do so.)

And, in the interests of conserving mankind’s shared resources including disk-spaces, energy usage, and most importantly, mental sanity, first, all the distributions of all versions of the Unity shell should be permanently deleted from all the servers of the world, except for an archival copy or two for reference in the studies of pathological cases of the practice of computer science. Then, this archival copy should be given a permanent resting place next to that of the Microsoft Bob.

[Oh, yes, BTW, I know, the title is slightly stupid… But what else can strike you if you write something—anything—about Unity and Microsoft Bob also in the same post? Also, Java?]

* * * * *   * * * * *   * * * * *

OK. Back to trying out the different C++ libraries, now far more easily, from within the Python environment. … I am going to have to try many libraries first (and also explore Python itself further) before I come true on the promise about the next version of that check-dams toy program.

* * * * *   * * * * *   * * * * *

A Song I Like:
(Hindi) “ik raastaa hai zindagi…”
Singers: Kishore Kumar, Lata Mangeshkar
Music: Rajesh Roshan
Lyrics: Sahir Ludhianvi

[PS: This song is from 1979—the year I was in my XII. It is, thus, some 36 years old.

Going further back by 36 years, to 1943, guess we are somewhere firmly in the “unknown” territory of Hindi film songs. Sehgal’s “baabool moraa” is from even slightly earlier times, from 1938, and it sounds so quaint. Talking of 1943 proper, even the more modern sounding Anil Biswas had this “dheere dheere aa re baadal” in the movie Kismet—do check it out, how quaint it sounds to the ears of even my generation. And I am not even talking of the other “gems” of that era!

… When I was growing up, the elders would always talk about how beautiful the old songs were—and how trashy, the new ones. But come to think of it, there was a much smaller period of just 23 years between say Chori Chori (1956) and 1979, than there is between 1979 and 2015.

Yet, this song of 1979 sounds so completely modern, at least as far as its audio goes. BTW, in case you don’t know, in this section of my blog, I primarily refer only to the audio tracks of songs. Making an exception for this song, and thus referring also to its video, except for a little oddity about the kind of clothes Shashi Kapoor is seen wearing, there is almost nothing that is 35 years old to that song. … May be because of the rural/jungle settings in which it was shot. Even Shashi Kapoor’s bike looks almost every bit modern. I don’t know which one it actually was, but going by the shape of the tank, of the headlamp, and of the front side indicators, not to mention the overall way in which it takes to the road and handles the curves, I would bet that it was a Yamaha bike. (It can’t possibly be a Rajdoot 350—which also was about the same size—because the Rajdoot 350 was launched in India, I just checked, only 4 years later, in 1983—the year I graduated from COEP.)

Conclusion? There is some sort of an underlying cultural reason why people in their 50s (like me) no longer sound or even look as old as people in their 50s used to, when we were young. … Even if we now are that old. Well, at least, “mature.” [No Hollywood actresses were harmed in the writing of this post. [Hollywood is in California, USA.]]]

[E&OE]

Getting dusty…

I have been getting dusty for some time now.

… No, by “dusty” I don’t mean that dust of the “Heat and Dust” kind, even though it’s been quite the regular kind of an “unusually hot” summer this year, too.

[In case you don’t know, “Heat and Dust” was a neat movie that I vaguely recall I had liked when it had come on the scene some 2–3 decades ago. Guess I was an undergrad student at COEP or so, back then or so. (Google-devataa now informs me that the movie was released in 1983, the same year that I graduated from COEP.)]

Anyway, about the title of this post: By getting dusty, I mean that I have been trying to get some definite and very concrete beginning, on the software development side, on modelling things using “dust.” That is, particles. I mean to say, methods like molecular dynamics (MD), smoothed particle hydrodynamics (SPH), lattice Boltzmann method (LBM), etc. … I kept on postpoing writing a blog post here with the anticipation that I would succeed in tossing a neat toy code for a post.

… However, I soon came face-to-face with the  sobering truth that since becoming a professor, my programming skills have taken a (real) sharp dip.

Can you believe that I had trouble simply getting wxWidgets to work on Ubuntu/Win64? Or to get OpenGL to work on Ubuntu? It took almost two weeks for me to do that! (And, I haven’t yet got OpenGL to work with wxWidgets on Ubuntu!) … So, finally, I (once again) gave up the idea of doing some neat platform-neutral C++ work, and, instead (once again) went back to VC++. Then there was a problem awaiting me regarding VC++ too.

Actually, I had written a blog post against the modern VC++ at iMechanica and all (link to be inserted) but that was quite some time back (may be a couple of years or so). In the meanwhile, I had forgotten how bad VC++ has really become over the years, and I had to rediscover that discouraging fact once again!

So, I then tried installing VC++ 6 on Win7 (64-bit)—and, yet another ugly surprise. VC++ 6 won’t run on Win7. It’s possible to do that using some round-about ways, but it all is now a deprecated technology.

Finally, I resigned myself to using VC++ 10 on Win7. Three weeks of precious vacation time already down!

That‘s what I meant when I said how bad a programmer I have turned out to be, these days.

Anyway, that’s when I finally could begin writing some real though decidedly toy code for some simple MD, just so that I could play around with it a bit.

Though writing MD code seems such a simple, straight-forward game (what’s the Verlet algorithm if not plain and simple FDM?), I soon realized that there are some surprises in it, too.

All of the toy MD code to be found on the Internet (and some of the serious code, too) assumes only a neat rectangular or a brick-like domain. If you try to accommodate an arbitrary shaped domain (even if only with straight-lines for boundaries), you immediately run into the run-time efficiency issues. The matter gets worse if you try to accommodate holes in the domain—e.g., a square hole in a square domain like what my Gravatar icon shows. (It was my initial intention to quickly do an MD simulation for this flow through square cavity having a square hole.)

Next, once you are able to handle arbitrarily shaped domains with arbitrarily shaped holes, small bugs begin to show up. Sometimes, despite no normal flux condition, my particles were able to slip past the domain boundaries, esp. near the points where two bounding edges meet. However, since the occurrence was rare, and hard to debug for (what do you do if it happens only in the 67,238th iteration? hard-code a break after 67,237, recompile, run, go off for a coffee?) I decided to downscale the complexity of the basic algorithm.

So, instead of using the Lennard-Jones potential (or some other potential), I decided to switch off the potential field completely, and have some simple perfectly hard and elastically colliding disks. (I did implement separate shear and normal frictions at the time of collisions, though. (Of course, the fact that frictions don’t let the particles be attracted, ever, is a different story, but, remember, we are trying to be simple here.)) The particles were still managing to escape the domain, at rare times. But at least, modelling with the hard elastic disks allowed me to locate the bugs better. Turned out to be a very, very stupid-some matter: my algorithm had to take care for a finite-sized particle interacting with the boundary edges.

But, yes, I could then get something like more than 1000 particles happily go colliding with each other for more than 10^8 collisions. (No, I haven’t parallelized the code. I merely let it run on my laptop while I was attending in a longish academics-related meeting.)

Another thing: Some of the code on the ‘net, I found, simply won’t work for even a modestly longer simulation run.  For instance, Amit Kumar’s code here [^]. (Sorry Amit, I should have written you first. Will drop you a line as soon as this over-over-overdue post is out the door.) The trouble with such codes is with the time-step, I guess. … I don’t know for sure, yet; I am just loud-thinking about the reason. And, I know for a fact that if you use Amit’s parameter values, a gas explosion is going to occur rather soon, may be right after something like 10^5 collisions or so. Java runs too slowly and so Amit couldn’t have noticed it, but that’s what happens with those parameter values in my C++ code.

I haven’t yet fixed all my bugs, and in fact, haven’t yet implemented the Lennard-Jones model for the arbitrarily shaped domains (with (multiple) holes). I thought I should first factor out the common code well, and then proceed. … And that’s when other matters of research took over.

Well, why did I get into MD, in the first place? Why didn’t I do something useful starting off with the LBM?

Well, the thing is like this. I know from my own experience that this idea of a stationary control volume and a moving control volume is difficult for students to get. I thought it would be easy to implement an MD fluid, and then, once I build in the feature of “selecting” (or highlighting) a small group of molecules close to each other, with these molecules together forming a “continuous” fluid parcel, I could then directly show my students how this parcel evolves with the fluid motion—how the location, shape, momentum and density of the parcel undergoes changes. They could visually see the difference between the Eulerian and Lagrangian descriptions. That, really speaking, was my motivation.

But then, as I told you, I discovered that I have regressed low enough to have become a very bad programmer by now.

Anyway, playing around this way also gave me some new ideas. If you have been following this blog for some time, you would know that I have been writing in favor of homeopathy. While implementing my code, I thought that it might be a good idea to implement not just LJ, but also the dipole nature of water molecules, and see how the virtual water behaves: does it show the hypothesized character of persistence of structure or not. (Yes, you read it here first.) But, what the hell, I have far too many other things lined up for me to pursue this thread right away. But, sure, it’s very interesting to me, and so, I will do something in that direction some time in future.

Once I get my toy MD code together (for both hard-disk and LJ/other potentials models, via some refactorability/extensibility thrown in), then I guess I would move towards a toy SPH code. … Or at least that’s what I guess would be the natural progression in all this toys-building activity. This way, I could reuse many of my existing MD classes. And so, LBM should logically follow after SPH—what do you think? (And, yes, I will have to take the whole thing from the current 2D to 3D, sometime in future, too.)

And, all of that is, of course, assuming that I manage to become a better programmer.

Before closing, just one more note: This vacation, I tried Python too, but found that (i) to accomplish the same given functional specs, my speed of development using C++ is almost the same (if not better) than my speed with Python, and (ii) I keep missing the nice old C/C++ braces for the local scope. Call it the quirky way in which an old programmer’s dusty mind works, but at least for the time being, I am back to C++ from that brief detour to Python.

Ok, more, later.

* * * * *   * * * * *   * * * * *

A Song I Like:
(Marathi) “waaT sampataa sampenaa, kuNi waaTet bhetenaa…”
Music: Datta Dawajekar
Lyrics: Devakinandan Saaraswat
Singer: Jayawant Kulkarni

[PS: A revision is perhaps due for streamlining the writing. May be I will come back and do that.]

[E&OE]