Re: The computer language for CFD
 

Axel, I couldn't agree more! VB is certainly the easiest way to quickly write functional CFD code. Why waste days on C++ when you could whip the same code out in a few hours in VB?

John

Re: Continuous Fortran Debugging
 

And what advantages has switching to Java given you?

- GUI. Create GUI in FORTRAN - nightmare (I am not talking here about C++). A lot of old extremly good codes which were developed by tens of Ph.D. by decades now are dead due to poor GUI or no GUI at all. I am speaking mainly about Russia but according to publications and forums I see the same situation everythere. In JAVA to create GUI - no problem (I mean with SWING). OK, it is possible to write UI in one language and solver in another language, but in this case you always have problems. Not principal ones but they exist. In JAVA I can write as GUI as solver in one language.

- Work with database. Usually one nozzle calculation took from 1 hour to 1 week (I am speaking about non-equilibrium problems with a number of components, reactions, etc.). To store initial data and results we used flat files (as everyone). To my suprise even commercial CFD packages currently use flat files to store thermodynamic database. All this is result of problems of invoking databases from FORTRAN. Today these problems are in process of solution by implemetation of CGNS format - but it is only begining. JAVA has no problems with work with databases.

- Cross-platformity - no need to explain.

- Web-Oriented. I have some program. I would like to publish it as commercial or shareware or free product. What I have to do with FORTRAN program ? Nothing.

With JAVA program I can allow to start it from web by JavaWebStart for example.

- Object-oriented. It gives practically nothing to making easier writing the solver - right! But usually solver is 5-10 % of code. Largest part - initial data, preprocessing, postprocessing. Here JAVA is OK.

- Pre/Postprocessing. Here we have Java3D product which allow quiqly create geometrical models, 3D pictures ans so on.

I think - enough. From other side - speed of JAVA (better to say - slowness of JAVA) is not acceptable. I agree. I can only remind situation 20 (or probably more)years ago - before FORTRAN H compiler. CFD codes were written in FORTRAN, but due to bad quality of G compiler the most time-taking parts of codes were written in Assembler. After few years H compiler appiared and all these Assembler parts went to garbage - FORTRAN began to give the same speed as manual assembler code. I think that with JAVA we have the same situation - currently JAVA is slow (excpecially with arrays which everyone CFD-developer needs!). But it is today...

And one more - probably it is hard to understand me, but, please, don't think that I am trying to say that FORTRAN is bad. No, I like it (it is as first love:)). But currently, for CFD JAVA seems to be better.

Re: Continuous Fortran Debugging
 

For GUI I use SWING. For preprocessing - JAVA3D and my classes like Point, Line, Curve, Volume, ... Inside solver - a lot od classes(objects) like Substance, Reaction, Mixture, Volume, Kinetics,...

Re: The computer language for CFD
 

Thanks for your support, John! - This topic turned into quite a heated debate... :)

Axel

Re: The computer language for CFD
 

I seem to be completely missing something here. What is Visual Basic? (I had been assuming it was something like the BASIC I learnt in the 70s but with buttons and menus instead of circles and rectangles.) What makes it significantly faster for writing CFD code than C?

Re: The computer language for CFD
 

Andy,

The original version of BASIC from the 70's was a purely interpreted language, which means the code had to be translated into machine code for each and every instruction, even if the instructions were repeated in a loop. Very slow! Assembly code was generally more than 100 times faster.

Microsoft QuickBasic was one of the first Basic languages that used a compiler and was very similar to Fortran in programming style and speed. However, arrays were limited to 64K due to its reliance on DOS when it came to memory addressing.

For Windows programmers, Microsoft then came out with Visual Basic which was originally an interpreted pseudo-code, significantly slower than the truly compiled languages. The first three versions were 16-bit only, but due to a Windows workaround one could address arrays larger than 64K. A simple bubble sort was about 50 times faster when coded in assembly (I created these benchmarks for my own use).

