opinions on OpenFOAM
 

Hello forum, I'll soon be starting a long research project in CFD. (Assuming) I have the option of doing all my work using in-house FORTRAN code (that is not well maintained centrally) or using OpenFOAM, I wonder if anyone can recommend the latter choice? I have done some C++ programming before, but still have a good deal to learn on the linux OS side (scripts, networking, etc.) Is it worth it for me to try to swim against the current in my department and invest my efforts in OpenFOAM? What are the advantages?

Regards,

marco

Re: opinions on OpenFOAM
 

Hi Marco,

For my taste it is definitely worth the effort. Implementing new features you are interested in and benefiting from existing architecture, inluding everything from efficient parallelism to moving mesh and topological changes, together with a wealth of pre-implemented models and solvers will make your work much more fun.

I wouldn't particularly worry about the Linux side of things (this is easily mastered + you can use the Cygwin port of OpenFOAM, which is also available). Handling code organisation and reading C++ may be an issue but most people find it relatively straightforward.

The best advice I could give you is to find a friend :) in academia doing similar kind of work with OpenFOAM and trade experiences + learn together. This is the fastest way to become an expert.

I think it's fair to say that my opinion is biased because I wrote about a half of OpenFOAM myself - you may get a more detailed opinion from the OpenFOAM user forum.

Good luck,

Hrv

Re: opinions on OpenFOAM
 

Dear Hrvoje

But how is performance of OPENFOAM as you used OOP method its overhead leads to performance decay (my experience with OOP lib showes that their performance is about 3-10 times lower) than usuall programming).

Do you compare it with commersial package (e.g. FLUENT) from performance viewpoint.

Also has the parallel version AMG solver?

Re: opinions on OpenFOAM
 

Hi Mike,

There has been a number of tests of OpenFOAM relative to commercial solvers and I was never disappointed. I think it is fair to say that the idea of OOP libraries being slower that procedural programming is a myth supported by Fortran programmers (a dying breed). In fact, even a small search on the web will bring you to things like Pooma, Blitz++ etc. which are no slower (and sometimes faster) that the C equivalents. Without this, there would be no point in doing object orientation in the first place.

The best advice I could give you is to try it out yourself. OpenFOAM has a strong pedigree in Large Eddy Simulation, multi-phase flow, combustion and spray, free surface flows etc, all of which run massively parallel and perform very well. Typically, it is quite easy to match the speed of commercial solvers with OpenFOAM and as a benefit you also get lower memory usage, as each solver (for example incompressible LES) is separate, purpose-written and optimised and does not carry the luggage of "other models" that are not needed (not to mention that fact that a parallel 1000 CPU license for OpenFOAM "costs" exactly zero dollars).

Parallel AMG: yes, it's got it and it has beed there for years (I wrote it myself). By the way, the design of the library is such that you can quite easily write and add your own run-time selectable solver, whatever takes your fancy that day. :)

Hrv

Re: opinions on OpenFOAM
 

How is the support for compressible flow these days?

First of all - OpenFOAM looks great and after tesing it briefly (quite a while ago) I had a very good impression.

One thing, however, I am missing is high speed flow. Last year I tested a few of the compressible solvers on the forward facing step tutorial. None of them gave a result that was acceptable - they were either extremly dissipative or had massive over shoots at shock waves. We had a brief discussion on the OpenFOAM forum about that. Did the situation improve, or is a "classical" FV Roe like solver still preferable?

Don't misunderstand my comment please - OpenFOAM is good software!!

Re: opinions on OpenFOAM + Fort. Prog. dying breed
 

Hello Hrvoje,

I am an enthousiast supporter of OpenFOAM and I am really fascinated by the clever and tremendous job you have done.

However, are not you a bit severe with Fortran Programers?

Take a look on the DNS-S3D project in the US (Scidac Website). This is the most advanced and ambitious project dedicated to DNS, a field requiring efficient codes. It is in Fortran. As you are an expert (and not me), I am really interested in your opinion.

Sincerely.

Re: opinions on OpenFOAM
 

Actually, I agree with you: the support for compressible flows in OpenFOAM sucks (watch the forum go crazy) :)

The algorithms that are released are all pressure-based and (in my opinion) cannot compete with a commercial-strength density-based solver. This (together with the block matrix support and direct solver technology) is the biggest hole in OpenFOAM right now.

I've got a basic density-based solver which is reasonable, but:

- it is explicit

- it does not handle run-time selection of a gas law, flux limiter, gradient reconstruction and real gas properties

- it does not have the acceleration tools, e.g. FAS, geometric multigrid, point-implicit solvers

In short, it is useless but at least it shows there is no problem with putting all the necessary things into the code and making it efficient. I believe there is 6-9 months of work in order to do this properly: an ideal job for a PhD student if someone's got one to share. I am open for offers and quite ready to donate the current state + get involved as a joint supervisor or similar with the ideas on code design, block solvers, guidance on mesh coarsening structures and some old geometric multigrid code.

