# Python scripts for simulating QM, part 0: A general update

My proposed paper on my new approach to QM was not accepted at the international conference where I had sent my abstract. (For context, see the post before the last, here [^] ).

“Thank God,” that’s what I actually felt when I received this piece of news, “I can now immediately proceed to procrastinate on writing the full-length paper, and also, simultaneously, un-procrastinate on writing some programs in Python.”

So far, I have written several small and simple code-snippets. All of these were for the usual (text-book) cases; all in only $1D$. Here in this post, I will mention specifically which ones…

Time-independent Schrodinger equation (TISE):

Here, I’ve implemented a couple of scripts, one for finding the eigen-vectors and -values for a particle in a box (with both zero and arbitrarily specified potentials) and another one for the quantum simple harmonic oscillator.

These were written not with the shooting method (which is the method used in the article by Rhett Allain for the Wired magazine [^]) but with the matrix method. … Yes, I have gone past the stage of writing all the numerical analysis algorithm in original, all by myself. These days, I directly use Python libraries wherever available, e.g., NumPy’s LinAlg methods. That’s why, I preferred the matrix method. … My code was not written from scratch; it was based on Cooper’s code “qp_se_matrix”, here [PDF ^]).

Time-dependent Schrodinger equation (TDSE):

Here, I tried out a couple of scripts.

The first one was more or less a straightforward porting of Ian Cooper’s program “se_fdtd” [PDF ^] from the original MatLab to Python. The second one was James Nagel’s Python program (written in 2007 (!) and hosted as a SciPy CookBook tutorial, here [^]). Both follow essentially the same scheme.

Initially, I found this scheme to be a bit odd to follow. Here is what it does.

It starts out by replacing the complex-valued Schrodinger equation with a pair of real-valued (time-dependent) equations. That was perfectly OK by me. It was their discretization which I found to be a bit peculiar. The discretization scheme here is second-order in both space and time, and yet it involves explicit time-stepping. That’s peculiar, so let me write a detailed note below (in part, for my own reference later on).

Also note: Though both Cooper and Nagel implement essentially the same method, Nagel’s program is written in Python, and so, it is easier to discuss (because the array-indexing is 0-based). For this reason, I might make a direct reference only to Nagel’s program even though it is to be understood that the same scheme is found implemented also by Cooper.

A note on the method implemented by Nagel (and also by Cooper):

What happens here is that like the usual Crank-Nicolson (CN) algorithm for the diffusion equation, this scheme too puts the half-integer time-steps to use (so as to have a second-order approximation for the first-order derivative, that of time). However, in the present scheme, the half-integer time-steps turn out to be not entirely fictitious (the way they are, in the usual CN method for the single real-valued diffusion equation). Instead, all of the half-integer instants are fully real here in the sense that they do enter the final discretized equations for the time-stepping.

The way that comes to happen is this: There are two real-valued equations to solve here, coupled to each other—one each for the real and imaginary parts. Since both the equations have to be solved at each time-step, what this method does is to take advantage of that already existing splitting of the time-step, and implements a scheme that is staggered in time. (Note, this scheme is not staggered in space, as in the usual CFD codes; it is staggered only in time.) Thus, since it is staggered and explicit, even the finite-difference quantities that are defined only at the half-integer time-steps, also get directly involved in the calculations. How precisely does that happen?

The scheme defines, allocates memory storage for, and computationally evaluates the equation for the real part, but this computation occurs only at the full-integer instants ($n = 0, 1, 2, \dots$). Similarly, this scheme also defines, allocates memory for, and computationally evaluates the equation for the imaginary part; however, this computation occurs only at the half-integer instants ($n = 1/2, 1+1/2, 2+1/2, \dots$). The particulars are as follows:

The initial condition (IC) being specified is, in general, complex-valued. The real part of this IC is set into a space-wide array defined for the instant $n$; here, $n = 0$. Then, the imaginary part of the same IC is set into a separate array which is defined nominally for a different instant: $n+1/2$. Thus, even if both parts of the IC are specified at $t = 0$, the numerical procedure treats the imaginary part as if it was set into the system only at the instant $n = 1/2$.

Given this initial set-up, the actual time-evolution proceeds as follows:

• The real-part already available at $n$ is used in evaluating the “future” imaginary part—the one at $n+1/2$
• The imaginary part thus found at $n+1/2$ is used, in turn, for evaluating the “future” real part—the one at $n+1$.

At this point that you are allowed to say: lather, wash, repeat… Figure out exactly how. In particular, notice how the simulation must proceed in integer number of pairs of computational steps; how the imaginary part is only nominally (i.e. only computationally) distant in time from its corresponding real part.

Thus, overall, the discretization of the space part is pretty straight-forward here: the second-order derivative (the Laplacian) is replaced by the usual second-order finite difference approximation. However, for the time-part, what this scheme does is both similar to, and different from, the usual Crank-Nicolson scheme.

Like the CN scheme, the present scheme also uses the half-integer time-levels, and thus manages to become a second-order scheme for the time-axis too (not just space), even if the actual time interval for each time-step remains, exactly as in the CN, only $\Delta t$, not $2\Delta t$.

However, unlike the CN scheme, this scheme still remains explicit. That’s right. No matrix equation is being solved at any time-step. You just zip through the update equations.

Naturally, the zipping through comes with a “cost”: The very scheme itself comes equipped with a stability criterion; it is not unconditionally stable (the way CN is). In fact, the stability criterion now refers to half of the time-interval, not full, and thus, it is a bit even more restrictive as to how big the time-step ($\Delta t$) can be given a certain granularity of the space-discretization ($\Delta x$). … I don’t know, but guess that this is how they handle the first-order time derivatives in the FDTD method (finite difference time domain). May be the physics of their problems itself is such that they can get away with coarser grids without being physically too inaccurate, who knows…

Other aspects of the codes by Nagel and Cooper:

For the initial condition, both Cooper and Nagel begin with a “pulse” of a cosine function that is modulated to have the envelop of the Gaussian. In both their codes, the pulse is placed in the middle, and they both terminate the simulation when it reaches an end of the finite domain. I didn’t like this aspect of an arbitrary termination of the simulation.

However, I am still learning the ropes for numerically handling the complex-valued Schrodinger equation. In any case, I am not sure if I’ve got good enough a handle on the FDTD-like aspects of it. In particular, as of now, I am left wondering:

What if I have a second-order scheme for the first-order derivative of time, but if it comes with only fictitious half-integer time-steps (the way it does, in the usual Crank-Nicolson method for the real-valued diffusion equation)? In other words: What if I continue to have a second-order scheme for time, and yet, my scheme does not use leap-frogging? In still other words: What if I define both the real and imaginary parts at the same integer time-steps $n = 0, 1, 2, 3, \dots$ so that, in both cases, their values at the instant $n$ are directly fed into both their values at $n+1$?

In a way, this scheme seems simpler, in that no leap-frogging is involved. However, notice that it would also be an implicit scheme. I would have to solve two matrix-equations at each time-step. But then, I could perhaps get away with a larger time-step than what Nagel or Cooper use. What do you think? Is checker-board patterning (the main reason why we at all use staggered grids in CFD) an issue here—in time evolution? But isn’t the unconditional stability too good to leave aside without even trying? And isn’t the time-axis just one-way (unlike the space-axis that has BCs at both ends)? … I don’t know…

PBCs and ABCs:

Even as I was (and am) still grappling with the above-mentioned issue, I also wanted to make some immediate progress on the front of not having to terminate the simulation (once the pulse reached one of the ends of the domain).

So, instead of working right from the beginning with a (literally) complex Schrodinger equation, I decided to first model the simple (real-valued) diffusion equation, and to implement the PBCs (periodic boundary conditions) for it. I did.

My code seems to work, because the integral of the dependent variable (i.e., the total quantity of the diffusing quantity present in the entire domain—one with the topology of a ring) does seem to stay constant—as is promised by the Crank-Nicolson scheme. The integral stays “numerically the same” (within a small tolerance) even if obviously, there are now fluxes at both the ends. (An initial condition of a symmetrical saw-tooth profile defined between $y = 0.0$ and $y = 1.0$, does come to asymptotically approach the horizontal straight-line at $y = 0.5$. That is what happens at run-time, so obviously, the scheme seems to handle the fluxes right.)

Anyway, I don’t always write everything from the scratch; I am a great believer in lifting codes already written by others (with attribution, of course :)). Thus, while thus searching on the ‘net for some already existing resources on numerically modeling the Schrodinger equation (preferably with code!), I also ran into some papers on the simulation of SE using ABCs (i.e., the absorbing boundary conditions). I was not sure, however, if I should implement the ABCs immediately…

As of today, I think that I am going to try and graduate from the transient diffusion equation (with the CN scheme and PBCs), to a trial of the implicit TDSE without leap-frogging, as outlined above. The only question is whether I should throw in the PBCs to go with that or the ABCs. Or, may be, neither, and just keep pinning the  $\Psi$ values for the end- and ghost-nodes down to $0$, thereby effectively putting the entire simulation inside an infinite box?

At this point of time, I am tempted to try out the last. Thus, I think that I would rather first explore the staggering vs. non-staggering issue for a pulse in an infinite box, and understand it better, before proceeding to implement either the PBCs or the ABCs. Of course, I still have to think more about it… But hey, as I said, I am now in a mood of implementing, not of contemplating.

Why not upload the programs right away?

BTW, all these programs (TISE with matrix method, TDSE on the lines of Nagel/Cooper’s codes, transient DE with PBCs, etc.) are still in a fluid state, and so, I am not going to post them immediately here (though over a period of time, I sure would).

The reason for not posting the code runs something like this: Sometimes, I use the Python range objects for indexing. (I saw this goodie in Nagel’s code.) At other times, I don’t. But even when I don’t use the range objects, I anyway am tempted to revise the code so as to have them (for a better run-time efficiency).

Similarly, for the CN method, when it comes to solving the matrix equation at each time-step, I am still not using the TDMA (the Thomas algorithm) or even just sparse matrices. Instead, right now, I am allocating the entire $N \times N$ sized matrices, and am directly using NumPy’s LinAlg’s solve() function on these biggies. No, the computational load doesn’t show up; after all, I anyway have to use a 0.1 second pause in between the rendering passes, and the biggest matrices I tried were only $1001 \times 1001$ in size. (Remember, this is just a $1D$ simulation.) Even then, I am tempted a bit to improve the efficiency. For these and similar reasons, some or the other tweaking is still going on in all the programs. That’s why, I won’t be uploading them right away.

