Hi CFDers,

Could you explain the merits and demerits of Object-Oriented Programming for CFD codes?

Most of the CFD codes are written in structured programming style. But recently there appear CFD codes based on OOP. I heard that it is possible to code Object-Oriented programs with Fortran77. And I know that C++ is not fully Object-Oriented language, it just has the capabilities for OOP.

I usually program numerical codes in Structured type. If it is good to invest time and effort for OOP based CFD code, I want to try. But before that, I really want to hear your opnions.

Thanks in advance.

There is some literature about an OOP approch to CFD on

http://monet.me.ic.ac.uk

Look for the papers from Henry Weller about FOAM.

Hi,

I do have some experience in writing a CFD code in C++. To my oppinion it is very well possible to write an efficient numerical code in C++. However, you should be aware of some pitfalls. Check out the . In particular Todd Veldhuizen's article on <a href=http://extreme.indiana.edu/~tveldhui/papers/techniques/>Techniques for Scientific C++ is a good introduction to efficient numerical techniques.

Oliver

(1). In oop, you first define a class (user-defined type) to include the data, the function which operates on the data. Once you have the class defined, you can create an object from it (just a copy of it, similar to a copy of integer or floating point variable) and use it . (2). For example, you can create a class which includes name (this is data member) and print function (this is member function of the class) and call it class np. Now class np has the name and print function in it, say { name; print(name)} (my simplified notation). (3). To use it, you define an object from it (just a copy) as np kim. You can also initialize the name with your name as Jongtae_kim. Once this is done, anytime you like to print your name, just write: kim.print This is possible because the object has the name in it and also a print function also. (4). Since you can define a new class in anyway you want, there is no standard way to write cfd code in oop. (5). In Java you will have to write everything in oop, in C++ you don't have to use any oop because it is c + oop. You can write code in c, non-oop C++, or oop C++, or mix of above. (5). The nice thing of using this is kim.print will always print your name. While if you use name="Jongtae kim", ......, print(name), there is no guarantee that it will print your name,because the name can be changed to someone's name in this approach. In oop approach, the name is not available to the outside function, thus will remain safe. (6). To use oop or not, it is hard to say, because the programmer must first fully understand the oop first.

Hi,

I don't think you can write oop code using f77; or atleast it will be very cumbersome. F90 has some features which allow easy use of some programming concepts like data-hiding (classes), encapsulation, modularity etc. I am told that the template capabilities in C++ are almost discouraged. So F90 does allow some nice concepts to be used.

Currently, I try to write "modular" programs with some data-hiding and encapsulation ideas using F90 which I think make the code a little bit better in terms of reuse. I have never programmed in C++, only read books on general ideas (Stroustrup; The C++ programming language).

chidu

(1). I am not familiar with oop in f77 or f90. So, I can't say whether it is a good way to do oop there. (2). In C++, since you don't have to do everything in oop (as compare with Java), the extent of the oop is really up to the programmer. (3). But the basic principle is very simple, you can define a new user-defined type by combining the data and the function in the class, and use it through object. (4). How to do the oop? It can be quite involved, if you push it to the limit, or try to create a large scale program. So, the question is: Is there a need to write the program with class and object? If there is a need to do so, how do you define a class? what data and what functions should be included? Well, that is up to the programmer, I guess. (5). It is like saying that do I need to define a new type of integers which are greater than 60 and smaller than 100 ? It would be nice to do so in grading the exam. In this way, the grade will be between 60 and 100. I think, the usefulness of such class depends on the application program.

I don't think so about writting oop code using f77. Fortran Power Station or F90 has facility to get OOP. I think OOP in F90 is not easy as well as in the Visual Basic or Delphi. I think we must writting it in the Visual Basic or Visual C++. In this software, the OOP is available completely. we can writting OOP for CFD by combination of Visual Basic ans F90, or Visual C++ and F90, or Visual Basic, F90, and Visual C++. I have ever programmed in Visual Basic and F90 and it is easy to do OOP. Thanks

If you are writing a typical numerical CFD program where the requirement for efficiency is high, you understand and have control over all the code and the task of writing/developing the code is small (as opposed to evaluating the algorithms) then the benefits of OOP do not really kick in. The OOP approach wins big for large projects with many programmers. Even here you will often find the numerically intensive bits are still written in Fortran 77.

Perhaps the biggest problem with most OOP languages (in fact most computer languages) is that they are simply not targetted at the needs of scientific computing. Perhaps the easiest test is to look at the support for arrays. Languages that "box" their objects have made a design decision that has many benefits but is at the expense of numerical support at the level of Fortran 77. Implementing multi-dimensional arrays as pointers to pointers to ... is also an indication of the priorities of the language designers. If you choose to write in C++ one of the first things you have to do is put together a sensible array class. This has nothing to do with specifying the CFD task to be solved it is just a low level fixing up of an inappropriate language. You will almost certainly have to spend a lot of time programming other implementation issues that also have nothing to do with specifying the CFD task to be solved. C/C++ is a relatively low level language sitting somewhere between an assembler and a proper programming language (a "systems" language?).

