It seems to me that working with a CFD package which include post-processing (integrations, graph plot, contours) under UniX + Latex enables me to reach the same level of analysis and understanding with less efforts and a good quality (reports, weekly productivity as an engineer) with the default standards.

Under NT, there is often other software to use like Excel :< (Errk!) And the system seems more obscure to me with those overwritted dll. Although you can change the colors the icons, add plenty of softwares.

I think it is better to do more with the required quality than to act as perfectionnist.

What do you think? Is this feeling justified...or is it just me?

I am 100% agree with u. What do you use for plotting the graphs? I use plotmtv, visual3.

GS

(1). What about working with punched hole cards, like those used in Florida election? (2). I think, you are assuming that CFD code is an engineering tool. But, we are far from that stage, just like the punched hole card systems used in the presidential election. (3). The machine counting is just like a CFD run, and the voting place is like the CFD code enviroment. (4). It is the result of the analysis, so is the result of the presidential election, which is important. (5). My theory is: GIGO, Garbage in Garbage out. The speed to improve the system turn-around time, is likely to promote the message to re-calculate from the boss or the client, which is the same as the recount-after-recount by human eyes looking through the holes at different angles and to determine whether it is a hole or not. (6). Punched hole cards and the integrated CFD codes are not designed for that purposes, they are just human activities which are not reliable, repeatable or fun to do at all. (that is why there is a shortage of PS2 game machines but not a shortage of CFD codes or answers.)

Without getting into the debate about how good CFD actually is, I think both Unix and Windows are useful and I run both simultaneously on a PC using Exceed/XWin-32 to display X from a Workstation/Server on my PC under Windows 2000.

I find this gives the best of both worlds, and allows you to choose the best application for a particular job. Software like mail, web-browsing, simple spreadsheets etc seems to be better under Windows, but then for numerical stuff I prefer unix apps - like Fluent, and my own codes etc, and utilies like grep and latex.

Greg

I think anyone who had pursued CFD for a reasonable length of time will have started using unix machines to solve the problems. They were until recently, the only machines that were capable of doing the job.

There are many facilities in unix (such as grep etc mentioned above and also unix scripts and the like) that are not in a NT system and therefore the users who have previously used unix swear by unix.

Now, whilst I also feel this way, there is no getting away from the fact that you can buy an equvivalent performance (not just clock-speed, but actual number-crunching performance) for an order of magnitude less, in price.

All the commercial codes run under NT platforms and can take full advantage of parallel capability.

Referring to John Chien's comment:

It seems John's favorite topic to deride commercial codes. Now, when it would be nice for us all to write our own code to tackle fluid flow problems, few of us have the time to do this in the commercial world.

I have tackled many 'real' problems using CFX4 and CFX5 that predicted the perceived problem and provided a solution that worked well. this is not just simple flow problems, but more complex multi-phase problems.

If you use the appropriate models to solve your problems then you can get good (well-validated) results in a time-scale that the engineers require.

I was amused at John's analogy of the American election. Especially as to me, his consistent harping on about their uselessness smacks of the intimidation of voters that evenually lost the Democrats the election.

Just a thought.

(1). The point is : for those who are professional, they go back to the main frame system (UNIX) all the time. (2). For those who love CFD, they always have confidence in it, even if they are still using the IBM punched hole cards to store the program. (3). From the recent experience in the presidental election in Florida, it is going to be very hard to tell people that the CFD runs using punched hole cards are accurate. (luckly, no one is still using punched hole cards to run CFD codes. But I still have some boxes in my closet) (4). Recently (in the last several years), I had experienced a few cases where, one of the world leading company invested several years in improving the various phases of CFD codes and interfaces to make it user-friendly, but, in the end, there were many layers of errors created in the modification of the code and the results turned out to be wrong. This also happened to the other company. (5). The point here is user-friendly programming without in-depth understanding from the programming side will always create errors through program logic or equation used or definition interpreted. (by programmers who are not familiar with the CFD side of the theory and the code. ....similar to the counting process of the presidental election, where the counting devices or persons do not have actual knowledge of the voters intention.) (6). The other occasion was that one leading company claimed to have developed an advanced design based on a person's study using a commercial CFD code, but, when the same code was used by an expert to validate the performance gain, the improvement was not there. (7). I can only say that CFD result is still a personal thing, and if it is not done carefully, the user-friendly part will have extra bugs in it.( I guess, one bug is enough to make the result useless. ) (8). So, are you sure that your integrated post-processing part is 100% bug free? Are you sure that the user will use the integrated post-processor in the 100% correct way? (9). When is a hole not a hole on the punched card hole? I guess, researchers at Caltech and MIT are looking into it to come up with a better system. (Are you sure that the results from the PC/NT system will be the same as workstation/UNIX system? Maybe, cavity flow is easy to do, but what about a compex 3-D problem?) (10). And if the code is ported from the UNIX side to the PC/NT side, then, even the graphic display on the screen will have different appearance. Some icons might not be working properly.(that's my own experience) (11). So, assuming that one can make the code operation more user-friendly, then, naturally it will help the user a lot to cut down the number of steps to obtain the solution. But, that is a big assumption. For example, if a new user of a code forget to properly set the reference parameters in the post-processor, the result will be wrong. And sometimes, the post-processor uses only the perfect gas law, then the calculations with other gas properties will be incorrect. (12). In other words, you have more opportunities to make mistakes, when you are using more pieces of codes which were written by non-cfd professional. So, CFD is like Florida presidential election process, it is a dynamic one, not yet a sure science. (so, there are opportunities to everybody)

