More on the project ideas. Also, a new CFD software benchmark-cum-shop-floor test.

Update added on 2015.05.17; check out the near the end of this post.

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

More on the project ideas:

In my last post [^], I had given a description of 3 different ideas for student projects. I would be interested in guiding all these projects in the near future, once I get a suitable job.

If you had gone through my earlier post about my current research interests [^], you would have sure noticed how the project idea no. 2 and 3 relate to my current research in computational modeling of the ceramic injection moulding (CIM) process.

These ideas are basically meant to provide reliable experimental bench-marks for validating separate aspects of the software that I will be writing. (I am still considering and reconsidering the issue of whether to write the software starting from the scratch, or only adapt/extend OpenFOAM.)

The project idea no. 3 (viz., paste-filling in cavity) completely keeps out the aspects of heat transfer and phase transformations, and instead selectively focuses on the aspect of mould-filling using a non-Newtonian material. Thus, if the momentum equations are handled right, predictions about the progress in the filling and the instantaneous shapes of the front at different times would be accurate. If not, the software would have to address only the momentum equations, but with better models/parameter values for the wall friction, viscosity, and surface tension.

In contrast, the project idea no. 2 (viz., melting of wax by a source) tries to selectively focus on the heat transfer and phase transformation aspects, but without significantly involving any momentum transport. (It is anticipated that the symmetry of the configuration means that convection within the molten wax would not be of much significance. However, this part, too, will have to be carefully looked into, at a later stage.)

The CIM process itself involves a liquid-to-solid phase transformation. In contrast, what the idea no. 2 models is the opposite phase transformation, viz., from solid-to-liquid. However, it does have a travelling interface. If the software handles the energy equation, the phase-transformations, and the motion of the liquid-solid interface right, then the speed of the interface should get predicted accurately. If not, the software development work would have to selectively focus only on this part.

Thus, the two project ideas split up the CIM process into two different parts. The reason is the complexity of such problems—the accurate predictions of the instantaneous positions of the moving boundary.

I was only partly successful while comutationally modeling the melting snowman (which I did during my PhD research). The software I wrote had qualitatively predicted the evolution of the shape right, but the speed of the evolution was quantitatively off the mark. I therefore knew that I had to further simplify even just this much part: of transient heat transfer, phase transformation and moving interface, but without any momentum exchanges involved in it. The project idea no. 2 tries to do precisely that: simplify just the heat-related part even further.

In the case of the melting snowman, the outer boundary happens to be the singular location where all the action happens: heat enters, phase-transformation occurs, and then, importantly, the resulting liquid gets drained away, traveling under gravity over the outer surface, and in the process exposing a new surface for the heat to enter, and also moving back the phase-transformation interface. The process thus has a kind of a loop built into it, and so, despite the apparent simplicity, from a modeling viewpoint, it actually is quite complex. Something went wrong with the timings at which the successive processes took place in the simulation. But I could not reliably locate precisely where; I didn’t have any experimental data to be able to do so. My experimentation was too simple; I could not get funds for instrumented data logging, and therefore, I had to remain content with just photographically capturing the outer profiles at successive instants; continuous monitoring of temperatures at various points within the volume of the snowman was not possible.

The current project idea tries to rectify the situation. It reduces the complexity a bit further, by completely doing away with the draining part—the molten wax remains in the jar.

However, in the process, I now realized, the experimental part has become perhaps a bit too simple for a project at the ME level. Some more work could be thrown in. So, here are two possibilities:

1. Also model solidification of wax (instead of only its melting). The liquid-to-solid is anyway the direction of the phase transformation in the actual CIM process.

The simplest model to try would be just to take an instrumented jar, pour some molten wax in it, and let it solidify. If the predictions for the solidification front—its shape and size at various times—are accurate enough, then well and good.

Realize that the project idea no. 2 (viz., wax-melting using a rod for heat input) remains absolutely essential, because experimental errors involved in determining the geometry of the phase transformation front are minimal in it: the boundary of the front has a very simple geometry (ideally, circular on the top surface), and its biggest section remains at the top surface, and therefore easily visible, throughout the process. For both these reasons, its motion would be very accurately measurable. In contrast, in solidification studies, the shape of the solidification front would remain more complicated. Further,  since the front would lie interior to the block, it would not be as easy to measure ina continuous nondestructive manner.

2. Another idea is related to bench-marking and testing. I will later on post this part (may be with a little additions and editing) on iMechanica and CFD-related fora, so as to solicit some informal comments about it. Let me note down a preliminary description here, in the next section.

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

A new software benchmark-cum-shopfloor test:

In CFD, the utility of suitable bench-marks is well-established. Think of some typical cases: flow through a converging-diverging channel, flow at a corner or at a T-joint, lid-driven flow with formation of vortices at the corners, flow past an obstacle or over a step and the resultant vortex shedding, the Ahmed body, the Rayleigh-Taylor instability, the dam-break simulation, the falling droplet, etc. These have proved very helpful in validating CFD techniques and software codes/packages—at least for comparing different packages against each other. The idea I propose is in a similar vein.

