A friend of mine recently made me aware of this group and I wanted to mention an ongoing project in France dedicated to simulation for the geothermal industry. It is a CFD Fortran code. I wrote many of the routines and/or adapted many of them from Numerical Recipes.
I don’t know if my expertise could be of any help here, but as union makes strength, I am happy to join, share my experience if you have questions and keep you posted of this adventure. If you are interested to know more please visit : www.cofluco.com
Best regards,
Do you intend to distribute the code? The Numerical Recipes license prohibits this. Code adapted from Numerical Recipes would be a gray area. If you mention specific NR routines you are using, replacements that are in the public domain, and which may be of higher quality, could be suggested.
@Laurent let us know which routines / functionality you need. We would like to eventually have all common numerical algorithms either in stdlib or in packages that you can easily install using fpm, all under permissive (MIT/BSD) licenses so that you can easily use it in internal or commercial production codes. If you are interested, you can help us develop and maintain the routines/algorithms that you need.
I feel there needs to be a sticky thread discussing which routines to include in stdlib or not. If not, I would like to see the cubic spline interpolation routines from NR in stdlib.
People really need to be careful about using anything from Numerical Recipes. The license for all versions (Fortran, C++, etc) is very restrictive. Plus some of the code appears to be ripped off from the Forsythe, Moler book. Another issue is some of the code and algorithms are just plain wrong. See the following compilation Van Snyder put together several years ago of comments from various reviewers about why you should not use Numerical Recipes
Thanks for your swift and constructive answers.
I do not intend to distribute the code- at least at the moment. @Beliavsky and other commentators (being here a new user I cannot address more than two persons), thank you for making me aware of the possible issues with NumRec. There are 5 subroutines in the code adapted from NumRec. I use two of them frequently as they allow significant speed up of the calculation: the successive overrelaxation with Chebyshev acceleration and the corresponding routine for calculation of the radius of Jacobi. They are used to solve the Poisson equation on pressure.
And yes they are routines from the 1992 NumRec or previous editions.
Until now what I ve liked with NumRec is that it is relatively simple, so that I understand what I am doing. But in a second step it is perhaps better to rely on other tools. @certik tell me how/if I can help you to develop routines. I am curious to know that. Because you notice, I use 30 years old NumRec.
The best way you can help is to send us Pull Requests with the implementation and then we can collectively improve it.
I agree that I used to like Numerical Recipes, I like that they explain how the algorithm works and give you a code that you can use. Unfortunately as others said, the license pretty much prohibits to use the code. So I also avoid Numerical Recipes for this reason. But I would like to have similar tutorials and Fortran code (that we develop ourselves), MIT licensed, on the fortran-lang site. That would be awesome!
FWIW, I do not see any need for NR for writing a new CFD software. But it certainly depends on the kinds of algorithms, grids etc one considers. Alas, we do not even learned if it will be finite differences, finite element, finite volumes or even lattice Boltzmann and what kind of grids it is going to use.
There are so many modern algorithms for these linear system. I am afraid you are looking into an obsolete resource. For a good modern performance consider using some algebraic multigrid or more advanced Krylov methods such as GMRES or BiCGStab.
The code is based on finite differences. Time integration is explicit.
Actually I implemented the biconjugate gradient method of NumRec 1992 (it is not mentionned to
be a stabilized version version of the method back then). It ran slower that the overralaxation.
I will definitely try more recent versions of the method.
Remember all Newton-Krylov schemes need a pre-conditioner to get performance close to any of the Guass-Sediel or SOR varients. Look at Yousef Saad’s Sparskit implementations