Anything else about my new approach, like delivering a seminar or so? Any news from the Indian physicists?

I had already contacted a couple of physics professors from India, both from Pune: one, about 1.5 years ago, and another, within the last 6 months. Both these times, I offered to become a co-guide for some computational physics projects to be done by their PG/UG students or so. Both times (what else?) there was absolutely no reply to my emails. … If they were to respond, we could have together progressed further on simulating my approach. … I have always been “open” about it.

The above-mentioned experience is precisely similar to how there have been no replies when I wrote to some other professors of physics, i.e., when I offered to conduct a seminar (covering my new approach) in their departments. Particularly, from the young IISER Pune professor whom I had written. … Oh yes, BTW, there has been one more physicist who I contacted recently for a seminar (within the last month). Once again, there has been no reply. (This professor is known to enjoy hospitality abroad as an Indian, and also use my taxpayer’s money for research while in India.)

No, the issue is not whether the emails I write using my Yahoo! account go into their span folder—or something like that. That would be too innocuous a cause, and too easy to deal with—every one has a mobile-phone these days. But I know these (Indian) physicists. Their behaviour remains exactly the same even if I write my emails using a respectable academic email ID (my employers’, complete with a .edu domain). This was my experience in 2016, and it repeated again in 2017.

The bottom-line is this: If you are an engineer and if you write to these Indian physicists, there is almost a guarantee that your emails will go into a black-hole. They will not reply to you even if you yourself have a PhD, and are a Full Professor of engineering (even if only on an ad-hoc basis), and have studied and worked abroad, and even if your blog is followed internationally. So long as you are engineer, and mention QM, the Indian physicists simply shut themselves off.

However, there is a trick to get them to reply you. Their behavior does temporarily change when you put some impressive guy in your cc-field (e.g., some professor friend of yours from some IIT). In this case, they sometimes do reply your first email. However, soon after that initial shaking of hands, they somehow go back to their true core; they shut themselves off.

And this is what invariably happens with all of them—no matter what other Indian bloggers might have led you to believe.

There must be some systemic reasons for such behavior, you say? Here, I will offer a couple of relevant observations.

Systemically speaking, Indian physicists, taken as a group (and leaving any possible rarest of the rare exceptions aside), all fall into one band: (i) The first commonality is that they all are government employees. (ii) The second commonality they all tend to be leftists (or, heavily leftists). (iii) The third commonality is they (by and large) share is that they had lower (or far lower) competitive scores in the entrance examinations at the gateway points like XII, GATE/JAM, etc.

The first factor typically means that they know that no one is going to ask them why they didn’t reply (even to people like with my background). The second factor typically means that they don’t want to give you any mileage, not even just a plain academic respect, if you are not already one of “them”. The third factor typically means that they simply don’t have the very intellectual means to understand or judge anything you say if it is original—i.e., if it is not based on some work of someone from abroad. In plain words: they are incompetent. (That in part is the reason whenever I run into a competent Indian physicist, it is both a surprise and a pleasure. To drop a couple of names: Prof. Kanhere (now retired) from UoP (now SPPU), and Prof. Waghmare of JNCASR. … But leaving aside this minuscule minority, and coming to the rest of the herd: the less said, the better.)

In short, Indian physicists all fall into a band. And they all are very classical—no tunneling is possible. Not with these Indian physicists. (The trends, I guess, are similar all over the world. Yet, I definitely can say that Indians are worse, far worse, than people from the advanced, Western, countries.)

Anyway, as far as the path through the simulations goes, since no help is going to come from these government servants (regarded as physicists by foreigners), I now realized that I have to get going about it—simulations for my new approach—entirely on my own. If necessary, from the basic of the basics. … And that’s how I got going with these programs.

Are these programs going to provide a peek into my new approach?

No, none of these programs I talked about in this post is going to be very directly helpful for simulations related to my new approach. The programs I wrote thus far are all very, very standard (simplest UG text-book level) stuff. If resolving QM riddles were that easy, any number of people would have done it already.

… So, the programs I wrote over the last couple of weeks are nothing but just a beginning. I have to cover a lot of distance. It may take months, perhaps even a year or so. But I intend to keep working at it. At least in an off and on manner. I have no choice.

And, at least currently, I am going about it at a fairly good speed.

For the same reason, expect no further blogging for another 2–3 weeks or so.

But one thing is for certain. As soon as my paper on my new approach (to be written after running the simulations) gets written, I am going to quit QM. The field does not hold any further interest to me.

Coming to you: If you still wish to know more about my new approach before the paper gets written, then you convince these Indian professors of physics to arrange for my seminar. Or, else…

… What else? Simple! You. Just. Wait.

[Or see me in person if you would be visiting India. As I said, I have always been “open” from my side, and I continue to remain so.]

A song I like:
(Hindi) “bheegee bheegee fizaa…”
Music: Hemant Kumar
Singer: Asha Bhosale
Lyrics: Kaifi Aazmi

History:
Originally published: 2018.11.26 18:12 IST
Extension and revision: 2018.11.27 19.29 IST

# A list of books for understanding the non-relativistic QM

TL;DR: NFY (Not for you).

In this post, I will list those books which have been actually helpful to me during my self-studies of QM.

But before coming to the list, let me first note down a few points which would be important for engineers who wish to study QM on their own. After all, my blog is regularly visited by engineers too. That’s what the data about the visit patterns to various posts says.

Others (e.g. physicists) may perhaps skip over the note in the next section, and instead jump directly over to the list itself. However, even if the note for engineers is too long, perhaps, physicists should go through it too. If they did, they sure would come to know a bit more about the kind of background from which the engineers come.

# I. A note for engineers who wish to study QM on their own:

The point is this: QM is vast, even if its postulates are just a few. So, it takes a prolonged, sustained effort to learn it.

For the same reason (of vastness), learning QM also involves your having to side-by-side learn an entirely new approach to learning itself. (If you have been a good student of engineering, chances are pretty good that you already have some first-hand idea about this meta-learning thing. But the point is, if you wish to understand QM, you have to put it to use once again afresh!)

In terms of vastness, QM is, in some sense, comparable to this cluster of subjects spanning engineering and physics: engineering thermodynamics, statistical mechanics, kinetics, fluid mechanics, and heat- and mass-transfer.

I.1 Thermodynamics as a science that is hard to get right:

The four laws of thermodynamics (including the zeroth and the third) are easy enough to grasp—I mean, in the simpler settings. But when it comes to this subject (as also for the Newtonian mechanics, i.e., from the particle to the continuum mechanics), God lies not in the postulates but in their applications.

The statement of the first law of thermodynamics remains the same simple one. But complexity begins to creep in as soon as you begin to dig just a little bit deeper with it. Entire categories of new considerations enter the picture, and the meaning of the same postulates gets both enriched and deepened with them. For instance, consider the distinction of the open vs. the closed vs. the isolated systems, and the corresponding changes that have to be made even to the mathematical statements of the law. That’s just for the starters. The complexity keeps increasing: studies of different processes like adiabatic vs. isochoric vs. polytropic vs. isentropic etc., and understanding the nature of these idealizations and their relevance in diverse practical applications such as: steam power (important even today, specifically, in the nuclear power plants), IC engines, jet turbines, refrigeration and air-conditioning, furnaces, boilers, process equipment, etc.; phase transitions, material properties and their variations; empirical charts….

Then there is another point. To really understand thermodynamics well, you have to learn a lot of other subjects too. You have to go further and study some different but complementary sciences like heat and mass transfer, to begin with. And to do that well, you need to study fluid dynamics first. Kinetics is practically important too; think of process engineering and cost of energy. Ideas from statistical mechanics are important from the viewpoint of developing a fundamental understanding. And then, you have to augment all this study with all the empirical studies of the irreversible processes (think: the boiling heat transfer process). It’s only when you study such an entire gamut of topics and subjects that you can truly come to say that you now have some realistic understanding of the subject matter that is thermodynamics.

Developing understanding of the aforementioned vast cluster of subjects (of thermal sciences) is difficult; it requires a sustained effort spanning over years. Mistakes are not only very easily possible; in engineering schools, they are routine. Let me illustrate this point with just one example from thermodynamics.

Consider some point that is somewhat nutty to get right. For instance, consider the fact that no work is done during the free expansion of a gas. If you are such a genius that you could correctly get this point right on your very first reading, then hats off to you. Personally, I could not. Neither do I know of even a single engineer who could. We all had summarily stumbled on some fine points like this.

You see, what happens here is that thermodynamics and statistical mechanics involve entirely different ways of thinking, but they both are being introduced almost at the same time during your UG studies. Therefore, it is easy enough to mix up the some disparate metaphors coming from these two entirely different paradigms.

Coming to the specific example of the free expansion, initially, it is easy enough for you to think that since momentum is being carried by all those gas molecules escaping the chamber during the free expansion process, there must be a leakage of work associated with it. Further, since the molecules were already moving in a random manner, there must be an accompanying leakage of the heat too. Both turn out to be wrong ways of thinking about the process! Intuitions about thermodynamics develop only slowly. You think that you understood what the basic idea of a system and an environment is like, but the example of the free expansion serves to expose the holes in your understanding. And then, it’s not just thermo and stat mech. You have to learn how to separate both from kinetics (and they all, from the two other, closely related, thermal sciences: fluid mechanics, and heat and mass transfer).

But before you can learn to separate out the unique perspectives of these subject matters, you first have to learn their contents! But the way the university education happens, you also get exposed to them more or less simultaneously! (4 years is as nothing in a career that might span over 30 to 40 years.)

Since you are learning a lot many different paradigms at the same time, it is easy enough to naively transfer your fledgling understanding of one aspect of one paradigm (say, that of the particle or statistical mechanics) and naively insert it, in an invalid manner, into another paradigm which you are still just learning to use at roughly the same time (thermodynamics). This is what happens in the case of the free expansion of gases. Or, of throttling. Or, of the difference between the two… It is a rare student who can correctly answer all the questions on this topic, during his oral examination.

Now, here is the ultimate point: Postulates-wise, thermodynamics is independent of the rest of the subjects from the aforementioned cluster of subjects. So, in theory, you should be able to “get” thermodynamics—its postulates, in all their generality—even without ever having learnt these other subjects.

