Hi, Has anyone compared the advantages and disadvanteges between C/C++ and Fortran in CFD programming. Maybe it is much more of the personal preference. but could anyone suggest which is better. Thank you in advance.

Ciao,

I think you are asking something like what is the best religion.

I have seen people discussing this subject for days not comming to a conclusion. Maybe say it like this: A FORTRAN programmer should not be forced to program C/C++ and also the other way around.

Ciao

Heinz

(1). In Fortran, you deal with main program, subroutines, data and variables separately. The main program calls the subroutines which then operate on the data and variables, to print, to compute etc.. (2). In C++, you deal with main program, classes and objects and functions separately. The class includes its data and related functions as members. By changing the data, you can define different objects from the class. In this area, it is like a parametric representation. Member functions are just functions which operate on the data members. In Fortran, data and related functions are defined separately. In C++, you can group them together and define a class. For example, to print a number in Fortran, you first define the number, and then write the number to the screen . In C++, you declare a class called,say "class print_number", then inside the class you put in the number as the data member, and the function which print the number as the member function,say "prt()". Then, in the main function (program) you first create an object from the class, this is a copy of class with number and function in it. You exercise the member function of the object to print the number. If you had defined the object as "print_number myprint", then "myprint.prt" will print the number for you. The difference is "packaging", in Fortran, there are parts, in C++ the parts are packaged into many different classes. In this way you can protect your data similar to your bank account, or money in your pocket instead of money on the desk top with your name in front of it. With this concept, you can also derive other classes with additional functions in it, something like custom made PC with add-on in it. So, as you see, Fortran and C++ are different things, especially related to the use of classes and objects. So, if you treat data and the related functions as separate things, then Fortran and C are the way to go. On the other hand, if you group the data and the related function into classes and use it as object, then C++ has some nice features for you. Unfortunately, the transformation from Fortran and C to C++ is not simple because it requires the change in concept. ( in a way similar to the change in political systems ) By the way, JAVA is also object-oriented ,without the complexity of the pointer. I am interested in C++ because I have been looking at the PC windows environment, graphics as an integrated system for CFD programs. If your main interest is the solver and number crunching, then Fortran is the one designed for that purpose.(in some cases,it also has windows and graphics support) I would say, C++ will improve your vision of the current picture of computer programming technology.

John's description of C++ is spot-on, highlighting many of the advantages of an object-oriented approach. Here are some of my thoughts on the subject...

Fortran 77 is about the fastest high-level language for doing numerical computation. Good C code can go about as fast, but it is easier to write fast F77 than fast C. ie: It is easy to write BAD C code. The reason is that F77 compilers can do a better job optimising the code. With C, C++ and FORTRAN 90 the existence of pointers can be detrimental for performance. The compilers cannot optimise memory accesses if the data is spread all over the place in memory. However, pointers are incredibly useful for creating useful data structures, such as a linked list for an unstructured grid. Bear in mind that the performance could be abysmal if implemented niavely though.

FORTRAN 90 has two very useful features (amongst others!). The first is dynamic memory allocation. The second is modules. These make program managability much easier. Therefore, I think that you can do well by using a mixture of Fortran 90 and 77. F77 for the number crunching numerical kernel routines, and F90 for job setup and program management.

Similarly, C/C++ could be used together with F77 numerical routines. This seems to give a good balance between performance and flexible code structure.

An alternative is to make use of BLAS (Basic Linear Algebra Subroutines) and LAPACK routines. Vendor-optimied versions of these (including Pentium Pro/II/III) can significantly improve code performance. For example, we tested SAXPY on a PII 266MHz and Alpha 21164 500MHz machine. Performance of the PII was almost the same as the Alpha when using the Intel maths library under Linux on the PII and basic source code versions on the Alpha. Many of these routines are coded in assembly and they are all tuned for the particular CPU register/cache architecture.

On the subject of MS Windows. It is possible to compile FORTRAN DLLs to be called from C++ and Visual Basic. Therefore you can build nice GUIs for your FORTRAN code under NT, going beyond what is available within products like Visual FORTRAN.

Hope you find this interesting Kenji Takeda Dept of Aeronautics and Astronautics University of Southampton England

I posted a similar question a few months ago if you can access the archives.

