Has anyone used Diff Pack? Has anyone used Diff Pack to implement a CFD code? If so, what were your experiences? Would you recommend this package as the basis for a new CFD code? Why so or why not?

I used a time ago, it's pretty good, but very dificult to understand. If you are new with cfd or doesn' t have enough time it's not a got option

I looked at diffpack a few years ago when it was freely available (in terms of cost) but with a strict license which enabled one to look at it but not much more. It is now fully commercial. My observations may not apply to the current version. It was one of the contributory factors in my stopping using C++ for numerical work.

(1) Along with the Los Alamos codes it is (was now it has gone commercial) one of the few openly available example of what a well written and reasonably complete C++ CFD code looks like.

(2) The abstraction approach did not use templates. This tends to clean-up the abstraction but hurt execution efficiency. A few years ago templates in C++ were essentially unusable because of practical problems (I suspect they still are for all but the believers).

(3) The mapping from the concrete statements which change state within DiffPack to the abstract presented to the user appeared (to me) to work for simple problems (e.g. Poisson equation in box) but to start to break down for more complex problems. This showed up as a requirement to reinvoke procedures for reasons to do with the concrete internal workings of the procedure rather than requirements to do with manipulating the exported abstraction. This requires the user to know a lot about what is going on behind the scenes rather than just to assemble a list of "atomic" abstractions. If the objective is to write a straightforward CFD code and get on with something else all my experience suggests working at a relatively simple level of abstraction with vectors and matrices wins out in terms of (a) efficient execution (b) easy to modify code by people other than the author. Packages like diffpack often offer a fast start to a project but after that...

I ought to emphasize that I am not criticizing diffpack itself but the approach of using packages like diffpack. I have little direct experience and, as far as I can judge based on the publicly available release from 3 or 4 years ago, it looks like a good example of its kind.

Thanks for your response Andy (and Joel too in another thread). On one hand, Diffpack looks like a way to get up and running quickly as it supplies a lot of infrastructure (some mesh generation capabilities, basic classes for fields and finite elements, equation solvers, display facilities, etc.), but on the other hand the code looks rather formidable. Like most codes, the finite element support is for Lagrange elements and I wonder how much it will directly support my needs.

I have developed some new divergence-free finite elements for incompressible flow. These are of the Hermite type, with stream function (or vector potential) and solenoidal field (curl) components as degrees of freedom. These are truly pointwise solenoidal on the elements and the element boundaries. Thus all complexities associated with penalties or projections are eliminated resulting in a simple (but nonlinear) method with no concern about the LBB-compatible element pairs as in mixed methods. I attended a FEM conference last Spring in Austin, TX where many of the speakers had to waste time telling how they "solved" the incompressibility problem. These elements eliminate all that.

A downside of the new elements is that mesh generation must be modified to take the stream function/vector potential degrees of freedom into account. Also the field components are necessarily fully coupled. This means extra coding, but the coding need be done only once.

I suppose I am a little concerned about how much support to expect from the Diffpack classes when venturing off the beaten track. On the other hand, starting from scratch and having to develop the necessary infrastructure is not very attractive either. The propriatory nature of Diffpack is also of concern as everything would have to be rewritten later to get a freely distributable code, but this is weighed against possibly getting something running quickly.

Also, what Los Alamos CFD codes written in C++ are you refering to, Andy?

Jonas Holdeman - Knoxville, Tennessee

To answer you last question first. I was referring to Overture based on the A++/P++ infrastructure. This is was an active project in the early 90s in the C3(?) group (i.e. not the well known T3 group of MAC, ICE, ALE, KIVA, etc... fame). It was a more computing orientated group. The person I corresponded with is no longer there nor is his home directory. At the time of correspondence (about 3-4 years ago) the infrastructure project had not been active as a full project for a while. All my links in the README files seem to be dead and I cannot find the project by searching LANL pages? Stop press: I have found the project and some of the people at LLNL - it seems to have moved in 1998?

http://www.llnl.gov/casc/Overture/

and it looks currently active.

Most (all?) of the major research labs in the States have substantial projects of this kind which are completely open to Americans (by law I believe?) which has always struck me as very sound policy. If the taxpayer's funded it then the taxpayer's should be able to benefit if they want (it also looks as if a complete project can move from one lab to another as well). This means you can choose one that looks comfortable for your purposes, spend a modest amount of time picking up how the infrastructure works and then concentrate on your elements. At least that is the theory. How well it works in real life is for others to judge. Anyone?

For us non-Americans things are different. Although I have always found the Amercian groups more than open and willing to cooperate with genuine researchers outside America (usually subject to one's instituion signing some agreements) one loses the right to effectively do what you want locally with the "full code" (most of which, of course, is not yours). There are one or two European projects on a smaller scale that have grown around particular codes. UG, FEAT and MOUSE spring to mind (all German) but there are others. Anyone?.

A simple alternative adopted by many academics who do not have to support any "non-expert" users is to use fully independent input generation, solver and display programs and to link them with simple text/binary files. The latter is easily solved by programs like gmv/pV3 for 3D views and gnuplot/xmgr for graphs. The solver you already have. The problem is usually input generation for reasonably complex. There are one or two partial solutions such as GID but I am not aware of anything comfortable. Anyone?