Hi,

I ask myself if there is a interest for a joint development of a public CFD? The idea might be, to develop something under a common project wich is simular to GNU software development projects.

Is there a chance to agree on a general starting point / code platform (eg. programm languages, discritisation, numerics, physical models and ...)

Heinz Wilkening

I think the minimal requirements would be fortran 90 or C++, finite volume, unstructured code, collocated variables, segregated pressure-based algorithm

Why not finite elements? In general, I'm somewhat sceptical about public domain CFD code. Too many options, too many models, too many methods, etc. But first of all, I don't see why it should be done.

Hi,

I do not agree with the minimum requirements you mentioned. I agree that we have to agree on the programming language to be used, but here you even can mix. The data structure is important and therefor also to know wether the code should be structured or unstructured.

Numerics is optional and should be selected by the user by various options in the code depending on the application. E.g. solvers for compressible or incompressible flows are different.

Ciao Heinz

A very interesting idea indeed. I know what you are trying to do something, but I don't know exactly what you are trying to do with this "public CFD Code development". There are several possibilities1). the development process is open to the public, any one can join the development work. (2). this is a code development and the final code will be available to the public. (3). the CFD code developed will be in the public domain, free of charge. I think, regardless of the interpretation of the title posted, you are talking about some kind of the organized activities. So, to be successful, an organization with clearly stated goal must be created first. Next, resources also must be located in order to carried out the tasks which are yet to be identified. (4). I would say, the idea has been around for sometimes within academic institutions, where professors, students work on some research projects for years within a CFD framework. The results normally published in public journals and the codes are also available in general.

Heinz,

I like the idea. Let me give you my two cents. I believe the code should be of a finite element formulation. There are many free finite volume codes out there (Or relatively free, you pay $50 for the book and get the code. This beats paying at least $10,000 for the code, if you are industry.) I don't want to get into an arguement here, but I think much higher order numerics are possible with finite elements. Hence, LES simulation would be much more of a reality. I think F90 or F95 should be used, preferablly 95. If you are going to make a code, make it with the most current standard. C, is standardized, but after doing some scientific programing in it, I think the 'new' Fortrans are easier to program in. I should not that ther is no offical C++ standard yet. Writing in standard fortran (95) would make it portable to all computers. Now, let's take pre and post processing. I wouldn't build any of these. For preprocessing, I would try to rely on the grid generators as much as possible. I looks like there are many grid generators available. I would then rely on an easy notation to set up the rest of the problem. (Just like editing the actual flags in a 'case' file.) Post processing,same thing. There are many free post processing packages out there, like Visual 3, etc. The industrial codes are reasonable, too. Well, you can see what I am getting at, concentrate on the solvers, but the input and output in a standard data format, and rely on the computer scientist to build a GUI. As long as the code is heavily commmented and structured so anybody could easily make changes, I am all for it. If you can organize it, sign me up.

I am interested. My suggestion is Java even though I know aerospace engineers are more comfortable with Fortran or C. Its just that everything is possible with this language + the fact that it is the language of the internet makes it more attractive.

If you have the time, perhaps you could look at peoples' backgrounds and organize some sort of a committee to overlook the progress of the project. I think this is an excellent idea. It's actually about time someone started something along these lines.

You just need to make sure that people who sign up are up for the challenge.

Keep us informed.

I am willing to write radiation part of a CFD code in Fortran 90. Discrete transfer, discrete ordinates, finite volume methods can be used.

Actually, application of CFD codes takes too much CPU times. I think it is better to write the CFD code as a parallel code rather than a serial one.

That is great idea.

As we know, CFD is growing area because it excepted between Science and industry. The more need for CFD, the more applications, the more efficient code is needed. I meant, we need to use the most efficient language for number crunching, Since the CFD is mainly number crunching. One time I was reading comparison between Fortran 77, Fortunate 90, C, and C++. FROTANT 90 is the most efficient languages for number crunching that is the time consuming. C++ is the most efficient language for objected oriented programming. Therefore, we most probably use FROTRAN 90 to do number crunching and C++ for other activities. Off course we can link between them, during the compilation.

Interim of what methods (finite Volume, Finite Element, or Finite difference) to use. AS we know, generating grid is the most headache process. So we need to make a code that minimize the headache for grid generation. So my suggestion is to use Finite difference with Cartesian grids since it is easier to generate.