The proposed experiment is very simple to perform, and yet, it is expected to be very useful. At least I am convinced about its utility enough that I have decided to write a short journal paper on it, just for proposing this test—I mean just for putting forth only the idea of the test, without performing any experimentation/simulation involving it.

Here is the idea.

Take a small solid object, say, a ball-bearing ball made of alloy steel, or a small machined cube of copper, or a small cone of brass. (The surface roughness would need to be specified.)

Hold the object at a suitably high temperature for a sufficiently long of time that it develops a steady temperature throughout its section. Or, assuming that it initially has  been at the room temperature for a sufficiently long time, now place it inside a furnace (or over a hot-plate) of a well-controlled constant temperature for a specified period of time. Basically, the idea is that we come to specify the entire temperature profile of the object.

Take a block of wax of a specified grade i.e. material properties. (Shape and size is to be given some thought, and the issue is to be finalied after some preliminary experiments.) Drill a small hole of a specified shape and size at the center of its top surface. The size of the hole should slightly exceed that of the heated small object.

Place the block snugly fitting inside a well-insulated enclosure (of specified dimensions and material/properties). Or, may be, just place it on a ceramic tile on the laboratory table. (This in fact should work better.)

Rapidly take the small object out of the furnace (or from the hot plate) and gently place it in the hole drilled in the block of wax.

Initially, the hot object will give off its heat to the air above and to the portions of the wax block surrounding it, and so, the wax will melt locally. The object being heavy will displace the molten wax underneath, and thus it will slide deeper into the block. The molten wax will rise from the side-ways. The object will soon get completely covered with a layer of the so-molten wax now convected also onto its top surface. Simultaneously, the column of the molten wax above the object will begin to solidify from the top, by giving off its heat to the air as well as to the surrounding unmolten portions of the block. Also, the heat of the object will continue to get transferred to the wax, and so, its own temperature will go on dropping down, even as it slides down. All these processes will continue until a time when the temperature of the object goes below the melting point of the wax, and so, unable any more to melt the wax, it will come to a stand-still. All of the molten wax wouldn’t have solidified by this time, and so, so we have to wait a little longer for this to happen.

Then (i.e., after waiting for sufficient time), carefully cut through the block, and measure the shape of the region of the wax affected by the heat—in particular, the depth of penetration.

The software should be able to accurately predict the extent of the heat-affected zone, esp. its depth, say as measured by the penetration depth of the object.

This experiment is very simple to perform—it involves no instrumentation. Yet it yields a very specific measure, viz., the extent of the heat affected zone, and most particularly, the depth of the penetration.

However, the process involved in the test is expected to pose a sufficiently difficult case for any CFD software to handle. There is transient heat transfer in two different phases, two successive phase transformations (solid-to-liquid, and then, also liquid-to-solid), convection of liquid wax, buyoancy effects for both the molten wax and the hot object, and motion of the solid-liquid interface. Yet, the overall geometry remains simple enough.

In CFD, people have been studying things such as rising of bubbles and rising/falling of droplets of a second-phase fluid. The process here is somewhat similar.

It is anticipated that during the experimentation, the test should also show good repeatability, provided the wax is homogeneous, and different blocks carry the same material properties.

For processes such as the CIM, the proposed test should be of definite help in two completely different ways: not just as a benchmark for validating software, but also in industrial practice, as a convenient shop-floor test for characterizing the feedstock (i.e. for the routine process quality-control purposes).

For the latter purpose, the feedstock would have to be pressed into the form of a block. This may be achieved via simple cold-pressing, say by filling the feedstock in a container of a square base and then simply placing a specified weight on its top for a specified period of time. These aspects need to be looked into and finalized after some preliminary experimentation.

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

Update added on 2015.05.17:

This update concerns the software benchmark. A couple of points occurred to me after publishing the post.

1. Note the difference of this test from the hot penetration test of bitumen, or the hot hardness test of metals.

In the proposed test here, the hot object gets completely immersed within the wax block. We are interested not only in melting, but also in the relative motion between the hot and cold objects even as cooling takes place simultaneously. Further, we are also interested in solidification. Finally, unlike those two tests, we are not interested in measurements of forces.

(Indeed, when I thought of this idea, the hot hardness/penetration tests were not even in my peripheral awareness; I was just trying to have as simple a test suitable for processing like CIM, as might be possible.)

2. On the second thoughts, completely doing away with instrumentation may not be such a good idea.

Going by my experience of simulating the melting snowman (as well as my browsing of the transient simulations, and their experimental validations), I think that if this test is to be used as an experimental benchmark for software validation (rather than just as a quick quality-control test on the shopfloor), then it should also specify measuring the precise positions of the hot object at different times, and not just the final depth of penetration it reaches.

In other words, the software should be able to predict the times required to reach the intermediate positions, too, accutately. The intermediate times would come out right only if the software handles the entire process right.