VB4 was the first 32-bit version. It still relied on interpreted pseudo-code, but its memory addressing was much more efficient, and it also allowed for multi-tasking under Windows 95 and later, which meant you could run CFD code but still use your computer for something else. My assembly optimized bubble sort routine ran about 15 times faster compared to the interpreted VB code under VB4.

VB5 was the first version that incorporated the option to compile to native code, which is a 'truly' compiled code and thus much faster. VB6 added options for coprocessor speed optimization. Under VB6 my assembly coded bubble sort routine was only about 1% faster.

The problem of compiling efficiently comes into play for 3-D arrays of variable size or higher dimensional arrays, which are often encountered in CFD. 3 spatial locations with 5 flow properties at each location creates a 4-D array, Q(i,j,k,l).

The Intel family of processors can only efficiently address 2-D arrays of variable size or 3-D arrays of fixed size due to their limited set of instructions when it comes to memory addressing. My shareware MicroTunnel is an example of a 3-D array of fixed size (2-D flow field with 600x800 cells), which is why it was worth writing it in assembly, because VB compiles array calculations of fixed and variable size the same way. Also, I don't know of any high level language that allows you to use all eight floating point registers of the FPU simultaneously. Keeping intermediate results on the coprocessor instead of transferring it to RAM is another great time saving.

In essence, there is no efficient way to program a 4-D array addressing routine in assembly on an Intel processor, and depending on what language you use, you get a slightly different machine code, and slightly different run times. For simpler problems, such as the 1-D bubble sort, or 2-D array calculations of variable size, it makes no difference what language you use on an Intel machine. There is only one way to do it efficiently using the memory addressing instructions of the Intel processor.

I hope this clears up some of the common misconceptions about VB.

Axel

Re: The computer language for CFD
 

Thanks for the answer but this still doesn't answer the question why it is faster to write CFD code in BASIC rather than C. I was quite happy to accept that BASIC executes at the same speed as C on the MS platform. (My growing suspicion is that BASIC simply has more libraries that you are familiar with and this helps you with the glue code rather than the "proper" CFD code but please correct me if I am wrong.)

Re: Continuous Fortran Debugging
 

Amen Brother (engineer)!

Re: F90
 

Dear Axel,

I know about the package since 1997 when the name of the program was "AeroShape-3D" and it was originally developed by "Computational Aerodynamics Systems Co." in Moscow - Russia.

From talking to the developers and looking at some examples I was quite impressed. Especially the automatic remeshing for moving mesh transient problems was something, which I really wanted for some of my problems.

This developement was discontinued and the code was rewritten as a Solidworksplugin (Floworks) and later as EDF.-Lab.

I already tested Floworks when it came out. Since there are only a hand full of models in the code it is a nice tool for very simple stuff but completly useless for the kind of cfd-problems I usually have to solve.

And please dont force me to tell my experiences with Nika to the readers of this forum.

Have you ever read their homepage. It is 100percent makreting bla bla ("since we call our inlet an opening we do not cfd but engineering fluid dynamics").

The other problem is that they dont tell you what they are doing in the code. They simply tell you, that you have to belive them that they and the results are right.

PS: I'm still waiting for some results from a completely within solidworks prepared test case which someone at Nika promised me to run. This was about 3 years ago.

Re: The computer language for CFD
 

Very interesting discussion. Let me make a few comments.

1. Style. It seems to me that the biggest difference between the languages is their traditional style, and not anything else such as features or syntax. For example, C++ tends to have much larger numbers of smaller subroutines than FORTRAN. There is no reason other than programming philosophy why this is so. Which is better depends on what you're doing. If you're programming a user interface, where there's no predictable flow to the logic, the user may select this option or that, then the C++ tradition makes more sense. However, if things progress in a logical series of predictable steps, with only occasional branches, then the FORTRAN tradition makes more sense. In other words, I find FORTRAN programmers tend to "tell a story" with subroutines taking the role of chapters in a book, breaking things down into logical and cohesive units, not too large and not too small. By contrast, it can be much more difficult to read a story out of the C++ tradition, it comes across more as a collection of random paragraphs. If early FORTRAN suffered from "spaghetti" code, with everything in one or a few large routines, and lots of "go to" statements, it learned from its mistake - it's rare to see anyone write this way today. I'm not sure but what the C++ tradition is not an equal and opposite mistake, with many little units masking the logic and flow to a similar extent as "spaghetti" FORTRAN.