Yet, paradoxically enough, we find that complicated concepts and processes also become easier to understand when they are approached using many different conceptual pathways. A good example here would be the concept of entropy.

When you are a XII standard student (or even during your first couple of years in engineering), you are, more or less, just getting your feet wet with the idea of the differentials. As it so happens, before you run into the concept of entropy, virtually every physics concept was such that it was a ratio of two differentials. For instance, the instantaneous velocity is the ratio of d(displacement) over d(time). But the definition of entropy involves a more creative way of using the calculus: it has a differential (and that too an inexact differential), but only in the numerator. The denominator is a “plain-vanilla” variable. You have already learnt the maths used in dealing with the rates of changes—i.e. the calculus. But that doesn’t mean that you have an already learnt physical imagination with you which would let you handle this kind of a definition—one that involves a ratio of a differential quantity to an ordinary variable. … “Why should only one thing change even as the other thing remains steadfastly constant?” you may wonder. “And if it is anyway going to stay constant, then is it even significant? (Isn’t the derivative of a constant the zero?) So, why not just throw the constant variable out of the consideration?” You see, one major reason you can’t deal with the definition of entropy is simply because you can’t deal with the way its maths comes arranged. Understanding entropy in a purely thermodynamic—i.e. continuum—context can get confusing, to say the least. But then, just throw in a simple insight from Boltzmann’s theory, and suddenly, the bulb gets lit up!

So, paradoxically enough, even if multiple paradigms mean more work and even more possibilities of confusion, in some ways, having multiple approaches also does help.

When a subject is vast, and therefore involves multiple paradigms, people regularly fail to get certain complex ideas right. That happens even to very smart people. For instance, consider Maxwell’s daemon. Not many people could figure out how to deal with it correctly, for such a long time.

…All in all, it is only some time later, when you have already studied all these topics—thermodynamics, kinetics, statistical mechanics, fluid mechanics, heat and mass transfer—that finally things begin to fall in place (if they at all do, at any point of time!). But getting there involves hard effort that goes on for years: it involves learning all these topics individually, and then, also integrating them all together.

In other words, there is no short-cut to understanding thermodynamics. It seems easy enough to think that you’ve understood the 4 laws the first time you ran into them. But the huge gaps in your understanding begin to become apparent only when it comes to applying them to a wide variety of situations.

I.2 QM is vast, and requires multiple passes of studies:

Something similar happens also with QM. It too has relatively few postulates (3 to 6 in number, depending on which author you consult) but a vast scope of applicability. It is easy enough to develop a feeling that you have understood the postulates right. But, exactly as in the case of thermodynamics (or Newtonian mechanics), once again, the God lies not in the postulates but rather in their applications. And in case of QM, you have to hasten to add: the God also lies in the very meaning of these postulates—not just their applications. QM carries a one-two punch.

Similar to the case of thermodynamics and the related cluster of subjects, it is not possible to “get” QM in the first go. If you think you did, chances are that you have a superhuman intelligence. Or, far, far more likely, the plain fact of the matter is that you simply didn’t get the subject matter right—not in its full generality. (Which is what typically happens to the CS guys who think that they have mastered QM, even if the only “QM” they ever learnt was that of two-state systems in a finite-dimensional Hilbert space, and without ever acquiring even an inkling of ideas like radiation-matter interactions, transition rates, or the average decoherence times.)

The only way out, the only way that works in properly studying QM is this: Begin studying QM at a simpler level, finish developing as much understanding about its entire scope as possible (as happens in the typical Modern Physics courses), and then come to studying the same set of topics once again in a next iteration, but now to a greater depth. And, you have to keep repeating this process some 4–5 times. Often times, you have to come back from iteration n+2 to n.

As someone remarked at some forum (at Physics StackExchange or Quora or so), to learn QM, you have to give it “multiple passes.” Only then can you succeed understanding it. The idea of multiple passes has several implications. Let me mention only two of them. Both are specific to QM (and not to thermodynamics).

First, you have to develop the art of being able to hold some not-fully-satisfactory islands of understanding, with all the accompanying ambiguities, for extended periods of time (which usually runs into years!). You have to learn how to give a second or a third pass even when some of the things right from the first pass are still nowhere near getting clarified. You have to learn a lot of maths on the fly too. However, if you ask me, that’s a relatively easier task. The really difficult part is that you have to know (or learn!) how to keep forging ahead, even if at the same time, you carry a big set of nagging doubts that no one seems to know (or even care) about. (To make the matters worse, professional physicists, mathematicians and philosophers proudly keep telling you that these doubts will remain just as they are for the rest of your life.) You have to learn how to shove these ambiguous and un-clarified matters to some place near the back of your mind, you have to learn how to ignore them for a while, and still find the mental energy to once again begin right from the beginning, for your next pass: Planck and his cavity radiation, Einstein, blah blah blah blah blah!

Second, for the same reason (i.e. the necessity of multiple passes and the nature of QM), you also have to learn how to unlearn certain half-baked ideas and replace them later on with better ones. For a good example, go through Dan Styer’s paper on misconceptions about QM (listed near the end of this post).

Thus, two seemingly contradictory skills come into the play: You have to learn how to hold ambiguities without letting them affect your studies. At the same time, you also have to learn how not to hold on to them forever, or how to unlearn them, when the time to do becomes ripe.

Thus, learning QM does not involve just learning of new contents. You also have learn this art of building a sufficiently “temporary” but very complex conceptual structure in your mind—a structure that, despite all its complexity, still is resilient. You have to learn the art of holding such a framework together over a period of years, even as some parts of it are still getting replaced in your subsequent passes.

And, you have to compensate for all the failings of your teachers too (who themselves were told, effectively, to “shut up and calculate!”) Properly learning QM is a demanding enterprise.

# II. The list:

Now, with that long a preface, let me come to listing all the main books that I found especially helpful during my various passes. Please remember, I am still learning QM. I still don’t understand the second half of most any UG book on QM. This is a factual statement. I am not ashamed of it. It’s just that the first half itself managed to keep me so busy for so long that I could not come to studying, in an in-depth manner, the second half. (By the second half, I mean things like: the QM of molecules and binding, of their spectra, QM of solids, QM of complicated light-matter interactions, computational techniques like DFT, etc.) … OK. So, without any further ado, let me jot down the actual list.  I will subdivide it in several sub-sections

II.0. Junior-college (American high-school) level:

Obvious:

• Resnick and Halliday.
• Thomas and Finney. Also, Allan Jeffrey

II.1. Initial, college physics level:

• “Modern physics” by Beiser, or equivalent
• Optional but truly helpful: “Physical chemistry” by Atkins, or equivalent, i.e., only the parts relevant to QM. (I know engineers often tend to ignore the chemistry books, but they should not. In my experience, often times, chemistry books do a superior job of explaining physics. Physics, to paraphrase a witticism, is far too important to be left to the physicists!)

II.2. Preparatory material for some select topics:

• “Physics of waves” by Howard Georgi. Excellence written all over, but precisely for the same reason, take care to avoid the temptation to get stuck in it!
• Maths: No particular book, but a representative one would be Kreyszig, i.e., with Thomas and Finney or Allan Jeffrey still within easy reach.
• There are a few things you have to relearn, if necessary. These include: the idea of the limits of sequences and series. (Yes, go through this simple a topic too, once again. I mean it!). Then, the limits of functions.
Also try to relearn curve-tracing.
• Unlearn (or throw away) all the accounts of complex numbers which remain stuck at the level of how $\sqrt{-1}$ was stupefying, and how, when you have complex numbers, any arbitrary equation magically comes to have roots, etc. Unlearn all that talk. Instead, focus on the similarities of complex numbers to both the real numbers and vectors, and also their differences from each. Unlike what mathematicians love to tell you, complex numbers are not just another kind of numbers. They don’t represent just the next step in the logic of how the idea of numbers gets generalized as go from integers to real numbers. The reason is this: Unlike the integers, rationals, irrationals and reals, complex numbers take birth as composite numbers (as a pair of numbers that is ordered too), and they remain that way until the end of their life. Get that part right, and ignore all the mathematicians’ loose talk about it.
Study complex numbers in a way that, eventually, you should find yourself being comfortable with the two equivalent ways of modeling physical phenomena: as a set of two coupled real-valued differential equations, and as a single but complex-valued differential equation.
• Also try to become proficient with the two main expansions: the Taylor, and the Fourier.
• Also develop a habit of quickly substituting truncated expansions (i.e., either a polynomial, or a sum complex exponentials having just a few initial harmonics, not an entire infinity of them) into any “arbitrary” function as an ansatz, and see how the proposed theory pans out with these. The goal is to become comfortable, at the same time, with a habit of tracing conceptual pathways to the meaning of maths as well as with the computational techniques of FDM, FEM, and FFT.
• The finite differences approximation: Also, learn the art of quickly substituting the finite differences ($\Delta$‘s) in place of the differential quantities ($d$ or $\partial$) in a differential equation, and seeing how it pans out. The idea here is not just the computational modeling. The point is: Every differential equation has been derived in reference to an elemental volume which was then taken to a vanishingly small size. The variation of quantities of interest across such (infinitesimally small) volume are always represented using the Taylor series expansion.
(That’s correct! It is true that the derivations using the variational approach don’t refer to the Taylor expansion. But they also don’t use infinitesimal volumes; they refer to finite or infinite domains. It is the variation in functions which is taken to the vanishingly small limit in their case. In any case, if your derivation has an infinitesimall small element, bingo, you are going to use the Taylor series.)
Now, coming back to why you must learn develop the habit of having a finite differences approximation in place of a differential equation. The thing is this: By doing so, you are unpacking the derivation; you are traversing the analysis in the reverse direction, you are by the logic of the procedure forced to look for the physical (or at least lower-level, less abstract) referents of a mathematical relation/idea/concept.
While thus going back and forth between the finite differences and the differentials, also learn the art of tracing how the limiting process proceeds in each such a case. This part is not at all as obvious as you might think. It took me years and years to figure out that there can be infinitesimals within infinitesimals. (In fact, I have blogged about it several years ago here. More recently, I wrote a PDF document about how many numbers are there in the real number system, which discusses the same idea, from a different angle. In any case, if you were not shocked by the fact that there can be an infinity of infinitesimals within any infinitesimal, either think sufficiently long about it—or quit studying foundations of QM.)

