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.

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.

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.

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.

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?

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

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

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

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

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.

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

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

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

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

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

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

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

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

[lakeat]

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?

[DoHander]

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