Sorry but I dont use Windows at all.

Your solution might be ok in the windows world but I dont know any one who is using windows for cfd calculations.

"Your solution might be ok in the windows world but I dont know any one who is using windows for cfd calculations."

I do. Glad to meet you!

Sorry! I didn't read it closely.

I'm sure having a bad day today. No, Absoft is not "free" - I missed the word entirely. (Didn't know Intel's was either ...). And Leahey is the name I couldn't remember.

"All programs ultimately run in assembly or machine language, so your '20 year old' argument is a lame one!" Yes, but compiler do that for me.

"Yes, I am not moron," I didn't say that!!!!!

"I don't care for Unix, because 94% of the people who visit my site run a Windows platform according to my web statistics. For such a small market (6%), why should I bother to write a UNIX version of my shareware." Yes, you are wright but this 6% of UNIX machines are calcualting just now (many of them CFD calculation) and 99.9% of your 94%Windoze machines are using only for surfing. Why????

"In your opinion, what is not scientific about VB" Clearly (moustly) with any language today you can do what you want. But VB is NOT scientific language. Why dont you have VB compiler for CRAY or SGI or ...

Best Regards,

pp

Only INTEL f90/95 compiler win/linux and C/C++ is for free.

Best Regards,

Pero

Finally,

Where are you guys til now!!!!!!!!!

Best UNIX wishes, pp

Actually, quite a number of people run CFD on Windows these days. For example the commercial package EFD.Lab, www.efdlab.com, which I endorsed on this site the other day, is EXCLUSIVELY written for Windows. It even interfaces with other MS applications such as Excel for some pre- and post-processing tasks.

EFD.Lab is currently used by over 500 companies worldwide. The company who developed the package in 1999 is headquartered in Frankfurt, Germany. Since you are German, why don't you give them a call to arrange for a free web demo. You might be surprised to find out that running CFD on a Windows platform is not such an odd concept.

Is EFD.lab writen in VB?

It must be very good if it need MS Exceel for pre end post procesing. Is it also MSPowerPoint and MSWord required for pre-postprocesing?

There are a range of Fortran compilers available for PCs:

http://www.polyhedron.com/compare.html

(note the scatter on Windows compared with Linux - there seems to be something odd with the Windows results?).

The Intel compiler is freely available but unsupported for Linux - I assume you have to pay on Windows.

The two leading compilers would seem to be Intel (they make the chip) and DEC (bought by Compaq and given a Microsoft name "Visual Fortran" - which seems a curious marketing move to me given how poor the genuine Microsoft product used to be before it was abandoned).

"Is EFD.lab writen in VB?"

I don't know, but I can find out.

"It must be very good if it need MS Exceel for pre end post procesing. Is it also MSPowerPoint and MSWord required for pre-postprocesing?"

EFD.Lab does not NEED any of the MS apps for pre- and post-processing. However, you can export your results (graphs, tables, etc.) directly into an Excel or Word document with a click of a button. This greatly streamlines your report writing.

Regarding the pre-processing, you can create design tables in Excel that change your solid model depending on the control parameters you set. This is very efficient if you want to analyze slightly different versions of your design.

I am currently running EFD.Lab on my Windows XP machine, and it is the most GUI driven package I have seen. I would say anyone can use it after a day of training. Certainly the most intuitive CFD package I have ever encountered.

Day before yesterday best language for CFD was FORTRAN. Yesterday best languages were Visual FORTRAN or C++. Today best language is JAVA.

OK, I expect a lot of voices "It is so slow!" ,"No libraries!","Practically nobody in CFD world is using it!", etc.

Yes - slow, yes - no libraries to go, yes - very limited number of people are currently using JAVA for CFD/scientific software development.

BUT the reality is that all leading CFD vendors (Fluent, CFD RC, STAR, etxc.) have to support multiple platforms and spend a lot of money and efforts to make versions for 10-20 platforms and dialects of UNIX.

Only JAVA is free from such nightmare.

CFD is object-oriented area - all components (point, grid, geometry, mixture, substance, kinetic model, etc.) - they are objects with properties and methods. Proper CFD software SHOULD use it. That means that CFD developer has to write object-oriented code. That it is easy to do in JAVA.

Dear Peter,

everything you say is corect, especially that the Java is preaty slow.

