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”]
Singers: Avadhoot Gupte, Vaishali Samant
Music: Shashank Powar
Lyrics: Ravi Wadkar (?)

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



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…]


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?

Good question. Answer is: Economics.

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



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.


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

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

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

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

Another virtue of Python:

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

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

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

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

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

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

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

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

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

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

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

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

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

What about the MATE?

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

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

Good riddance!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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