Coming to timings, we should not ask only for the final time when the object comes to a rest. After all, it is possible that the computational technique is such that it errs on the intermediate timings, but it does so in such a way that these errors get cancelled out, and so, the total time taken for the object to come to a rest still is predicted right. Such computational techniques will still not be reliable for modeling the actual CIM processing. So, the time-position profile is of primary importance.

Since the wax (and feedstock in general) is not transparent, for experimental measurements of positions, we cannot use light, and so, a simple technique like video shooting wouldn’t work.

However, since the hot object anyway would be metallic (read: electrically conducting), it would always be possible to sense its internal positions using electromagnetic induction. From my experience of the eddy current NDT, I think, it wouldn’t necessarily have to be an LVDT, and the sensing coil wouldn’t have to necessarily enclose the entire block of wax. If my feel is right (though this will have to be determined after a bit of a trial), a simple “one-way” coil placed on one side of the wax block, should also turn out to be sensitive and accurate enough. Of course, the issue of a differential vs. a direct solenoid is something that needs to be looked into separately.

Now, inductive sensing does make the test much more complicated—you have to firsst calibrate the output of the sensing coil. However, realize, the time-position measurements would be performed only in a laboratory, not under the routine production environments. So, it should be OK. …

… Research is always multi-disciplinary. Indeed, knowledge itself cannot be compartmentalized—regardless of what many influential academicians from the Savitribai Phule University of Pune evidently think. (Though, it was not to show them down that I wrote this post/update. I was mainly concerned only with the research, here.)

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

A Song I Like:

(Marathi) “manmohana juLatil naa, taaraa punhaa”
Music: Kedar Pandit
Singer: Ketaki Mategaonkar
Lyrics: ??

[There are two versions of this song, both by the same music director, the same singer, the same melody, and in fact, both also come in the same album! One is in the usual Marathi “bhavgeet” style, whereas the other one is in the “jazz” style. (Not quite jazz all the way through, but it does use some Western instruments someway along that genre.) Surprisingly, the melody fits both the styles so well! I honestly cannot decide which one I like better, though perhaps it’s an indication of my age that I am at times inclined ever so slightly towards the “bhavgeet” version. Or may be, it’s because of Kedar Pandit’s restrained but competent “tablaa” which comes only in that version. (I didn’t know anything about him, but the Wiki tells me that he accompanies Pandit Jasraj on all concerts.) Ketaki is young, and does have limitations to her voice, but the songs here have come out very well. May be with a little help coming in from all those track-editing and pitch-correcting software they all use these days. I don’t know really, but that could easily be the case. But it also is a fact that this kind of a melody would suit her well. And, in any case, the final outcome has come out pretty neat. That counts. … I was driving in the Pune city when I first heard the jazz version on radio, and wished I were driving through a lonely rural patch, instead. So, noted down the words, and looked up the ‘net later on. … Give both the versions a try, even if you don’t know Marathi.]

[E&OE]

Posted in Uncategorized | Tagged , , , , , , , | Leave a comment

An evening by a candle light

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Project Idea 1:

(2–4 PG students)

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

Project Idea 2:

(1–2 PG students)

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

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

Project Idea 3:

(3–4 PG students)

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

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

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

Compare the simulation with the experiment.

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

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

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

A Song I Like:

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

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

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

[E&OE]

Posted in Uncategorized | Tagged , , , , , | 1 Comment

An introductory course on CFD—0

There goes another series of posts!

I have been having a thought of writing down some notes on CFD using FVM. However, it didn’t quite materialize, mainly because I didn’t have an opportunity to teach a course on CFD. The situation may soon change, once I land a suitable job in the University of Mumbai in the upcoming academic year.

I am going to insist that I be considered for teaching courses on CFD above anything else—including FEM.

Anticipating that I should get to teach CFD, I then decided to note down something, mostly just equations without much explanation, and mostly for my own use, not for distribution to students (at least as of now).

I began, and already have the rough versions for, the first two “chapters” in the notes: (i) FVM of 1D steady-state diffusion, and (ii) FVM of 1D steady-state convection-diffusion.

The initial idea was to note down only those equations that will be helpful in writing programs. I would be supplying some simple illustrative code too. After a bit of vacillation, I settled down on writing these programs in Python, rather than in C++. So far, it seems that this was a good decision to make.

I had begun by basing these notes mostly on Versteeg and Malasekara’s text, mainly because there are nice completely solved examples in it. However, as I progressed further in my writing, I found it better to use Jayathi Murthy’s notes as the primary reference, mainly because of the consistency of the mathematical notation (e.g. she explicitly notes down the flux vector, explicitly writes down the formulae for handling Neumann and even mixed conditions, etc.). My rough drafts still are in something of an awkward state, because of this switch-over in the middle of writing them. It will be about a week before they get straightened out and finalized.

