Comparison between C/C++ and Fortran?
 

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.

Re: Comparison between C/C++ and Fortran?
 

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

Re: Comparison between C/C++ and Fortran?
 

(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.

Re: Comparison between C/C++ and Fortran?
 

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

Re: Comparison between C/C++ and Fortran?
 

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).

Re: Comparison between C/C++ and Fortran?
 

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

Re: Comparison between C/C++ and Fortran?
 

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.

Re: Comparison between C/C++ and Fortran?
 

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!

Re: Comparison between C/C++ and Fortran?
 

(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.

Re: Comparison between C/C++ and Fortran?
 

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

Re: Comparison between C/C++ and Fortran?
 

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

Re: Comparison between C/C++ and Fortran?
 

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.

Re: Comparison between C/C++ and Fortran?
 

(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.

Re: Comparison between C/C++ and Fortran?
 

(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.

Re: Comparison between C/C++ and Fortran?
 

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

Re: Comparison between C/C++ and Fortran?
 

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

Re: Comparison between C/C++ and Fortran?
 

(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?

Re: Comparison between C/C++ and Fortran?
 

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.

Re: Comparison between C/C++ and Fortran?
 

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.

Re: Comparison between C/C++ and Fortran?
 

(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?)

Re: Comparison between C/C++ and Fortran?
 

I'm not sure about it, but as my experience, C++ is designed for 32-bit system and best run with windows, so if you are doing your work on PC or UNIX, it should be the best one for every kind of applications except its complecity.

Re: Comparison between C/C++ and Fortran?
 

The thing I don't like about C++ for fluid dynamics is the inability of the C++ compilers I have looked to run time allocate higher dimension arrays. They can do vectors but not higher order arrays. Fortran can do this so I don't have to recompile for every problem. Now, Delphi also provides a very powerful object Pascal which can also do run time allocation of higher dimension arrays. This makes a very convenient way to build an application if you, as I, are not a full time C++ programmer. Delphi allows you to do object programming and to build beautiful graphical interfaces with little effort. The number crunching is done using F90 or F77 and compiled as dll's to be called by the Delphi interface. Or, you can easily just use Delphi to white an input file for the Fortran program. It makes for a very user friendly program.

Re: Comparison between C/C++ and Fortran?
 

I agree fully with the sentiment but the reason "C++ cannot do this" is rarely true. If you want something (like nice higher dimension arrays) then you can do one of two things: (a) write the class yourself or (b) get one from somewhere. The former takes a long time unless an experienced C user. The latter appears quicker but you will have to learn how to use it in combination with other classes which may lose more time in the long run. A typical matrix class (cmat.h) from an old version of the TNT toolkit I just looked at is 592 lines long including comments. This is probably typical for a fully sorted class.

However, you can dynamically create C's usual representation of a multidimensional array in a number of ways at the "raw C" level. For example:

typedef float * float_p; float ** a = new float_p[ ni ]; for (i=0;i<ni;++i) a[i] = new float[ nj ];

[JONAS. WHY IS THIS GETTING MANGLED? AND CAN I STOP IT?]

and refer to the elements as a[i][j] and pass the array around as float ** a. This is a bit cryptic, slightly messy, a bit unreliable but works. Probably an accurate summary of C?

It is only Fortran 90 and later that supports dynamic arrays. Fortran 77 which is still probably the most widely used does not support dynamic arrays.

I have only heard good things from people about the ease of using Delphi. However, using it locks you into a proprietary system running on Windows. This is often fine for small projects but unacceptable for large ones where portability and maintainance/development over the long term is usually a significant consideration.

Re: Comparison between C/C++ and Fortran?
 

I have been using the Watcom f77 compiler for several years to do run time allocation of higher dimension arrays. It works well and has a good development platform.

I agree that Delphi may not be a good solution for those building commercial programs for a wide variety of platforms. There are still many of us out here who are building our own programs to support our own design work and Delphi provides a very productive tool for doing this. I have built a full up 3D general purpose Navier Stokes program using this approach. I use a Delphi front end to write input decks for the f77 program components. This has made a very user friendly interface and I have not had to invest a great deal of time doing computer programming which is not my primary purpose.

Re: Comparison between C/C++ and Fortran?
 

The dynamic arrays in Watcom Fortran are a Watcom extension and nothing to do with Fortran 77. I had a student many years ago who used a dynamic array extension on an HP system and when it came to moving the code to a more standard system it required a major rewrite. The use of dynamic arrays had significantly affected the way the program was structured.

Again I would hearitly endorse your sensible approach so long as the portability of your work really is not particularly important. As one gets older and has moved systems and institutions a few times one does tend to recognise and adopt standards more.

I am curious about why you decided to write the solver in Watcom f77 and not keep everything in Delphi? Or did the solver come first?

Re: Comparison between C/C++ and Fortran?
 

(1). I think, both approaches are acceptable. (2). Back in 80's, when I was looking for graphic library for Fortran, I had to wait until MSFortran became available. The other approach was to use a third party graphic library. The decision was based on "portability" which turned out to be the right one. The code developed was able to run on PC without any problem, anywhere. It was amazing because in those days, one must have compatible hardware, software, libraries for the mini-computer systems. (3). Since then I have been looking at the windows GUI. There were several approaches available, Visual Basic, Visual Basic + Fortran, Windows + Fortran, Windows in C, Windows in C++. (4). The straight Visual Basic approach was very user-friendly, but the only problem was the speed. It was slow in graphics and number crunching. (5).The mixed language programming of Visual Basic + Fortran didn't work out even though there was a book on that subject. This was back in early 90's, when Visual Basic was relatively new. (6). At that time, MSFortran was limited to DOS system. This was relaxed later and a larger program could be compiled on Windows environment without direct graphic support in Fortran. Once again, the Fortran code with direct graphic library approach was disrupted . (7). At that point, my conclusion was that I have to move over to the C language system in order to get access to the graphics and the window GUI. Without a large market, the Fortran language platform is going to be left alone without strong support. This proved to be true because MS finally decided to stop the Fortran support. MSFortran is still available under different name through another company. (8). The move from DOS based Fortran to window GUI based C is not simple becuase I had to learn C and window programming. The window GUI part is much harder than C. It took me several years , on-and -off, to learn the window GUI programming. (9). Finally, C++ arrived. Suddenly the move from DOS Fortran to windows stopped again. I had to learn C++, OOP and something called MFC (which I didn't understand when I started reading C++). (10). Now I am reading many, many books on C++. And I think OOP is fairly straightfordward for anyone who has written large scale Fortran codes. In Fortran, you package the operation in subroutines, on the other hand, the operation and the data are packaged in class in C++. This OOP approach is much easier to understand. (11). The most difficult part is the use of the memory address of a variable , that is the so-called pointer. For those who work in the post office, this should be very easy to understand, because they deal with the address all the time. They are not allowed to open the mail to see what is inside. I think the advantage of using the pointer is the efficiency. This avoids creating extra copy of the variable when send through the function argument. You are dealing with the home address or the social security number, or the passport number, instead of dealing with the person directly. (12). This has not solved my problem yet because I need to know how to deal with 3D graphics directly, using DirectX and OpenGL. As I dig deeper into this field using C++ concept, it becomes clear that C++ is the only natural language to combind the objects and the related procedures together, this is especially true when dealing with 3-D graphic elements. (13). VC++ is not as easy to learn as Visual Basic. But now here comes the C++Builder for Borland C++. Based on my son's suggestion, this is as easy as Visual Basic. It is also the same thing used in Delphi. So, there is another route to replace the DOS Fortran, that is C++Builder. (14). Well, the world is becoming very complicated now, instead of simple Fortran, I now have to face : C, C++, window GUI in C, window GUI in C++, MFC (class library for VC++), VC++, C++Builder, OWL. (15). I used to work on my car with carburator in old days. But now, I can't touch my car and I can't work on it. It has a computer in it now. And it is more reliable. The car just start each time I turn on the switch. That was not possible with my old car. I think, even if the world is becoming more complicated, we still have to move on because it gets better that way. ( when I saw the words "several hundred thousands copies sold" on a C++ book cover, I knew that I was behind.) Give yourself at least three years to make the transition.

Re: Comparison between C/C++ and Fortran?
 

(1). My son recently mention the C++Builder for Borland C++ to me because he said that the GUI is the same as the one used in Borland's Delphi and it is very user-friendly to program. So, I am looking into it right now. (2). My son has used Delphi in his program a couple years ago, and he said that it was very fast. (3). So, the question is " Can I write everything in Delphi to replace Fortran?" Naturally, it should include GUI, 3-D graphics, and number crunching. In other word, can I program in Pascal instead of Fortran? What do you think? ( I guess I need to learn Pascal also. But , that's no problem.)

Re: Comparison between C/C++ and Fortran?
 

I have been using C++ for seven years which is why I am disappointed by it. However, I would not claim to have really mastered any of the three alternative implementations of "C++" I use fairly regularly.

You commented on struggling with pointers but did you ask yourself why you should bother? Almost no other programming language I am aware of burdens the programmer with this sort of nonsense (not even Fortran). C++ has inherited this problem (along with many others) by choosing to maintain compatability with the "high level assembler" C.

You listed a lot of packages you feel you need to master in order to use C++ and seem to recognise this as being somehow wrong but accept it. Why? I guess this may be because you have chosen to work in the closed Windows environment rather than a more open environment like unix. As a rare Windows user, it seems to be no problem if you can work fully within a single package and there are some excellent packages (hence my question about why the Pascal/Fortran split). If you wish to use an OOP approach and a single environment why not use smalltalk? Or one of the OOP Pascal languages?

I have never seen the jumble of features that is C++ described as a natural language before. It can certainly have a go at almost anything and in a variety of ways but the cost in terms of reliability, length of code, required knowledge and above all discipline on the part of the programmer is much too high in my opinion. A natural language would surely restrict the user to the implemented approach (i.e. functional, generic, algorithmic, modular, OOP or whatever).

Re: Comparison between C/C++ and Fortran?
 

(1). We do need this kind of stimulating conversation. (2). As for the pointer, it really took me a while to understand it. It is probably easier to call it the social security number of a person. It is hard, because you have to think in parallel. There are two ways to reach a person. (3). I think there are many reasons why I have decided to take the window GUI approach. And the mixed-language approach is at most the intermediate solution for me. (4). So, the problem is I set the goal first, that is the package must be able to run on windows environment. ( naturally, it is aiming at PC environment.) From this goal, I tried to find out how to achieve it. (5). The conclusion is, if you take three weeks on Visual Basic, you can write a CFD code in windows including graphics. But it is too slow for 3-D problems. (6). If it can be done in Delphi, then it should be much faster than Visual Basic. I know it can handle the windows and the graphics. But I don't know whether it can handle the number crunching part easily. (7). So, the next level is the windows + C++, I think it can be done either in VC++, VC++ and MFC, or Borland C++Builder. (8). Well, if one is taking the non-windows approach as a goal, then it is a different story. (9). I think the concept of JAVA is ideal for me. It got ride of the pointer and at the same time it has almost everything in it,including the graphics. But the speed is a problem. (10). Well, I think, I have been looking at CFD program from the users' point of view. As for the research, the old F77 is good enough for number crunching. By the way, you can't see your mesh with F77 though, and that was my main concern.

Re: Comparison between C/C++ and Fortran?
 

I have been looking for some 'modern' language to replace fortran in engineering calculations for nearly 30 years. They all have come up short for one reason or another. The problem of run time allocation of higher dimensional arrays was the main irritation. Of course, as Andy so passionately states, many ways to work around this problem in C or C++. My problem is I am lazy and just want to to the fun stuff. Java also does run allocation of arrays and it looks fun to work with; especially using Borlands Java builder(Delphi=C++Builder=Java Builder). But, as with Visual Basic, the resulting code is slow with its JIT compiler. With Delphi 4 the first OOPS for the lazy person arrived. If I were starting over with my 3D flow code I would write it entirely in object Pascal. $92 for a compiler including graphics, bebugging, GUI, and run time allocatable arrays ain't bad. Porting the fortran as dlls is straightforward and so far works pretty well.

By the way the run time allocation of arrays fortran 90 extension used by Watcom has proven compatible with Laheys 32 bit compiler as well as its fortran 90 compiler. Also the extensions by both Lahey and Watcom move easily into the Absoft fortran 90 comiler. It really has not been a problem for me to move between these various compilers. I did port the code to both a linux(PC) and to a unix platform(SGI) and used the default f77 compiler. This change required that I comment out 2 allocation statements and add parameter statements for the dimensions in the usual way. The change took 15 minutes for my 3D Navier Stokes code. I really have not had a lot of trouble moving from one computer and/or system to another. My advantage is probably that I have written all of my code with this kind of portability in mind.

Re: Comparison between C/C++ and Fortran?
 

(1).Do you always have to write the Fortran portion as DLL in the Delphi (or C++)? Is it possible to write everything in Delphi (Pascal)? I know Pascal can handle the graphics, windows GUI, can we also use it to replace the Fortran portion? (2). In Visual Basic, writing a code with windows GUI , graphics, and number crunching in one single code to replace the Fortran is no problem. This is because Basic language is almost identical to Fortran language. I am not familiar with Pascal language. So, the question is: Can we write code in Pascal to replace the Fortran? Is it possible? Are there limitations?

Re: Comparison between C/C++ and Fortran?
 

Larry,

I have been thinking about all this stuff for a couple of months now and I haven't come to any conclusion yet. Right now I am programming with the Lahey fortran 90 and as you said the export the number crunching package i.e the dlls to a nice user interface generated by delphi works very well. BUT... as soon as your flow conditions change i.e different size of arrays you are running into trouble don't you? or is there a nice way around using dynamic arrays AND common blocks or that kind of things? This probabbly the reason why i still like the good ole HP fortran.

but I will be happy for any recommendation.

cheers

thomi

Re: Comparison between C/C++ and Fortran?
 

(1). I have come to the conclusion that straight C++ (which includes C) is the right way to go. (2). In this way, one can put together the code with windows GUI (using VC++ or C++-Builder), graphics, number crunching and OOP. (3). It is the trend, the market and the support. (4). AS for the memory management, I think, it depends on the purpose of the program, whether it should be dynamic or static.

Re: Comparison between C/C++ and Fortran?
 

I am curious. Unlike Fortran 77, Fortran 90 supports variable array allocation so why is there a problem changing the grid dimensions when driving a Fortran 90 solver from a Delphi front end?

I would recommend sticking with whatever language you know unless there is a sound reason to change. But...

ADA 95 is possibly the best standard language for numerical analysis but the commercial compilers are often expensive. It has similarities with the non-standard "OOP Pascal" languages like Delphi, Modula-2, Modula-3, etc... There is a freely availiable version based on the gnu-cc backend but I am not sure it has many Windows widgets (but I may well be wrong). Companies like Aonix supply full development environments presumably with masses of Windows widgets but may be expensive ($92 dollars is pretty unlikely).

Re: Comparison between C/C++ and Fortran?
 

Andy,

yes of course you are right that in fortran 90 there exist a couple of new features like allocatables, pointers etc to use dynamic arrays. the problem is that programing becomes a much bigger effort and I am pretty sure that this slows down the computation. (sorry guys..thats just a guess, so please feel free to prove me wrong). anyway, like john said we have spent so much time on worrying about number crunching efficiency and in the meantime the computer industry doubles the speed of the hardware components. so why worry..? have a nice day

thomi

Re: Comparison between C/C++ and Fortran?
 

(1). I am just guessing that dynamic arrays ( which will expand and shrink as needed by the program in execution) must be very important for large un-structured mesh programs. (2). I am currently running serveral versions of a program on different workstations in different mesh sizes. (3) There is no simple solution to the first problem, that is you have to use a version of the code compiled on that machine because of differences in hardware and compiler. (4). For the second problem, that is using versions of code with different mesh sizes, I think it can be handled well by using the dynamic arrays. In this way, you don't have to compile and keep several versions of code with different mesh sizes. And, I think, it will improve productivity as well. At the same time, we don't have to worry about the problem of whether the compiled code will run on a particular workstation or not.(because of the installed RAM memory) (5). So, I think, dynamic array is useful in this case.

Re: Comparison between C/C++ and Fortran?
 

Hi, Computational efficiency is still main concern for CFD users dealing with large scale industrial furnaces. For example, computation of 12 dependent variables at 200 000 nodes requires at least 10 000 iterations with 9 min /iteration using a powerfull PC. People in industry desire to get the result as soon as possible but without spending more money for computers

Multigrid, multiblock or angular multiblock method are developed as a remedy for computational economy.

Nuray

Re: Comparison between C/C++ and Fortran?
 

(1). Multi-grid is one way to improve the convergence of iterative methods. (2). Actually, there are many ways to obtained faster convergence. It depends largely on the problem you are trying to solve. And I think, it is a very good research field by itself. (3). So, I think, it is worthwhile to look into it when the problem is well-established and you also have the time to do some research. (4). In industries, time is money. To write a program quickly and easily, I would use the simplest method, like point S.O.R. or line method. Then you just let the computer to do its job for you. If it takes more than one day, then make sure that you do save the output file to disk from time to time. If it takes more than a week, then it is necessary to install UPS to avoid power outage. (5). Based on my experience, we are limited by the computer RAM memory. One Giga bytes of RAM is about the upper limit for high end workstation in the office. So, the computer time is not the most serious problem ( limitation). (6). The next problem is the network problem. If your workstation is in a network, it is likely that you will run into the network problem once a couple of week. Also, in some area, the power outage is a routine problem. (7). Once you have solved these problems, and if the project and the time allows, then one can start looking into the improved methods of getting faster convergence. (8). If you happens to be using a commercial code, and you have to turn off the multi-grid option and reduce the over-relaxation factors to a small number in order to get it running, then, there is not much you can do about it. (9). I can only say that it is a good research field to improve convergence, and the solutions are problem dependent. You really need to know your problem inside and out before you can do anything about it. (10). This is the main reason why a general CFD code is not ideal for fast design applications. It is not designed to obtain a fast solution for a specific problem. But if you are writing your code for your problem, then , as I siad before, there are many ways you can try to improve the convergence rate. In this area, I think, you are right, only if you have access to the code and have the time to write the code.

Now is year 2011!

Sorry to bring this topic up again after 10 years! But I do hope to see more people could share their insights on the (parallel) efficiency issue, I mean which one is faster.
Has anything changed during these ten years?

For parallel CPU processing I think C++ is as fast as Fortran today.

If you are wiling to consider GPU processing, CUDA-C is way faster than any of the Fortran implementations.

Today it is not a question about language, but about what compiler and libraries you can use to do your computation.

Do