II.3. Quantum chemistry level (mostly concerned with only the TISE, not TDSE):

• Optional: “QM: a conceptual approach” by Hameka. A fairly well-written book. You can pick it up for some serious reading, but also try to finish it as fast as you can, because you are going to relean the same stuff once again through the next book in the sequence. But yes, you can pick it up; it’s only about 200 pages.
• “Quantum chemistry” by McQuarrie. Never commit the sin of bypassing this excellent book.
A suggestion: Once you finish reading through this particular book, take a small (40 page) notebook, and write down (in the long hand) just the titles of the sections of each chapter of this book, followed by a listing of the important concepts / equations / proofs introduced in it. … You see, the section titles of this book themselves are complete sentences that encapsulate very neat nuggets. Here are a couple of examples: “5.6: The harmonic oscillator accounts for the infrared spectrum of a diatomic molecule.” Yes, that’s a section title! Here is another: “6.2: If a Hamiltonian is separable, then its eigenfunctions are products of simpler eigenfunctions.” See why I recommend this book? And this (40 page notebook) way of studying it?
• “Quantum physics of atoms, molecules, solids, nuclei, and particles” (yes, that’s the title of this single volume!) by Eisberg and Resnick. This Resnick is the same one as that of Resnick and Halliday. Going through the same topics via yet another thick book (almost 850 pages) can get exasperating, at least at times. But guess if you show some patience here, it should simplify things later. …. Confession: I was too busy with teaching and learning engineering topics like FEM, CFD, and also with many other things in between. So, I could not find the time to read this book the way I would have liked to. But from whatever I did read (and I did go over a fairly good portion of it), I can tell you that not finishing this book was a mistake on my part. Don’t repeat my mistake. Further, I do keep going back to it, and may be as a result, I would one day have finished it! One more point. This book is more than quantum chemistry; it does discuss the time-dependent parts too. The only reason I include it in this sub-section (chemistry) rather than the next (physics) is because the emphasis here is much more on TISE than TDSE.

II.4. Quantum physics level (includes TDSE):

• “Quantum physics” by Alastair I. M. Rae. Hands down, the best book in its class. To my mind, it easily beats all of the following: Griffiths, Gasiorowicz, Feynman, Susskind, … .
Oh, BTW, this is the only book I have ever come across which does not put scare-quotes around the word “derivation,” while describing the original development of the Schrodinger equation. In fact, this text goes one step ahead and explicitly notes the right idea, viz., that Schrodinger’s development is a derivation, but it is an inductive derivation, not deductive. (… Oh God, these modern American professors of physics!)
But even leaving this one (arguably “small”) detail aside, the book has excellence written all over it. Far better than the competition.
Another attraction: The author touches upon all the standard topics within just about 225 pages. (He also has further 3 chapters, one each on relativity and QM, quantum information, and conceptual problems with QM. However, I have mostly ignored these.) When a book is of manageable size, it by itself is an overload reducer. (This post is not a portion from a text-book!)
The only “drawback” of this book is that, like many British authors, Rae has a tendency to seamlessly bunch together a lot of different points into a single, bigger, paragraph. He does not isolate the points sufficiently well. So, you have to write a lot of margin notes identifying those distinct, sub-paragraph level, points. (But one advantage here is that this procedure is very effective in keeping you glued to the book!)
• “Quantum physics” by Griffiths. Oh yes, Griffiths is on my list too. It’s just that I find it far better to go through Rae first, and only then come to going through Griffiths.
• … Also, avoid the temptation to read both these books side-by-side. You will soon find that you can’t do that. And so, driven by what other people say, you will soon end up ditching Rae—which would be a grave mistake. Since you can keep going through only one of them, you have to jettison the other. Here, I would advise you to first complete Rae. It’s indispensable. Griffiths is good too. But it is not indispensable. And as always, if you find the time and the inclination, you can always come back to Griffiths.

Starting sometime after finishing the initial UG quantum chemistry level books, but preferably after the quantum physics books, use the following two:

• “Foundations of quantum mechanics” by Travis Norsen. Very, very good. See my “review” here [^]
• “Foundations of quantum mechanics: from photons to quantum computers” by Reinhold Blumel.
Just because people don’t rave a lot about this book doesn’t mean that it is average. This book is peculiar. It does look very average if you flip through all its pages within, say, 2–3 minutes. But it turns out to be an extraordinarily well written book once you begin to actually read through its contents. The coverage here is concise, accurate, fairly comprehensive, and, as a distinctive feature, it also is fairly up-to-date.
Unlike the other text-books, Blumel gives you a good background in the specifics of the modern topics as well. So, once you complete this book, you should find it easy (to very easy) to understand today’s pop-sci articles, say those on quantum computers. To my knowledge, this is the only text-book which does this job (of introducing you to the topics that are relevant to today’s research), and it does this job exceedingly well.
• Use Blumel to understand the specifics, and use Norsen to understand their conceptual and the philosophical underpinnings.

II.Appendix: Miscellaneous—no levels specified; figure out as you go along:

• “Schrodinger’s cat” by John Gribbin. Unquestionably, the best pop-sci book on QM. Lights your fire.
• “Quantum” by Manjit Kumar. Helps keep the fire going.
• Kreyszig or equivalent. You need to master the basic ideas of the Fourier theory, and of solutions of PDEs via the separation ansatz.
• However, for many other topics like spherical harmonics or calculus of variations, you have to go hunting for explanations in some additional books. I “learnt” the spherical harmonics mostly through some online notes (esp. those by Michael Fowler of Univ. of Virginia) and QM textbooks, but I guess that a neat exposition of the topic, couched in contexts other than QM, would have been helpful. May be there is some ancient acoustics book that is really helpful. Anyway, I didn’t pursue this topic to any great depth (in fact I more or less skipped over it) because as it so happens, analytical methods fall short for anything more complex than the hydrogenic atoms.
• As to the variational calculus, avoid all the physics and maths books like a plague! Instead, learn the topic through the FEM books. Introductory FEM books have become vastly (i.e. categorically) better over the course of my generation. Today’s FEM text-books do provide a clear evidence that the authors themselves know what they are talking about! Among these books, just for learning the variational calculus aspects, I would advise going through Seshu or Fish and Belytschko first, and then through the relevant chapter from Reddy‘s book on FEM. In any case, avoid Bathe, Zienkiewicz, etc.; they are too heavily engineering-oriented, and often, in general, un-necessarily heavy-duty (though not as heavy-duty as Lancosz). Not very suitable for learning the basics of CoV as is required in the UG QM. A good supplementary book covering CoV is noted next.
• “From calculus to chaos: an introduction to dynamics” by David Acheson. A gem of a book. Small (just about 260 pages, including program listings—and just about 190 pages if you ignore them.) Excellent, even if, somehow, it does not appear on people’s lists. But if you ask me, this book is a must read for any one who has anything to do with physics or engineering. Useful chapters exist also on variational calculus and chaos. Comes with easy to understand QBasic programs (and their updated versions, ready to run on today’s computers, are available via the author’s Web site). Wish it also had chapters, say one each, on the mechanics of materials, and on fracture mechanics.
• Linear algebra. Here, keep your focus on understanding just the two concepts: (i) vector spaces, and (ii) eigen-vectors and -values. Don’t worry about other topics (like LU decomposition or the power method). If you understand these two topics right, the rest will follow “automatically,” more or less. To learn these two topics, however, don’t refer to text-books (not even those by Gilbert Strang or so). Instead, google on the online tutorials on computer games programming. This way, you will come to develop a far better (even robust) understanding of these concepts. … Yes, that’s right. One or two games programmers, I very definitely remember, actually did a much superior job of explaining these ideas (with all their complexity) than what any textbook by any university professor does. (iii) Oh yes, BTW, there is yet another concept which you should learn: “tensor product”. For this topic, I recommend Prof. Zhigang Suo‘s notes on linear algebra, available off iMechanica. These notes are a work in progress, but they are already excellent even in their present form.
• Probability. Contrary to a wide-spread impression (and to what one group of QM interpreters say), you actually don’t need much of statistics or probability in order to get the essence of QM right. Whatever you need has already been taught to you in your UG engineering/physics courses.Personally, though I haven’t yet gone through them, the two books on my radar (more from the data science angle) are: “Elementary probability” by Stirzaker, and “All of statistics” by Wasserman. But, frankly speaking, as far as QM itself is concerned, your intuitive understanding of probability as developed through your routine UG courses should be enough, IMHO.
• As to AJP type of articles, go through Dan Styer‘s paper on the nine formulations (doi:10.1119/1.1445404). But treat his paper on the common misconceptions (10.1119/1.18288) with a bit of caution; some of the ideas he lists as “misconceptions” are not necessarily so.
• arXiv tutorials/articles: Sometime after finishing quantum chemistry and before beginning quantum physics, go through the tutorial on QM by Bram Gaasbeek [^]. Neat, small, and really helpful for self-studies of QM. (It was written when the author was still a student himself.) Also, see the article on the postulates by Dorabantu [^]. Definitely helpful. Finally, let me pick up just one more arXiv article: “Entanglement isn’t just for spin” by Dan Schroeder [^]. Comes with neat visualizations, and helps demystify entanglement.
• Computational physics: Several good resources are available. One easy to recommend text-book is the one by Landau, Perez and Bordeianu. Among the online resources, the best collection I found was the one by Ian Cooper (of Univ. of Sydney) [^]. He has only MatLab scripts, not Python, but they all are very well documented (in an exemplary manner) via accompanying PDF files. It should be easy to port these programs to the Python eco-system.

Yes, we (finally) are near the end of this post, so let me add the mandatory catch-all clauses: This list is by no means comprehensive! This list supersedes any other list I may have put out in the past. This list may undergo changes in future.

Done.

OK. A couple of last minute addenda: For contrast, see the article “What is the best textbook for self-studying quantum mechanics?” which has appeared, of all places, on the Forbes!  [^]. (Looks like the QC-related hype has found its way into the business circles as well!) Also see the list at BookScrolling.com: “The best books to learn about quantum physics” [^].

OK. Now, I am really done.

A song I like:
(Marathi) “kiteedaa navyaane tulaa aaThavaave”
Music: Mandar Apte
Singer: Mandar Apte. Also, a separate female version by Arya Ambekar
Lyrics: Devayani Karve-Kothari

[Arya Ambekar’s version is great too, but somehow, I like Mandar Apte’s version better. Of course, I do often listen to both the versions. Excellent.]

