I was just wondering about the reason that brings to consider Fortran better than C/C++ for CFD. Can anyone help me? Matteo.

Personally I prefer C for CFD coding because (1) You can get a high-quality free compiler on pretty much any platform (2) it's portable and (3) if you know what you are doing, it's as fast as anything fortran can spit at you: C can do anything fortran does, but NOT vice-versa.

However, C takes a long time to master and is definitely not for anyone.

The basic question you should ask yourself is hence: are you (A) a scientist, (B) a computer programmer or (C) both? If you answer either (B) or (C) then leave Fortran behind you, code everything in C, and you'll never regret it.

good luck~

-bern

(1). Fortran is a very old language. So, it has always been used in solving engineering problems, including fluid dynamics problems. (2). Original hardware for CFD was the mainframe and super-computers. The original language was Fortran. (3). So, Fortran has been improved and optimized for number crunching in solving engineering problems. (4). C++ is a relatively new language, with powerful capability in object-oriented programming using classes and objects. C++ was developed based on C language, and the ANSI standard C++ was recently released a couple of years ago. (5). C++ is large and complex. And it requires careful programming skill for efficiency.(see Scott Meyers's book on effective C++, 50 specific ways to improve your programs and designs, Addison-Wesley) (6). Fortran is an old language designed to solve engineering problems, while C/C++ is a new general purpose language, with additional powerful object-oriented programming capabilities. For old programs, there is not much you can do. For new programs, it is up to you to choose.

You already seem to have concluded that Fortran is better than C/C++. Well, refer to the previous postings on the forum, subject was probably Fortran vs. C or something like that. I'd say that Fortran is certainly not better than C, whether they speak of High Performance Fortran or anything, it'd always remain the same.

Hi Bernard,

> leave Fortran behind you, code everything in C, and you'll
> never regret it.

Too right!! You're my hero! - I had to fight Fortran programmers for years and I have never seen anyone convert back.

(Just to add a bit of spice here) You can carry on the argument further -> leave all your C code behind, learn C++ (big investment) and you'll never regret it!

Hrv

A question:

1) Why not JAVA?

Comment:

As I understand it JAVA compilers (not translaters)have been developed. Some people (one day I hope to be introduced to this mythical group of commentators!) claim that JAVA programs, when compiled are as or even more powerful than their C++ counterparts.