2. Reusability. C++, for example, is traditionally sold on its easy reusability. However, people will rarely reuse code unless they can understand it or, at least, clearly understand how to use it. Thus the most essential aspect of reusability is documentation, including comments in the source code. Unfortunately, adequate commenting and documentation is rarely done in any language. The next most important thing is the choice of the names of variables, modules, subroutines, etc. Because FORTRAN used to limit the length of variable names, there is a tradition in FORTRAN of using cryptically-short variable names (e.g., DXTRN). C++ tends to be much better in this regard, although again this is only traditional and not inherent to the language. On the other hand, much of the C++-specific synatx is so unelegant and cryptic as to be difficult to interpet, except for those deeply immersed in the language.

3. Development speed. Visual Basic is specifically intended as a "fast development" environment, and is far superior to traditional alternatives in this regard. Many people today are programming in even higher level languages such as MATLAB, although probably not for something as complex as CFD. It's a tradeoff. If you're writing a code for a specific analysis, and the code may only be used a few times, it doesn't make sense to increase your development time by using a traditional language just to reduce your runtime. And, in many cases, there is no rutime penalty with Visual Basic or the other "fast development" alternatives. C++, to my understanding, typically has the longest development time of any major language.

4. Flexibility. The modern programming languages, e.g. C++, seem to me to offer so much flexibility that they allow, or even encourage, extremely poor programming practices. Earlier languages tend to encourage or force users to choose the simplest and most direct solution. For example, I have seen C++ codes where no variables were explicitly passed, everything was essentially a global variable. This could never be done in FORTRAN, where you are forced to at least define passed variables in common blocks, and even this practice was increasingly frowned on as the language developed. When trying to understand an unfamiliar program, one of the surest courses is to track the variables. This is much more difficult when it is unclear which subroutines modify which variables. I have never known a code development project using a traditional language (FORTRAN, C, BASIC, etc.) to fail based solely on the difficulties of the language. However, I have known of complete disasters with attempts at "modern" programming practices.

5. Portability. I believe one poster questioned whether portability is really of great concern. I'm frankly flabergasted. In general, the simpler and older the language, the more portable it is. But even FORTRAN 77 rarely compiles smoothly from one compiler to another, much less from one platform to another. Anything involving GUIs and system calls is almost by definition not portable. JAVA is a reasonable attempt to overcome this longstanding problem.

Perhaps the best codes I've seen have the "meat and potatoes" of the numerical routines written in a traditional "simple" language, such as F77, F90, or C, with perhaps limited judicous use of more "modern" features such as objects. By contrast the GUI was written in C++, JAVA, or some other completely modern language, which was, after all, developed specifically for this purpose. The features and concepts that facilite GUIs and systems calls are not necessarily appropriate to numerical routines, and vice versa.

This is only my perspective. I'd be glad to learn more. I've found it's extremely difficult to get reliable clear information on the advantages and disadvantages of different languages. Certainly there was a big migration to C++ in the 1990's but it's hard for me to tell if this had a sound technical basis, or was simply the the trend of the day, where people were afraid to appear "old fashioned." Like many other trends of the 1990's, there appears to have been at least some backlash against the movement towards C++ for engineering algorithms. But I may be ill informed.

Bert Laney

Re: The computer language for CFD
 

frankly, i feel that Java has NO applications for High Performance Computing.....its simply beyond its scope .

The best approach to problem solving is to make ur solver in Fortran/C/C++ and make the GUI in some sort of cross platform library like Qt

That way u take the load off urself and have time to comcentrate on ur algos rather than on the plethora of platforms :)

-mayank