I am sure a significant number of people have performed comparisons, particularly the CFD companies, but I have seen nothing published. There are quite a few language comparisons on the net but they tend to be written by computer people interested in computer languages rather than engineers trying to get a job done (there were a few exceptions but I have kept no links).

It is impractical to write a graphical user interface in Fortran so I will concentrate on the suitability of C/C++ or Fortran for the CFD solver only.

Fortran is an old, relatively small (conceptually), language developed for numerical analysis. It is small enough to be mastered by someone who is a non-programmer (i.e. someone principally interested in studying fluid mechanics via CFD). It is not well suited to large projects with multiple programmers. It's support for abstraction is poor.

C is a small low level systems language developed more with a view to getting things done at a system level than to be an elegant general purpose programming language. It is small enough to be mastered by someone who is a non-programmer. However, it has a long list of serious deficiencies which makes it a poor tool for large projects with more than one programmer. It's direct support for abstraction is low but it is not unusual to construct something on top. It's support for numerical programming is weaker than Fortran.

C++ is an imperative object-orientated language and a superset of C. It addresses a few of the weaknesses of C and supports one approach to abstraction fairly well. It is a large and unreliable language which requires considerable knowledge, experience and discipline on the part of the programmer to produce good programs. It is hard to recommend it as a suitable tool for someone principally interested in studying fluid mechanics via CFD.

As a sweeping generalization, a "natural" C program will be a bit slower than a "natural" Fortran program because the optimiser is usually more effective with Fortran arrays/loops. However, it is not unusual for a "natural" C++ program to be 10-100 times slower than a "natural" Fortran program. This does not mean that a C++ program cannot approach the speed of Fortran program - it can and it can also express things which would be very clumsy in Fortran - but a C++ programmer has got to know a lot more about what they are doing.

It was the recognition of the large number of practical problems associated with using C++ for real CFD projects that prompted my original posting here. It found no echos at the time and I remain baffled by the widespread enthusiasm for the language given the alternatives.

Circumstances often dictate which language to use but as a summary:

1. If you are the sole developer of, say, an efficient structured grid LES solver then the case to use Fortran is strong.

2. If you are part of a team developing complex, adaptive restructuring/regridding strategies for general p.d.e.s then the case to use Fortran is weak. I would not consider the case for C++ as particularly strong either but the best choice is likely to involve a wide range of factors (e.g. everyone else likes C++ and wants to use it).

Few years ago, I was searching the Internet for Fortran. I found a group of people did benchmark for C, FRTORAN77, C++, and FROTRAN 90. I forgot the web side for this group. But I still remember their conclusion. C++ is the best for object oriented programming. FROTRAN90 is the best for number crunching. Especially for a big problem where the industry and scientist interest, CFD need more time for number crunching than data processing. I prefer to use both FROTRAN 90 and C++ in one code. I will have FROTRAN 90 do number crunching, and c++ do data processing.

Tareq Al-shaalan

There is a very good web page about object-oriented numerics: <a href=http://monet.uwaterloo.ca/oon> http://monet.uwaterloo.ca/oon </a> There you find lots of information and also comparisons, I think.

Hi,

A good paper with could help you is: "Comparison of C++ and Fortran 90 for Object-Oriented Scientific programming", submitted for publication in Computer Physics communications, Nov. 1996.

This paper is available from Los Alamos National Laboratory as Report No. LA-UR-96-4064, and it is on the Internet at http://jove.colorado.edu/~cary/CompCPP_F90SciOOP.html

Hope this helps!

(1). It is indeed a very good site on the object-oriented numerics. (2). I think, within the framework of the numerical solution of fluid dynamics problems, Fortran, and Basic as well, are both simple and easy to understand. So, at that level, the main activity seems to be related to the speed of the computation. Perhaps, this was because in old days the computer was very slow and one had to run the program at night or weekend. (3). Fortunately, the hardware advancement has been much faster than the software improvement. Actually, the speed gain comes mainly from the hardware. From this point of view, it becomes very important to make the programming more flexible, easier to handle more complex geometry, and can communicate with the user graphically so that 3-D or 4-D results can be evaluated in real time as the program is being run on the computer. (4). Therefore, the future of CFD must be able to model the complex geometry and generate the computational mesh easily. It also must be able to detect the nature of the flow in the computational domain and apply the most efficient solution procedure locally. The decision to control the solution procedure in real time also depends solely on the ability to display the 3-D results in graphic form interactively with the user. (5). In the future, one should be able to run a CFD program like a computer game , instead of batch operation. I think there are a lot of interesting things need to be explored to make the CFD program more intellegent,such as selecting and switching a turbulence model, adjusting mesh, accelerating the convergence, presenting real time results, suggesting and changing the geometry for optimum performance,etc.. when the program is running. These features need to be incorporated into the CFD programs so that one can run a CFD program like a computer game. (6). Looking from this point of view, it becomes clear why it is important to explore programming languages beyond Fortran and Basic.

