How time flies…

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

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


Don’t raise difficult questions right away!

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

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

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

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

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

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

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

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


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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In short, OpenFOAM is out.

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

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

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

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

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

I was delighted, excited, even thrilled.

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

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

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

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

How time flies…


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

Bye for now, and take care…


A Song I Like:

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

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

 

Advertisements

I am keeping my New Year’s…

I am keeping my NYR [^], made last year.

How about you?


No, really. I AM keeping my NYR. Here’s how.


December is meant for making resolutions. (It doesn’t matter whether it’s the 1st or the 31st; the month is [the?] December; that’s what matters.)

Done.

January is meant for making a time-table. … But it must be something on which you can execute. I have been actively engaged doing that. … You could see that, couldn’t you? … And, what’s more, you could’ve bet about it at any time in the past, too, couldn’t you?

Since execution can only follow, and not precede, planning, it must be February before execution proper itself can begin. As far as I am concerned, I will make sure of that. [And you know me. You know that I always deliver on all my promises, don’t you?]

March is known for madness. To be avoided, of course.

April is known for foolishness. To be avoided, as far as possible, but, hey, as “friends” of this blog, you know, it’s nothing to be afraid of!

May, in this part of the world, is far too hot for any one to handle it right, OK? The work-efficiency naturally drops down. This fact must be factored into any and every good piece of planning, I say! (Recall the British Governors and Other officers of the Bombay Presidency shifting their offices to Matheran/Mahabaleshwar during summer? [Anyone ever cared to measure the efficiency of this measure on their part? I mean, on work?])

Now, yes, June does bring in the [very welcome] monsoons, finally! But then, monsoon also is universally known to be the most romantic of all seasons. [It leaves a certain something of a feeling which ordinarily would require you to down a Sundowner or so. [I am trying to be honest, here!]… And then, even Kalidas would seem to agree. Remember (Sanskrit) “aashaaDhasya pratham…”? Naturally, the month is not very conducive to work, is it?]


OK.


This is [just] January, and my time-table is all done up and ready. Or, at least, it’s [at least] half-way through. …

I will really, really begin work in the second half of the year.

Bye until then.


A Song I Don’t Ever Recall Liking Back Then [When Things Mattered Far More Routinely in Far More Respects than They Do Today]

[Not too sure I like it today either. But there were certain happy isolated instances related to my more recent career which are associated with it. I had registered, but hadn’t known this fact, until recently.

But then, recently, I happened suddenly to “re-hear” the phrase (Hindi) “yeh kaunsaa…”, complete with the piece of the “sax” which follows it…

Then, the world had become [in a [comparatively] recent past] a slightly better place to live in.

So, I’d decided, not quite fully certain but still being inclined to this possibility, that I might actually like this song. … But I still don’t fully, you know… But I still do fully want to run it, you know…

Anyway, just listen to it…]

(Hindi) “chocolate, lime juice, ice-cream…” [No, it really is a Hindi song. Just listen to it further…]
Singer: Lata Mangeshkar [A peculiarity of this song is that precisely when [an aged] Lata sounds [a bit] heavy [of course due to the age not to mention the pressures of the day-to-day work and every one’s normal inability to hit the sweet spot every time!], the directors of the movie and the music together focus your attention on a rather cheerfully smiling and dancing Madhuri. [No, never been one of my favorite actresses, but then, that’s an entirely different story altogether.]]
Music: Ramlaxman
Lyrics: Dev Kohli [?]

[PS: And, coming to the video of this song, did you notice that the hero drives a Maruti Gypsy?

I mean, ask any NRI in USA, and they he will tell you that it was because this was an early 90’s movie; the fruits of the [half-/quarter-/oct-something-/etc.] economic liberalization had still not been had by the general public; the liberalization they [I mean these NRIs] had brought about.

If these [I mean the economic freedoms] were to be brought about , they could easily point out, with good amount of references to Hindi movies of the recent years, that the presence on Indian roads of the [government-subsidized-diesel-driven] SUVs could easily have been seen in the same movie!!!

Hmmm…  Point[s] taken.]


How about your NYR?


[A bit of an editing is still due, I am sure… TBD, when I get the time to do so…]

“Blog” less; write journal papers!

“‘Blog’ less; write journal papers.”

That’s my NYR for 2018.

Allow me to explain.


My research is not experimental, neither is it connected with, say, design of a new machine or development of a new manufacturing process. The most concrete aspect my work involves only computational modeling. But that too is not of the kind which engineering researchers typically undertake. I don’t do FEM of this multi-physics problem or that. What I work on are some very fundamental issues of physics and engineering.

My research thus is decidedly theoretical, often bordering on being “speculative.” It tends to concentrate on fundamental aspects. For decades by now, I have been trying to tackle some of the trickiest, deepest or very abstract problems (e.g. foundations of QM). At other times, I have been busy just isolating something new as a problem in its right (e.g., instantaneous action-at-a-distance in diffusion, or non-uniqueness of solution to the diffusion equation, or the fundamentality of stress vis-a-vis strain, or mode transitions in ideal vibrations and their relation to vibrations in the real mechanical system, or the physical meaning of the delta of calculus of variations….).

