Flames not so old…

The same picture, but two American interpretations, both partly misleading (to varying degrees):

NASA releases a photo [^] on the FaceBook, on 24 August at 14:24, with this note:

The visualization above highlights NASA Earth satellite data showing aerosols on August 23, 2018. On that day, huge plumes of smoke drifted over North America and Africa, three different tropical cyclones churned in the Pacific Ocean, and large clouds of dust blew over deserts in Africa and Asia. The storms are visible within giant swirls of sea salt aerosol (blue), which winds loft into the air as part of sea spray. Black carbon particles (red) are among the particles emitted by fires; vehicle and factory emissions are another common source. Particles the model classified as dust are shown in purple. The visualization includes a layer of night light data collected by the day-night band of the Visible Infrared Imaging Radiometer Suite (VIIRS) on Suomi NPP that shows the locations of towns and cities.

[Emphasis in bold added by me.]

For your convenience, I reproduce the picture here:

Aerosol data by NASA

Aerosol data by NASA. Red means: Carbon emissions. Blue means: Sea Salt. Purple means: Dust particles.

Nicole Sharp blogs [^] about it at her blog FYFD, on Aug 29, 2018 10:00 am, with this description:

Aerosols, micron-sized particles suspended in the atmosphere, impact our weather and air quality. This visualization shows several varieties of aerosol as measured August 23rd, 2018 by satellite. The blue streaks are sea salt suspended in the air; the brightest highlights show three tropical cyclones in the Pacific. Purple marks dust. Strong winds across the Sahara Desert send large plumes of dust wafting eastward. Finally, the red areas show black carbon emissions. Raging wildfires across western North America are releasing large amounts of carbon, but vehicle and factory emissions are also significant sources. (Image credit: NASA; via Katherine G.)

[Again, emphasis in bold is mine.]

As of today, Sharp’s post has collected some 281 notes, and almost all of them have “liked” it.

I liked it too—except for the last half of the last sentence, viz., the idea that vehicle and factory emissions are significant sources (cf. NASA’s characterization):


My comment:

NASA commits an error of omission. Dr. Sharp compounds it with an error of commission. Let’s see how.

NASA does find it important to mention that the man-made sources of carbon are “common.” However, the statement is ambiguous, perhaps deliberately so. It curiously omits to mention that the quantity of such “common” sources is so small that there is no choice but to regard it as “not critical.” We may not be in a position to call the “common” part an error of commission. But not explaining that the man-made sources play negligible (even vanishingly small) role in Global Warming, is sure an error of omission on NASA’s part.

Dr. Sharp compounds it with an error of commission. She calls man-made sources “significant.”

If I were to have an SE/TE student, I would assign a simple Python script to do a histogram and/or compute the densities of red pixels and have them juxtaposed with areas of high urban population/factory density.


This post may change in future:

BTW, I am only too well aware of the ugly political wars being waged by a lot of people in this area (of Global Warming). Since I do appreciate Dr. Sharp’s blog, I would be willing to delete all references to her writing from this post.

However, I am going to keep NASA’s description and the photo intact. It serves as a good example of how a good visualization can help in properly apprehending big data.

In case I delete references to Sharp’s blog, I will simply add another passage on my own, bringing out how man-made emissions are not the real cause for concern.

But in any case, I would refuse to be drawn into those ugly political wars surrounding the issue of Global Warming. I have neither the interest nor the bandwidth to get into it, and further, I find (though can’t off-hand quote) that several good modelers/scientists have come to offer very good, detailed, and comprehensive perspectives that justify my position (mentioned in the preceding paragraph). [Off-hand, I very vaguely remember an academic, a lady, perhaps from the state of Georgia in the US?]


The value of pictures:

One final point.

But, regardless of it all (related to Global Warming and its politics), this picture does serve to highlight a very important point: the undeniable strength of a good visualization.

Yes I do find that, in a proper context, a picture is worth a thousand words. The obvious validity of this conclusion is not affected by Aristotle’s erroneous epistemology, in particular, his wrong assertion that man thinks in terms of “images.” No, he does not.

So, sure, a picture is not an argument, as Peikoff argued in the late 90s (without using pictures, I believe). If Peikoff’s statement is taken in its context, you would agree with it, too.

But for a great variety of useful contexts, as the one above, I do think that a picture is worth a thousand words. Without such being the case, a post like this wouldn’t have been possible.


A Song I Like:
(Hindi) “dil sajan jalataa hai…”
Singer: Asha Bhosale
Music: R. D. Burman [actually, Bertha Egnos [^]]
Lyrics: Anand Bakshi


Copying it right:

“itwofs” very helpfully informs us [^] that this song was:

Inspired in the true sense, by the track, ‘Korbosha (Down by the river) from the South African stage musical, Ipi Ntombi (1974).”

However, unfortunately, he does not give the name of the original composer. It is: Bertha Egnos (apparently, a white woman from South Africa [^]).

“itwofs” further opines that:

Its the mere few initial bars that seem to have sparked Pancham create the totally awesome track [snip]. The actual tunes are completely different and as original as Pancham can get.

I disagree.

Listen to Korbosha and to this song, once again. You will sure find that it is far more than “mere few initial bars.” On the contrary, except for a minor twist here or there (and that too only in some parts of the “antaraa”/stanza), Burman’s song is almost completely lifted from Egnos’s, as far as the tune goes. And the tune is one of the most basic—and crucial—elements of a song, perhaps the most crucial one.

However, what Burman does here is to “customize” this song to “suit the Indian road conditions tastes.” This task also can be demanding; doing it right takes a very skillful and sensitive composer, and R. D. certainly shows his talents in this regard, too, here. Further, Asha not only makes it “totally, like, totally” Indian, she also adds a personal chutzpah. The combination of Egnos, RD and Asha is awesome.

If the Indian reader’s “pride” got hurt: For a reverse situation of “phoreenn” people customizing our songs, go see how well Paul Mauriat does it.

One final word: The video here is not recommended. It looks (and is!) too gaudy. So, even if you download a YouTube video, I recommend that you search for good Open Source tools and use it to extract just the audio track from this video. … If you are not well conversant with the music software, then Audacity would confuse you. However, as far as just converting MP4 to MP3 is concerned, VLC works just as great; use the menu: Media \ Convert/Save. This menu command works independently of the song playing in the “main” VLC window.


Bye for now… Some editing could be done later on.

Advertisements

General update: Will be away from blogging for a while

I won’t come back for some 2–3 weeks or more. The reason is this.


As you know, I had started writing some notes on FVM. I would then convert my earlier, simple, CFD code snippets, from FDM to FVM. Then, I would pursue modeling Schrodinger’s equation using FVM. That was the plan.

But before getting to the nitty-gritties of FVM itself, I thought of jotting down a note, once and for all, putting in writing my thoughts thus far on the concept of flux.


If you remember, it was several years ago that I had mentioned on this blog that I had sort of succeeded in deriving the Navier-Stokes equation in the Eulerian but differential form (d + E for short).

… Not an achievement by any stretch of imagination—there are tomes written on say, differentiable manifolds and whatnot. I feel sure that deriving the NS equations in the (d + E) form would be less than peanuts for them.

Yet, the fact of the matter is: They actually don’t do that!

Show me a single textbook or a paper that does that. If not at the UG level, then at least at the PG level, but one that is written using the language of only plain calculus, as used by engineers—not that of advanced analysis.

And as to the UG/PG books from engineering:

What people normally do is to derive these equations in its integral form, whether using the Lagrangian or the Eulerian approach. That is, they adopt either the (i + L) approach or the (i + D) approach.

At some rare times, if they at all begin fluid dynamics with a differential form of the NS equations, then they invariably follow the Lagrangian approach, never the Eulerian. That is, they invariably begin with only (d + L)—even in those cases when their objective is to obtain (d + E). Then, after having derived (d +L) , they simply invoke some arbitrary-looking vector calculus identities to “transform” those equations from (d + L) to (d +E).

And, worse:

They never discuss the context, meaning, or proofs of those identities. None from fluid dynamics or CFD side does that. And neither do the books on maths written for scientists and engineers.

The physical bases of the “transformation” process must remain a mystery.


When I started working through it a few years ago, I realized that the one probable reason why they don’t use the (d +E) form right from the beginning is because: forget the NS equations, no one understands even the much simpler idea of the flux—if it is to be couched entirely in the settings of (d+E). You see, the idea of the flux too always remains couched in the integral form, never the differential. For example, see Narasimhan [^]. Or, any other continuum mechanics books that impresses you.

It’s no accident that the Wiki article on Flux [^] says that it

needs attention from an expert in Physics.

And then, more important for us, the text of the article itself admits that the formula it notes, for a definition of flux in differential terms, is

an abuse of notation

See the section here [^].

Also, ask yourself, why is a formula that is free of the abuse of notation not being made available? In spite of all those tomes having been written on higher mathematics?


Further, there were also other related things I wanted to write about, like an easy pathway to the idea of tensors in general, and to that of the stress tensor in particular.