After all, Not many people familiar with CFD, So we have to make it as friendly as Possible.

YOU CAN SIGNME IN FOR THIS COD. I am looking forward for to share in doing such things. Let all of us think of it seriously.

Seems I'm the only one sceptic about the whole project. All discuss the implementation details, but first of all I would like to make it clear, why a new, huge (as long as you are going to put everything in) code should be developed. Who will use it? Probably, not industry. Students? Often they are asked to develop a small, simple code, but from scratch, for educational reasons, in order to understand the methods and technology. There are many people who are ready to develop, but is there anybody who can say: "Yes! I want a public domain CFD code, because ...."

Regards. Gassan

I thought there is already such development. NPARC and KIVA forum are two examples.

> I thought there is already such development. NPARC and KIVA forum are two examples.

Then why there should be another one? But anyway, is there anybody who needs public CFD code?

actually all current incompressible algorithms can and have been extended to simulate compressible flow at all speed, with little extra-computational cost if we simulate incompressible flow

I still thing FV is a better choice than FE, coding is easier, conservation is assured, high-resolution schemes are widely available, and more in the community can contribute, concerning post processing, I think HDF (developed by nasa) formatis quite adequate, its libraries in the public domain

what would be nice in a well documented and readable public domain code, is that it would help expand the CFD community and enable us to tackle more complex problems in group and thus share experience in areas, such as solidification, radiation, solid-liquid interaction.

how can we contact these forums and get the codes

A few comments, on the topic of public CFD codes, but first let me present myself.

I'm a colleague of Heinz Wilkening, who first floated the idea of a public-domain or "open source" CFD developement. Since there is some interest in this, maybe it's time to be more specific:

We started this thread because we have developed a code, REACFLOW, and we are looking at ways to maintain and extend the project. The code is not yet open source, but if there is sufficient (at least some) interest we will try to persuade management to release it.

In the following I will try to explain:

1. Why open source? 2. What have we got? 3. What is it possible to do?

1. Why open source? -------------------

The basic arguments are two: price and flexibility.

By itself, of course, the price (0 euros per user) cannot be beat. For some people the price is of minor importance compared to that of manpower, but in many cases the price of commercial CFD software is absolutely prohibitive. A good example is universities. Here budgets are often tight and slave^H^H^H^H^Hstudent labour is plentiful. A university will often think nothing of buying a high-end PC, maybe install Linux on it, and give it to a student for thesis work, but they will *not* shell out $50k for software. In fact, for $50k they could build themselves a 16 (maybe 32) node Beowulf cluster and have their own supercomputer, but they will have nothing to run on it.