Hmmm, this question has been asked before. usually the C/C++ programmers say C/C++ has all these great features that fortran doesn't have and that fortran carries a lot of baggage from previous versions. i'd say that fortran90 in its 'pure' form is as good as C. now i am a C programmer and if i was going to write a program from scratch it would be in C (i don't know C++) but i know enought f90 to modify a well written f90 code (i learned recently) i'd say that f90 is quite a good feature filled language. everything that i ever wanted to use in C is now available in f90. the main problem with f90 is that it holds on to the old crappy features of every version of fortran before it. also there's too much 'platform/compiler specific'ness about it. so standard code that compiles and runs on an sgi won't work properly on an rs6000 or pc etc. while with C if you stick to ANSI standard you're always safe. but i don't think that it is necessarily worth the effort to switch if you know either C/C++ or f90 (although i do think a programmer should know at least two common languages) if you write in fotran 77 (for example) i would strongly recommend learning either f90 or C. the problem is that the f77 programmer who learns f90 has a tendency to stick with some of the old practises he used for f77 and not truly program in pure f90 while if he swtched to C he has no option but to do everything 'properly'. so nowadays when people ask me should i learn C or f90 as a new programming language i say do either but make sure if you're learning f90 to avoid old carried over features and write free format (fixed sucks). if they are an old programmer in C and they ask me should i learn f90 i say do you work with others who use f90 because multilanguage programming can cause problems if so then learn f90 else stick with C and vice versa for C. if you know C++ of course you should never consider anything else except MATLAB

It's not merely a question of how powerful a language is, the execution time taken would be of consideration to all when running a CFD code, I guess. PERL is far more powerful than C/C++, but I believe that people wouldn't generally code in PERL because of the slow execution speed compared to C, and similarly in JAVA.

I agree with most of what you said, however, I don't think MATLAB should be used for anything except plotting results. I have a program that does 2D heat conduction in both FORTRAN and MATLAB. The FORTRAN code executes in a couple of seconds, the MATLAB code takes an hour.

People say you have to code differently in MATLAB, but I don't see it.

I can give you several arguable advantages of FORTRAN over C/C++.

1. It is has all of the capabilities that most people doing scientific and engineering applications need. In fact, it is customized for this (relatively small) application area. Other languages may have powerful additional features, but it is unclear how often they are actually needed for "nuts and bolts" scientific programming. Especially with C++, sometimes people have a tendency to use the modern features just because they're there, even though they're not necessarily a better solution, and often result in less-efficient and more-difficult-to-understand code.

2. I have found that classic FORTRAN is faster to debug. Maybe this is just because I am more proficient in FORTRAN, but I have experienced two problems with C/C++. First, in C/C++, miss one closing brace in a long program and you're in trouble; it can take forever to find. Second and more importantly, modern FORTRAN compilers will take you straight to the line that causes a run-time error, even allowing you to examine all of the variables on-the-spot. This includes floating point errors, domain errors, and going outside of allocated memory. The C/C++ compilers I have used seem less able to do this due, I believe, to the flexibilty they offer in terms of memory allocation.

3. Almost all legacy scientific code is written in FORTRAN, including most CFD code. While it is certainly possible to mix FORTRAN and C/C++ using modern compilers, it is nicer not to have to.

The difference between C and FORTRAN is not a huge deal IMHO. If you know one, you can pick up the other enough to do science applications programming in short order. Most people should probably learn C first, just because it is used so widely outside of science and engineering. As far as C++, while I am far from expert, the more I learn and work with it, the less impressed I am. The syntax is complicated and non-intuitive. While almost anyone can be an adequate C or FORTRAN programmer within a few months or a year, C++ takes far more time and ability to learn. According to those I have talked to, even expert C++ programmers have difficulty understanding long codes written by others, farmoreso than straight C or FORTRAN. As far as code reusability, so often touted as a C++ advantage, this seems to rarely happen.

In my current thinking, and I am willing to be convinced, if you do not absolutely need the advanced object-oriented features that C++ offers, you would be better off with straight C or FORTRAN.

that's not what i meant. MATLAB isn't for hardcore computing. it's really good for small stuff and developing algorithms etc. also it has really good subroutines and special purpose stuff that you wouldn't want to spend time writing. also the coding is very compact and intuitive. but since they have the new extension that converts MATLAB code into fortran or C programs you can do big programs in matlab debug them and then translate them into whichever and compile. in fact there's a guy at school here who does that. he's a PhD student and he write FEM codes and optimisers in Matlab and then converts them to C. trust me if you've ever written a FEM code in another langauge then use matlab you'd probably never go back

I cannot agree with some of your viewpoints. I am developing 3D CFD codes of FORTRAN, C and C++ altogether using visual studio on Windows NT. I hate to debug FORTRAN code, since I cannot watch the values of many variables (such as those in common blocks) while I am debugging. C and C++ has no such problems. C codes are easier to maintain compared with FORTRAN codes, and C++ codes are the easiest to maintain. I have to use FORTRAN codes just because my CG-solver and many core functions were written by FORTRAN codes long time ago. It's time consuming to convert it to C codes. I tried some parts with success, but the converted C codes are ugly to look, so I still have to modify them manually. If I write a CFD code in scatch, I will definitely use C++.

However, for all of us developing CFD codes, all of these language has the problem of memory management. If you want to allocate and release some large temporary arrays frequently, you will encounter severe problems. (You know what I mean. If you want to develop efficient algorithm, you have to do like that.) FORTRAN tool cannot even allows you to allocate and release temporary arrays, so in many CFD codes, this is done manually. That's painful, and is difficult to understand the code!

I don't know if anybody ever used DIFFPACK package. That package was written by C++. I hate that package because it didn't care about the above problem. You know, some derived classes are really large, if you define them as local variables, similar thing appears. DIFFPACK can never be used in practical engineering problems. It only can be used by some academic researchers.

i think you have some good points here. i find that C++ has too much stuff, to me classes and this private/public thing can make the code seem overly bulky. i guess if you're a database programmer it might help. C/C++ lend themselves too much to tricks. ie you can do something very,very cleverly but noone else would understand unless you commented it real well. i like C and prefer it to fortran (although i know fortran only enough to read and modify other peoples programs) although the dynamic allocation in fortran is clearly superior (it's easier to follow and there are no pesky asterisks and pointer signs) and passing variables particularly pointers and arrays is also better. Mr. bao's comment about debugging is probably limited strictly to people who use PC based compilers (which are a waste of money anyway) the error messages on fortran and c compilers on a workstation are about the same to me although it is true that a misplaced colon, comma or close brace can mess up your whole day