Overall, my plan is to write about 2 chapters (complete with the accompanying Python code) every week. The sequence roughly is this:

  1. 1D steady-state diffusion
  2. 1D steady-state convection-diffusion
  3. 2D steady-state convection-diffusion
  4. 2D steady-state pressure-velocity coupling—part 1 (mostly SIMPLE)
  5. 2D steady-state pressure-velocity coupling—part 2 (implementation issues, and SIMPLER etc.)
  6. 1D transient diffusion
  7. 2D transient convection-diffusion (QUICK)
  8. 2D transient SIMPLE
  9. 2D unstructured grids—part 1
  10. 2D unstructured grids—part 2
  11. Implementation of a simple Navier-Stokes solver (incompressible, viscous)—part 1
  12. Implementation of a simple Navier-Stokes solver (incompressible, viscous)—part 2
  13. Multi-gridding

Of course, as I go along, the organization may get changed. The chapters may have to be split up further. And, may be, I would rather directly begin with 2D (as is done by Murthy) and so, the chapters on 1D would get absorbed in the later chapters. Further, an addition of a chapter on coupling the energy equation would be nice to have, though not a must.

Time constraint is important. I have to finish this exercise by mid-June.

I had intended the notes to remain bare-bones. However, once I began writing, explanations invariably kept on creeping in, and the notes became thicker. Some of these explanations didn’t seem to fit in anywhere, but having already written down something, I didn’t have the heart to simply delete this material out. So, I gathered some of these remarks in a separate chapter, which now has become the Chapter 0.

And, realizing how much explanation of how many obvious things I had needlessly inserted, I then decided to publish this zeroth chapter, by way of a definite admonishment to me. Publishing means highlighting, and ease of recall, and I wanted to remind myself how not to write these notes.

I really need to write only the equations first, and implement the programs, even if both are done in a hurried, dirty manner. I could always edit the notes later on and expand them. But first, I need to just finish typing in the equations! Not write very long explanations of the obvious.

So, it is in that sense of admonishment that I now publish the zeroth chapter of the notes. (I may change the contents without notice.) “Enjoy”! [^]

I am sure that I will be publishing the notes and the programs for the first couple of chapters, may be sometime in the second half of this month.

However, I am not sure—indeed, I am not encouraged—that I should also publish the entirety of the material, ahead of actually landing a suitable job.

And, yes, as I said the last time, I don’t think I will have an occasion to blog about anything else in the near future. So, bye for now…

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

A Song I Like:
(Hindi) “aaye tum yaad mujhe”
Singer: Kishore Kumar
Lyrics: Yogesh
Music: S. D. Burman

[E&OE]

 

Posted in Uncategorized | Tagged , , , | Leave a comment

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

[E&OE]

 

Posted in Uncategorized | Tagged , , , , , , , , , , , , , , | 1 Comment

Micro-level water-resources engineering—5

Important Update added on 2015.04.22!

See near the end of this post.

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

Today is (Sanskrit) “akshay tritiya.” In the Khandesh area of North Maharashtra (in which the Shirpur town of the famous Shirpur pattern falls), in the local lingo, the day is known as “aakhaaji.” In Khandesh, it is a festival of women visiting their (Marathi) “maaher” (i.e. their parents’ home, or the home before marriage). There are traditional songs in the local “AhiraNi” dialect, and dance of the Gujarathi garbaa style, but played only by women. When I was a school-boy in that region, the dance would be done with “Tipri”s, but as far as I remember, without any dhols (i.e. drums), loud-speakers, or any large-scale organization, even if all the streets of the town would overflow with women playing “Tipri”s. I don’t know what the situation is like today.

Festivals mark days of relief. But otherwise, summer is a time of gruelling hard work for rural women. Maharashtra’s population is already 11.4 crores. Even if you take only 20% population as drought-affected, that makes it about 2 crores. (In the 2013 drought, the estimates were about 3 crores.) That means about 1 crore drought-affected women. So, as a rough estimate, there must be at least about 50–75 lakh women facing water-scarcity in a normal year—e.g., right now! Imagine, some tens of lakhs of women having to daily carry pots on their heads for several kilometers a day, just for fetching water—often only poor quality and soily/brackish water, but something that allows them at least cooking food for their families for their barest sustenance. What can we do to spare them the hardship? Obvious.

Find out cost-effective water resources strategies and solutions that can be within their means, without remaining dependent either on government or even on charity.

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

I have been browsing a lot of material, but have found that in this area, even some of the simplest questions are so hard to answer.

For instance, the data about the local geology. Or, even the data about local morphology—I mean, maps with contour lines having 1, 2, or even 5 m resolution, and not 20 or 30 m resolution. Digital DEMs with say 5 m resolution are impossible to find, and so, some creative solutions have to be found out. Here, I first thought of an idea, and later on found a part of it mentioned in a Marathi official document for irrigation department that my father gave me. I will write about it, and address many such questions some time later in this series.

In this post, instead, let me touch upon another simple question.

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

How much of the fallen rainwater really runs off the ground to the rivers? Why don’t some of the dams fill up every monsoon?

In Maharashtra, Marathwada is the region of the lowest rainfall (about 65 cm/annum). The river Godavari flows through this region. There is a big dam called the Jayakwadi project [^]; the reservoir is called “Naath Saagar;” it is named after the great Marathi poet-saint Eknath Maharaj.