So, I thought of writing it down it for once and for all, in one note. I possibly could convert some parts of it into a paper later on, perhaps. For the time being though, the note would be more in the nature of a tutorial.


I started writing down the note, I guess, from 17 August 2018. However, it kept on growing, and with growth came reorganization of material for a better hierarchy or presentation. It has already gone through some 4–5 thorough re-orgs (meaning: discarding the earlier LaTeX file entirely and starting completely afresh), and it has already become more than 10 LaTeX pages. Even then, I am nowhere near finishing it. I may be just about half-way through—even though I have been working on it for some 7–8 hours every day for the past fortnight.

Yes, writing something in original is a lot of hard work. I mean “original” not in the sense of discovery, but in the sense of a lack of any directly citable material whatsoever, on the topic. Forget copy-pasting. You can’t even just gather a gist of the issue so that you could cite it.

And, the trouble here is, this topic is otherwise so very mature. (It is some 150+ years old.) So, you know that if you go even partly wrong, the whole world is going to pile on you.

And that way, in my experience, when you write originally, there is at least 5–10 pages of material you typically end up throwing away for every page that makes it to the final, published, version. Yes, the garbage thrown out is some 5–10 times the material retained in—no matter how “simple” and “straightforward” the published material might look.

Indeed, I could even make a case that the simpler and the more straight-forward the published material looks, if it also happens to be original, then the more strenuous it has been, on the part of the author.

Few come to grasp this simple an observation, ever, in their entire life.


As a case in point, I wish to recall here my conference paper on diffusion. [To be added here soon enough.]

I have many times silently watched people as they were going through this paper for the first time.

Typically, when engineers read it, they invariably come out with a mild expression which suggests that they probably were thinking of something like: “isn’t it all so simple and straight-forward?” Sometimes they even explicitly ask: “And, what do you say was the new contribution here?” [Even after having gone through both the abstract and the conclusion part of it, that is.]

On the other hand, on the four-five rare occasions when I have had the opportunity to watch professional mathematicians go through this paper of mine, in each case, the expression they invariably gave at the end of finishing it was as if they still were very intently absorbed in it. In particular, they never do ask me what was new about it—they just remain deeply engaged in what looks like an exercise in “fault-finding”, i.e., in checking if any proof, theorem or lemma they had ever had come across could be used in order to demolish the new idea that has been presented. Invariably, they give the same argument by way of an objection. Invariably, I explain why their argument does not address the issue I have raised in the paper. Invariably they chuckle and then go back to the paper and to their intent thinking mode, to see if there is any other weakness to my basic argument…

Till date (even after more than a decade), they haven’t come back.

But in all cases, they were very ready to admit that they were coming across this argument for the first time. I didn’t have to explain it to them that though the language and the tone of the paper looked simple enough, the argument itself was not easy to derive originally.


No, the notes which I am currently working on are nowhere near as original as that. [But yes, original, these are.]

Yet, let me confess, even as I keep prodding through it for the better part of the day the way I have done over the past fortnight or so, I find myself dealing with a certain doubt: wouldn’t they just dismiss it all as being too obvious? as if all the time and effort I spent on it was, more or less, ill spent? that it was all meaningless to begin with?


Anyway, I want to finish this task before resuming blogging—simply because I’ve got a groove about it by now… I am in a complete and pure state of anti-procrastination.

… Well, as they say: Make the hay while the Sun shines…


A Song I Like:
(Marathi) “dnyaandev baaL maajhaa…”
Singer: Asha Bhosale
Lyrics: P. Savalaram
Music: Vasant Prabhu

 

Links…

Here are a few interesting links I browsed recently, listed in no particular order:


“Mathematicians Tame Turbulence in Flattened Fluids” [^].

The operative word here, of course, is: “flattened.” But even then, it’s an interesting read. Another thing: though the essay is pop-sci, the author gives the Navier-Stokes equations, complete with fairly OK explanatory remarks about each term in the equation.

(But I don’t understand why every pop-sci write-up gives the NS equations only in the Lagrangian form, never Eulerian.)


“A Twisted Path to Equation-Free Prediction” [^]. …

“Empirical dynamic modeling.” Hmmm….