i take issue with some of your comments. your first one on debugging is probably limited to those who use Visual Studio. i think microsoft deliberately made it easier to write C code rather than fortran code to get people onto pc's. i think most programmers write code on unix where i find that the debugging / error identification is about the same. (sgi's are great at this by the way). i am mostly a C programmer and some fortran and you have to admit that a missing semicolon or close brace can ruin your whole day. i do prefer C though but f90 is very good.

your comment that fortran does not allow dynamic allocation is not true. f90 allows you to do it (and it is very nice) and you can always do it implicitly via subroutines. i 've also been told (and i read it in the help on visual studio) that overuse of structures and classes etc can slow down your code and should be avoided.

i agree wholeheartedly with the last comment though. i've found that many libraries are not worth using. the subroutines are difficult to understand, bulky and not portable. for example don't try using numerical recipes for C because they have a subroutine that converts the C array numbering (starting at 0) to fortran default style (starting at 1) which totally messes everything up. oh that's another good thing about fortran i recently discovered you can start your indices anywhere not just from one, saves a lot on index algebra which can be a pain. also those colons really save on do loops. anyhow C is really cool F90 is just cool and everything else is a waste of this CFDers time

Hi, Mr. Bradford,

We all know, that PC's memory can be expanded to more than 1Gb, and with Pentium III/800MHz, it is not inferior to any ordinary workstations.

Now that you mention PC power, I have made an interesting observation: I am currently using a Pentium II 400 MHz PC as well as a Pentium III 600 MHz PC (same amount of RAM). The same problem executes only 10% faster on the Pentium III.

I have spoken to some people-in-the-know and they believe it has to do NOT with the floating point spec of the Intel chip but rather the integer spec; manipulating the indices of the large arrays used for CFD calculations can apparently be costly.

Does anybody have another explenation?

Thats interesting.

I have a question.

If I were to write something like the following in FORTRAN

DO I=1,N DX(I)=X(I+1)-X(I) END DO

and I wanted to write it using MATLAB, is there an efficient way to write it using MATLAB array arithmetic without using a loop. I know that direct translation of the above to a MATLAB loop in a function file is hugely inefficient.

To get Matlab to run fast you should use as much matrix operations as possible. Your example could be done with a one-line matrix operation looking something like this:

DX = X(2:N) - X(1:N-1)

Where DX and X are matrices. I haven't used Matlab a lot lately so the syntax might be slightly wrong, but the principle works. This will be many times faster than the loop solution.

I think it depends on what kinds of problems you are running. If your problem is so large that swap space has to be used as visual memory, then PIII/600 is almost the same as PII/400. Sometimes you should check if your RAM is large enough to hold all the data and codes and stacks. I am not sure if PC is inferior to workstation in float point calculation, maybe some expert familiar with computer logic circuit and structure can give us some explanations.

I am also using PII/400 (in my office with NT) and PIII/500 (in my home with 98). With the same 3D problem, PIII/500 is obviously much quicker than PII/400.