The simple question is this: Why does the Naath Saagar reservoir does not fill up to its full capacity every rainy season?

An easy answer would be to say: “Because the rainfall is deficient.”

Let us see whether, starting from some simple basic assumptions, this answer turns out to make any sense or not. Let’s try to do a quick, back-of-the-envelop estimate for how much water should flow into the Jayakwadi dam every year. (My objective behind working out this simple exercise was to get some kind of a datum for the small check dams.)

The basic source of water is the rainfall. To estimate the total water received via rainfall, we have to know the watershed area of the dam. The Wiki page on the Jayakwadi dam [^] notes the catchment area as 21,750 square km. Referring to the rainfall for the upstream catchment area of this dam [I used the map in the book River Basins of India (p. 66)], I estimate the average rainfall for this region as about 65 cm (which also is the figure quoted by P. R. Pisharoty as noted in an earlier post in this series). So, the total annual water received via rainfall in the Jayakawadi watershed is about 1.41375E10 cubic m. Raghunath’s text on hydrology [^] on page 5 notes that for India’s total annual rainfall water of 370 million ha-m, the total runoff into all the rivers is 167 million ha-m. Thus, the runoff to the biggest river in a basin should be about 45% of the total water received from the skies. Assuming that a similar figure applies here, I get the runoff calculations as the following Python code shows:

# Assumed data
dRainfall = 0.65 # meter, assumed
dRunoffCoefficient = 0.45 # for all India
dCatchmentArea = 21750.0*1000*1000 # meters
# Calculations
dRainwaterVolume = dRainfall*dCatchmentArea
dEvaporationLoss = dRainwaterVolume/3.0
dRunoff = dRunoffCoefficient*dRainwaterVolume
dSeepageIntoSubsoil = dRainwaterVolume - dEvaporationLoss - dRunoff
print ("Total Volume: %E, Runoff: %E, Evaporation Loss: %E Seepage: %E" % (dRainwaterVolume, dRunoff, dEvaporationLoss, dSeepageIntoSubsoil))

On Ubuntu, open a terminal, type “python” in it, and at the Python prompt (say >>>) copy-paste the above lines, and hit enter. (On Windows, you will have to install a suitable Python environment first.) Or, use the online interactive Python terminal here [^].

Thus, the total quantity of water rushing into the Jayakawadi dam every year should be 6.36E9 m^3 (i.e. cubic meters). The Wiki page on the Jayakwadi dam notes that the total capacity of the dam is just 2.91E9 m^3.

Thus, the total quantity of water flowing into the dam should be about 2.1 times the dam reservoir capacity. The dam should more than overflow every year.

Yet, the dam doesn’t even fully fill up every year—it does so only about 2–3 times in a decade.

Even if we take a lower runoff coefficient, say as low as 0.35 (e.g., to factor in the presence of the relatively smaller dams upstream, and also an increased forest cover—which must be a very unrealistic assumption), and even if we take the annual rainfall in the watershed region to be as drastically low as just 40 cm (i.e. the worst drought situation, because they declare a drought if the rainfall is 20% lower [^], and the average for the catchment area of Jayakawadi is above 65 cm), you should still get some 3.045E9 m^3 of water into the Jayakawadi reservoir—more than enough to fill it up fully.

Indeed, there is a further irony. This dam has already gathered a lot of silt (because it is situated in a relatively flatter region, with more loose soil), and the live storage has gone down by 14% (as per Wiki).

[Incidentally, there has been some criticism that the project was moved 100 km upstream. Chances are, the reservoir then would have covered even a flatter area of loose topsoil.]

All of which means that the Naath Saagar reservoir should fill up and overflow even in the worst drought-hit years.

In practice, it doesn’t.

What gives? Any idea? I have no clue.

There must be something the wrong with the way the run-off calculations are performed—they are going off the mark by some 250%. That is too big an error. Has anyone looked into this aspect more carefully?

Exercise: Undertake the same exercise for the Ujjani dam. It is supposed to supply water to another severely drought-prone region in Maharashtra, viz. that of the Solapur district and the nearby areas. It too doesn’t fill up every year.

Realize that big dams like Jayakwadi and Ujjani have comparatively huge catchment areas. For a check dam, the catchment area (or the watershed area) is very small—and therefore, subject to even wider fluctuations from year to year. This is one sobering point we must keep in mind in our enthusiasm for the micro-level projects.

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

The Evaporation Loss, the High Intensity Rains, and Seepage vs. Storage:

As Raghunath’s book [^] shows on page 5, the water balance equation is:

total rainfall = evaporation loss + runoff + seepage into sub-soil.

The item of seepage into subsoil is further split into two parts: (i) a slightly bigger part (53%) of the contribution to moisture (which is the part that is used by the shrubs and the trees in their life-processes; this is the part that is ultimately released to the atmosphere via transpiration), and (ii) a smaller part (47%) of the recharge into groundwater.

Thus, the biggest items here are (1) runoff and (2) evaporation.

