# C++ or Python for a development of CFD library

What would you say would be the advantages/disadvantages of two approaches to coding a general (finite volume, fem, dg) library for Computational Continuum Mechanics? This is how I see things right now, so please provide your own experiences and don't flame me for mine :) :

1) C++:

• generic programming, virtual functions, overloading, speed... : all the genreic + OOP tools available to build whatever you want

• low level libraries available mostly (no wide spread science&engineering library development such as the one for Python)

2) Python + wrappers for parallel computing (pyOpenCL and others)

• huge amount of supporting libs of various kinds

• code what you think: the implementation is done really fast

• slower execution time

If you wanted to code a framework that would support various methods, work with complex geometries and problems, what would you choose and why?

-
I'm not very familiar with pyOpenCL, but generally speaking Python will be much too slow for even moderate-sized problems in 2D or 3D, unless your computational "kernels" are implemented in a low-level language (Fortran, C, etc.) –  David Ketcheson Dec 20 '11 at 17:01

I would aim to get the best of both worlds and code the "user interface" (that is, the framework of functions that the user of your library will call to describe the geometry and other properties of the problem) in Python to get the quick turnaround time, then write the simulation run time in C++.

In fact, I would probably mock even the simulation run time up in Python first, then replace it by C++ code piece by piece. Eventually you could consider having your Python code generate C++ source, to be compiled and linked to your runtime online, so that the actual simulation doesn't need to call into Python at all - only return the results at the end. The nice thing about this setup is that it's inherently agile: you start with the quickest and easiest working solution, you'll find out quickly what works and doesn't work, and once you have something you like you can start speeding it up.

(This is how Maple's ODE/DAE solver works, except using Maple instead of Python. Full disclosure: I work for them.)

-
+1. One of the nice bits of Python is the ability to step away from "Pure Python" if needed. –  Fomite Dec 20 '11 at 23:20

You can also use Cython for your algorithms. It's essentially Python with added type information for some variables that need to be "fast". It translates Python code to C code, which can subsequently be compiled by your favorite C compiler. Careful adding of this type information can make your code up to 150 times faster than naive Python code.

-

I think there are more to this question. First and foremost a developer will typically prefer what he/her is familiar with unless significant advantages (e.g. in productivity, development time and tools). Personally, I give priority to being productive (time is usually the most scarce resource!) and this favors choices which are close to my experience base.

Perhaps also relevant to take into account are

3) Development time

• how much time is reserved for development
• when is results of the work to be delivered? and how?
• do a code already exist which can do the job? (uniqueness?)

4) Maintenance

• how many (people) resources are devoted to maintenance?
• how many people are to work on the code?
• Is the code to be released at some point? (criteria?)
• are the code going to rely on third-party libraries?

5) Licensing issue

• is the code for research?
• is the code for commercial applications?

6) Productivity and Fun factor (often overlooked!)

• Where can one be most productive?
• Where can one have the most fun developing?
• Any opportunities to be a part of a (social) network?
-

This depends whether your code can be written as:

some_library_specific_type grid;

for t=0 to T do
library_function_1(grid,...);
library_function_2(grid,...);
end


or rather must be written as something like this:

some_home_made_mixture_of_native_types grid;

for t=0 to T do
for all grid elements as g do
some_function(g,...);
library_function(g,...);
end
end


In the first case choose what you like most to code in; in the second case don't use any scripting language or prepare to suffer from execution time.

-