The problem is GUI on diferent platforms not solver. You take solver code and compile them but there is a problem with GUI. Very good practice is to develope your GUI with cros platform developers. With thar you can create GUI in one shot for all platforms.

BR,

PP

The majority of people involved in development of CFD techniques have an engineering background. They are not computer science people eager to jump up and learn every new and exotic language that comes out. I'll freely admit I fall into that category myself. You spend enough time in code development without having to rewrite routines every other year in "the latest and greatest language." Surely another one will come along after Java.

At the bigger vendors, the people doing the actual algorithm development are focused on the physics of what they are coding (they are engineers), and the languages of choice are the languages most people were trained in, C and Fortran. These big vendors have a separate CS group that specifically deals with interfacing and platform requirement issues.

There are enough niche markets to choose the route you want to follow. If that route is Fortran, C, Visual Basic, Java, or whatever else, there's enough compiler support and upgrades for each path so that ultimately the "correct" choice is.....

....whatever you know best and work in most efficiently!

I spend 15 years with development of non-equlibrium CFD softawe in FORTRAN and can state that change FORTRAN to JAVA is easier than change MacCormack scheme to TVD one...

The main disadvantage of FORTRAN is no real support of objects. For a long years the number of articles about advantages of object-oriented programming were treated as having nothing common with scientific computation. But reality is that good CFD program should be object-oriented.

"EFD.Lab does not NEED any of the MS apps for pre- and post-processing. However, you can export your results (graphs, tables, etc.) directly into an Excel or Word document with a click of a button. This greatly streamlines your report writing." Yes, from 15days to 14.99999999 days. Maybe you can also drag and drop something.

"Regarding the pre-processing, you can create design tables in Excel that change your solid model depending on the control parameters you set." You can do that in any ASCII procesor (like Notepad).

"This is very efficient if you want to analyze slightly different versions of your design." If you want to do some optimisation then you need again some language to code optimisation rutine which will guide this parameter changing.

"I am currently running EFD.Lab on my Windows XP machine, and it is the most GUI driven package I have seen." Come on Alex, what is a main part of good CFD package: GUI or turbulence models, numerical schemes, discretization etc.

And what advantages has switching to Java given you? Is the solver faster? Was it easier to develop a GUI for users? What tangible impacts does being a code being "object-oriented" have on solver performance? I'm genuinely curious.

One can write modular, easy to maintain routines in just about any language. Again, I believe this debate all comes down to one of personal preference and there is no "correct answer".

"Come on Alex, what is a main part of good CFD package: GUI or turbulence models, numerical schemes, discretization etc."

EFD.Lab has all of the above, at least for my purposes. I would be happy to arrange a free web demo for you. If you want to criticize the package, I think you should take a look at it first before you dismiss it.

Java is a cut down C++ without an abstraction mechanism suitable for efficient numerical computation (nor does it support efficient arrays). Back in the 70s when Fortran 77 got a few generic functions and ADA was designed it was clear that polymorphic types and generic functions would allow abstraction without impacting numerical efficiency (what C++ confusingly calls templates). The same is true today. Until Java sorts this out no sensible author of numerical software is going to consider Java.

The time taken to "port" Fortran numerical code from one platform to another is usually zero seconds. For C/C++ (a platform dependent language by design) it is going to take longer but the time is usually irrelevant for numerical code which typically has minimal dependencies outside ANSI/POSIX.

The input processing and output processing is somewhat different and a few years ago a few companies did use/promote Java but they do not seem to be around now. Perhaps there is a connection? Do you have any evidence that porting CFD software to a variety of platforms requires significant resources? I suspect Windows might be a bit of a problem given Microsoft's business model but I would assume a CFD company could handle this without too much of a problem.

I would contest that CFD is a problem that maps well to an object-orientated model (unlike, say, a window system which does). CFD typically has a small set of conceptual types and a small structured set of operations. The baggage associated with object-orientation would appear to be unnecessary (although it does tend to make the inexperienced programmer think about interfaces more than they would using, say, C or Fortran 77).

However, I would suggest that what can work well conceptually for CFD are functional languages but, unfortunately, their inefficiency on current designs of hardware would seems to prevent their adoption for serious number crunching.

I too am curious what it is about java objects that you find useful for CFD beyond, say, the module/type system found in Fortran 90/95?