There's an interesting discussion on the topic in the paper "Robust linear and nonlinear strategies for solution of the transonic Euler equations" by H. Jiang and P. A. Forsyth (Computers & Fluids 24: 753-770, 1995). They compared F77 and C++ on a conjugate gradient solver, and concluded that C++ could get within 5-10% of fortran's speed if a bit of care was taken to avoid the generation of temporary objects through the overloading of "linked triad operators" (such as Vector -= (const Vector &)). Otherwise efficiency could drop by 50%. The monet stuff from Waterloo that others have mentioned is designed to get around this issue by the clever use of templates, but seems to be somewhat more complex.

I used C++ for an unstructured solver in my PhD and found that many features of the solver could be expressed quite naturally with the object-oriented framework. (Cells, faces, vertices, vectors are all objects and encapsulated with the standard methods with which they are associated.)

phil

Your comments on CFD 'computer games' are pertinent. This area is known as 'Computational Steering' and is used in computational chemistry and metereology to change simulation parameters on-the-fly already.

I think that real value can be gained by using these techniques, and also coupling CFD with experimental setups. For example, we have used CFD codes to provide information for the control system of our flexible-wall transonic wind tunnel.

The issue of using object-oriented code is a tricky one - purely on the the basis of speed. There is much work in the Computer Science community (from which I recently escaped!) about using Java for simulation codes. Personally I think this is disastrous, but believe that Java can be used to 'wrap' code and ship it around the network. The new paradigm is to move the simulation code to where the data is. Data management is the new bottleneck, not CPU power. Similarly, I think using C++ to wrap FORTRAN code (at whatever granularity, be it program, subroutine/class or intrinsic function level) can provide the best of both worlds. Of course, cross-compiling can be a pain though ;-)

This may be slightly off-topic, but will hopefully be of interest Cheers, Kenji Takeda, Dept of Aero/Astro (ex-High Performance Computing Centre!), University of Southampton, UK

Within the last year, a US Airforce researcher made the statement to me that "the young researchers coming out of school are using C++; the (ahem!) more mature investigators are still using Fortran." So I'll waste no more time bidding for Airforce projects. We mature investigators of course want to spend our remaining days doing CFD (grin!).

By the way, I doubt that this is official USAF policy.

(1). I have looked at the mixed language programming back in late 80's, and I decided that it was not the right approach for me. (2). Currently, I am looking at VC++ and OpenGL or VC++ alone. (3). My previous approach was MSFortran with build-in interactive graphics for CFD programs,which was accomplished back in late 80's under DOS . (4). One of the main purpose was to use the graphics as the sole output,without any data files saved , final or intermediate.(5). I don't think the speed of the language is a big problem. Back in early 80's, I used to run 2-D CFD code in Basic on PC. The current machine is at least a couple of thousands times faster than an 8-bit 2MH PC. (6).At the point when you think you need a faster CPU, the problem is ,I would say, largely solved. The reason is very simple: the existence of CFD depends on the existence of unsolved CFD problems. Once the difficulty of solving the problem is gone, the issue of solving the problem is also gone. (7). One of the main goal of CFD is to find the source of difficulties or to identify more problems associated with fluid dynamic design and analysis. It would not be very interesting to write the fastest code for super-computer so that one can just obtain THE RESULT in the shortest time. ( once it is shown that the problem can be solved, it is no longer a problem. The solution can be PLANNED. ) (8). From my point of view, the current need of CFD is the interactive process which will bring the modeling and solution to the user's finger tip at real time. In this way, the user's brain can be used to find the answer. ( The current computer program can not determine whether the solution is good or bad.) You really don't want to use the user's brain to plot the results from a super-computer. You don't want to save the results, you just want to know what's wrong with the design or analysis. In other words, one should not identify the post-processing as a job for human brain. The computer is suppose to do the processing of the resluts and display only the final picture. (9). There is a simple way to solve the JAVA speed problem, that is merge all the computer software and hardware companies into one giant company and hire only one programmer to write the software using one standard ( his standard). (10). So, I think, between Fortran, C and C++, the biggest difference is the opportunities ( the new uncertainty and unsolved problems)provided by object-oriented programming concept when applied to CFD activities. It is attractive because of new unsolved problems, not because of new solutions.