OK, there are some simple experiments here and there I might do. But they are not a very significant aspect of my work. The experiments are more in the nature of illustrations (e.g. melting snowman). They are not even fully in the nature of quantitative validations, let alone the prime vehicles to discovery. So, they are just “potatoes” of my research. The meat is: deep theoretical issues themselves. That’s what it’s like when you say “fundamental.”

The only way in which you can formulate or tackle such problems—fundamental or foundational—is by being a bit “relaxed” about both the specifics of your topic and the way you go about tackling it.

If you believed too much in the existing theory, you wouldn’t be able to spot unidentified problems with it or find new solutions to the known ones. If you try to do theoretical research and if you still try to stick to a schedule like what they do in experimental research (say in designing and fabricating a gadget, complete with bill of materials, or in developing a process, complete with prototype 1, prototype 2, etc.), you wouldn’t able to even get off to a decent start. After all, a schedule can be made from only those ingredients that are already known to you, not of never seen possibilities or unknown ideas. And, while in experimental research, reality has a wonderful way to throw up new possibilities, you have no such luxury in theoretical research. Every “never seen” possibility has to be forged by your own mind. If you don’t think in a relaxed manner, you are never going to believe that the issue is easy enough for you to tackle it.

But one unintended consequence of it all is that, in theoretical research like mine, it’s easy (far too easy in fact) to get a bit too relaxed. It is easy to pursue too many diverse theoretical threads, and in examining them, to run around in circles and so keep on getting back to the same points again and again.

But now I have come to realize that perhaps time has come to stop pursuing new threads in my research and to consolidate what has already been learnt.

The best way I can think of for doing the latter is: writing papers.

In particular, I have to kick aside this one habit: writing things down only when and as “inspiration” strikes.

Writing thoughts down (maintaining pocket diaries) has done a world of good to me. But this long-pursued activity seems to have by now come, in my case, to the point of diminishing marginal utility.

In place of this habit (of keeping on idly brain-storming and noting down possibilities it throws up) I would now like to put in place another habit: writing things (papers, actually) down in a structured, routine, regular, day-to-day, and time-bound manner. Allow me to explain this part too.

Given the way I have pursued my research (and in fact, given even the very nature of problems I ended up tackling), it would have been impossible for me to say something like this:

“OK! January, diffusion paper! February, stress-strain paper! March and April, QM position paper!”

“… What, in February, I don’t write something on QM? neither on diffusion? How ridiculous?”

That is how I would have reacted. But not any more.

Instead, I am now going to be a bit “bureaucratic” about my research. (UGC and AICTE folks ought to be happy in discovering a new soul-mate in me!)

What I am going to do is what I indicated just minutes ago. I am going to make some kind of a “time-table”: this period, work (i.e. actually write papers about) only this particular problem. Leave aside all other issues. Just finish that particular paper. Only then move to those other, more interesting (even alluring) issues in a next delimited period specifically allocated for that. I will have to pursue this policy. And I had better.

After all, while “passively” letting myself jump from issues to issues has yielded a lot of new insights, there are any number of issues where I have “hit the plateau” by now—and I mean those words in a positive sense. By “hitting the plateau,” I mean not a loss of creativity or originality, but a sense, even a firm realization (based on logic) that a certain stage of completeness is already achieved.

And that’s why, I am going to concentrate on “professionally” writing papers, in the next year. Following some kind of a time-bound schedule. As if I were writing a report, or delivering a software product on its schedule. So, it’s high time I became a bit less “creative” and more “professional,” to put it vaguely.

Since I will not be pursuing this bit of this idea or that bit of that idea a lot, I will be blogging less. And since a lot of my research seems to have actually “hit the plateau” in the above-mentioned, positive sense, I would instead be writing papers.