This primary importance of the runoff quantity in the overall quantitative scheme was the reason why I decided to check whether the simple runoff factors or calculations are realistic or not. If they were to be OK, I could use them as they are, in my detailed calculations concerning computational watershed modelling.  But as the above example of the Jayakwadi dam showed, at least at a gross scale, the runoff factors are not reliable. Now, even if there are some more detailed (say GIS based) models and micro-models for computing runoffs, I am not sure how reliable they would be. And, if the runoff factor itself is wrong, we are basically regressing back to the stage of empirical data collecting and validation, and so, coarsening out of the micro-models to macro-models (even if using GIS) would be an even more distant a step … Anyway, to proceed further….

For India, the runoff figure is several times higher than the total groundwater recharge.

Further, in the Deccan trap basalt region of Maharashtra, the seepage mechanism is not as efficient as it is in the alluvial soils (for instance, of Aravali region of Rajasthan, or in the Tapi and Purna basins of Maharashtra (the area of the Shirpur pattern)).

Recall Pisharoty’s paper I quoted in my last post in this series [^]. In Maharashtra, half of the annual rainfall occurs within only 15 to 20 high-intensity hours, which occur sometime over only 35–45 days of any actual rainfall.

Thus, in the Deccan trap region of Maharashtra, first there is an overall inefficiency of seepage. It is further compounded worse due to the infrequent high intensity bursts of rains. If the same amount of rainfall were to occur as a slow drizzle over a long period of time, say a continuous stretch of weeks, then such a rainfall pattern would be better conducive to seepage. On the other hand, a sporadic high intensity pattern implies less seepage and more runoff.

Hence, in the Deccan trap regions of Maharashtra, it is the surface storage strategy which is likely to prove better than the underground seepage strategy.

For the above reasons, our solutions should be able to handle arresting the high intensity runoff, for storage.

Next, in India in general, evaporation also is several times higher than the groundwater recharge.

Evaporation is a really bad factor in hot climates like India. At the level of large-scale dams and even for check dams, there is precious little that can be done about it. (Solutions have been sought, e.g., spreading some chemicals on top of the water, but their side effects is a worry.)

Realize that evaporation is a surface phenomenon. Dams with a shallow and wide-spread reservoir (e.g. Jayakwadi) tend to have a relatively higher percentage of evaporation losses, as compared to the deeper dams. Ditto, also for check dams. (That is the reason why the nallah-deepening aspect of the Shirpur pattern makes good sense—provided the cost of excavation is low enough. For the time being, let’s focus on evaporation.)

Evaporation maps for Maharashtra show losses as high as 1.5 m to even 2.5 m per year. Thus, if you build a check-dam with a 3 m high wall, expect to lose more than half of the water to evaporation alone. (The famous bund of the bund-garden in the Pune city used to be actually shallow; it would hold a nice expanse of water simply because the bigger Khadakvasla dam upstream would periodically release water into the river.)

For the same reason of evaporation, most nallah-bunding and contour-trenching works, such as those by Anna Hazaare in Ralegan Siddhi, or those typically undertaken under the socialist programs like MNREGA, don’t translate to anything at all for storage, or for that matter even seepage. Typically, the bunds are less than 1 m tall, and theoretically, water in them is expected to plain evaporate out right before December. Practically, that anyway is the observation! No matter what Anna Hazare might tell you, it is a waste of money and effort.

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

Farm Ponds:

Before closing, let me mention farm ponds as an effective storage strategy, apart from check-dams.

One big advantage with check dams as compared to conventional dams is that there is no cost incurred in the acquisition of land, and for rehabilitation of the displaced people. Speaking purely costs-wise, I read somewhere (or heard in Suresh Khanapurkar’s interviews) that about half of the cost of the conventional dams is on just these two counts.

However, in the case of check dams, if the natural depth of the river gorge is not sufficient (try the small software I wrote earlier in this series), then in order to reduce the percentage loss due to evaporation and thus to make the project economical, some extra expenditure may become necessary in deepening the nallahs.

Now, in the Deccan trap region of Maharashtra, since small rivers and nallahs tend to run through regions of hard rocks (the top soil layer can be as thin as just 0.5 to 1 m or even zero, in them), the excavation work to deepen the nallahs can easily prove to be too costly—this is a factor going against the Shirpur pattern. (More on the economics of excavation in check dams, and of farm ponds, in a later post.)

An advantage with the farm ponds, when compared to check dams, is that since they are built in the field, i.e. in a deeper layer of soft soil, deepening the ditch turns out to be much more economical.

On the downside, as compared to check dams, the storage capacity of farm ponds is much smaller. They also eat up what otherwise could have been a productive farm land.

But, as we saw, a deeper water body means lower percentage of evaporation losses.

Thus, overall, costs-wise, there are many oppositely directed factors, and it’s not possible to draw general conclusions. It’s the cost balance that really determines whether a farm pond makes sense in a given location or not, or is it a check dam for storage, or a check dam for seepage. (I will write another post covering the economics of check dams vs. farm ponds vs. conventional dams).