(1). It is consistent with the saying that " it is easier to move the land than to change the human nature ". (2). It is hard to erase the Fortran program in one's brain. So, I think, the practical way to do is to read a lot of books in C++, and hope that it will push the Fortran programs to some corners of the brain. (3). One gets old because one stops learning for time is nothing but calendar which can be printed easily. (4). I thought the policy can only be created at the congress and white house.

I am interested in describing a waterspout. Do you know of any computer models that have already been written?

Hi again, hope you don't mind continuing this thread but it is very interesting to hear your views As you may have guessed, my background is in parallel CFD. That is, running for a long time to get 'THE RESULT' rather than 'A RESULT'. That's what happens when you're an academic I guess!

I would be interested to know your situation, I presume that you are an engineer using CFD to really build things to deadline. However, I think that the issue of writing code that is as fast as possible on the available computing resource is critical. Basically, it would be nice to achieve a more accurate result in the same timescale, or achieve the same result in a shorter timescale. This affects the entire design cycle. For example, I have been loosely involved in a project developing and deploying a Finite/Boundary-element code with a loudspeaker company. The parallel version of this code runs over a cluster of PCs running NT. They can now do bigger grids (some of which were completely infeasible previously) in the same time as doing much coarser grids on a single machine. This has significantly improved their design capability. What used to take overnight, now takes 2-3 hours. Therefore they can now do a week's work in a day.

That's an example of parallel computing, but a similar argument can be applied to writing 'optimal' code. If C++ can only get to within 15% of F77, then that translates to the same timescale. A week's work can be performed in a day. Running in debug mode is 10 times slower than optimised code. I have heard of a lot of people who run in debug mode because they don't even know what an optimisation flag is!

Clearly C++ is great for many CFD apps, including the ones you describe. However, using the appropriate language can result in huge gains over the long-term. This goes both ways. Using FORTRAN 77 for unstructured grids is painful (I've done it, and it is!), while F77 is perfectly good (and fast) for many other apps. C++ is fabuluous for many things (including CFD) and its object-oriented nature improves reusability too - always a good thing.

I think that in your situation that using optimal maths kernel libraries (such as those released by Intel) can give a performance boost while sticking to your preferred language. Indeed, I am writing a GUI (in VC++ with OpenGL) for a structural analysis program that is being written in Visual FORTRAN. We can simply link the two together to get the best of both worlds.

Speed is also crucial when dealing with interactive computations. The difference in waiting 1 second and 2 seconds for a result is massive. The end-user is an impatient beast!

Anyway, I'd better get on with my aeroacoustics. Look forward to hearing more of your views Warmest regards, Kenji Takeda

(1). This is a very good subject, mainly because I don't have the real experience of writing a CFD code in C++, in the way I have in mind. It is also because I am studying C++, VC++, OpenGL and 3-D games progarmming. (2). O.K. I am going to tell you something about my interest in computer. Back in early 80's, when the Radio Shack/model-III first appeared on the market, I decided to get one. It costed me around 2600 dollars. I also got a pen plotter so that I could plot the streamlines and velocity vectors. In those days, there was no Fortran compiler (yet). It took them about a year to release a Fortran compiler. By then, I was running 2-D Navier-Stokes programs in Basic. The computing time was typically 8 hours a case. So, I had to let it run over-night. By the way, the CPU was has only one MH speed. I later upgraded the CPU myself to a two MH machine. This speed improvement and the arrival of the Fortran compiler made the life easier to do CFD on a 2-MH PC.( in those days, a PC was called a micro-computer.) At that time, around 82, or 83, I had a opportunity to present a paper on the applications of micro-computer to an engineering society, at CalTech. Naturally, it covered word-processing, Chinese characters generation , games and CFD. I predicted that with the PC, one no longer have to depend on the company's main frame computer to do professional work, including CFD. ( even at that time, the parallel computing was old for me because I had the idea back in mid-70's when I was running my CFD program using dual grid to speed up the convergence. ) (3). Around mid-80's, right after the release of Mac from Apple computer, there was a PC which can do almost everything. It can play music, it can speak in english, it can paint pictures and do animation, and it can run several programs at the same time. It was called "Amiga". It costed me around 2400 dollars to get one. It came with a free Epson color printer though. The Amiga changed my way of thinking about the computer graphics. Instead of line drawing, I was able to do 3-D ray-tracing. (4). I will continue my story next time. (5). At the same time, I would like to know the specific reasons why there is such a speed variation writing a CFD program using C++. So far, there is no such statement written in C++ books. When you say " If C++ can only get to within 15% of f77,then...", I think, you definitely have something to say. Maybe, you can give us some examples of C++ programming techniques such that we don't have to work overnight, every night?