Hence the “slogan”: “`Blog’ less, write journal papers!”

That’s my NYR for 2018…. though I wouldn’t wait for 2018 to arrive before getting going on it. After all, a new year is just an excuse to make resolutions. The digits in the date aren’t important. A definite, demarcated change (“quantum jump” if you will! [LOL!]) is. But a change of the last digit in the YYYY, since it comes only after as long a period as one complete year, is a good time to making the required definite change.

So, there. I will keep you posted, with very brief notes here and there, as to how this paper-writing “business” is actually progressing in my case. My immediate plan is to get going writing the diffusion papers, and to finish writing them, right in January 2018.

Let’s see how things actually progress.


A Song I Like:

This is that Marathi song which I said I had liked a lot during my childhood vacation (see my last 2–3 posts). I still like it. It is the one which has a decidedly Western touch, but without spoiling or compromising on the Indian sense of melody. …

(Marathi) “raajaa saarangaa, maajyaa saarangaa”
Music: Hridaynath Mangeshkar
Singer: Lata Mangeshkar
Lyrics: Shanta Shelke


Bye for now, make a time-table you can stick to, and also take care to execute on it. … Best wishes for a happy and prosperous new year!

Yes I know it!—Part 2

This post directly continues from my last post. The content here was meant to be an update to my last post, but it grew, and so, I am noting it down as a separate post in its own right.


Thought about it [I mean my last post] a lot last night and this morning. I think here is a plan of action I can propose:

I can deliver a smallish, informally conducted, and yet, “official” sort of a seminar/talk/guest lecture, preferably at an IIT/IISER/IISc/similar institute. No honorarium is expected; just arrange for my stay. (That too is not necessary if it will be IIT Bombay; I can then stay with my friend; he is a professor in an engineering department there.)

Once arranged by mutual convenience, I will prepare some lecture notes (mostly hand-written), and deliver the content. (I guess at this stage, I will not prepare Beamer slides, though I might include some audio-visual content such as simulations etc.)

Questions will be OK, even encouraged, but the format will be that of a typical engineering class-room lecture. Discussions would be perfectly OK, but only after I finish talking about the “syllabus” first.

The talk should preferably be attended also by a couple of PhD students or so (of physics/engineering physics/any really relevant discipline, whether it’s acknowledged as such by UGC/AICTE or not). They should separately take down their notes and show me these later. This will help me understand where and how I should modify my notes. I will then myself finalize my notes, perhaps a few days after the talk, and send these by email. At that stage, I wouldn’t mind posting the notes getting posted on the ‘net.

Guess I will think a bit more about it, and note about my willingness to deliver the talk also at iMechanica. The bottom-line is that I am serious about this whole thing.

A few anticipated questions and their answers (or clarifications):

  1. What I have right now is, I guess, sufficient to stake a claim. But I have not taken the research to sufficiently advanced stage that I can say that I have all the clarifications worked out. It’s far more than just a sketchy conceptual idea, and does have a lot of maths too, but it’s less than, say, a completely worked out (or series of) mathematical theory. (My own anticipation is that if I can do just a series of smaller but connected mathematical models/simulations, it should be enough as my personal contribution to this new approach.)
  2. No, as far as QM is concerned, the approach I took in my PhD time publications is not at all relevant. I have completely abandoned that track (I mean to say as far as QM is concerned).
  3. However, my PhD time research on the diffusion equation has been continuing, and I am happy to announce that it has by now reached such a certain stage of maturation/completion that I should be writing another paper(s) on it any time now. I am happy that something new has come out of some 10+ years of thought on that issue, after my PhD-time work. Guess I could now send the PhD time conference paper to a journal, and then cover the new developments in this line in continuation with that one.
  4. Coming back to QM: Any one else could have easily got to the answers I have. But no, to the best of my knowledge, none else actually has. However, it does seem to me now that time is becoming ripe, and not to stake a claim at least now could be tantamount to carelessness on my part.
  5. Yes, my studies of philosophy, especially Ayn Rand’s ITOE (and Peikoff’s explanations of that material in PO and UO) did help me a lot, but all that is in a more general sense. Let me put it this way: I don’t think that I would have had to know (or even plain be conversant with) ITOE to be able to formulate these new answers to the QM riddles. And certainly, ITOE wouldn’t at all be necessary to understand my answers; the general level of working epistemology still is sufficiently good in physics (and more so, in engineering) even today.  At the same time, let me tell you one thing: QM is very vast, general, fundamental, and abstract. I guess you would have to be a “philosophizing” sort of a guy. Only then could you find this continuous and long preoccupation with so many deep and varied abstractions, interesting enough. Only then could the foundations of QM interest you. Not otherwise.
  6. To formulate answers, my natural proclivity to have to keep on looking for “physical” processes/mechanisms/objects for every mathematical idea I encounter, did help. But you wouldn’t have to have the same proclivity, let alone share my broad convictions, to be able to understand my answers. In other words, you could be a mathematical Platonist, and yet very easily come to understand the nature of my answers (and perhaps even come to agree with my positions)!
  7. To arrange for my proposed seminar/talk is to agree to be counted as a witness (for any future issues related to priority). But that’s strictly in the usual, routine, day-to-day academic sense of the term. (To wit, see how people interact with each other at a journal club in a university, or, say, at iMechanica.)
  8. But, to arrange for my talk is not to be willing to certify or validate its content. Not at all.
  9. With that being said, since this is India, let me also state a relevant concern. Don’t call me over just to show me down or ridicule me either. (It doesn’t happen in seminar talks, but it does happen during job interviews in Pune. It did happen to me in my COEP interview. It got repeated, in a milder way, in other engineering colleges in SPPU (the Pune University). So I have no choice but to note this part separately.)
  10. Once again, the issue is best clarified by giving the example. Check out how people treated me at iMechanica. If you are at an IIT/IISc/similar institute/university and are willing to treat me similarly, then do think of calling me over.

More, may be later. I will sure note my willingness to deliver a seminar at an IIT (or at a good University department) or so, at iMechanica also, soon enough. But right now I don’t have the time, and have to rush out. So let me stop here. Bye for now, and take care… (I would add a few more tags to the post-categories later on.)