[Almost 5000 More than 5,500 words! Give me a longer break for this time around, a much longer one, in fact… In the meanwhile, take care and bye until then…]

# 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

# Blog-Filling—Part 3

Note: A long Update was added on 23 November 2017, at the end of the post.

Today I got just a little bit of respite from what has been a very tight schedule, which has been running into my weekends, too.

But at least for today, I do have a bit of a respite. So, I could at least think of posting something.

But for precisely the same reason, I don’t have any blogging material ready in the mind. So, I will just note something interesting that passed by me recently:

1. Catastrophe Theory: Check out Prof. Zhigang Suo’s recent blog post at iMechanica on catastrophe theory, here [^]; it’s marked by Suo’s trademark simplicity. He also helpfully provides a copy of Zeeman’s 1976 SciAm article, too. Regular readers of this blog will know that I am a big fan of the catastrophe theory; see, for instance, my last post mentioning the topic, here [^].
2. Computational Science and Engineering, and Python: If you are into computational science and engineering (which is The Proper And The Only Proper long-form of “CSE”), and wish to have fun with Python, then check out Prof. Hans Petter Langtangen’s excellent books, all under Open Source. Especially recommended is his “Finite Difference Computing with PDEs—A Modern Software Approach” [^]. What impressed me immediately was the way the author begins this book with the wave equation, and not with the diffusion or potential equation as is the routine practice in the FDM (or CSE) books. He also provides the detailed mathematical reason for his unusual choice of ordering the material, but apart from his reason(s), let me add in a comment here: wave $\Rightarrow$ diffusion $\Rightarrow$ potential (Poisson-Laplace) precisely was the historical order in which the maths of PDEs (by which I mean both the formulations of the equations and the techniques for their solutions) got developed—even though the modern trend is to reverse this order in the name of “simplicity.” The book comes with Python scripts; you don’t have to copy-paste code from the PDF (and then keep correcting the errors of characters or indentations). And, the book covers nonlinearity too.
3. Good Notes/Teachings/Explanations of UG Quantum Physics: I ran across Dan Schroeder’s “Entanglement isn’t just for spin.” Very true. And it needed to be said [^]. BTW, if you want a more gentle introduction to the UG-level QM than is presented in Allan Adam (et al)’s MIT OCW 8.04–8.06 [^], then make sure to check out Schroeder’s course at Weber [^] too. … Personally, though, I keep on fantasizing about going through all the videos of Adam’s course and taking out notes and posting them at my Web site. [… sigh]
4. The Supposed Spirituality of the “Quantum Information” Stored in the “Protein-Based Micro-Tubules”: OTOH, if you are more into philosophy of quantum mechanics, then do check out Roger Schlafly’s latest post, not to mention my comment on it, here [^].

The point no. 4. above was added in lieu of the usual “A Song I Like” section. The reason is, though I could squeeze in the time to write this post, I still remain far too rushed to think of a song—and to think/check if I have already run it here or not. But I will try add one later on, either to this post, or, if there is a big delay, then as the next “blog filler” post, the next time round.

[Update on 23 Nov. 2017 09:25 AM IST: Added the Song I Like section; see below]

OK, that’s it! … Will catch you at some indefinite time in future here, bye for now and take care…

A Song I Like:

(Western, Instrumental) “Theme from ‘Come September'”
Credits: Bobby Darin (?) [+ Billy Vaughn (?)]

[I grew up in what were absolutely rural areas in Maharashtra, India. All my initial years till my 9th standard were limited, at its upper end in the continuum of urbanity, to Shirpur, which still is only a taluka place. And, back then, it was a decidedly far more of a backward + adivasi region. The population of the main town itself hadn’t reached more than 15,000 or so by the time I left it in my X standard; the town didn’t have a single traffic light; most of the houses including the one we lived in) were load-bearing structures, not RCC; all the roads in the town were of single lanes; etc.

Even that being the case, I happened to listen to this song—a Western song—right when I was in Shirpur, in my 2nd/3rd standard. I first heard the song at my Mama’s place (an engineer, he was back then posted in the “big city” of the nearby Jalgaon, a district place).

As to this song, as soon as I listened to it, I was “into it.” I remained so for all the days of that vacation at Mama’s place. Yes, it was a 45 RPM record, and the permission to put the record on the player and even to play it, entirely on my own, was hard won after a determined and tedious effort to show all the elders that I was able to put the pin on to the record very carefully. And, every one in the house was an elder to me: my siblings, cousins, uncle, his wife, not to mention my parents (who were the last ones to be satisfied). But once the recognition arrived, I used it to the hilt; I must have ended up playing this record for at least 5 times for every remaining day of the vacation back then.

As far as I am concerned, I am entirely positive that appreciation for a certain style or kind of music isn’t determined by your environment or the specific culture in which you grow up.

As far as songs like these are concerned, today I am able to discern that what I had immediately though indirectly grasped, even as a 6–7 year old child, was what I today would describe as a certain kind of an “epistemological cleanliness.” There was a clear adherence to certain definitive, delimited kind of specifics, whether in terms of tones or rhythm. Now, it sure did help that this tune was happy. But frankly, I am certain, I would’ve liked a “clean” song like this one—one with very definite “separations”/”delineations” in its phrases, in its parts—even if the song itself weren’t to be so directly evocative of such frankly happy a mood. Indian music, in contrast, tends to keep “continuity” for its own sake, even when it’s not called for, and the certain downside of that style is that it leads to a badly mixed up “curry” of indefinitely stretched out weilings, even noise, very proudly passing as “music”. (In evidence: pick up any traditional “royal palace”/”kothaa” music.) … Yes, of course, there is a symmetrical downside to the specific “separated” style carried by the Western music too; the specific style of noise it can easily slip into is a disjointed kind of a noise. (In evidence, I offer 90% of Western classical music, and 99.99% of Western popular “music”. As to which 90%, well, we have to meet in person, and listen to select pieces of music on the fly.)

Anyway, coming back to the present song, today I searched for the original soundtrack of “Come September”, and got, say, this one [^]. However, I am not too sure that the version I heard back then was this one. Chances are much brighter that the version I first listened to was Billy Vaughn’s, as in here [^].

… A wonderful tune, and, as an added bonus, it never does fail to take me back to my “salad days.” …

… Oh yes, as another fond memory: that vacation also was the very first time that I came to wear a T-shirt; my Mama had gifted it to me in that vacation. The actual choice to buy a T-shirt rather than a shirt (+shorts, of course) was that of my cousin sister (who unfortunately is no more). But I distinctly remember she being surprised to learn that I was in no mood to have a T-shirt when I didn’t know what the word meant… I also distinctly remember her assuring me using sweet tones that a T-shirt would look good on me! … You see, in rural India, at least back then, T-shirts weren’t heard of; for years later on, may be until I went to Nasik in my 10th standard, it would be the only T-shirt I had ever worn. … But, anyway, as far as T-shirts go… well, as you know, I was into software engineering, and so….

Bye [really] for now and take care…]

# Machine “Learning”—An Entertainment [Industry] Edition

Yes, “Machine ‘Learning’,” too, has been one of my “research” interests for some time by now. … Machine learning, esp. ANN (Artificial Neural Networks), esp. Deep Learning. …

Yesterday, I wrote a comment about it at iMechanica. Though it was made in a certain technical context, today I thought that the comment could, perhaps, make sense to many of my general readers, too, if I supply a bit of context to it. So, let me report it here (after a bit of editing). But before coming to my comment, let me first give you the context in which it was made:

Context for my iMechanica comment:

It all began with a fellow iMechanician, one Mingchuan Wang, writing a post of the title “Is machine learning a research priority now in mechanics?” at iMechanica [^]. Biswajit Banerjee responded by pointing out that

“Machine learning includes a large set of techniques that can be summarized as curve fitting in high dimensional spaces. [snip] The usefulness of the new techniques [in machine learning] should not be underestimated.” [Emphasis mine.]

Then Biswajit had pointed out an arXiv paper [^] in which machine learning was reported as having produced some good DFT-like simulations for quantum mechanical simulations, too.

A word about DFT for those who (still) don’t know about it:

DFT, i.e. Density Functional Theory, is “formally exact description of a many-body quantum system through the density alone. In practice, approximations are necessary” [^]. DFT thus is a computational technique; it is used for simulating the electronic structure in quantum mechanical systems involving several hundreds of electrons (i.e. hundreds of atoms). Here is the obligatory link to the Wiki [^], though a better introduction perhaps appears here [(.PDF) ^]. Here is a StackExchange on its limitations [^].

Trivia: Kohn and Sham received a Physics Nobel for inventing DFT. It was a very, very rare instance of a Physics Nobel being awarded for an invention—not a discovery. But the Nobel committee, once again, turned out to have put old Nobel’s money in the right place. Even if the work itself was only an invention, it did directly led to a lot of discoveries in condensed matter physics! That was because DFT was fast—it was fast enough that it could bring the physics of the larger quantum systems within the scope of (any) study at all!

And now, it seems, Machine Learning has advanced enough to be able to produce results that are similar to DFT, but without using any QM theory at all! The computer does have to “learn” its “art” (i.e. “skill”), but it does so from the results of previous DFT-based simulations, not from the theory at the base of DFT. But once the computer does that—“learning”—and the paper shows that it is possible for computer to do that—it is able to compute very similar-looking simulations much, much faster than even the rather fast technique of DFT itself.

OK. Context over. Now here in the next section is my yesterday’s comment at iMechanica. (Also note that the previous exchange on this thread at iMechanica had occurred almost a year ago.) Since it has been edited quite a bit, I will not format it using a quotation block.

[An edited version of my comment begins]

A very late comment, but still, just because something struck me only this late… May as well share it….

I think that, as Biswajit points out, it’s a question of matching a technique to an application area where it is likely to be of “good enough” a fit.

I mean to say, consider fluid dynamics, and contrast it to QM.

In (C)FD, the nonlinearity present in the advective term is a major headache. As far as I can gather, this nonlinearity has all but been “proved” as the basic cause behind the phenomenon of turbulence. If so, using machine learning in CFD would be, by the simple-minded “analysis”, a basically hopeless endeavour. The very idea of using a potential presupposes differential linearity. Therefore, machine learning may be thought as viable in computational Quantum Mechanics (viz. DFT), but not in the more mundane, classical mechanical, CFD.