There is an article by Bjarne Stroustrup ( the inventor of C++) entitled " Learning Standard C++ as a New Language" in the May issue of "C/C++ Users Journal". The article has several simple benchmark testing results on efficiency between C++ and C.

CREATORS ADMIT UNIX, C HOAX

In an announcement that has stunned the computer industry, Ken Thompson, Dennis Ritchie, and Brian Kernighan admitted that the Unix operating system and C programming language created by them are an elaborate April Fools prank kept alive for over 20 years. Speaking at the recent UnixWorld Software Development Forum, Thompson revealed the following:

"In 1969, AT&T had just terminated their work

with the GE/Honeywell/AT&T Multics project. Brian

and I had just started working with an early release

of Pascal from Professor Nichlaus Wirth's ETH labs in Switzerland and we were impressed with its elegant

simplicity and power. Dennis has just finished

reading 'Bored of the Rings', a hilarious National

Lampoon parody of the great Tolkien 'Lord of the

Rings' trilogy.

As a lark, we decided to do parodies of the

Multics environment and Pascal. Dennis and I were

responsible for the operating environment. We looked

at Multics and designed the new system to be as

complex and cryptic as possible to maximize casual

users' frustration levels, calling it Unix as a

parody of Multics as well as other more risque

allusions. Then Dennis and Brian worked on a

truly warped version of Pascal called 'A'. When

we found others were actually trying to create real

programs with A, we quickly added additional cryptic

features and evolved into B, BCPL, and finally C.

We stopped when we got a clean compile on the following

syntax:

for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("|"+(*u/4) %2);

To think that modern programmers would try to use a

language that allowed such a statement was beyond our

comprehension! We actually thought of selling this

to the Soviets to set their computer science

progress back 20 or more years. Imagine our surprise

when AT&T and other US corporations actually began

trying to use Unix and C! It has taken them 20 years

to develop enough expertise to generate even

marginally useful applications using this 1960s

technological parody, but we are impressed with the

tenacity (if not common sense) of the general Unix

and C programmer. In any event, Brian, Dennis,

and I have been working exclusively in Pascal on the

Apple Macintosh for the past few years and feel really

guilty about the chaos, confusion, and truly bad

programming that have resulted from our silly prank

of so long ago."

Major Unix and C vendors and customers, including AT&T, Microsoft, Hewlett-Packard, GTE, NCR, and DEC have refused comment at this time. Borland International, a leading vendor of Pascal and C tools, including the popular Turbo Pascal, Turbo C, and Turbo C++, stated that they had suspected this for a number of years and would continue to enhance their Pascal products and halt further efforts to develop C. An IBM spokesman broke into uncontrolled laughter and had to postpone a hastily convened news conference concerning the fate of the RS-6000 merely stating "VM will be available real soon now". In a cryptic statement, Professor Wirth of the ETH institute and father of the Pascal, Modula 2, and Oberon structured languages, merely stated that P. T. Barnum was correct.

In a related late-breaking story, usually reliable sources are stating that a similar confession may be forthcoming from William Gates concerning the MS-DOS and Windows operating environments. And IBM spokesmen have begun denying that the Virtual Machine (VM) product is an internal prank gone awry.