Are there OOP languages that provide significantly better support for CFD than C++? Two freely available examples are ADA95 (http://www.adahome.com) and Sather (http://www.icsi.berkeley.edu/~sather/). Would I use them to write my CFD programs? No. However, this has nothing to do with their abilities as languages and I certainly would consider them for teaching and learning.

To conclude. If your principle interest is CFD then OOP is unlikely to be of much relevance but if much of your interest is to do with programming then understanding OOP issues is probably a good thing. C++ is probably not a good vehicle for this initially although you may end up using it for other reasons.

There is a number of people working on nothing else, but efficient array classes for C++. The results are very promising. Just look at Blitz++ or MTL or many many others. If using OOP you can write generic algoritms. For instance a numerical integration of a discrete function in C++ could look like this:

struct Sin {
double operator()(double x) { return sin(x); };
};

int main() {
cout << integrate< Sin >(0,2*M_PI) << endl;
};

This code-snippet should print a zero on the screen, if the function has been properly written. For example this should do the job:

template < class FUNC >
double integrate(double x1, double x2, int n)
{
FUNC f;
double x, delta_x, sum;
int i;
delta_x = (x2-x1)/(n-1);
sum = 0.5*(f(x1)+f(x2));
for (i = 2, x = x1 + delta_x; i < n; i++, x += delta_x) sum += f(x);
return delta_x*sum;
};

The compiler should be able to highly optimize this. Actually for this particular case I have done some tests and there is absolutely NO performance loss, compared to a simple C routine doing the same job.

I hope people start to get some more confidence in C++ for numerics

Oliver

Now what do you mean by OOP? I would not describe generic programming as what is traditionally meant by OOPs (C++ barely supported it initially!), where is the inheritance?, etc... It is generic programming and even Fortran 77 has generic functions like min(), max() and particularly abs() (I am always being caught out in C/C++ by the wretched abs()!). However, I would strongly endorse your sentiment that generic programming and scientific programming are well suited. Unfortunately, generic programming in C++ suffers from the problem of having to use C++!

The results are still only promising? For how many years have these libraries been written? Despite all the benefits of reusable code? Why haven't we been using the numerical equivalent of STL for years? There are legions of computer scientists out there who all know C++ is the answer?

Please correct me if I am wrong but the author of Blitz++ has not being paying much attention to it recently. Having been forced to write most of an optimising compiler in developing Blitz++ he is now developing an optimising compiler framework. Combined with a programming language (rather than an implementation obsessed "system" language) this could be very useful particularly if the focus remains on numerical efficiency.

Not sure what the integrate example is supposed to be telling me? That C/C++ does not support first class functions like a proper programming language? and so you introduce this ugly construct to get round the deficiencies of the language?

Surely the speed comparison should be with Fortran 77 and not itself?

OK I am playing devil's advocate a bit (but only a bit!).

Well, I think one of the main ideas of OOP is to be able to define abstract interfaces. Another point of course is data encapsulation, which does not lead to performance problems at all. Coming back to the abstract interfaces, the traditional way in that example would be to create a common base class for functions and declare operator() as virtual. Thus you end up with what is called polymorphism. Using the construct I showed in the example you have pretty much the same, only the jump address is figured out during compile time. Compilers could also inline that function and perform all sorts of optimizations on it. I am not exactly sure, but if you talk about functions as parameters (first class functions), this is available in C and C++ by using function pointers, with the same problem as virtual methods (runtime jump resolution). The comparison was with C and not with itself. The only difference between C and F77 is the possibility of pointer aliasing in C, but that is another story I think... By the way, it is perfectly legal to build up an inheritance tree for functions in that example. For example a base class 'Series' could have coefficients anf then be inherited by 'Polynomial' or 'SinusSeries' or whatever. Crucial is to not make the operator() virtual, but use the template mechanism to achive polymorphism. Of course it is only an example. We use this for instance to define different fluxes for flow problems (Roe, AUSM, RoeTurkel, ...). All are derived from some a class CompressibleFlux, which is derived from ... and so on.

(1)."which is derived from... and so on." (2). I think this is the most difficult part in most oop oriented approach using class library. It is hard to learn, hard to understnad, because the users must fully understand the new environment. (3). What I am saying is, if it going to take the user (in this case, the programmer) a lot of time to get familiar with the new family of classes, then the code will be limited to the original programmers . Similar to the MFC library, in order to use it, one need to learn all of these new functions. (4). So, whether oop or C++ will be widely used in cfd depends on whether one can easily understand the code written in oop style by some other programmers using their class libraries. For internal use, then it does not matter how the code is written.

include(stdio) -- DEFINES PRINT(...) OBJECT
include(maths) -- DEFINES SIN(X) AND PI OBJECTS

def integrate( f, x1, x2, n )
delta = 0.5*(x2-x1)
sum = 0.5*(f(x1) + f(x2))
x = x1 + delta
do i = 2, n
sum = sum + f(x)
x = x + delta
end
return delta*sum
end

def main()
print( integrate( sin, 0.0, 2.0*pi, 10 ) )
end



The above piece of code is not in any particular language but a number of modern languages align with it in spirit. I am sure you will agree it is easier to understand (and more general) than the C++ version because it omits all the implementation guff. Rather than hammer away at the nastiness of C++ here is a link to a book on the subject of C++ problems:

http://www.elj.com/cppcv3/s5/

It is a bit old and I think some of the criticism are unfair but it gives a good indication of the breadth of the problems with C++. It also might persuade Jongtae Kim to consider a better language to learn OOP techniques.

This is pretty much the same as the template example. The point is the compiler has to inline the call to sin(x), otherwise it gets very slow. I don't know if C++ is a good language to learn OO-techniques. It is perfectly possible to write a C-style C++ program, without doing any OOP at all. For numerics, however, it offers many nice features which enable the use of OO-techniques in 'high performance parts' of a program.

How can we relate between C++ with IMSL routine. How can we call them as well as in F90?. In F90, we can use them easily, but I don't know how in C++.

Hmm. Not sure I am quite getting my point across. Last go I promise. What I am reacting to is not the use of C/C++ since this often cannot be avoided in the real world today. I am also not really reacting to the hacks employed to get C/C++ to work reasonable efficiently (so long as they are recognized as such and it is made clear just how long it takes to learn them - probably far longer than most people primarily interested in CFD can afford to spend). What I am mainly reacting to is the joy rather than irritation expressed by many in these hacks. It seems widespread and possibly stems from people being taught C/C++ first rather than a cleaner, higher level language much more suited to picking up concepts. 20 years ago Pascal was reasonably widely taught as a first language for pretty much this reason. Today?

Back to your example:




integrate( sin, 0.0, 2.0*pi, 10 )



We want to tell the optimiser to specialize code for the sin argument to gain efficiency in a critical part of our code. (Sidestepping the interesting issue of whether one even needs to the tell optimiser that. Probably yes today but, hopefully, no in the longer term with dynamic optimizers (ones that watch the code run and can optimise further the important parts). But if we have polluted our code with lots of implementation instructions then what?). We use the notation:




integrate( < sin >, 0.0, 2.0*pi, 10 )



C/C++ will not let me (this is clearly the easiest way for the programmer to indicate specialization so there is no chance C/C++ will support it!). It forces integrate to specialize code for every different function used even if most uses of integrate are not critical and we do not want the bloated code because we are going to run on a parallel machine. So we do the following:




integrate< sin >(0.0, 2.0*pi, 10)



Unfortunately, this does not work either in C/C++ because functions are not first class (not treated like variables) and the C/C++ pointer to function mechanism (?) is not up to the job. So we need to introduce the confusing hack of putting each function we want to use in it's own class and making that class behave as if it were a function. Writing extra code (confusing code for all but serious C/C++ developers), polluting the namespace with unnecessary names and generally weakening the link between the code and a clear expression of what the programmer wants to do.

Oliver, it was good to have engaged in debate around something more concrete than views. I wish you luck with your C/C++ project and if I have toned down the evangelization I will consider myself to have succeeded.

How does the Matlab to develope OOP ? I think, this software can also used. However, the source code can't convert to exe file like others.

You need to indicate to the compiler/linker that the Fortran routine does not have a mangled C++ name (code directive usually but possibly flag to linker).

Pass all arguments by reference.

Find out how strings are passed. Fortran routines will usually pass a pointer and a length. The lengths are usually appended at the end of the argument list but some compilers do it differently.

Link with the Fortran runtime libraries.

Take care with I/O. Some systems do not like mixed I/O so stick to either C/C++ or Fortran I/O to ease portability.

I may have forgotten something so look in the manual.

I have relatively little direct experience of matlab which is a commercial system. It is interpretted which is usually what you want when developing short scripts but can be incredibly slow if you leave your loops in the interpretting cycle. This is why there is no executable (binary code) the source code is executed directly. I had thought there was an option to generate binary code but could be wrong?

The language is aimed at scientific use and most users I have talked to find it straightforward to use for this purpose and my small experience would support that.

The OOP was grafted on later which is not good sign and was probably done for reasons of fashion (i.e. selling more copies of matlab!) rather than any practical need for OOP within the matlab system. The matlab language has been developed for writing short scripts for which the benefits of OOP methodology must be almost zero. Perhaps I am being too cynical. Comments from experienced matlab users?

I think, Matlab is a powerfull software for OOP. It is easy to convert or to combine with other software such as F90 and VBasic or V C++. We can build OOP like Delphi or VBasic. it is easy to build Graphic user interface (GUI).

So, I think F90 has already upagraded to Digital Visual Fortran, that may be easy to build user interface.