Second, as far as evaporation is concerned, there is an incredibly creative solution which I ran into only today. It suggests that if you cover a farm pond with a floating layer of the used plastic bottles, then the evaporation loss (at least for very small experimental ponds) can be cut by up to 40%! [(1.7 MB .PDF file) ^]. The work has been done at the well-known Vigyaan Aashram at PaabaL near Pune; guess they also have some kind of collaboration with COEP and MIT (USA). Anyway, coming back to evaporation losses, this is a huge, huge advantage at a throw-away price! The suggestion right now is only at a preliminary stage. I think it should be seriously taken up for studies on a larger scale of a realistic pond. But yes, as an engineer, I simply marvel at this idea—it again takes a perceived problem (“Gee, even Indians have started buying bottled water, huh?” and “Now how do we deal with this mess of all this plastic waste!”), turns it around on its head, and provides a cost-effective solution to another pressing problem. Neat!

BTW, the farm ponds need not always get only“naturally” filled, i.e., with the surface-running rain-water falling from the sky on the same field. Sometimes a combination of a lift-irrigation scheme + a farm pond can also be cost-effective.

Further, as has been practically demonstrated at many sites (e.g. in the Ahmednagar district, by actually practising farmers) a farm pond can also be very easily used for farming fish, as a side business (read side income)! Farming for fish requires relatively little labour—mostly, only some aeration (if at all required) and throwing food into the pond regularly (like twice/thrice a week or so), that’s all. Fish is not only very tasty food, it also is a very high quality and easily digested protein.

The side-walls of the farm-ponds can be also be planted with the kind of trees that give lush green shadow while making do with less water demand. A welcome sight, and a welcome spot for rest, on a hot summer afternoon.

Finally, talking of water bodies, trees, and how beautiful and (literally) cool a surroundings they can go on to make, and of side-businesses, and of creativity, here is yet another creative side-business that has come out of a bigger farm pond; check out the Saguna Baug in Neral near Mumbai [^].

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

Important Update added on 2015.04.22:

Python scripts for predicting the extent to which the Jayakwadi and Ujjani dams should fill, at a given rainfall level. Also, analysis of results, and some comments:

Since writing this post yesterday, I studied more closely the topic of the rainfall–runoff relationships in standard textbooks on hydrology.

There are quite a few models that allow you to calculate the expected runoff volume from the rainfall extent. These are specific to soil types, gradients, type of surface, etc. For Maharashtra, there is a well-known model by Inglis and De Souza (1929); e.g. see p. 180 here [^]. This is an empirical (curve-fitted) model that gives you two separate equations.

For the ghat region:
R = 0.85P - 30.5

and for the Deccan plateau:
R = \dfrac{1}{254} P \left( P - 17.8\right)

where R is the annual runoff and P is the annual rainfall, both in cm.

Since the formulae seemed to give far lower values for the runoff coefficient, and hence the runoff volume even for the average rains, I decided to write a Python script to find out the extent to which the Jayakwadi (and later, also Ujjani) dam would fill up, given different levels of rainfall.

Here is a link to a zip containing the Python script files and their outputs, in the CSV format [^]. In my code, I calculate the R parameter using both the above equations and take their average. Effectively, I assume that half of the watershed region is of the ghat region, and the other half is of the Deccan plateau. Though the zip file doesn’t show it, there aren’t very glaring differences in the values of R as estimated via the two equations.

The files make it clear that at the average rainfall level of 65 cm in the watershed (i.e. the catchment) region, the Jayakwadi dam is expected to fill only to 89.6%. If there is a drought year and so the watershed region receives some 45 cm rains, this dam would fill only to 21%!! For this dam to fill 100%, an above average rainfall of 67–68 cm would be necessary. Little wonder that the dam has filled only rarely.

The figures for the Ujjani dam are not much different, only slightly different. For instance, it would take 77–78 cm rain in its catchment area for it to fill up. The catchment area of the Ujjani dam does receive a somewhat higher rain, and so, let’s say the normal rainfall there is 70 cm. At this level, the Ujjani dam is expected to fill only to 73% of its full capacity!

There are other methods to estimate runoff too. But given the informal general knowledge about these dams, Inglis and De Souza’s correlations would seem to hold well.

I am no expert in dams design. To my lay engineer’s eyes, these are decidedly wasteful designs. After all, bigger-than-necessary designs imply greater-than-necessary expenditures, too. The Wiki page informs us that Jayakwadi project has cost more than Rs. 10,000 crores by now. … What portion of this huge amount are wasteful?

Among the Maharashtrian “intellectual,” “chattering” etc. classes  (and also among the NRI community, esp. that settled in the USA, esp. in California), it has become a fashion to blame politicians for every conceivable ill concerning water scarcity in Maharashtra.

Do you think that these civil engineering designs were done by politicians? Do you think that, for instance, say Vasantrao Naik, would have knowingly ordered a deliberately bigger and costlier dam, just to score some political high point for himself or his party? (I mention him because the Wiki informs us that the Jayakwadi dam design was finalized when he was the CM. Similarly, the Ujjani dam got designed when he was the CM.)