(COMPUTERWORLD 1 May) (contributed by Bernard L. Hayes)

The above announcement is at least a dozen years old. That explains the satire about IBM and the VM project which may be somewhat dated. Of course, it is a joke. At least, we hope so. Having used UNIX, I sometimes wonder if that system wasn't deliberately designed to be difficult.

For those in the international audience who are not familiar with U.S. history, P. T. Barnum (1810-1891) was a showman and circus promoter. His most famous saying was "There is a sucker born every minute." Again, for those who are not familiar with American idiom, a "sucker" is someone who can be fooled into buying some useless or fraudulent item or service. At one point, Barnum exhibited an old black woman who he claimed had been the nursemaid who took care of George Washington, the first president of the U.S., when he was an infant. Barnum was making this claim more than 130 years after Washington's birth, so it was an obvious fraud. Nevertheless, the suckers came to the exhibition and paid to see this woman. Obviously, the author of that announcement thinks the same kind of people would try to program in C.

Now that I hope I have entertained you for a moment, let me give my opinion on the relative merits of FORTRAN and C++ for CFD.

I think FORTRAN is a relatively easy language to learn. To me, that is an important virtue. A user wants to start out being able to do easy things without a lot of training and then grow into more complex operations as he gains experience. FORTRAN also tends to generate code that executes quickly. This is important. Remember that doing CFD requires a lot of number crunching. After some 40 years of evolution, the optimizing compilers (at least most of them) are quite powerful. This last statement may be less true for parallel machines. When the first vector machines appeared in the early 70s, they required a lot of hand coding to get the desired high speed. But, after about a decade, the compilers caught up and could either optimize the code or tell the user where and why it couldn't be optimized. I don't know how far the FORTRAN compilers for parallel machines have traveled on that road.

FORTRAN is not a perfect language, of course. Indeed, language theorists have been trying to get it replaced at least since the rise of structured programming concepts in the 60s. ALGOL appeared in the 60s. Later, IBM tried to sell APL to the world. At one time, many major centers of computational science had projects going to write new languages to replace FORTRAN. The objective of at least some of those projects was to create languages that would force the programmer to write well-structured code. The presumed virtues of those newer languages were never enough to overcome the inertia from the enormous numbers of people who already knew FORTRAN. Besides, the complaints of language theorists not withstanding, FORTRAN is entirely adequate for scientific programming. Those of us who have watched the evolution of FORTRAN from early versions (I myself learned FORTRAN I on an IBM 1620 in the fall of 1963) to the most recent language standard have seen a steady increase in features dear to the hearts of language theorists (such as "do while" and "if then else"). One can certainly write bad code in FORTRAN, that is, code that is difficult to maintain or modify and whose logical structure is tangled. One can also write slow code in FORTRAN. However, if one writes in FORTRAN, he will be using a language that was designed to do scientific number crunching and has been maintained and modified to continue doing that well.

Before I discuss C++, let me insert a disclaimer. I do not write in C++ or in C. My comments about C++ are based on what I have read and on talks with colleagues who do have C++ experience. These colleagues are scientists and engineers who are trying to get their scientific computing jobs done--not hobbyists or tinkerers who are looking for fun things to do with the computer. So, what you are getting is opinions of C++ from the point of view of scientific users.

C++ is the new kid on the block. It doesn't have as many decades of development as FORTRAN. Indeed, the nominal language standard has just recently been issued. C++ was not designed to do scientific number crunching. It came from languages to do things like generate compilers and communicate with the system to produce GUIs. The reason C++ is the language so often taught in computer science departments is that those are the kinds of things that computer scientists do. Scientific number crunching is a sidelight that is more likely to be the province of engineering, science, or applied math.

The learning curve on C++ is quite high. In C++ as in UNIX, you can't do simple things with minimal training. The language grew by having lots of tinkerers make additions by thinking "wouldn't it be great if we could get it to do this?" It was made to do lots of neat things by people who wanted to get computers to do neat things. Ease of use for anyone else besides the person writing the new feature never (or at least hardly ever) was a consideration. Even when one has mastered the language's intricacies, writing fast code in C++ is still quite difficult. I won't say that no C++ code can crunch numbers as fast as FORTRAN written by a competent programmer, but the level of expertise needed to write fast C++ code is much higher.