“Machine Learning’s `Amazing’ Ability to Predict Chaos” [^].

Click-bait: They use data science ideas to predict chaos!

8 Lyapunov times is impressive. But ignore the other, usual kind of hype: “…the computer tunes its own formulas in response to data until the formulas replicate the system’s dynamics. ” [italics added.]


“Your Simple (Yes, Simple) Guide to Quantum Entanglement” [^].

Click-bait: “Entanglement is often regarded as a uniquely quantum-mechanical phenomenon, but it is not. In fact, it is enlightening, though somewhat unconventional, to consider a simple non-quantum (or “classical”) version of entanglement first. This enables us to pry the subtlety of entanglement itself apart from the general oddity of quantum theory.”

Don’t dismiss the description in the essay as being too simplistic; the author is Frank Wilczek.


“A theoretical physics FAQ” [^].

Click-bait: Check your answers with those given by an expert! … Do spend some time here…


Tensor product versus Cartesian product.

If you are engineer and if you get interested in quantum entanglement, beware of the easily confusing terms: The tensor product and the Cartesian product.

The tensor product, you might think, is like the Cartesian product. But it is not. See mathematicians’ explanations. Essentially, the basis sets (and the operations) are different. [^] [^].

But what the mathematicians don’t do is to take some simple but non-trivial examples, and actually work everything out in detail. Instead, they just jump from this definition to that definition. For example, see: “How to conquer tensorphobia” [^] and “Tensorphobia and the outer product”[^]. Read any of these last two articles. Any one is sufficient to give you tensorphobia even if you never had it!

You will never run into a mathematician who explains the difference between the two concepts by first directly giving you a vague feel: by directly giving you a good worked out example in the context of finite sets (including enumeration of all the set elements) that illustrates the key difference, i.e. the addition vs. the multiplication of the unit vectors (aka members of basis sets).

A third-class epistemology when it comes to explaining, mathematicians typically have.


A Song I Like:

(Marathi) “he gard niLe megha…”
Singers: Shailendra Singh, Anuradha Paudwal
Music: Rushiraj
Lyrics: Muralidhar Gode

[As usual, a little streamlining may occur later on.]

Some suggested time-pass (including ideas for Python scripts involving vectors and tensors)

Actually, I am busy writing down some notes on scalars, vectors and tensors, which I will share once they are complete. No, nothing great or very systematic; these are just a few notings here and there taken down mainly for myself. More like a formulae cheat-sheet, but the topic is complicated enough that it was necessary that I have them in one place. Once ready, I will share them. (They may get distributed as extra material on my upcoming FDP (faculty development program) on CFD, too.)

While I remain busy in this activity, and thus stay away from blogging, you can do a few things:


1.

Think about it: You can always build a unique tensor field from any given vector field, say by taking its gradient. (Or, you can build yet another unique tensor field, by taking the Kronecker product of the vector field variable with itself. Or, yet another one by taking the Kronecker product with some other vector field, even just the position field!). And, of course, as you know, you can always build a unique vector field from any scalar field, say by taking its gradient.

So, you can write a Python script to load a B&W image file (or load a color .PNG/.BMP/even .JPEG, and convert it into a gray-scale image). You can then interpret the gray-scale intensities of the individual pixels as the local scalar field values existing at the centers of cells of a structured (squares) mesh, and numerically compute the corresponding gradient vector and tensor fields.

Alternatively, you can also interpret the RGB (or HSL/HSV) values of a color image as the x-, y-, and z-components of a vector field, and then proceed to calculate the corresponding gradient tensor field.

Write the output in XML format.


2.

Think about it: You can always build a unique vector field from a given tensor field, say by taking its divergence. Similarly, you can always build a unique scalar field from a vector field, say by taking its divergence.

So, you can write a Python script to load a color image, and interpret the RGB (or HSL/HSV) values now as the xx-, xy-, and yy-components of a symmetrical 2D tensor, and go on to write the code to produce the corresponding vector and scalar fields.


Yes, as my resume shows, I was going to write a paper on a simple, interactive, pedagogical, software tool called “ToyDNS” (from Toy + Displacements, Strains, Stresses). I had written an extended abstract, and it had even got accepted in a renowned international conference. However, at that time, I was in an industrial job, and didn’t get the time to write the software or the paper. Even later on, the matter kept slipping.

I now plan to surely take this up on priority, as soon as I am done with (i) the notes currently in progress, and immediately thereafter, (ii) my upcoming stress-definition paper (see my last couple of posts here and the related discussion at iMechanica).

Anyway, the ideas in the points 1. and 2. above were, originally, a part of my planned “ToyDNS” paper.


3.

You can induce a “zen-like” state in you, or if not that, then at least a “TV-watching” state (actually, something better than that), simply by pursuing this URL [^], and pouring in all your valuable hours into it. … Or who knows, you might also turn into a closet meteorologist, just like me. [And don’t tell anyone, but what they show here is actually a vector field.]


4.

You can listen to this song in the next section…. It’s one of those flowy things which have come to us from that great old Grand-Master, viz., SD Burman himself! … Other songs falling in this same sub-sub-genre include, “yeh kisine geet chheDaa,” and “ThanDi hawaaein,” both of which I have run before. So, now, you go enjoy yet another one of the same kind—and quality. …


A Song I Like:

[It’s impossible to figure out whose contribution is greater here: SD’s, Sahir’s, or Lata’s. So, this is one of those happy circumstances in which the order of the listing of the credits is purely incidental … Also recommended is the video of this song. Mona Singh (aka Kalpana Kartik (i.e. Dev Anand’s wife, for the new generation)) is sooooo magical here, simply because she is so… natural here…]

(Hindi) “phailee huyi hai sapanon ki baahen”
Music: S. D. Burman
Lyrics: Sahir
Singer: Lata Mangeshkar


But don’t forget to write those Python scripts….

Take care, and bye for now…

 

Exactly what does this script show?

Update on 02 March 2018, 15:34 IST: I have now added another, hopefully better, version of the script (but also kept the old one intact); see in the post below. The new script too comes without comments.


Here is a small little Python script which helps you visualize something about a state of stress in 2D.

If interested in understanding the concept of stress, then do run it, read it, try to understand what it does, and then, if still interested in the concept of stress, try to answer this “simple” little question:

Exactly what does this script show? Exactly what it is that you are visualizing, here?


I had written a few more notes and inline comments in the script, but have deliberately deleted most of them—or at least the ones which might have given you a clue towards answering the above question. I didn’t want to spoil your fun, that’s why.

Once you all finish giving it a try, I will then post another blog-entry here, giving my answer to that question (and in the process, bringing back all the deleted notes and comments).

Anyway, here is the script:


'''
A simple script to help visualize *something* about
a 2D stress tensor.

--Ajit R. Jadhav. Version: 01 March 2018, 21:39 HRS IST.
'''

import math
import numpy as np
import matplotlib.pyplot as plt

# Specifying the input stress
# Note:
# While plotting, we set the x- and y-limits to -150 to +150,
# and enforce the aspect ratio of 1. That is to say, we do not
# allow MatPlotLib to automatically scale the axes, because we
# want to appreciate the changes in the shapes as well sizes in
# the plot.
#
# Therefore, all the input stress-components should be kept
# to within the -100 to +100 (both inclusive) range.
#
# Specify the stress state in this order: xx, xy; yx, yy
# The commas and the semicolon are necessary.

sStress = "-100, 45; 90, 25"

axes = plt.axes()
axes.set_xlim((-150, 150))
axes.set_ylim((-150, 150))
plt.axes().set_aspect('equal', 'datalim')
plt.title(
    "A visualization of *something* about\n" \
    "the 2D stress-state [xx, xy; yx, yy] = [%s]" \
    % sStress)

mStress = np.matrix(sStress)
mStressT = np.transpose(mStress)

mUnitNormal = np.zeros((2, 1))
mTraction = np.zeros((2, 1))

nOrientations = 18
dIncrement = 360.0 / float(nOrientations)
for i in range(0, nOrientations):
    dThetaDegrees = float(i) * dIncrement
    dThetaRads = dThetaDegrees * math.pi / 180.0
    mUnitNormal = [round(math.cos(dThetaRads), 6), round(math.sin(dThetaRads), 6)]
    mTraction = mStressT.dot(mUnitNormal)
    if i == 0:
        plt.plot((0, mTraction[0, 0]), (0, mTraction[0, 1]), 'black', linewidth=1.0)
    else:
        plt.plot((0, mTraction[0, 0]), (0, mTraction[0, 1]), 'gray', linewidth=0.5)
    plt.plot(mTraction[0, 0], mTraction[0, 1], marker='.',
             markeredgecolor='gray', markerfacecolor='gray', markersize=5)
    plt.text(mTraction[0, 0], mTraction[0, 1], '%d' % dThetaDegrees)
    plt.pause(0.05)

plt.show()


Update on 02 March 2018, 15:34 IST:

Here is a second version of a script that does something similar (but continues to lack explanatory comments). One advantage with this version is that you can copy-paste the script to some file, say, MyScript.py, and invoke it from command line, giving the stress components and the number of orientations as command-line inputs, e.g.,

python MyScript.py "100, 0; 0, 50" 12

which makes it easier to try out different states of stress.

The revised code is here:


'''
A simple script to help visualize *something* about
a 2D stress tensor.

--Ajit R. Jadhav. 
History: 
06 March 2018, 10:43 IST: 
In computeTraction(), changed the mUnitNormal code to make it np.matrix() rather than python array
02 March 2018, 15:39 IST; Published the code
'''

import sys
import math
import numpy as np
import matplotlib.pyplot as plt

# Specifying the input stress
# Note:
# While plotting, we set the x- and y-limits to -150 to +150,
# and enforce the aspect ratio of 1. That is to say, we do not
# allow MatPlotLib to automatically scale the axes, because we
# want to appreciate the changes in the shapes as well sizes in
# the plot.
#
# Therefore, all the input stress-components should be kept
# to within the -100 to +100 (both inclusive) range.
#
# Specify the stress state in this order: xx, xy; yx, yy
# The commas and the semicolon are necessary.
# If you run the program from a command-line, you can also
# specify the input stress string in quotes as the first
# command-line argument, and no. of orientations, as the
# second. e.g.:
# python MyScript.py "100, 50; 50, 0" 12
##################################################

gsStress = "-100, 45; 90, 25"
gnOrientations = 18


##################################################

def plotArrow(vTraction, dThetaDegs, clr, axes):
    dx = round(vTraction[0], 6)
    dy = round(vTraction[1], 6)
    if not (math.fabs(dx) < 10e-6 and math.fabs(dy) < 10e-6):
        axes.arrow(0, 0, dx, dy, head_width=3, head_length=9.0, length_includes_head=True, fc=clr, ec=clr)
    axes.annotate(xy=(dx, dy), s='%d' % dThetaDegs, color=clr)


##################################################

def computeTraction(mStressT, dThetaRads):
    vUnitNormal = [round(math.cos(dThetaRads), 6), round(math.sin(dThetaRads), 6)]
    mUnitNormal = np.reshape(vUnitNormal, (2,1))
    mTraction = mStressT.dot(mUnitNormal)
    vTraction = np.squeeze(np.asarray(mTraction))
    return vTraction


##################################################

def main():
    axes = plt.axes()
    axes.set_label("label")
    axes.set_xlim((-150, 150))
    axes.set_ylim((-150, 150))
    axes.set_aspect('equal', 'datalim')
    plt.title(
        "A visualization of *something* about\n" \
        "the 2D stress-state [xx, xy; yx, yy] = [%s]" \
        % gsStress)

    mStress = np.matrix(gsStress)
    mStressT = np.transpose(mStress)
    vTraction = computeTraction(mStressT, 0)
    plotArrow(vTraction, 0, 'red', axes)
    dIncrement = 360.0 / float(gnOrientations)
    for i in range(1, gnOrientations):
        dThetaDegrees = float(i) * dIncrement
        dThetaRads = dThetaDegrees * math.pi / 180.0
        vTraction = computeTraction(mStressT, dThetaRads)
        plotArrow(vTraction, dThetaDegrees, 'gray', axes)
        plt.pause(0.05)
    plt.show()


##################################################

if __name__ == "__main__":
    nArgs = len(sys.argv)
    if nArgs > 1:
        gsStress = sys.argv[1]
    if nArgs > 2:
        gnOrientations = int(sys.argv[2])
    main()



OK, have fun, and if you care to, let me know your answers, guess-works, etc…..


Oh, BTW, I have already taken a version of my last post also to iMechanica, which led to a bit of an interaction there too… However, I had to abruptly cut short all the discussions on the topic because I unexpectedly got way too busy in the affiliation- and accreditation-related work. It was only today that I’ve got a bit of a breather, and so could write this script and this post. Anyway, if you are interested in the concept of stress—issues like what it actually means and all that—then do check out my post at iMechanica, too, here [^].


… Happy Holi, take care to use only safe colors—and also take care not to bother those people who do not want to be bothered by you—by your “play”, esp. the complete strangers…

OK, take care and bye for now. ….


A Song I Like:

(Marathi [Am I right?]) “rang he nave nave…”
Music: Aditya Bedekar
Singer: Shasha Tirupati
Lyrics: Yogesh Damle

 

Stress is defined as the quantity equal to … what?

Update on 01 March 2018, 21:27, IST: I had posted a version of this post also at iMechanica, which led to a bit of a very interesting interaction there [^] too. Check it out, if you want… Also see my today’s post concerning the idea of stress, here [^].


In this post, I am going to note a bit from my personal learning history. I am going to note what had happened when a clueless young engineering student that was me, was trying hard to understand the idea of tensors, during my UG years, and then for quite some time even after my UG days. May be for a decade or even more….

There certainly were, and are likely to be even today, many students like [the past] me. So, in the further description, I will use the term “we.” Obviously, the “we” here is the collegial “we,” perhaps even the pedagogical “we,” but certainly neither the pedestrian nor the royal “we.”


What we would like to understand is the idea of tensors; the question of what these beasts are really, really like.

As with developing an understanding of any new concept, we first go over some usage examples involving that idea, some instances of that concept.

Here, there is not much of a problem; our mind easily picks up the stress as a “simple” and familiar example of a tensor. So, we try to understand the idea of tensors via the example of the stress tensor. [Turns out that it becomes far more difficult this way… But read on, anyway!]

Not a bad decision, we think.

After all, even if the tensor algebra (and tensor calculus) was an achievement wrought only in the closing decade(s) of the 19th century, Cauchy was already been up and running with the essential idea of the stress tensor right by 1822—i.e., more than half a century earlier. We come to know of this fact, say via James Rice’s article on the history of solid mechanics. Given this bit of history, we become confident that we are on the right track. After all, if the stress tensor could not only be conceived of, but even a divergence theorem for it could be spelt out, and the theorem even used in applications of engineering importance, all some half a century before any other tensors were even conceived of, then developing a good understanding of the stress tensor ought to provide a sound pathway to understanding tensors in general.

So, we begin with the stress tensor, and try [very hard] to understand it.


We recall what we have already been taught: stress is defined as force per unit area. In symbolic terms, read for the very first time in our XI standard physics texts, the equation reads:

\sigma \equiv \dfrac{F}{A}               … Eq. (1)

Admittedly, we had been made aware, that Eq. (1) holds only for the 1D case.

But given this way of putting things as the starting point, the only direction which we could at all possibly be pursuing, would be nothing but the following:

The 3D representation ought to be just a simple generalization of Eq. (1), i.e., it must look something like this:

\overline{\overline{\sigma}} = \dfrac{\vec{F}}{\vec{A}}                … Eq. (2)

where the two overlines over \sigma represents the idea that it is to be taken as a tensor quantity.

But obviously, there is some trouble with the Eq. (2). This way of putting things can only be wrong, we suspect.

The reason behind our suspicion, well-founded in our knowledge, is this: The operation of a division by a vector is not well-defined, at least, it is not at all noted in the UG vector-algebra texts. [And, our UG maths teachers would happily fail us in examinations if we tried an expression of that sort in our answer-books.]

For that matter, from what we already know, even the idea of “multiplication” of two vectors is not uniquely defined: We have at least two “product”s: the dot product [or the inner product], and the cross product [a case of the outer or the tensor product]. The absence of divisions and unique multiplications is what distinguishes vectors from complex numbers (including phasors, which are often noted as “vectors” in the EE texts).

Now, even if you attempt to “generalize” the idea of divisions, just the way you have “generalized” the idea of multiplications, it still doesn’t help a lot.

[To speak of a tensor object as representing the result of a division is nothing but to make an indirect reference to the very operation [viz. that of taking a tensor product], and the very mathematical structure [viz. the tensor structure] which itself is the object we are trying to understand. … “Circles in the sand, round and round… .” In any case, the student is just as clueless about divisions by vectors, as he is about tensor products.]

But, still being under the spell of what had been taught to us during our XI-XII physics courses, and later on, also in the UG engineering courses— their line and method of developing these concepts—we then make the following valiant attempt. We courageously rearrange the same equation, obtain the following, and try to base our “thinking” in reference to the rearrangement it represents:

\overline{\overline{\sigma}} \vec{A} = \vec{F}                  … Eq (3)

It takes a bit of time and energy, but then, very soon, we come to suspect that this too could be a wrong way of understanding the stress tensor. How can a mere rearrangement lead from an invalid equation to a valid equation? That’s for the starters.

But a more important consideration is this one: Any quantity must be definable via an equation that follows the following format:

the quantiy being defined, and nothing else but that quantity, as appearing on the left hand-side
=
some expression involving some other quantities, as appearing on the right hand-side.

Let’s call this format Eq. (4).

Clearly, Eq. (3) does not follow the format of Eq. (4).

So, despite the rearrangement from Eq. (2) to Eq. (3), the question remains:

How can we define the stress tensor (or for that matter, any tensors of similar kind, say the second-order tensors of strain, conductivity, etc.) such that its defining expression follows the format given in Eq. (4)?


Can you answer the above question?

If yes, I would love to hear from you… If not, I will post the answer by way of an update/reply/another blog post, after some time. …

Happy thinking…


A Song I Like:
(Hindi) “ye bholaa bhaalaa man meraa kahin re…”
Singers: Kishore Kumar, Asha Bhosale
Music: Kishore Kumar
Lyrics: Majrooh Sultanpuri


[I should also be posting this question at iMechanica, though I don’t expect that they would be interested too much in it… Who knows, someone, say some student somewhere, may be interested in knowing more about it, just may be…

Anyway, take care, and bye for now…]

Fluxes, scalars, vectors, tensors…. and, running in circles about them!

0. This post is written for those who know something about Thermal Engineering (i.e., fluid dynamics, heat transfer, and transport phenomena) say up to the UG level at least. [A knowledge of Design Engineering, in particular, the tensors as they appear in solid mechanics, would be helpful to have but not necessary. After all, contrary to what many UGC and AICTE-approved (Full) Professors of Mechanical Engineering teaching ME (Mech – Design Engineering) courses in SPPU and other Indian universities believe, tensors not only appear also in fluid mechanics, but, in fact, the fluids phenomena make it (only so slightly) easier to understand this concept. [But all these cartoons characters, even if they don’t know even this plain and simple a fact, can always be fully relied (by anyone) about raising objections about my Metallurgy background, when it comes to my own approval, at any time! [Indians!!]]]

In this post, I write a bit about the following question:

Why is the flux \vec{J} of a scalar \phi a vector quantity, and not a mere number (which is aka a “scalar,” in certain contexts)? Why is it not a tensor—whatever the hell the term means, physically?

And, what is the best way to define a flux vector anyway?


1.

One easy answer is that if the flux is a vector, then we can establish a flux-gradient relationship. Such relationships happen to appear as statements of physical laws in all the disciplines wherever the idea of a continuum was found useful. So the scope of the applicability of the flux-gradient relationships is very vast.

The reason to define the flux as a vector, then, becomes: because the gradient of a scalar field is a vector field, that’s why.

But this answer only tells us about one of the end-purposes of the concept, viz., how it can be used. And then the answer provided is: for the formulation of a physical law. But this answer tells us nothing by way of the very meaning of the concept of flux itself.


2.

Another easy answer is that if it is a vector quantity, then it simplifies the maths involved. Instead of remembering having to take the right \theta and then multiplying the relevant scalar quantity by the \cos of this \theta, we can more succinctly write:

q = \vec{J} \cdot \vec{S} (Eq. 1)

where q is the quantity of \phi, an intensive scalar property of the fluid flowing across a given finite surface, \vec{S}, and \vec{J} is the flux of \Phi, the extensive quantity corresponding to the intensive quantity \phi.

However, apart from being a mere convenience of notation—a useful shorthand—this answer once again touches only on the end-purpose, viz., the fact that the idea of flux can be used to calculate the amount q of the transported property \Phi.

There also is another problem with this, second, answer.

Notice that in Eq. 1, \vec{J} has not been defined independently of the “dotting” operation.

If you have an equation in which the very quantity to be defined itself has an operator acting on it on one side of an equation, and then, if a suitable anti- or inverse-operator is available, then you can apply the inverse operator on both sides of the equation, and thereby “free-up” the quantity to be defined itself. This way, the quantity to be defined becomes available all by itself, and so, its definition in terms of certain hierarchically preceding other quantities also becomes straight-forward.

OK, the description looks more complex than it is, so let me illustrate it with a concrete example.

Suppose you want to define some vector \vec{T}, but the only basic equation available to you is:

\vec{R} = \int \text{d} x \vec{T}, (Eq. 2)

assuming that \vec{T} is a function of position x.

In Eq. 2, first, the integral operator must operate on \vec{T}(x) so as to produce some other quantity, here, \vec{R}. Thus, Eq. 2 can be taken as a definition for \vec{R}, but not for \vec{T}.

However, fortunately, a suitable inverse operator is available here; the inverse of integration is differentiation. So, what we do is to apply this inverse operator on both sides. On the right hand-side, it acts to let \vec{T} be free of any operator, to give you:

\dfrac{\text{d}\vec{R}}{\text{d}x} = \vec{T} (Eq. 3)

It is the Eq. 3 which can now be used as a definition of \vec{T}.

In principle, you don’t have to go to Eq. 3. In principle, you could perhaps venture to use a bit of notation abuse (the way the good folks in the calculus of variations and integral transforms always did), and say that the Eq. 2 itself is fully acceptable as a definition of \vec{T}. IMO, despite the appeal to “principles”, it still is an abuse of notation. However, I can see that the argument does have at least some point about it.

But the real trouble with using Eq. 1 (reproduced below)

q = \vec{J} \cdot \vec{S} (Eq. 1)

as a definition for \vec{J} is that no suitable inverse operator exists when it comes to the dot operator.


3.

Let’s try another way to attempt defining the flux vector, and see what it leads to. This approach goes via the following equation:

\vec{J} \equiv \dfrac{q}{|\vec{S}|} \hat{n} (Eq. 4)

where \hat{n} is the unit normal to the surface \vec{S}, defined thus:

\hat{n} \equiv \dfrac{\vec{S}}{|\vec{S}|} (Eq. 5)

Then, as the crucial next step, we introduce one more equation for q, one that is independent of \vec{J}. For phenomena involving fluid flows, this extra equation is quite simple to find:

q = \phi \rho \dfrac{\Omega_{\text{traced}}}{\Delta t} (Eq. 6)

where \phi is the mass-density of \Phi (the scalar field whose flux we want to define), \rho is the volume-density of mass itself, and \Omega_{\text{traced}} is the volume that is imaginarily traced by that specific portion of fluid which has imaginarily flowed across the surface \vec{S} in an arbitrary but small interval of time \Delta t. Notice that \Phi is the extensive scalar property being transported via the fluid flow across the given surface, whereas \phi is the corresponding intensive quantity.

Now express \Omega_{\text{traced}} in terms of the imagined maximum normal distance from the plane \vec{S} up to which the forward moving front is found extended after \Delta t. Thus,

\Omega_{\text{traced}} = \xi |\vec{S}| (Eq. 7)

where \xi is the traced distance (measured in a direction normal to \vec{S}). Now, using the geometric property for the area of parallelograms, we have that:

\xi = \delta \cos\theta (Eq. 8)

where \delta is the traced distance in the direction of the flow, and \theta is the angle between the unit normal to the plane \hat{n} and the flow velocity vector \vec{U}. Using vector notation, Eq. 8 can be expressed as:

\xi = \vec{\delta} \cdot \hat{n} (Eq. 9)

Now, by definition of \vec{U}:

\vec{\delta} = \vec{U} \Delta t, (Eq. 10)

Substituting Eq. 10 into Eq. 9, we get:

\xi = \vec{U} \Delta t \cdot \hat{n} (Eq. 11)

Substituting Eq. 11 into Eq. 7, we get:

\Omega_{\text{traced}} = \vec{U} \Delta t \cdot \hat{n} |\vec{S}| (Eq. 12)

Substituting Eq. 12 into Eq. 6, we get:

q = \phi \rho \dfrac{\vec{U} \Delta t \cdot \hat{n} |\vec{S}|}{\Delta t} (Eq. 13)

Cancelling out the \Delta t, Eq. 13 becomes:

q = \phi \rho \vec{U} \cdot \hat{n} |\vec{S}| (Eq. 14)

Having got an expression for q that is independent of \vec{J}, we can now use it in order to define \vec{J}. Thus, substituting Eq. 14 into Eq. 4:

\vec{J} \equiv \dfrac{q}{|\vec{S}|} \hat{n} = \dfrac{\phi \rho \vec{U} \cdot \hat{n} |\vec{S}|}{|\vec{S}|} \hat{n} (Eq. 16)

Cancelling out the two |\vec{S}|s (because it’s a scalar—you can always divide any term by a scalar (or even  by a complex number) but not by a vector), we finally get:

\vec{J} \equiv \phi \rho \vec{U} \cdot \hat{n} \hat{n} (Eq. 17)


4. Comments on Eq. 17

In Eq. 17, there is this curious sequence: \hat{n} \hat{n}.

It’s a sequence of two vectors, but the vectors apparently are not connected by any of the operators that are taught in the Engineering Maths courses on vector algebra and calculus—there is neither the dot (\cdot) operator nor the cross \times operator appearing in between the two \hat{n}s.

But, for the time being, let’s not get too much perturbed by the weird-looking sequence. For the time being, you can mentally insert parentheses like these:

\vec{J} \equiv \left[ \left( \phi \rho \vec{U} \right) \cdot \left( \hat{n} \right) \right] \hat{n} (Eq. 18)

and see that each of the two terms within the parentheses is a vector, and that these two vectors are connected by a dot operator so that the terms within the square brackets all evaluate to a scalar. According to Eq. 18, the scalar magnitude of the flux vector is:

|\vec{J}| = \left( \phi \rho \vec{U}\right) \cdot \left( \hat{n} \right) (Eq. 19)

and its direction is given by: \hat{n} (the second one, i.e., the one which appears in Eq. 18 but not in Eq. 19).


5.

We explained away our difficulty about Eq. 17 by inserting parentheses at suitable places. But this procedure of inserting mere parentheses looks, by itself, conceptually very attractive, doesn’t it?

If by not changing any of the quantities or the order in which they appear, and if by just inserting parentheses, an equation somehow begins to make perfect sense (i.e., if it seems to acquire a good physical meaning), then we have to wonder:

Since it is possible to insert parentheses in Eq. 17 in some other way, in some other places—to group the quantities in some other way—what physical meaning would such an alternative grouping have?

That’s a delectable possibility, potentially opening new vistas of physico-mathematical reasonings for us. So, let’s pursue it a bit.

What if the parentheses were to be inserted the following way?:

\vec{J} \equiv \left( \hat{n} \hat{n} \right) \cdot \left( \phi \rho \vec{U} \right) (Eq. 20)

On the right hand-side, the terms in the second set of parentheses evaluate to a vector, as usual. However, the terms in the first set of parentheses are special.

The fact of the matter is, there is an implicit operator connecting the two vectors, and if it is made explicit, Eq. 20 would rather be written as:

\vec{J} \equiv \left( \hat{n} \otimes \hat{n} \right) \cdot \left( \phi \rho \vec{U} \right) (Eq. 21)

The \otimes operator, as it so happens, is a binary operator that operates on two vectors (which in general need not necessarily be one and the same vector as is the case here, and whose order with respect to the operator does matter). It produces a new mathematical object called the tensor.

The general form of Eq. 21 is like the following:

\vec{V} = \vec{\vec{T}} \cdot \vec{U} (Eq. 22)

where we have put two arrows on the top of the tensor, to bring out the idea that it has something to do with two vectors (in a certain order). Eq. 22 may be read as the following: Begin with an input vector \vec{U}. When it is multiplied by the tensor \vec{\vec{T}}, we get another vector, the output vector: \vec{V}. The tensor quantity \vec{\vec{T}} is thus a mapping between an arbitrary input vector and its uniquely corresponding output vector. It also may be thought of as a unary operator which accepts a vector on its right hand-side as an input, and transforms it into the corresponding output vector.


6. “Where am I?…”

Now is the time to take a pause and ponder about a few things. Let me begin doing that, by raising a few questions for you:

Q. 6.1:

What kind of a bargain have we ended up with? We wanted to show how the flux of a scalar field \Phi must be a vector. However, in the process, we seem to have adopted an approach which says that the only way the flux—a vector—can at all be defined is in reference to a tensor—a more advanced concept.

Instead of simplifying things, we seem to have ended up complicating the matters. … Have we? really? …Can we keep the physical essentials of the approach all the same and yet, in our definition of the flux vector, don’t have to make a reference to the tensor concept? exactly how?

(Hint: Look at the above development very carefully once again!)

Q. 6.2:

In Eq. 20, we put the parentheses in this way:

\vec{J} \equiv \left( \hat{n} \hat{n} \right) \cdot \left( \phi \rho \vec{U} \right) (Eq. 20, reproduced)

What would happen if we were to group the same quantities, but alter the order of the operands for the dot operator?  After all, the dot product is commutative, right? So, we could have easily written Eq. 20 rather as:

\vec{J} \equiv \left( \phi \rho \vec{U} \right) \cdot \left( \hat{n} \hat{n} \right) (Eq. 21)

What could be the reason why in writing Eq. 20, we might have made the choice we did?

Q. 6.3:

We wanted to define the flux vector for all fluid-mechanical flow phenomena. But in Eq. 21, reproduced below, what we ended up having was the following:

\vec{J} \equiv \left( \phi \rho \vec{U} \right) \cdot \left( \hat{n} \otimes \hat{n} \right) (Eq. 21, reproduced)

Now, from our knowledge of fluid dynamics, we know that Eq. 21 seemingly stands only for one kind of a flux, namely, the convective flux. But what about the diffusive flux? (To know the difference between the two, consult any good book/course-notes on CFD using FVM, e.g. Jayathi Murthy’s notes at Purdue, or Versteeg and Malasekara’s text.)

Q. 6.4:

Try to pursue this line of thought a bit:

Start with Eq. 1 again:

q = \vec{J} \cdot \vec{S} (Eq. 1, reproduced)

Express \vec{S} as a product of its magnitude and direction:

q = \vec{J} \cdot |\vec{S}| \hat{n} (Eq. 23)

Divide both sides of Eq. 23 by |\vec{S}|:

\dfrac{q}{|\vec{S}|} = \vec{J} \cdot \hat{n} (Eq. 24)

“Multiply” both sides of Eq. 24 by \hat{n}:

\dfrac{q} {|\vec{S}|} \hat{n} = \vec{J} \cdot \hat{n} \hat{n} (Eq. 25)

We seem to have ended up with a tensor once again! (and more rapidly than in the development in section 4. above).

Now, looking at what kind of a change the left hand-side of Eq. 24 undergoes when we “multiply” it by a vector (which is: \hat{n}), can you guess something about what the “multiplication” on the right hand-side by \hat{n} might mean? Here is a hint:

To multiply a scalar by a vector is meaningless, really speaking. First, you need to have a vector space, and then, you are allowed to take any arbitrary vector from that space, and scale it up (without changing its direction) by multiplying it with a number that acts as a scalar. The result at least looks the same as “multiplying” a scalar by a vector.

What then might be happening on the right hand side?

Q.6.5:

Recall your knowledge (i) that vectors can be expressed as single-column or single-row matrices, and (ii) how matrices can be algebraically manipulated, esp. the rules for their multiplications.

Try to put the above developments using an explicit matrix notation.

In particular, pay particular attention to the matrix-algebraic notation for the dot product between a row- or column-vector and a square matrix, and the effect it has on your answer to question Q.6.2. above. [Hint: Try to use the transpose operator if you reach what looks like a dead-end.]

Q.6.6.

Suppose I introduce the following definitions: All single-column matrices are “primary” vectors (whatever the hell it may mean), and all single-row matrices are “dual” vectors (once again, whatever the hell it may mean).

Given these definitions, you can see that any primary vector can be turned into its corresponding dual vector simply by applying the transpose operator to it. Taking the logic to full generality, the entirety of a given primary vector-space can then be transformed into a certain corresponding vector space, called the dual space.

Now, using these definitions, and in reference to the definition of the flux vector via a tensor (Eq. 21), but with the equation now re-cast into the language of matrices, try to identify the physical meaning the concept of “dual” space. [If you fail to, I will sure provide a hint.]

As a part of this exercise, you will also be able to figure out which of the two \hat{n}s forms the “primary” vector space and which \hat{n} forms the dual space, if the tensor product \hat{n}\otimes\hat{n} itself appears (i) before the dot operator or (ii) after the dot operator, in the definition of the flux vector. Knowing the physical meaning for the concept of the dual space of a given vector space, you can then see what the physical meaning of the tensor product of the unit normal vectors (\hat{n}s) is, here.

Over to you. [And also to the UGC/AICTE-Approved Full Professors of Mechanical Engineering in SPPU and in other similar Indian universities. [Indians!!]]

A Song I Like:

[TBD, after I make sure all LaTeX entries have come out right, which may very well be tomorrow or the day after…]

Machine “Learning”—An Entertainment [Industry] Edition

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

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


Context for my iMechanica comment:

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

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

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

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

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

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

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

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


[An edited version of my comment begins]

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

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

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

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

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

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

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

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

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

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

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


 

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

You might be saying that….

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


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

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

A sea beach in the monsoons. Watercolor.

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


A Song I Like:

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

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


Endgame:

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

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

 

See, how hard I am trying to become a (Full) Professor of Mechanical Engineering in SPPU?

Currently, I am not only cashless but also jobless. That’s why, I try harder.

I am trying very hard to be a (Full) Professor of Mechanical Engineering, especially at the Savitribai Phule Pune University (or SPPU for short).

That’s right.

And that’s why, I have decided to adopt an official position whereby I abandon all my other research and study interests, especially those related to the mechanics of the quanta. Instead, I have officially decided to remain interested only in the official problems from the Mechanical Engineering discipline proper—not only for my studies, but also for my research interests.

… If only I were to have my first degree in Mechanical Engineering, instead of in Metallurgy! (It was some 37.5–33.5 years ago, with my decision to choose Metallurgy being from some 36.5 years ago.) … If only I were to choose Mechanical right back then, this problem wouldn’t have arisen today. …

Tch! …

…But, well, thinking of my first degree, its circumstances—where I got it from (COEP, the engineering college with the highest cut-off merit in the entire Maharashtra state), in what class (First Class with Distinction, the highest class possible), and, most crucially, for spending all my time at what place (The Boat Club)… You know, looking back some 3.5 decades later of all those circumstances—the circumstances of how I chose Metallurgy, back then, as I was sitting at the Boat Club… Hmmm… Boat Club. … Boat Club! Boat Club!!

It gives me some ideas.

So, to better support my current endeavors of becoming an Officially Approved Full Professor of Mechanical Engineering in SPPU, may be, I should solve some Mechanical Engineering problems related to boats. Preferably, those involving not just fluid mechanics, but also mechanisms and machine design—and vibrations! [Oh yes. I must not forget them! Vibrations are, Officially, a Mechanical Engineering topic. In fact even Acoustics. …]

Thinking along such lines, I then thought of one problem, and sort of solved it too. Though I am not going to share my answer with you, I certainly want to share the problem itself with you. (Don’t ask me for answers until I get the job as an Officially Approved Full Professor in Mechanical Engineering at SPPU.)

OK, so here we go.


The Problem Description:

Consider a boat floating on a stand-still lake. The boat has a very simple shape; it is in the shape of a rectangular parallelpiped (i.e., like a shoe-box, though not quite exactly like a punt).

In the plan (i.e. the top view), the boat looks like this:
mechanicalengineeringboat

 

 

 

 

 

As shown in the figure, at the centers of the front- and back-sides of the boat, there are two circular cylindrical cavities of identical dimensions, both being fitted with reciprocating pistons. These pistons are being driven by two completely independent mechanisms. The power-trains and the prime-movers are not shown in the diagram; in this analysis, both may be taken to be mass-less and perfectly rigid. However, the boat is assumed to have some mass.

We will try to solve for the simplest possible case: perfectly rigid boat walls (with some mass), perfectly rigid but mass-less pistons, complete absence of friction between the pistons and the cylinder walls, etc.

Assume also that both the boat and the lake water are initially stand-still, and that there are no other influences affecting the motions (such as winds or water currents).

Now, let’s put the pistons in oscillatory motions. In general, the frequencies of their oscillations are not equal. Let the frequency for the left- and right-side pistons be f_L and f_R Hz, respectively.

Problem 1:

Build a suitable Mechanical Engineering model, and predict how the boat would move, in each of the following three scenarios:

  • f_L = f_R
  • f_L > f_R
  • f_L < f_R

In each case, determine (i) whether the boat as a whole (i.e. its center of mass or CM) would at all undergo any motion at all or not, (ii) if yes, whether the motion of the CM would have an element of oscillations to it or not, and finally, (iii) whether the boat (i.e. its CM) would undergo a net displacement over a large number of pistons oscillations or not (i.e., the question asks whether the so-called “time-averaged” net displacement occurs in any one direction or not), and if yes, in which direction.

You may make other minor assumptions. For instance, in each of the above 3 cases, you may assume that at time t = 0, both the pistons are at their innermost positions, with each piston beginning its motion by pushing outwards. Also check out the effect of assuming, some other, suitable, values for the initial phases.

Though not at all necessary, if it will help you, you may perhaps consider the case where the higher frequency is an integer multiple of the lower frequency, e.g., in the second of the three cases, assume f_L = n f_R, where n \in \mathcal{N}. However, note that eventually, you are expected to solve the problem in the general case, the one in which the ratio of the frequencies may be any real number. The cases of practical interest may be where the ratio ranges from 0.0 to a real number up to, say, 2.67 or 3.14 (or, may be, 5.25).

Notice that nowhere thus far have we said that the oscillatory motion of the pistons would be SHM (i.e. simple harmonic). You may begin with an SHM, but as a further problem below illustrates, the piston motion may neither be simple-harmonic, nor even symmetrical in the to- and fro-directions.

On the fluid mechanics side: In your analysis, assume that the length of the boat is much, much greater than the stroke-lengths of the pistons. Essentially, we want to ensure that the water waves produced at one end do not significantly affect the local dynamics at the other end.

You may assume a highly simplified model for the fluid—the problem is not supposed to have a crucial bearing on what kind of a fluid you assume. I mean to say, we are not looking for so detailed a model that you would have to perform a CFD analysis. (That task, we will leave to the Naval Architecture engineers.) However, do make sure to note how your model behaves for an inviscid flow vs. for a viscous flow.

So, in short, the problem is to determine the nature of the motion of the boat, if there is any—i.e., to determine if its CM undergoes a net displacement in the time-averaged sense or not, and if yes, in which direction it occurs.

Problem 2:

Assume a relatively smaller stroke-length for one of the pistons, and repeat the problem.

Problem 3:

Assume that one of the frequencies is zero, which is as good as saying that the boat is fitted with only one cylinder-and-piston. Repeat the analysis.

Problem 4:

Continue to assume that one of the frequencies is zero. Now, also assume that the outward stroke of the moving piston happens faster than its inward stroke. Determine the nature of the motion, if any, for the CM of the boat.

Problem 5 (Optional):

Assuming that the prime mover outputs a uniform circular (or rotary) motion, design a suitable mechanism which will help implement the idea of having non-SHM motions—e.g., different stroke-times in the outward and inward directions. Conduct an informal (or a more formal, calculus-based) displacement-, velocity- and acceleration-analysis, if you wish.

Give it a thought whether this entire idea of transforming a circular motion to a nonuniform reciprocating motion can be done away with, thereby saving on energy—in real life, there is friction—using certain ideas from electrical engineering and electronics.

Ooops!

No, no, no! No!! Throw out that horrendous idea! I mean the very last one!!

We want to remain concerned only with the Mechanical Engineering Problems proper. That is the Official position I have adopted, remember?


That’s right. What I described above was, really, really, really only a Mechanical Engineering Problem.

It really, really, really has nothing to do with anything else such as electrical engineering or quantum physics.

[And if even Prof. Thanu Padmanabhan (IUCAA) does not know quantum physics (he told me so once, right in person), why should I be concerned with it, anyway?]

Anyway, so, Officially speaking, I made up this problem only because I want to become an Officially Approved Full Professor of Mechanical Engineering at SPPU.


If you are interested in some other Mechanical Engineering problems, especially on the fluids-thermal side, check out my recent posts on the Eco-Cooler, and see if you can take further the analysis given in them.

I myself had made a much more advanced engineering analysis right at that time, but I am not going to give it—or its results—until some time after I land and join the kind of job I am looking for—a Full Professor’s. (And I hope that you do have the sense to see that this is not a “prestige issue” on my part.)

The post having a preliminary (quantitative) fluids-thermal analysis is here [^], though the qualitative analysis of the problem begins with an earlier post, here [^].


[Guess the problem, as given, is enough for the time being. I may even come back and add one or two variations on the problem! But no guarantees.]

Update right on 2016.12.02: OK, here are a couple of minor variations. What happens if, when a piston comes to a rest at the extreme stroke, it continues staying idle for a while, before resuming its towards-the-center motion? What if the piston motion is such that the point of zero displacement does not occur exactly at the middle of its overall stroke-length?

I may post some further variations on the problem, or suggest alternative analogous problems, in future.

Currently, I am not just cashless but also jobless. That’s why, I try harder.


More, may be later. As to the Song I Like section, I don’t have anything playing at the back of my mind right away, so let me see if something strikes me by the time I come back tomorrow to give a final editing touch to this post. In that case, I will add this section; else, I will not!


[After the update right on 2016.12.02: I am done with this post now, and if there are any errors, I will let them stay. If you find the post confusing somewhere, please do drop me a line, though. Best, and take care.]

[E&OE]

 

Analyzing the Eco-Cooler, part 1

OK, that was ample time for you to have hit your fluid mech/heat transfer/thermo books, and to have it verified whether the 5 deg. C drop was believable or not… You must have made your notes, too, no?…  So, in this post, let’s cross-check our notes.


On my part, I will first present the simplest (and the most approximate) model, and also give you a simple Python script to play with, to see what kind of predictions this model makes. Then, we will go on considering more and more complicated but still approximate “engineering” models that hopefully become more and more realistic. We will cross-check their predictions too. We may eventually find that a full-fledged CFD analysis is called for. However, I will save that—I mean doing a full-fledged CFD analysis—for another day. (I in fact plan to write a paper on this problem, using CFD. (…Some day…).)

The reason we follow this method—from the simplest and crudest models to the more complicated and better ones—is because for problems related to fluid mechanics, it is this method which works best!

I mean to say, the full-fledged Navier-Stokes equations are too complicated to solve for, even when they are applied to the simplest of practically encountered geometries—e.g., the flow of air through the Eco-Cooler bottle. Since the NS equations cannot be solved exactly, the traditional engineering models (which are based on analytical or semi-analytical solutions) fall short, and then, a CFD analysis is called for.

But the fact of the matter also is, even CFD itself is only an approximate technique. CFD solutions sometimes even happen to carry more numerical artifacts than real physics. We therefore cannot approach CFD blindly. We ourselves have to have some good idea in the first place of what the desired solution should look like. We should have this idea right before we even think of setting up a CFD model/simulation. The traditional engineering models provide precisely these insights.

Yes, that’s right.

The traditional engineering models actually are more approximate than CFD. Yet, since they are also simpler than CFD, and since they explicitly carry conceptual connections with the major fluid mechanical phenomena in a more direct manner, they also make it easier to gain insights about both the nature of the problem, and the nature of the expected solution. No similar insights can be had by directly using CFD, for several reasons. The CFD theory itself is too complicated, and the CFD practice involves too many different analysis options. In the jungle of all those parameters, iterations, and convergence requirements, CFD happens to loose the directness of the conceptual connections with the basic analytical theory—with the fluid dynamical phenomena.

That’s why we first deal with the simplest engineering models, even though they are known to be approximate—and therefore, they are easily capable of giving us wrong results. But this way, we can build insights. Building insights is an art, and the process progresses slowly.

As I said, we will follow an iterative scheme of model building. In each phase or iteration of the model building activity, we will actually be applying the same set of principles: the conservation of mass, momentum, and energy. However, in going from a model-building phase to the next, we will aim to incorporate an increasing level of complexity or sophistication—and accuracy, hopefully.

Actually, in the fluid dynamics theory, all the three conservation equations come coupled to each other. You cannot solve for conservation of only the mass, or the momentum, or the energy, by neglecting any of the other two. However, for this particular problem (of the Eco-Cooler), for various reasons (which you will come to appreciate slowly), it so turns out that we can get away considering the mass, momentum and energy equations in a decoupled manner, and in the order stated: first mass, then momentum, and then energy. (It’s no accident that text-books spell out these three principles in this order. Many fluids-related phenomena with which we are well familiar through our direct experience of the world are such that for solving problems involving these phenomena, this order happens to be the best one to follow.)

So, with that big introduction, let’s now get going calculating—even though we will not shut up even while performing those calculations.


Model-Building Phase I: The Simplest Possible Model:

Geometry:

Consider the plastic-bottles used in the Eco-Cooler; they all lie horizontally. Consider one of these bottles. A tube has been obtained by cutting off the base of the bottle. Let the base-plane be identified by the subscript 1 and the neck-plane by 2. See the figure below:

diagram1

 

 

 

 

Air flows from the base-plane (1) to the neck-plane (2).

Conservation of mass:

The simplest possible expression for mass conservation, applied to the bottle geometry, would be the continuity equation, given below:
A_1 U_1 = A_2 U_2
where A_1 and A_2 are cross-sectional areas of the bottle, and U_1 and U_2 are wind velocities, at the base and the neck, respectively. Rearranging for U_2, we get:
U_2 = \dfrac{A_1}{A_2} U_1             …(1)

We can use this simple an equation for mass conservation only if the flow is incompressible. To determine if our flow is incompressible or not, we have to calculate the Mach number for the flow. To do that, we have to first know the expected wind velocities.

Referring to the Wiki article on the Beaufort scale [^], we may make an assumption that the inlet speed can go up to about 60 kmph. Actually, the wind-speeds covered by the Beaufort scale go much higher (in excess of 118 kmph). However, practically speaking, the only times such high wind-speeds (gales etc.) occur in India is when rains also accompany them. The rains bring down the ambient temperature anyway, thereby obviating the need for any form of a cooler. Thus, we have to consider only the lower range of speeds.

Assuming the speed of sound in air to be about 340 m/s, we find that the Mach number (for the range of the winds we consider) goes up to about 0.65. Now, for \text{Ma} < 0.33, the flow is sub-sonic, and can be regarded as incompressible. For 0.33 < \text{Ma} < 1.0, the flow is trans-sonic, meaning, the changes in pressures do not adjust “instantaneously” everywhere in the flow, and so, it is increasingly not possible to even idealize the flow as incompressible.

Therefore, in the interest of simplicity, for our first solution cut, we choose to consider only the wind-speeds up to 100 m/s, i.e. 28 kmph, so that the incompressibility assumption can be justified. Making this assumption about the highest possible wind-speed, we are then free to use the simplest form of mass conservation equation given above as Eq. (1).

For a typical one liter bottle, the base diameter is 7.5 cm, and the neck diameter is 2 cm (both referring to IDs i.e. inner diameters). (I measured them myself!) So, the area ratio \frac{A_1}{A_2} turns out to be about 14.

Thus, the wind accelerates inside the bottle; the outlet velocity is about 14 times the inlet velocity!

This looks like a remarkable bit of acceleration to happen over just some 20 cm of length. (The bottle is cut somewhere in the middle.) More on it, later.

Conservation of momentum:

The simplest possible equation to use for momentum conservation is the steady-state Bernoulli’s equation:
\dfrac{P_1}{\rho} + \dfrac{U_1^2}{2} = \dfrac{P_2}{\rho} + \dfrac{U_2^2}{2}        …(2)
where we have ignored the potential head term (gz) because the tube is horizontal as well as symmetrical about its central horizontal axis (and because the air is so thin that its weight can be easily neglected here).

Carefully note the assumptions behind Eq (2). It holds only for a steady-state and laminar flow, and only after neglecting viscosity.

Since we are in a hurry, we will assume them all, and proceed!

Rearranging Eq (2) for P_2, we obtain:
P_2 = P_1 + \dfrac{\rho}{2} \left( U_1^2 - U_2^2 \right)

Conservation of energy:

We basically need the equation of energy conservation only in order to calculate the temperature at the neck (T_2), from a knowledge of: (i) the temperature at the base, T_1, and (ii) the pressures P_1 and P_2.

In the last line, I said “from.” This usage implies that there already is an assumption I made, viz., that the energy equation can be decoupled from the momentum equation. How reasonable is this assumption? It seems pretty OK. Think: can air flowing through a 7.5 cm or a 2.0 cm diameter tube at under 100 m/s get heated up to a significant fraction of 5 deg. C, over a length of just a foot or less? Not likely. Can heating up the neck region cause the air flow to come a halt, say because it helps build up a sufficient amount of pressure? Not even remotely likely. So, we may get away by decoupling the two.

The simplest equation to compute T_2 from the other three quantities would be: the ideal gas law, given as:
\dfrac{P_1 V_1}{T_1} = \dfrac{P_2 V_2}{T_2}.

We have already found that the flow can be considered incompressible (at least up to 28 kmph of wind-speeds). Hence, the volume of each fluid part remains constant, i.e., V_1 = V_2. (Note, in this equation, we have to consider the volume of a fluid element or a part, not the volume for a unit axial length at a given cross-section of the bottle.) For constant volume, the ideal gas law reduces to:
\dfrac{P_1}{T_1} = \dfrac{P_2}{T_2},
from which we can conclude:
T_2 = P_2 \dfrac{T_1}{P_1}.

But we have to know whether the assumption of the ideal gas itself can be used in our problem—for the real air—or not. For doing that, we have to know the critical pressure and temperature of air. Cengel (“Thermodynamics: An Engineering Approach,” 8th SI units edition) lists them (Appendix A1) as 132.5 K, and 3.77 MPa. Using these values, the reduced temperature and the reduced pressure of air turn out to be T_{1_R} = (30 + 273.15)/132.5 \approx 2.29, and P_{1_R} = (101.32\times10^3)/(3.77\times 10^6) \approx 0.027. Further, the expected drops in the pressure and temperature would be just small fractions of the inlet values. Hence, the reduced quantities for the outlet also would not differ significantly from those for the inlet. Referring to the chart and the remarks on p. 139 in Cengel, it seems like we can get away using the ideal gas law.

Note, we are using the ideal gas law not as an approximation to the energy equation, but in place of it, simply because looking at the variables, we noticed that T_2 had to be determined from the other three variables, and this set of variables reminded us of the ideal gas law! Then, referring to the reduced pressure and temperature, the ideal gas approximation seemed to be OK. In short, we have not directly considered the energy conservation principle at all. We may subsequently have an occasion to revisit this issue.

Assumed data:

Now, let us make assumptions about the data to be used for our calculations.

Suppose that the ambient temperature is 30 deg C, and the Eco-Cooler is kept at the mean sea level (MSL), say by the sea-side (rather than somewhere on a slope going down into the Death Valley [^]). Now, seated at a sea-side, the evaporative cooler isn’t going to be feasible because of humidity, and that’s the reason why we are at all considering using the Eco-Cooler. Alright. So to wrap up this point, we have to use data values at the MSL.

Suppose that we can use the ambient MSL atmospheric pressure for the inlet of the bottle; it would then mean that P_1 = 101330 Pa. (Note, this is an assumption; like with many other assumptions, we may have occasion to revisit it later on.) The air density at MSL and at 30 deg. C may be taken to be \rho = 1.169 kg/m^3. (Minor changes to this value turn out to have minimal impact on the predictions, so it’s OK to use, even if we might have made a mistake in looking it up hurriedly.)

For wind-speeds, let’s assume that the speed at the inlet (i.e., at the base of the bottle, which is exposed to the outside) is the same as the ambient wind-speed. (Again, this is an assumption; we may have the occasion to revisit it later on.)

Since the wind-speeds vary, and since the pressure drop (and hence the temperature drop) obviously depends on the inlet wind-speed, we will have to repeat our calculations for each wind-speed, again and again.

Referring again to the Wiki article for the Beaufort scale [^], to have representative wind-speed values, we choose to take the averages of the lower and upper wind speeds which together define the range for each wind-grade on the Beaufort scale. Thus, our U_1 could be one of: 0.5, 3.0, 8.5, 15.5, 24.0, 33.5, 44.0, all in kmph.

We are now ready to do our calculations. To recap: First, we calculate U_2 from U_1 using the continuity (mass conservation) equation and the known area ratio (which is about 14). Then we substitute the data in the re-arranged Bernoulli’s equation (which brings in its own assumptions) and obtain P_2, the pressure at the outlet (i.e. the neck of the bottle). From the ideal gas law (being used in place of the energy equation proper), we then calculate T_2.

Python script:

We use a Python script only because the calculations for T_2 have to be repeated again and again for different wind-speeds. Anyway, here is the Python script:

'''
This Python script calculates the expected
outlet temperature for a bottle in the Eco-Cooler.
See the relevant blog posts by Ajit R. Jadhav.
All units are in SI.
'''

d1 = 7.5 # ID at the inlet (i.e. at the base), in cm
d2 = 2.0 # ID at the outlet (i.e. at the neck), in cm
AR = (d1*d1)/(d2*d2) # Area ratio for the bottle

T1 = 30.0 # Ambient temp., in deg. C
T1 = T1 + 273.15 # Conversion from deg. C to K
rho = 1.169 # Density of air, in kg/m^3
P1 = 101330 # Ambient pressure, in Pa

# The Beaufort Scale wind speeds in kmph, and their text descriptions
bsa = [0.5, 3.0, 8.5, 15.5, 24.0, 33.5, 44.0]
bsta = ["Calm","Light air", "Light breeze", "Gentle breeze", "Moderate breeze", "Fresh breeze", "Strong breeze"]

# Calculate the expected temperatures for various wind-speeds
for i in range(7):
    s1 = bsa[i] # wind-speed, in kmph
    sText = bsta[i] # wind-speed description

    U1 = s1 / 3.6 # conversion from kmph to m/s
    U2 = U1*AR

    # Calculate P2 using Bernoulli's equation
    P2 = P1 + rho*(U1*U1 - U2*U2)/2.0

    # Calculate T2 using the ideal gas law
    T2 = T1*P2/P1
    TC = T2 - 273.15 # conversion from K to deg. C
    print( "%20s %6.1f %6.2lf %10.0f %6.1f" % (sText, s1, U1, P2, TC) )
    

The program written using Python is so simple, that you can very easily modify it, say to report any additional calculations that were made along the way.

Output data:

Here is the output data I get. The columns are: wind description in words, wind speed in kmph, wind speed in m/s, outlet pressure, and outlet temperature:

    Wind Description        U_1        P2, Pa   T2, deg. C                     
                        kmph  m/s      
                Calm    0.5   0.14     101328   30.0
           Light air    3.0   0.83     101250   29.8
        Light breeze    8.5   2.36     100689   28.1
       Gentle breeze   15.5   4.31      99198   23.6
     Moderate breeze   24.0   6.67      96219   14.7
        Fresh breeze   33.5   9.31      91372    0.2
       Strong breeze   44.0  12.22      84151  -21.4
       

Interpretation of results:

Our model predicts that when the breeze is strong (but less strong than when the tube is held near the window of a car that is traveling on an expressway), we should get ice formation at the neck of the bottle—in fact, it should be a super-cooled ice!

From your knowledge of what happens on the Indian sea-side, do you expect a mere half-foot tube of variable diameter, to begin to have ice-formation at its neck?

Obviously, the model we dreamt up has gone wrong somewhere. …

… But precisely where? … We have made so many assumptions…. Which of these assumptions are likely to have impacted our analysis the most? In what all places should we bring in the corrections to our model?

I have already given a lot of explicit notes—not just hints—while writing down the analysis above. So, go through the entire post once again, now pausing especially at the assumptions, and think how we may go on to improve our model.

I will return to the business of improving our model, in my next post.

And as always, sure drop me a line if you think I am going wrong somewhere.

… For instance, also give it a thought as to whether my analysis scheme, based on fluid mechanics, itself is wrong or what. … Here, you may want to refer to the comments on the blog post I had linked to last time [^], esp. the comments made there by Arnaut Jaspers and others. (Jaspers’ and others’ comments appear somewhere in the middle of all the comments, so you have to ask the Web page to load more comments some 3–4 times; the exact URL where the comments in question begin is this: [^]).

Alright, enjoy!


Ummm… Since I have given you Python scripts to play with, guess the usual section on a song I like has become redundant. So, let me mention the “other” song (re. my last post) when I finish this series of posts—which will take one, or at the most two more posts).


[I may come back and cross-check the latex entries in this post, grammar, etc., later on today itself, when I may perhaps edit this post just a bit, but not much. Done on 2016.10.02 itself.]

[E&OE]