If you think such things are possible—things like increasing a dam size just to score some political high point for oneself or one’s party—then I would say that you just don’t know the way a typical politician thinks and operates. Yes, even in a mixed economy.

Yes, it’s important for a typical politician in a mixed economy (regardless of the party to which he belongs) to show that he is doing something meaningful, whether something actually meaningful gets done or not; yes, it is possible that given a choice, he would always pick up that choice which benefits his own constituency; yes, it is possible that he might even bring a bit of pressure on the officers to tweak solutions so that his constituency benefits. (They even publicly admit if not boast about such things.)

But a deliberate increase of size of a dam for absolutely no conceivable benefit to anyone? No way. No politician even in a mixed economy—and esp. in reference to a country like India—ever operates that way.

Here, if you say that an increased dam size means an increased budget, and therefore greater bribes to him/his party-men, then I would say, you just don’t understand the system. Even if I grant you the premise that every politician is always on principle on the look-out for kickbacks and bribes, granted that, a typical politician still wouldn’t want to increase a dam’s size, because—and get this right—he doesn’t have to. He can easily use the same amount of the additional (wasteful) budget on some other project without ever affecting the total quantum of his bribe, so why should he insist on making just one dam/project bigger than necessary, at the expense of all other possible dams/projects? If he can build two dams in the same budget—note, the amount of bribe has stayed the same—since he stands to get double the publicity with the same budget-money, he would rather go in for that.

Thus, all this “logic” is simply the smart “white-collared” Indian’s way of saving the “behind” of his own—or of groups of people he regards similar to him—nothing else.

Are bureaucrats and even engineers ever going to admit there might have been some mistakes here? More importantly, how many Indians of the “intellectual” kind are going to be willing to even think of such a possibility? (Even Anna Hazaare’s all-water-vaporizing nallah-bunds seem almost innocuous by comparison; they must have involved relatively smaller amounts, say of a mere few hundreds of crores. In contrast, wasteful big projects like these would involve thousands of crores.)

And, even more importantly, is there anyone willing to have an honest second look about the socialistic nature of the system that produces costly errors of this kind? (Not just costs. Since a wrong datum for the capacity of the dam has been established, now there also are fights: Marathwada people think that if the Jayakwadi dam doesn’t fill up fully, the reason must be that the smaller dams upstream have been criminally diverting water that is rightfully theirs… Think of the bigger and bigger mess it all gets into.)

…Anyway, since I can’t do anything about it, let me wind down on that topic, and instead, let me focus on what I can do.

What this exercise means is that I can use some of these even simple text-book methods to build computational models for the check dams/farm ponds with acceptable enough accuracy; they would be accurate at least to a first-order. (After all, Inglis and De Souza’s second equation shows that a quadratic dependence of the runoff on the rainfall. Also, the other rainfall-runoff models show different kinds of nonlinear relations. So, they should be accurate at least to the first order in further usage.)

One more point before we close. Let me note a couple of good links on the topic of farm ponds. Here they are:

“Farm Ponds: A Climate Resilient Technology for Rainfed Agriculture: Planning, Design and Construction” [(13.1 MB PDF) ^]

“Rainwater Harvesting and Reuse through Farm Ponds: Experiences, Issues and Strategies” [(5.4 MB PDF) ^]

Also, a useful reference on the topic of evaporation: “Potential Evapotranspiration Estimation for Indian Conditions: Improving accuracy through calibration coefficients” [(3.8 MB PDF) ^]

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

A Song I Like:

[I recently randomly stumbled on a listing of this song, and then listened to it after a long, long time—long enough that reading only through the words, I was not able to place the song; I had to listen to it to “get” it back…  A relaxed tempo, and a beautiful melody by SD. … I don’t know if RD assisted SD for this song or not (this one is from 1963), but going by the orchestration, there is at least a hint of the young RD here, esp. in those interludes of the sax and guitar. I doubt if Dada Burman, in 1963, could have given that much of a freedom to Manohari Singh (an assistant and the probable sax player) sans RD’s presence. The tune, of course, is unmistakably SD’s own. … It’s the kind of a tune which you inadvertently catch yourself humming aloud sometime later, perhaps even a few days later, and it still surprises you, and it still makes you want to re-listen to the song…  Shailendra is at his lyrical best… And yes, it’s Suman Kalyanpur, not Lata.  Enjoy the brilliant simplicity of SD (possibly with a small assistance coming from RD)…]

(Hindi) “ye kis ne geet chheDaa…”
Music: S. D. Burman
Singers: Mukesh, Suman Kalyanpur
Lyrics: Shailendra

 

[PS: Though the content will not change much, tomorrow, I might come back and add just a few links to some good documents on design/experience/economics of farm ponds that I have downloaded. Done. Also added Python scripts for computing the percentage of dam capacity to which the Jayakwadi and Ujjani dams would fill up, at various levels of rainfall in their respective catchment areas.]

Posted in Uncategorized | Tagged , , , , , , , , , , , , | Leave a comment