Any offers?

Hrv

Re: opinions on OpenFOAM + Fort. Prog. dying breed
 

Sorry, this is my personal bone - I am quite ready to apologise to all the people who wish to carry on using Fortran. Thye are quite welcome to do so, provided they don't try and force it on me.

Hrv

Re: opinions on OpenFOAM + Fort. Prog. dying breed
 

That was not the sense of my post.

I am really interested in your opinion as an expert. There are numerous discussions on this forum regarding the speed of Fortran compared to C and OOP C++.

The consortium on the S3D-DNS project uses Fortran as well.

OpenFOAM is in C++. Some other codes are like this.

My question is: because of the architecture of FOAM, you need C++. You put the emphasis on the modularity. If you had to put the emphasis on pure performance (like people doing the aforementioned DNS code), will you switch to Fortran or do you consider that you will start the same S3D DNS project code in C++ if you were in charge of?

Looking forward your answer.

Re: opinions on OpenFOAM + Fort. Prog. dying breed
 

Well, I cannot really do Fortran any more so this is really not an option. Let me try and reformulate your question: in a performance-critical code, would I use the procedural or object-oriented approach? (I think that's fair).

The answer critically depends on the project and the team. I'm personally quite happy that the required performance can be reached with object orientation and there are no issues with compilers. However, every programmer in the team must know what they are doing - for me that's the critical factor. There are also other factors, e.g. will I have access to the code after it's ready to work, how long the code should live for, what extensions are planned, who is responsible for the maintenance etc.

The real benefit of OO is code re-use and modularisation. Therefore, as long as you are interested in keeping your code for the future, object orientation should be the right choice.

Hrv

Re: opinions on OpenFOAM + Fort. Prog. dying breed
 

Dear Guillaume

I think your question is about selection between

1. C (C++) and FORTRAN based on performance veiwpoint 2. and also OOP style and procedural style

answer 1: the performance is completely function of programmers expertness and their information about state-of-the-art computer science knowledge. Roughly it can be said that simple fortran program has better performance than C, but by changing some swithing item (array bound control and ... there are several artilces about comparision) the performance of C can be increased but still lower than FOR, But give us possiblity of some option that they are not possible in FOR withouth interfacing with C. For example the mini-SSE-L1-BLAS library is portable C library for linear algebra that outperform all of the linear algebra kernels (ATLAS BLITZ++, ...) from my nowledge it use inline assembly code for increasing performance, also i think that adding other performance features such as register reusing cache blocking and rune time tilling increase its performance consibrably (note that ATLAS and BLITZ++ use these features).

answer 2: generally it can be said that OOP has overhead due to its hierarchical nature and usually its poor data locality (the data unit is usually biger). But it is easy to understand, development, taem work and further extension. Management of OOP project is severly simpler than others. But success (extension and performance) of OOP project is severly function of expertness of its developpers. For example design of object their functionablity are hard work nad is really an art. If such design be good loss of performance is small and can be compensated. In the other hand if design is poor the project encounter failor after some progress. So we loss some portion of performance due to simplicity of programming, extension and ... I think it is prefarable for scientist.

Also there are some cure: for example we design a inhouse translator for translating our OOP codes to low level high performance program after completenig each stage or for practical simulation.

Thanks!
 

Hrvoje, rt,

Thanks a lot for your comprehensive answer.

I have retained from both of you that:

- OOP is very good for code developers due to the architecture it allows

- Procedural is very good for code programmers (I name programmers scientists who need to do simulations in the most effective way. Let's consider they do not do that because they have limited skills in programming).

rt,

in which language do you translate your OOP code when you need to increase efficiency? Do you translate it into Fortran, machine language...? Do you recover the same performance as a code natively written in a procedural way?

Thanks a lot again.

Re: Thanks!
 

We traslate our OOP code to low level C code (not FORTRAN), But if you say that why C, some optimization is not possible in FORTRAN and probably our group is more friendly with C and also other features (pre and post proccessing and GUI) of code were written with C and so cupling is more easy.

Also the performance is prior predicted. Note that when an object is designed its translator based on our purpose (optimization level) is also designed. It increase time of initial programming (performed with expert programmer) but instead using OOP method for developper scientist (is not expert programmer and is CFD man or CFD student) decrease his programming errors and time of developing. In this manner the developper learn at first step suitable application of objects for his work. This takes short time and your student don't needs deep background in OOP and other programming features. So he sticks only to main purpose and don't miss lots of time due to debuging and ...

with Regard.

Re: Thanks!
 

Really clever! Thanks a lot.

I think I have to give the background of my questions.

I firstly used to work in C. I switched to Fortran when I started to work on DNS and LES, because the codes I was given and I had to pursue the development were in Fortran. It was claimed it was for efficiency. I can say I agreed at that time.

Since this time, I have been regularly in a survey to know whether it is time to come back to C/C++.

Thanks a lot again.

Best Wishes.