But then, consider the role of the BCs and the ICs in any simulation. It is true that if you don’t handle nonlinearities right, then as the simulation time progresses, errors are soon enough going to multiply (sort of), and lead to a blowup—or at least a dramatic departure from a realistic simulation.

But then, also notice that there still is some small but nonzero interval of time which has to pass before a really bad amplification of the errors actually begins to occur. Now what if a new “BC-IC” gets imposed right within that time-interval—the one which does show “good enough” an accuracy? In this case, you can expect the simulation to remain “sufficiently” realistic-looking for a long, very long time!

Something like that seems to have been the line of thought implicit in the results reported by this paper: [(.PDF) ^].

Machine learning seems to work even in CFD, because in an interactive session, a new “modified BC-IC” is every now and then is manually being introduced by none other than the end-user himself! And, the location of the modification is precisely the region from where the flow in the rest of the domain would get most dominantly affected during the subsequent, small, time evolution.

It’s somewhat like an electron rushing through a cloud chamber. By the uncertainty principle, the electron “path” sure begins to get hazy immediately after it is “measured” (i.e. absorbed and re-emitted) by a vapor molecule at a definite point in space. The uncertainty in the position grows quite rapidly. However, what actually happens in a cloud chamber is that, before this cone of haziness becomes too big, comes along another vapor molecule, and “zaps” i.e. “measures” the electron back on to a classical position. … After a rapid succession of such going-hazy-getting-zapped process, the end result turns out to be a very, very classical-looking (line-like) path—as if the electron always were only a particle, never a wave.

Conclusion? Be realistic about how smart the “dumb” “curve-fitting” involved in machine learning can at all get. Yet, at the same time, also remain open to all the application areas where it can be made it work—even including those areas where, “intuitively”, you wouldn’t expect it to have any chance to work!

[An edited version of my comment is over. Original here at iMechanica [^]]

“Boy, we seem to have covered a lot of STEM territory here… Mechanics, DFT, QM, CFD, nonlinearity. … But where is either the entertainment or the industry you had promised us in the title?”

You might be saying that….

Well, the CFD paper I cited above was about the entertainment industry. It was, in particular, about the computer games industry. Go check out SoHyeon Jeong’s Web site for more cool videos and graphics [^], all using machine learning.

And, here is another instance connected with entertainment, even though now I am going to make it (mostly) explanation-free.

Check out the following piece of art—a watercolor landscape of a monsoon-time but placid sea-side, in fact. Let me just say that a certain famous artist produced it; in any case, the style is plain unmistakable. … Can you name the artist simply by looking at it? See the picture below:

A sea beach in the monsoons. Watercolor.

If you are unable to name the artist, then check out this story here [^], and a previous story here [^].

A Song I Like:

And finally, to those who have always loved Beatles’ songs…

Here is one song which, I am sure, most of you had never heard before. In any case, it came to be distributed only recently. When and where was it recorded? For both the song and its recording details, check out this site: [^]. Here is another story about it: [^]. And, if you liked what you read (and heard), here is some more stuff of the same kind [^].

Endgame:

I am of the Opinion that 99% of the “modern” “artists” and “music composers” ought to be replaced by computers/robots/machines. Whaddya think?

[Credits: “Endgame” used to be the way Mukul Sharma would end his weekly Mindsport column in the yesteryears’ Sunday Times of India. (The column perhaps also used to appear in The Illustrated Weekly of India before ToI began running it; at least I have a vague recollection of something of that sort, though can’t be quite sure. … I would be a school-boy back then, when the Weekly perhaps ran it.)]

# Haptic, tactile, virtual, surgery, etc.

Three updates made on 24th March 2016 appear near the end of this post.

Once in a while I check out the map of the visitors’ locations (see the right bar).

Since hardly any one ever leaves any comment at my blog, I can only guess who these visitors possibly could be. Over a period of time, guessing the particular visitors in this way has become an idle sort of a past-time for me. (No, I don’t obsess over it, and I don’t in fact spend much time on it—at the most half-a-minute or so, once in a while. But, yes, check, I certainly do!)

Among the recent visitors, there was one hit on 6th March 2016 coming from Troy, NY, USA (at 11:48:02 AM IST, to be precise). … Must be someone from RPI, I thought. (My blog is such that mostly only academics could possibly be interested in it; never the people with lucrative industrial jobs such as those in the SF Bay Area. Most of the hits from the Bay Area are from Mountain View, and that’s the place where the bots of Google’s search engines live.)

But I couldn’t remember engaging in any discussion with any one from RPI on any blog.

Who could this visitor possibly be? I could not figure it out immediately, so I let the matter go.

Yesterday, I noticed for the first time an ad for “several” post-doc positions at RPI, posted on iMechanica by Prof. Suvranu De [^]. It had been posted right on the same day: 6th March 2016. However, since recently I was checking out only my thread on the compactness of support [^], I had missed out on the main front page. Thus, I noticed the ad only today.

Curious, I dropped an informal email to Prof. De immediately, almost more or less by cognitive habits.

I am not too keen on going to the USA, and in fact, I am not even inclined to leave India. Reasons are manifold.

You, as every one else on the planet, of course comes to know all that ever happens to or in the USA. Americans make sure that you do—whether you like it or not. (Remember 9/11? They have of course forgotten it by now, but don’t you remember the early naughties when, imagining you to be just as dumb and thick-skinned as they are,  the kind of decibels they had pierced into your metaphorical ears (and in fact also in your soul)? Justifiable, you say? How about other big “controversies” which actually were nothing but scandals? Can’t you pick up one or two?)

Naturally, who would want to go to that uncivilized a place?

And even if you want to argue otherwise, let me suggest you to see if you can or cannot easily gather (or recollect) what all that has happened to me when I was in the USA?

So, the idea of trying to impress Dr. De for this post-doc position was, any which way, completely out of the question. Even if he is HoD at RPI.

And then, frankly, at my age, I don’t even feel like impressing any one for a mere post-doc; not these days anyway (I mean, some 6 years after the PhD defense, and after having to experience so many years of joblessness (including those reported via this blog)). … As far as I am concerned, either they know what and who I am, and act accordingly (including acting swiftly enough), or they don’t. (In the last case, mostly, they end up blaming me, as usual, in some or the other way.)

OK, so, coming back to what I wrote Dr. De. It was more in the nature of a loud thinking about the question of whether I should at all apply to them in the first place or not. … Given my experience of the other American post-docs advertised at iMechanica, e.g. those by Prof. Sukumar (UC Davis), and certain others in the USA, and also my experience of the Americans of the Indian origin (and even among them, those who are JPBTIs and those who are younger to me by age), I can’t keep any realistic expectation that I would ever receive any reply to that email of mine from Prof. De. The odds are far too against; check out the “follow-up” tag. (I could, of course, be psychically attacked, the way I was, right this week, a few days ago.)

Anyway, once thus grown curious about the subject matter, I then did a bit of a Web search, and found the following videos:

The very first listing after a Google search (using the search string: “Suvranu De”; then clicking on the tab: “videos”) was the one on “virtual lap band – surgical simulation”: [^].

Watching that video somehow made me sort of uneasy immediately. Uneasy, in a minor but a definitely irritating way. In a distinctly palpable way, almost as if it was a physical discomfort. No, not because the video carries the scene of tissue-cutting and all. … I have never been one of those who feel nervous or squeamish at the sight of blood, cuts, etc. (Most men, in fact, don’t!) So, my uneasiness was not on that count. …

Soon enough (i.e., much before the time I was in the middle of that video), I figured out the reason why.

I then checked out a few more videos, e.g., those here [^] and here [^]. … Exactly the same sense of discomfort or uneasiness, arising out of the same basic reason.

What kind of an uneasiness could there possibly be? Can you guess?

I don’t want to tell you, right away. I want you to guess. (Assume that an evil smile had transitorily appeared on my face.)

To close this post: If you so want, go ahead, check out those videos, see if it makes you uncomfortable watching some part of an implementation of this new idea. Then, the sin of the sins (“paapam, paapam, mahaapaapam” in Sanskrit): drop me a line (via a comment or an email) stating what that reason possibly could be. (Hint: It has nothing to do with the feely-feely-actually-silly/wily sort of psychological reasons. )

After a while, I will come back, and via an update to this post let you know the reason.

Update 1:

Yahoo! wants you to make a note of the “12 common mistakes to avoid in job interview”: [^]. They published this article today.

Update 2 (on 24th March 2016):

Surprise! Prof.  De soon enough (on 18th March IST) dropped me an email which was brief, professional, but direct to the point. A consequence, and therefore not much of a surprise: I am more or less inclined to at least apply for the position. I have not done so as of today; see the Update 3 below.

Update 3 (on 24th March 2016):

Right the same day (on 18th March 2016 about 10:00 PM IST), my laptop developed serious hardware issues including (but not limited to) yet another HDD crash! The previous crash was less than a year ago, in last June  [^].

Once again, there was  loss of (some) data: the initial and less-than-25%-completed drafts of 4+ research papers, some parts (from sometime in February onwards) of my notes on the current course on CFD, SPH, etc., as well as some preliminary Python code on SPH). The Update 2 in fact got delayed because of this development. I just got the machine back from the Dell Service last evening, and last night got it going on a rapid test installation of Windows 7. I plan to do a more serious re-installation over the next few days.

Update 4 (on 24th March 2016):

The thing in the three videos (about haptics, virtual surgery) that made me uncomfortable or uneasy was the fact that in each case, the surgeon was standing in a way that would have been just a shade uncomfortable to me. The surgeon’s hands were too “free” i.e. unsupported (say near elbow), his torso was stooping down in a wrong way (you couldn’t maintain that posture with accuracy in hands manipulation for long, I thought), and at the same time, he had to keep his eyes fixed on a monitor that was a bit too high-up for the eyes-to-hands coordination to work right. In short, there was this seeming absence of a consideration of ergonomics or the human factors engineering here. Of course, it’s only a prototype, and it’s only a casual onlooker’s take of the “geometry,” but that’s what made me distinctly uncomfortable.

(People often have rationalistic ideas about the proper (i.e. the least stress inducing and most efficient) posture.  In a later post, I will point out a few of these.)

A Song I Like:
(filled-in on 24th March 2016)

(Marathi) “thembaanche painjaN waaje…” [“rutu premaachaa aalaa”]
Music: Shashank Powar