With the price (0) comes the availability (\infty). Open source is only a download away, which compares favourably with getting a purchase order through the company bureaucracy (at our place, we're talking *months*, your mileage may vary).

Flexibility: The fact that you have the source code and have contact to people who know their way around it can be surprisingly valuable, because:

- you can modify the code anywhere you like to try out new concepts or just to tweak, whereas commercial codes only have limited "tweakability". If the open-source code is still maintained, you can often get excellent help finding your way through the code. - you can (within limits, of course) port the code to your preferred architecture/OS. I've seen commercial software (a grid generator) that was available for M$-Windows, HP-UX and AIX. Too bad we're running Linux and DEC-Unix. - turnaround time for bug fixes can be orders of magnitude faster than for commercial codes. A week ago I ported a grid generator to DEC-Unix. It took two iterations with the author to iron out the bugs in less than 48 hours.

I could mention things like quality, too, though this varies a lot for open source. The Linux machine I'm writing this on has been up 188 days now and hasn't crashed since 1996 (IIRC). But of course a CFD code is not likely ever to get 10^7 users, so will be less tested.

2. What have we got? ---------------------

What we (hope to be able to) offer the world is REACFLOW. The salient features are:

- 2D (cartesian and axisymmetric) and 3D geometries

- Unstructured grids, based on triangles (2D) or tetrahedra (3D)

- Finite-volume solvers for multicomponent compressible gas flows (Roe's solver and a flux-vector splitting method). In 2D implicit and explicit timestepping is available, in 3D only explicit.

- A finite-volume solver in 2D (cartesian) for incompressible flows.

- Solvers for diffusive processes and turbulence (so far only the k-epsilon model)

- A finite-rate chemistry module (no turbulence coupling).

- A very simple turbulent combustion model.

- A system for dynamic grid adaptation, inserting extra grid points where needed and taking them away again when the need has passed.

- Graphics for 2D and (nearly finished) 3D. Uses the QT and Mesa libraries.

- The 3D solver has been paralellized for non-adaptive grids.

The old 2D code is mainly in FORTRAN with some C, the new 3D code is entirely in C++. At the moment it is known to run on Linux and DEC Unix, though porting to other Unices should be easy.

3. What is it possible to do?

Since tastes and opinions vary, I'm sure I will be roundly attacked for the above choices, of which some are due to history, and some are more recent decisions. However, I think it's better to wait for the attacks before explaining. Instead, I would like to say a bit about what can be done with this code.

The only thing that is really essential to the code is the unstructured geometry. If somebody wants a structured grid code, REACFLOW is pretty useless.

Otherwise, various solvers could be introduced into the code. At present we have concentrated on finite-volume solvers, but there shouldn't be any reason to rule out finite-element methods. Likewise, a number of different turbulence models could be included.

Our own wishlist of things are (more or less in order of priority):

- A low-mach number solver for compressible flows.

- A better turbulent combustion model. Presumed PDF and flamelet models are among the contenders.

- Finishing the parallelization, extending it to non-static grids. This is being worked on.

- Radiation modelling

- Better turbulence models, maybe LES. Wall laws for turbulence.

- Two-phase flows (?)

- Investigating ENO schemes on unstructured grids

- Moving walls, conducting walls

Now if anybody has read this far, I would like to conclude by asking for comments, suggestions, criticism (constructive) but first and foremost whether this is at all interesting.

Thomas Huld Thomas.Huld@jrc.it

Since the code has been developed and named, also the wishlist has been determined, I don't think there is much left to be done. Since it is copy righted, it is up to the author to determine what to do with his code. I normally think that the most important part of CFD is the person not the code. On the cfd-online, I can talk to other persons directly, but for a code, there is not much I can do, except to download it, read it, decode it...not really a fun thing to do.

Hi,

there where a few points which came up during the discussion which I want to add some comment to.

The most essential question is why do such an open project? If your are interessed in research it is very difficult to develop something new if you have to start from the very beginning because CFD has developed so far and your time is limited. Often you have to write a hole code, before you are able to prove that your invention is right. Or you implement your ideas into a exciting peace of software. This is often very basic stuff. Then you write a publication and a lot of your work will be lost because there is no joint development.

By a joint project we are able to profit all, because new developers will profit form the work done before. Also more users means better testing of models and coding. Examples which already excits will make it much easier for beginners to start. This means you will get the freedom to work on what you are realy interested in.

For example the interests of NURAY KAYAKOL in radiation modeling and of Mamdud Hossain in non premixed flames would perfectly match.

An open code will also give you the opportunity to work together with different science communities, eg computer science faluty for software manegment, visulization or parallelization. Somebody working in this filds often just is looking for a testcode to implement his ideas into. We have made this experience in the past, and got some support by such a procedure.

Where to start from? This is by sure the most diffiucult question, and if there are already such a project, we just can stop here. I do not know other public domain CFD-Codes in detail. Our own developed code, as described by Thomas Huld, is just an option, and I must admid that we will need permission to give the source away for such a project from our bosses first, if there is an interest. Nether the less interest will help us with our argumentation.

To emplain a little more. We came up which this idea, because we reached a point in our code development where it will become more and difficult to make progress with the restricted manpower we have. Working together should help us all.

In all cases the "final" CFD code should never become commercial and always be free available for everybody in the world.

Thanks for your attention.

Ciao Heinz

I am interested in this concept. I currently work as a CFD developer and I am willing to participate in this effort. Many issues have been addressed already. I would like to suggest a few things from my personal experience.

1. I suggest using C/C++ for the development effort. Having ported many numerical codes to different platforms I have found that these languages have been the easiest.

2. It seems that a good starting point for the solver should be an unstructured (completely) incompressible solver based on the SIMPLE algorithm. This is a fairly standard implementation and will lay the data structures for extensions yet yeild a usefull tool.

Lets see what happens,

Jeff