User login


You are here

What Platform Would You Prefer for a Software That Helps in Learning FEM---Windows or Java?

Ideally, this post of mine should carry a poll, but I guess as an ordinary user, I cannot insert one.

Currently, I am writing a small software program that is especially designed to help learn FEM. For instance, I will be providing detailed listings for every intermediate step, e.g. all those [D], [B], [k], etc. matrices for each element, as well as the final assembled global system {F} = [K]{d} and its solution separately at each Gauss point. Only linear static problems for the time being; will add transients/eigenvalue problems in near future.

Needless to add, to make it all easy to use, I am providing a GUI as well.

Currently, I am implenting it all in VC++ 6 on Windows. (That's the latest version of MFC I have with me.) However, I am open to change the platform and/or language should the need arise.

This post is to ascertain whether you would rather prefer a C++/Windows version or should it be Java-based. (A third possibility is a QT based version, but I haven't seriously considered it---I would rather do it in Java than compile on many platforms.)

Please, this is not about platform wars. I am honestly interested in knowing what you would honestly find more convenient to use---as an end-user. And, before you answer, please note that this will not be an open source thing. There will be a small charge, say through a PayPal sort of arrangement. (Currently, I plan to keep the cost at about US $ 25/- per copy or less.)

So, please indicate what version you would prefer: Java or Windows. Thanks in advance.


- - - - -
I remain jobless---and I remain being targeted by the Americans on a daily basis, including psychically, but to a noticeably lesser extent since I began talking about it here at iMechanica.


As You Know, There are lots of commerical and open-source FEM packages available, It would be helpful If you clarify  Differences of your's. However,  I recommend JAVA.

Dear Roozbeh,

Thanks for your reply.

It's only natural to raise the point about differentiation the way you have. After all, even at the level of commercial offerings, the FEM software market (and more generally, the market for any CAE analysis software) is already highly fragmented the world over. This is not the case for most other markets. For example, consider the "big three" of automobiles, the HP-IBM-Dell trio in computers worldwide (or the TCS-Infosys-Wipro in software in India), etc. So, when it comes to the FEM market, it's true that far too many competing products exist already. If you throw in the university/govt. lab codes and the more recent open source ones, then the spectrum of the available software becomes even more rich. That's why it's very natural to raise the question you have.

But while the question is valuable, frankly, I have no answer to that! At least not a very pointed one. So, allow me to write at length, once again!

The fact of the matter is that I didn't realize I needed such a software (the one which I am now writing) when I taught FEM myself through self-studies. I began to feel the need to have such a software only when I began teaching FEM.

During my teaching, there were times when I found myself drawing (poor) diagrams with a feverish pace on the white-board, or frantically waving my hands in the air, when, ideally, I should have been coolly pointing out to a live software demo. Ideally, the software should have been small/tiny, something that students would own individually, something that wouldn't take more than 2 to 3 days to master completely.

No such a software existed.

I could not include any packaged software as a part of my class-room teaching. Our students did have a Lab course using a commercial software (ANSYS), but it already was a full-fledged system meant for professional work. To learn to effectively handle a system like that becomes a separate piece of work by itself. (If not, they wouldn't charge Rs. 11,500/- for a three day introductory course, would they?) Our actual experience is that the students take approximately 2 months to get comfortable with the packaged software. But the need was to show them something in the classroom right in the second week. A software that would handle the simplest case of a spring assemblage too!

Another point. No software I know of gives you easy-to-read listings of all the intermediate steps in a convenient manner.

First of all, the commercial software won't list the intermediate matrices. (Most such software won't even list the final Gauss-point stress matrices---all that they would give you are those field plots and contour lines for the recovered stresses.)

Secondly, even the open source software tends to be far too big to introduce even simple changes---I mean, not just matrix listings but also other minor matters. (Here, I speak from experience. I have actually tried at least three open-source softwares.) And, one likes to see things like, say, the [B] matrix being made available keeping a factor like, say AE/L, outside of the matrix entries. This would be helpful for the student to cross-check his answers.

There are other teacher-student-friendly things needed too. Many of them. But I won't list them here because (i) I am still experimenting with them, and (ii) one likes to rather show than desribe. (No point in raising expectations unrealistically high.)

All in all, it is a software I should have had in my hands before my course began.

I think I will spare the reader a sales pitch about it. But, honestly, I must note one more point---a point that is often taken lightly by many engineers. 

It's funny to see how the human mind is. It is very gossamer-like and yet, very powerful. When we learn something new, there are many minor things which it is necessary to be told. These are the things which help concretize complex abstract notions, things which help us establish relations between the intangible mental entities on the one hand and the concrete entities actually existing in the world on the other. The mind does require such small things because the mind is so gossamer-like. These minor things help introduce that sense of reality, they give us that sense of confidence, during that crucial initial phase of learning. ... Of course, soon enough, we outgrow that initial phase. And now, those many  small and minor things which had once actually helped us learn, now begin to look laughably small. ... For example, by the time you finish modal analysis, the static linear 1D spring begins to look like an insignificantly small topic. This does not mean that the topic of the spring, therefore, should be removed from the course. No. Springs serve a certain purpose for a certain learning objective for a certain time period, and during that time period, the spring element is crucial, nay, even irreplaceable. There is a hierarchy of topics and within the learning context, no matter how simple, each concept is difficult and important to learn.

And, if you have a simple software to play with, it helps consolidate the understanding in a way that no teacher or book can. Again, I recall a software for curve-fitting that I used in my graduate school... It was a simple, DOS based utility that did nothing but read a comma separated file of modest size as an input and allow you to play with the coefficients of the interpolating polynomials so that you could do the fit visually... That one simple software alone has helped clarify so many things to me that so many other, highly sophisticated programs could not. In a way, that software (a shareware it was) is my inspiration.

I hope to give a software which might look like a laughable thing to someone who has already finished one/two courses on FEM. Indeed, it ought to look like a laughable toy to the student if has finished his course work right. And yet, it should be a software which undertakes to walk besides that student who is just beginning to learn FEM. The first-time learner of FEM---that's my market. (And their teachers, too!)



I think I will complete the current development in C++ (already more than half-way through), and then port it to Java. I think the final product to be released will be only in Java. ... The more I thought about it, the more I found that I really have no alternative other than Java for multiplatform release.


PS: This software will be, at least initially, very small and simple... Indeed, it will be too small for it to even become the MINIX of FEM. But may be, if there is a market for it, one day, it could aspire to become that---the MINIX of FEM. ... Hope this helps clarify this entire matter.


- - - - -
I remain jobless---and I remain being targeted by the Americans on a daily basis, including psychically, but to a noticeably lesser extent since I began talking about it here at iMechanica.

Temesgen Markos's picture

Hi Ajit,

I think MATLAB is very suitable for such a program. Hiding/displaying intermediate results such as shape function values, their derivatives, B-matrix, element stiffness matrix, post processing results at quadrature points etc becomes a matter of using or not using the semicolon at the end of a subroutine call or some other line of code whose result you want to be displayed. Besides, with a judicious use of the pause command you can allow your students to see an intermediate step and go to the next step on their own pace. The easy to use graphics and the natural feel of Matlab commands, and not having to bother with linear solvers and other mathematical aspects makes it easy for a beginning student to focus on the FE aspects of the code. Ofcourse I am assuming your students have access to Matlab. If not, you may try Octave which is open source and very similar to Matlab.

Good luck.

Hi Temesgen,

Neat points.

1. I don't know whether they have licenses for Matlab or not at COEP. I did use Freemat a couple of times in my class, and also am aware about Octave. And Scilab.

That way, people have used even Excel VBScript to teach FEM; the book by Chandrupatla and Belegundu comes readily to my mind. Of course, Excel doesn't have good graphics capabilities, but is excellent for matrix listings!

2. However, I am not too impressed by any package such as Excel or Matlab or even the open source ones. A few points. ...

(2.1) With scripting, there is no encapsulation---whether at the source code level or from a functionality viewpoint. Both are serious limitations from my viewpoint. For instance, I cannot easily enforce a sequence or add a greater interaction than what the package permits.

(2.2) With any general purpose (GP) package, there is tieing up to that particular product, and I hate to do that. Octave is, they say, 95% compatible with Matlab, but what about the remaining 5%? Ditto for any other software. If I use Octave for instance, I am sure Scilab folks will have something to say about it... The tendency is especially prevalent in that free and sometimes even chaotic atmosphere which is characteristic of academia.

(2.3) What goes for tieing up with a GP package also goes for versions. Few are as thorough as Microsoft is in maintaining backward compatibility. That esp. holds in the Open Source side.

(2.4) Finally, I don't want to act as an unpaid salesman of sorts for any American software maker, and that includes Matlab. ... You (would) know (pretty well) that when it comes to giving jobs, they isolate me as if I were an untouchable of sorts. Frankly, such behavior patterns on their part do seep away any enthusiasm one might have for using/buying/recommending their software as well... Trade is not a one-way street; it's an exchange; the idea extends to all realms including intellectual/teaching activities.

3. There is no gainsaying that with a special product, one has enormous freedom for designing. Also the pleasure of designing one.

4. If I bring out a product, it will help me make money.

On another note, I will use the readymade JAMA or similar other library. In any case, they advertise it that JAMA uses the same algos as Mathematica does (if I remember it right).


A Personal Note to Temesgen: Apart from it all, it was quite some time back that I noticed that you have joined Duke and wanted to congratulate you... But somehow it kept slipping off the mind. ... So, here are belated congrats for gaining admission and visa and all that... I feel sure you won't have a US univ. experience like I did. (With John and all, you certainly are in a good company.) Anyway, wish you all the best...


BTW, my US univ. exp. doesn't bother me any longer; emotionally, it's merely a memory; but it's impossible to "forget and forgive" its professional consequences because I am still living through them. ... But, in any case, it isn't what led to the point. 2.4 above---it was just a contributory factor like everything else is.


A Note to iMechanicians in General: I will be offline for a while---about ten days. Pl. don't feel bad if I don't reply immediately. But eventually, I will read and reply all your posts, so keep them coming in (i.e. if you wish to :) )

Bye for now


- - - - -
I remain jobless---and I remain being targeted by the Americans on a daily basis, including psychically, but to a noticeably lesser extent since I began talking about it here at iMechanica.

i think, to learn fem well, writing scipts is necessary. python itself is so simple but so strong. it also can be the glue of different languages. by the way, its scipy module made it like matlab.

I agree with you that the to learn FEM you have to start writing the scripts. WordPress services



The decision to use what language for a particular program is not new. I have experimented and worked with various languages and here's what I think:

In my opinion the choice of language really depends on a variety of factors, including personal bias. If your program is "small", I think applying an object-oriented (OO) approach would be an overkill because it can add a tremendous amount of code relative to the number of essential functions. I think the OO approach only makes sense if you foresee your program evolving into a large piece of software.

Some people prefer to use a single language for everything while others prefer to apply a multi-language approach for reasons such as speed and extensibility, for example, the core using Fortran/C with a scripting/wrapper language for the GUI. And in Java, you can call other languages. Commercial programs such as ANSYS and ABAQUS have their core written in Fortran/C/C++ and the GUI using scripting languages. 

In my opinion, Java's sparse solver technology is still not up to par with Fortran's or C's solvers so if speed is important, then Java may be slow for large-scale applications. If I remember correctly, JAMA offers only dense matrix solvers so if your problem is large, you'll run into memory issues. 

I think all good programs, including those written using procedural languages, are "object-oriented" to a certain extent. Many languages including Matlab and scripting ones allow for object-oriented
programming so I disagree with you that encapsulation cannot be readily achieved using
scripting languages. 

I think the more important thing is the documentation, especially if you want to disseminate your code for others to modify and extend.


Thank you all for your valuable comments.

However, I am pleased to inform you that I have (temporarily) lost interest in this thread because I don't have the time to think about it because I have landed a small software development contract in the CAE area (just the way I wanted it---in the CAE area and not for financial/business domains) right in Pune. (The contract is expected to last a month or two. (Everything comes to a pass sometime.))

I hope, nay, I am sure, that you all will forgive me my loss of interest in this thread if it has come about in the aforementioned manner.

So, may be, more, sometime later.... Thanks again in the meanwhile...


Subscribe to Comments for "What Platform Would You Prefer for a Software That Helps in Learning FEM---Windows or Java?"

Recent comments

More comments


Subscribe to Syndicate