[An incidental note: The crash occurred—the computer suddenly froze—while I was listening to—actually, watching the YouTube video of—this song. … Somehow, even today, I still continue liking the song! … But yes, as is usual for this section, only the audio track is being referred to. (I had run into this song while searching for some other song, which I will use in a later post.)]

[Some editorial touches, other than the planned update, are possible, as always.]

[E&OE]

# The Infosys Prizes, 2015

I realized that it was the end of November the other day, and it somehow struck me that I should check out if there has been any news on the Infosys prizes for this year. I vaguely recalled that they make the yearly announcements sometime in the last quarter of a year.

Turns out that, although academic bloggers whose blogs I usually check out had not highlighted this news, the prizes had already been announced right in mid-November [^].

It also turns out also that, yes, I “know”—i.e., have in-person chatted (exactly once) with—one of the recipients. I mean Professor Dr. Umesh Waghmare, who received this year’s award for Engineering Sciences [^]. I had run into him in an informal conference once, and have written about it in a recent post, here [^].

Dr. Waghmare is a very good choice, if you ask me. His work is very neat—I mean both the ideas which he picks out to work on, and the execution on them.

I still remember his presentation at that informal conference (where I chatted with him). He had talked about a (seemingly) very simple idea, related to graphene [^]—its buckling.

Here is my highly dumbed down version of that work by Waghmare and co-authors. (It’s dumbed down a lot—Waghmare et al’s work was on buckling, not bending. But it’s OK; this is just a blog, and guess I have a pretty general sort of a “general readership” here.)

Bending, in general, sets up a combination of tensile and compressive stresses, which results in the setting up of a bending moment within a beam or a plate. All engineers (except possibly for the “soft” branches like CS and IT) study bending quite early in their undergraduate program, typically in the second year. So, I need not explain its analysis in detail. In fact, in this post, I will write only a common-sense level description of the issue. For technical details, look up the Wiki articles on bending [^] and buckling [^] or Prof. Bower’s book [^].

Assuming you are not an engineer, you can always take a longish rubber eraser, hold it so that its longest edge is horizontal, and then bend it with a twist of your fingers. If the bent shape is like an inverted ‘U’, then, the inner (bottom) surface has got compressed, and the outer (top) surface has got stretched. Since compression and tension are opposite in nature, and since the eraser is a continuous body of a finite height, it is easy to see that there has to be a continuous surface within the volume of the eraser, some half-way through its height, where there can be no stresses. That’s because, the stresses change sign in going from the compressive stress at the bottom surface to the tensile stresses on the top surface. For simplicity of mathematics, this problem is modeled as a 1D (line) element, and therefore, in elasticity theory, this actual 2D surface is referred to as the neutral axis (i.e. a line).

The deformation of the eraser is elastic, which means that it remains in the bent state only so long as you are applying a bending “force” to it (actually, it’s a moment of a force).

The classical theory of bending allows you to relate the curvature of the beam, and the bending moment applied to it. Thus, knowing bending moment (or the applied forces), you can tell how much the eraser should bend. Or, knowing how much the eraser has curved, you can tell how big a pair of fforces would have to be applied to its ends. The theory works pretty well; it forms of the basis of how most buildings are designed anyway.

So far, so good. What happens if you bend, not an eraser, but a graphene sheet?

The peculiarity of graphene is that it is a single atom-thick sheet of carbon atoms. Your usual eraser contains billions and billions of layers of atoms through its thickness. In contrast, the thickness of a graphene sheet is entirely accounted for by the finite size of the single layer of atoms. And, it is found that unlike thin paper, the graphen sheet, even if it is the the most extreme case of a thin sheet, actually does offer a good resistance to bending. How do you explain that?

The naive expectation is that something related to the interatomic bonding within this single layer must, somehow, produce both the compressive and tensile stresses—and the systematic variation from the locally tensile to the locally compressive state as we go through this thickness.

Now, at the scale of single atoms, quantum mechanical effects obviously are dominant. Thus, you have to consider those electronic orbitals setting up the bond. A shift in the density of the single layer of orbitals should correspond to the stresses and strains in the classical mechanics of beams and plates.

What Waghmare related at that conference was a very interesting bit.

He calculated the stresses as predicted by (in my words) the changed local density of the orbitals, and found that the forces predicted this way are way smaller than the experimentally reported values for graphene sheets. In other words, the actual graphene is much stiffer than what the naive quantum mechanics-based model shows—even if the model considers those electronic orbitals. What is the source of this additional stiffness?

He then showed a more detailed calculation (i.e. a simulation), and found that the additional stiffness comes from a quantum-mechanical interaction between the portions of the atomic orbitals that go off transverse to the plane of the graphene sheet.

Thus, suppose a graphene sheet is initially held horizontally, and then bent to form an inverted U-like curvature. According to Waghmare and co-authros, you now have to consider not just the orbital cloud between the atoms (i.e. the cloud lying in the same plane as the graphene sheet) but also the orbital “petals” that shoot vertically off the plane of the graphene. Such petals are attached to nucleus of each C atom; they are a part of the electronic (or orbital) structure of the carbon atoms in the graphene sheet.

In other words, the simplest engineering sketch for the graphene sheet, as drawn in the front view, wouldn’t look like a thin horizontal line; it would also have these small vertical “pins” at the site of each carbon atom, overall giving it an appearance rather like a fish-bone.

What happens when you bend the graphene sheet is that on the compression side, the orbital clouds for these vertical petals run into each other. Now, you know that an orbital cloud can be loosely taken as the electronic charge density, and that the like charges (e.g. the negatively charged electrons) repel each other. This inter-electronic repulsive force tends to oppose the bending action. Thus, it is the petals’ contribution which accounts for the additional stiffness of the graphene sheet.

I don’t know whether this result was already known to the scientific community back then in 2010 or not, but in any case, it was a very early analysis of bending of graphene. Further, as far as I could tell, the quality of Waghmare’s calculations and simulations was very definitely superlative. … You work in a field (say computational modeling) for some time, and you just develop a “nose” of sorts, that allows you to “smell” a superlative calculation from an average one. Particularly so, if your own skills on the calculations side are rather on the average, as happens to be the case with me. (My strengths are in conceptual and computational sides, but not on the mathematical side.) …

So, all in all, it’s a very well deserved prize. Congratulations, Dr. Waghmare!

A Song I Like:

(The so-called “fusion” music) “Jaisalmer”
Artists: Rahul Sharma (Santoor) and Richard Clayderman (Piano)
Album: Confluence

[As usual, may be one more editing pass…]

[E&OE]

# Blogging some crap…

I had taken a vow not to blog very frequently any more—certainly not any more at least right this month, in April.

But then, I am known to break my own rules.

Still, guess I really am coming to a point where quite a few threads on which I wanted to blog are, somehow, sort of coming to an end, and fresh topics are still too fresh to write anything about.

So, the only things to blog about would be crap. Thus the title of this post.

Anyway, here is an update of my interests, and the reason why it actually is, and also would be, difficult for me to blog very regularly in the near future of months, may be even a year or so. [I am being serious.]

1. About micro-level water resources engineering:

Recently, I blogged a lot about it. Now, I think I have more or less completed my preliminary studies, and pursuing anything further would take a definitely targeted and detailed research—something that only can be pursued once I have a master’s or PhD student to guide. Which will only happen once I have a job. Which will only happen in July (when the next academic term of the University of Mumbai begins).

There is only one idea that I might mention for now.

I have installed QGIS, and worked through the relevant exercises to familiarize myself with it. Ujaval Gandhi’s tutorials are absolutely great in this respect.

The idea I can blog about right away is this. As I mentioned earlier, DEM maps with 5 m resolution are impossible to find. I asked my father to see if he had any detailed map at sub-talukaa level. He gave me an old official map from GSI; it is on a 1:50000 scale, with contours at 20 m. Pretty detailed, but still, since we are looking for check-dams of heights up to 10 m, not so helpful. So, I thought of interpolating contours, and the best way to do it would be through some automatic algorithms. The map anyway has to be digitized first.

That means, scan it at a high enough resolution, and then perform a raster to vector conversion so that DEM heightfields could be viewed in QGIS.

The trouble is, the contour lines are too faint. That means, automatic image processing to extract the existing contours would be of limited help. So, I thought of an idea: why not lay a tracing paper on top, and trace out only the contours using black pen, and then, separately scan it? It was this idea that was already mentioned in an official Marathi document by the irrigation department.

Of course, they didn’t mean to go further and do the raster-to-vector conversion and all.  I would want to adapt/create algorithms that could simulate rainfall run-offs after high intensity sporadic rains, possibly leading also to flooding. I also wanted to build algorithms that would allow estimates of volumes of water in a check dam before and after evaporation and seepage. (Seepage calculations would be done, as a first step, after homogenizing the local geology; the local geology could enter the computations at a more advanced stage of the research.) A PhD student at IIT Bombay has done some work in this direction, and I wanted to independently probe these issues. I could always use raster algorithms, but since the size of the map would be huge, I thought that the vector format would be more efficient for some of these algorithms. Thus, I had to pursue the raster-to-vector conversion.

So I did some search in this respect, and found some papers and even open source software. For instance, Peter Selinger’s POTrace, and the further off-shoots from it.

I then realized that since the contour lines in the scanned image (whether original or traced) wouldn’t be just one-pixel wide, I would have to run some kind of a line thinning algorithm.

Suitable ready made solutions are absent and building one from the scratch would be too time consuming—it can possibly be a good topic for a master’s project in the CS/Mech departments, in the computer graphics field. Here is one idea I saw implemented somewhere. To fix our imagination, launch MS Paint (or GIMP on Ubuntu), and manually draw a curve in a thick brush, or type a letter in a huge font like 48 points or so, and save the BMP file. Our objective is to make a single pixel-thick line drawing out of this thick diagram. The CS folks apparently call it the centerlining algorithm. The idea I saw implemented was something like this: (i) Do edge detection to get single pixel wide boundaries. The “filled” letter in the BMP file would now become “hollow;” it would have only the outlines that are single pixel wide. (ii) Do raster-to-vector conversion, say using POTrace, on this hollow letter. You would thus have a polygon representation for the letter. (iii) Run a meshing software (e.g. Jonathan Schewchuk’s Triangle, or something in the CGAL library) to fill the interior parts of this hollow polygon with a single layer of triangles. (iv) Find the centroids of all these triangles, and connect them together. This will get us the line running through the central portions of each arm of the letter diagram. Keep this line and delete the triangles. What you have now got is a single pixel-wide vector representation of what once was a thick letter—or a contour line in the scanned image.