Yet another thought provoking question with each contributor adding their own experience and analogies.What definitely emerges from this question to many many others is that of the model rationality to the real world physics of flow. Just how much of our science and mathematical reasoning do we actually convert into practical flawless working items. John mentioned cfd in terms of an engineering tool-yes it is but it is not the only tool in our overall evaluation processes.If computers become supercomputers then where stands the cfd practioner in ten years time.Can we simply categories problems with their known best theoretical answers [safe answers too] -sit back and wait for the product to roll of the line and do its stuff right away.

I disagree with John's comment that 'professionals' go back to 'mainframes'.

Being a 'professional' engineer, is (in my view) more about the processes of analysis, application of knowledge and scientific reasoning, and ethical standards - and importantly, making judgements (and often appropriate compromises), than about what tool one uses.

A carpenter doesn't just use a hammer does he?

Also, even if you write your own code, are you 100% certain that it's bug free??

I suspect that the only significant advantage (and it can be SIGNIFICANT) of having the source code, is that you can investigate and make changes if required WHEN you find something that appears 'wrong'.

Up until the point that you suspect something amiss in the code, there appears little to differentiate (in terms of accurarcy...) the use of a commerical or inhouse code that do essentially the same thing (solve same equations, use similar method etc.).

Greg

(1). I do agree with you that even the author of the CFD can not guarantee that the code is 100% bug free. So, I used the word "dynamic". A 100% error free code is "static", it does not change from time to time. (2). I was surprised myself, ten years ago, to find out that the code I wrote 20 years ago had a real bug in it. It was a bug, but it didn't affect the results very much. So, over the years, I thought the results were 100% correct. (3). This is the reason why CFD validation and mesh independent solution issues are very important to everybody. (4). The only reason why I said "mainfraim computers" is because these computers were designed to handle CFD type scientific calculations, while PC type was not designed for such tasks. (How many commercial CFD codes are duble-precision code ? )

Just a small comment - you can get the best of both worlds by running Linux on low-cost PC hardware. Over the last two years we've done the majority of all our heavy CFD computations on a cluster of Linux PC's - stability, performance and total-cost blows away all other alternatives.

Any code development, commercial included, is also 'dynamic'. The difference, and often frustrating aspect is that the changes are not always tightly coupled to your particular problem or area of interest, since the changes are made on a 'commerical' basis. And there is a time lag between changes (albeit reather short these days).

An interesting question is whether having more users, actually aids in the 'bug finding' process, thereby potentially allowing more bugs to be found in a given time?????? (isn't that we complain Microsoft does purposely with new releases?)

As I pointed out before, you can't do anything until you suspect a problem - or happen to stumble upon it for some obscure reason. So do you think its possible, your 'bug' would have been found a lot earlier if more people were using the code??

Greg

(1). I rarely make programming mistakes, except in two occasions. (2). The one I just mentioned was a real surprise to me. I would say that without the source code, the users alone will not be able to detect the bug. (3). The other occasion was, it took me almost three months to find the bug, a single typing error, in my new version of a 3-D Navier-Stokes code. The error will appear only in the non-symmetric cases. For symmetric flows, the bug has no effect on the result. Still, with the source code, (my own code),it took three months to find the bug. For the users, all they could say is there is something wrong in the code. Fortunately, it was not a commercial code. (4). I'll now share the experience with you about the source of the error. Normally, when I develop a code, I first write down the program on paper. Then, I double check it, type it in using editor, and compile it. (5). But then at that time, I decided to write the whole program, and type in every subroutines. In this way, I was able to improve my typing speed. And somewhere along the line, I typed a j instead of an i inside the subscript of a dimensioned variable. (6). As a result, for the symmetric problems, there was no problem. But, for non-symmetric problems, the result simply was not realistic. (6). A simple approach to this type of problem is to have two engineers working on the same code(same function, or same subroutine) at the same time. In this way, at least the function and the subroutine will be double checked by another engineer. It is similar to the engineering drafting (drawing) practice, where there is always a group of people to check the accuracy of the drawing, before it is released to other group.