So, if C++ is so bad for scientific work, why are we having this discussion? There must be something good about it. After all, the people who wrote and continue to extend the language are hardly morons. Few of the college professors who teach C++ and not FORTRAN are congenitally stupid. Even the managers who specify which language is to be used by a project are not all COMPLETE idiots. The answer lies in the I/O. A colleague of mine reminds me that, with the level of interactive and graphical I/O desired in modern applications (in other words, GUIs), far more than half of the programming team's time will be spent in designing, maintaining, and upgrading the I/O. C++ is used because the language was intended to do such things and seems to do them well (if with an awful lot of complexity). One can certainly write FORTRAN code that will talk back and forth to the terminal and even draw pictures on the CRT. I have worked on codes that do just exactly that. But, my colleagues insist that the level of interaction that can be done with C++ is far higher.

I think that interactivity is the reason why one would deliberately try to write CFD code in C++ rather than in FORTRAN (by deliberately, I mean because you think it is a good idea rather than because you only know C++ or because the boss told you to use C++ or find another job). This is not a totally indefensible decision even to an old FORTRAN programmer like me. The calendar time needed to complete a project often matters to the scientist or engineer trying to solve a real world problem with CFD at least as much as the number of CPU cycles consumed. This would especially be true for commercial companies whose profits are driven by time to market. Therefore, it may be most economical to sacrifice raw number crunching speed for greater convenience in setup and processing of results.

Let me finish before all of you go to sleep. If the GUI and its associated interactivity are most important, then one uses C++ and either sacrifices number crunching speed or finds a VERY good C++ programmer. On the other hand, if number crunching speed is most important, one has to write in FORTRAN and sacrifice some level of interactivity. I would think that the optimum solution is to create the input using a GUI written in C++, pass input to a number crunching code written in FORTRAN, and then return the results to the GUI. Not either FORTRAN or C++, but an intelligent combination of both. Mixing the two languages in a single code seems to be difficult (if not impossible), so that the product of this approach is usually stand alone codes for preprocessing, postprocessing, and number crunching. A disadvantage of combining the two languages is that the team has both good FORTRAN programmers and good C++ programmers. A disadvantage of a stand alone FORTRAN number cruncher is that one must accept less interactivity with that kernel than if it had been written in C++. Well, no solution to any problem. Balancing the pros and cons to come up with the best plan for what you want to do is part of the challenge. So, I'll leave all of you to contemplate this matter and hope that maybe I have shed a little light.

(1).I think your observation is 100% correct. (2). The speed alone is not the biggest issue. In many areas, when the speed is important, people would just use the assembly language to code the function. (3). C++ language is not difficult to learn. The difficulty lies in the old programming models stored in our brain. Getting data and functions under a class is just one more convenient step in using it later on. (4). The confusing part is related to the use of the pointer ( the address of a variable in the computer memory). It speeds up the operation but at the same time, it requires the understanding of the computer architecture from the programmer. The use of the pointer is shared by C and C++. (5). The windows systems have been around for 15 years on PC. The windows, the icons, the check box, etc.. are all derived from the window class. And most CAD programs and 3-D graphic animation programs are all written in object-oriented fashion. It would be very hard for most people to go back to the DOS command-line input approach.(UNIX command names are much harder to use and hard to remember.) It is much easier to make errors in the command-line input approach. (6). As I said before, the speed alone is not everything. For example, I am currently running a 3-D program to do turbine stage analysis. Each case takes about 100 hours CPU time. I normally run several jobs on different computers, and the biggest problems are :a) bad results, b) power outage, c) workstation shut-down, d) net-work trouble, e) system upgrade,etc... You simply have to live with these problems in order to get a complete run. And even when you have a result, 99% of the time, there is something wrong with it. (7). so the speed alone can not solve the problem. I am not going to tell you which way I am heading. But I am sure that you don't want to run a CAD program or a game program on super-computer ( or parallel computers) in BATCH MODE.( So, if you are the commercial code vendor, it is a good idea to get rid of the batch mode operation) (8). Production is one-way, but design and analysis is iterative. That is, you need to be able to create and modify objects easily. (by the way, I think the speed is still important, but there is not much we can do about it. If you need the speed, simply buy a faster computer. When was the time you were able to re-write and speed up a Fortran code by a factor of two?)