Sine this algorithm seemed too complicated, I thought whether it won’t be possible to simply apply a suitable diffusion algorithm to simply erode away the thickness of the line. For instance, think that the thick-walled letter is initially made uniformly cold, and then it is placed in uniformly heated surroundings. Since the heat enters from boundaries, the outer portions become hotter than the interior. As the temperature goes on increasing, imagine the thick line to begin to melt. As soon as a pixel melts, check whether there is any solid pixel still left in its neighbourhood or not. If yes, remove the molten pixel from the thick line. In the end, you would get a raster representation one pixel thick. You can easily convert it to the vector representation. This is a simplified version of the algorithm I had implemented for my paper on the melting snowman, with that check for neighbouring solid pixels now being thrown in.

Pursuing either would be too much work for the time being; I could either offload it to a student for his project, or work on it at a later date.

Thus ended my present thinking line on the micro-level water-resources engineering.

2. Quantum mechanics:

You knew that I was fooling you when I had noted in my post dated the first of April this year, that:

“in the course of attempting to build a computer simulation, I have now come to notice a certain set of factors which indicate that there is a scope to formulate a rigorous theorem to the effect that it will always be logically impossible to remove all the mysteries of quantum mechanics.”

Guess people know me too well—none fell for it.

Well, though I haven’t quite built a simulation, I have been toying with certain ideas about simulating quantum phenomena using what seems to be a new fluid dynamical model. (I think I had mentioned about using CFD to do QM, on my blog here a little while ago).

I pursued this idea, and found that it indeed should reproduce all the supposed weirdities of QM. But then I also found that this model looks a bit too contrived for my own liking. It’s just not simple enough. So, I have to think more about it, before allocating any specific or concrete research activities about it.

That is another dead-end, as far as blogging is concerned.

However, in the meanwhile, if you must have something interesting related to QM, check out David Hestenes’ work. Pretty good, if you ask me.

OK. Physicists, go away.

3. Homeopathy:

I had ideas about computational modelling for the homeopathic effect. By homeopathy, I mean: the hypothesis that water is capable of storing an “imprint” or “memory” of a foreign substance via structuring of its dipole molecules.

I have blogged about this topic before. I had ideas of doing some molecular dynamics kind of modelling. However, I now realize that given the current computational power, any MD modelling would be for far too short time periods. I am not sure how useful that would be, if some good scheme (say a variational scheme) for coarse-graining or coupling coarse-grained simulation with the fine-grained MD simulation isn’t available.

Anyway, I didn’t have much time available to look into these aspects. And so, there goes another line of research; I don’t have much to do blogging about it.

4. CFD:

This is one more line of research/work for me. Indeed, as far as my professional (academic research) activities go, this one is probably the most important line.

Here, too, there isn’t much left to blog about, even if I have been pursuing some definite work about it.

I would like to model some rheological flows as they occur in ceramics processing, starting with ceramic injection moulding. A friend of mine at IIT Bombay has been working in this area, and I should have easy access to the available experimental data. The phenomenon, of course, is much too complex; I doubt whether an institute with relatively modest means like an IIT could possibly conduct experimentation to all the required level of accuracy or sophistication. Accurate instrumentation means money. In India, money is always much more limited, as compared to, say, in the USA—the place where neither money nor dumbness is ever in short supply.

But the problem is very interesting to a computational engineer like me. Here goes a brief description, suitably simplified (but hopefully not too dumbed down (even if I do have American readers on this blog)).

Take a little bit of wax in a small pot, melt it, and mix some fine sand into it. The paste should have the consistency of a toothpaste (the limestone version, not the gel version). Just like you pinch on the toothpaste tube and pops out the paste—technically this is called an extrusion process—similarly, you have a cylinder and ram arrangement that holds this (molten wax+sand) paste and injects it into a mould cavity. The mould is metallic; aluminium alloys are often used in research because making a precision die in aluminium is less expensive. The hot molten wax+ceramic paste is pushed into the mould cavity under pressure, and fills it. Since the mould is cold, it takes out the heat from the paste, and so the paste solidifies. You then open the mould, take out the part, and sinter it. During sintering, the wax melts and evaporates, and then the sand (ceramic) gets bound together by various sintering mechanism. Materials engineers focus on the entire process from a processing viewpoint. As a computational engineer, my focus is only up to the point that the paste solidifies. So many interesting things happen up to that point that it already makes my plate too full. Here is an indication.

The paste is a rheological material. Its flow is non-Newtonian. (There sinks in his chair your friendly computational fluid dynamicist—his typical software cannot handle non-Newtonian fluids.) If you want to know, this wax+sand paste shows a shear-thinning behaviour (which is in contrast to the shear-thickening behaviour shown by, say, corn syrup).

Further, the flow of the paste involves moving boundaries, with pronounced surface effects, as well as coalescence or merging of boundaries when streams progressing on different arms of the cavity eventually come together during the filling process. (Imagine the simplest mould cavity in the shape of an O-ring. The paste is introduced from one side, say from the dash placed on the left hand side of the cavity, as shown here: “-O”. First, after entering the cavity, the paste has to diverge into the upper and lower arms, and as the cavity filling progresses, the two arms then come together on the rightmost parts of the “O” cavity.)

Modelling moving boundaries is a challenge. No textbook on CFD would even hint at how to handle it right, because all of them are based on rocket science (i.e. the aerodynamics research that NASA and others did from fifties onwards). It’s a curious fact that aeroplanes always fly in air. They never fly at the boundary of air and vacuum. So, an aeronautical engineer never has to worry about a moving fluid boundary problem. Naval engineers have a completely different approach; they have to model a fluid flow that is only near a surface—they can afford to ignore what happens to the fluid that lies any deeper than a few characteristic lengths of their ships. Handling both moving boundaries and interiors of fluids at the same time with sufficient accuracy, therefore, is a pretty good challenge. Ask any people doing CFD research in casting simulation.

But simulation of the flow of the molten iron in gravity sand-casting is, relatively, a less complex problem. Do dimensional analysis and verify that molten iron has the same fluid dynamical characteristics as that of the plain water. In other words, you can always look at how water flows inside a cavity, and the flow pattern would remain exactly the same also for molten iron, even if the metal is so heavy. Implication, surface tension effects are OK to handle for the flow of molten iron. Also, pressures are negligibly small in gravity casting.

But rheological paste being too thick, and it flowing under pressure, handling the surface tensions effect right should be even bigger a challenge. Especially at those points where multiple streams join together, under pressure.

Then, there is also heat transfer. You can’t get away doing only momentum equations; you have to couple in the energy equations too. And, the heat transfer obviously isn’t steady-state; it’s necessarily transient—the whole process of cavity filling and paste solidification gets over within a few seconds, sometimes within even a fraction of a second.

And then, there is this phase change from the liquid state to the solid state too. Yet another complication for the computational engineer.

Why should he address the problem in the first place?

If the die design isn’t right, the two arms of the fluid paste lose heat and become sluggish, even part solidify at the boundary, before joining together. The whole idea behind doing computational modelling is to help the die designer improve his design, by allowing him to try out many different die designs and their variations on a computer, before throwing money into making an actual die. Trying out die designs on computer takes time and money too, but the expense would be relatively much much smaller as compared to actually making a die and trying it. Precision machining is too expensive, and taking a manufacturing trial takes too much time—it blocks an entire engineering team and a production machine into just trials.

So, the idea is that the computational engineer could help by telling in advance whether, given a die design and process parameters, defects like cold-joins are likely to occur.

The trouble is, the computational modelling techniques happen to be at their weakest exactly at those spots where important defects like cold-joins are most likely. These are the places where all the armies of the devil come together: non-Newtonian fluid with temperature dependent properties, moving and coalescing boundaries, transient heat transfer, phase change, variable surface tension and wall friction, pressure and rapidity (transience would be too mild a word) of the overall process.

So, that’s what the problem to model itself looks like.

Obviously, ready made software aren’t yet sophisticated enough. The best available are those that do some ad-hoc tweaking to the existing software for the plastic injection moulding. But the material and process parameters differ, and it shows in the results. And, that way, validation of these tweaks still is an on-going activity in the research community.

Obviously, more research is needed! [I told you the reason: Economics!]

Given the granular nature of the material, and the rapidity of the process, some people thought that SPH (smoothed particle hydrodynamics) should be suitable. They have tried, but I don’t know the extent of the sophistication thus far.

Some people have also tried finite-differences based approaches, with some success. But FDM has its limitations—fluxes aren’t conserved, and in a complex process like this, it would be next to impossible to tell whether a predicted result is a feature of the physical process or an artefact of the numerical modelling.

FVM should do better because it conserves fluxes better. But the existing FVM software is too complex to try out the required material and process specific variations. Try introducing just one change to a material model in OpenFOAM, and simulating the entire filling process with it. Forget it. First, try just mould filling with coupled heat transfer. Forget it. First, try just mould filling with OpenFOAM. Forget it. First, try just debug-stepping through a steady-state simulation. Forget it. First, try just compiling it from the sources, successfully.

I did!

Hence, the natural thing to do is to first write some simple FVM code, initially only in 2D, and then go on adding the process-specific complications to it.

Now this is something about I have got going, but by its nature, it also is something about you can’t blog a lot. It will be at least a few months or so before even a preliminary version 0.1 code would become available, at which point some blogging could be done about it—and, hopefully, also some bragging.

Thus, in the meanwhile, that line of thought, too comes to an end, as far as blogging is concerned.

Thus, I don’t (and won’t) have much to blog about, even if I remain (and plan to remain) busy (to very busy).

So allow me to blog only sparsely in the coming weeks and months. Guess I could bring in the comments I made at other blogs once in a while to keep this blog somehow going, but that’s about it.

In short, nothing new. And so, it all is (and is going to be) crap.

More of it, later—much later, may be a few weeks later or so. I will blog, but much more infrequently, that’s the takeaway point.

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

(Marathi) “madhu maagashee maajhyaa sakhyaa pari…”
Lyrics: B. R. Tambe
Singer: Lata Mangeshkar
Music: Vasant Prabhu

[I just finished writing the first cut; an editing pass or two is still due.]

[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.

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

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]