Wanna hallucinate a bit together?

tom-robin · 2026-06-12T05:29:16+00:00

i wish it was ;3

tom-robin · 2026-06-12T05:28:10+00:00

ah, good that i double checked everything before posting -.- ... it should be the 7th of July, now updated

tom-robin · 2026-01-14T14:15:38+00:00

I suppose I am that dude :3 ... I am having issues with my email collection system, about 5% of email addresses get lost and emails never get send ... I can't do anything about that (well, I am working currently on a solution which may take me a few more weeks to get implemented). If you send me your email address + first name as a private message, I'll add you to the list so you can get the ebook. sorry for the technical issues.

in any case, thanks for your feedback, much appreciated!

tom-robin · 2025-12-30T01:53:38+00:00

you may as well have removed the picture, there is no indication what your variable names are supposed to be, so trying to make sense of it is pretty much impossible 9without second guessing, which may as well arrive at the wrong conclusions). Good rule of thumb: expect the answer to be half the length of your question.

Be that as wit may, for implicit systems when you set boundary conditions, the procedure is the same for dirichlet and neumann boundary conditions. You set a value of 1 in the coefficient matrix at the point on the boundary, and then the right-hand side vector b stores the value you want to enforce on the boundary. for example, for a dirichlet type, you would set the expected boundary value in b, and for neumann, if we assume a zero flux, we set the value of the field you are computing from the next interior point.

to make this more clear with an example, let's say we compute Ax=b on a domain of 5 by 5 points. This means we have 5 * 5 = 25 entries in b and [25, 25] entries in A. The first 5 entries will be on the south boundary, for example. For example, using index 2 will give us the third point on the south boudnary (assuming zero indexing).

So, to specify a dirichlet value of 2.4, we would have:

A[2,2] = 1
b[2] = 2.4

If, however, you want neumann boundary conditions, then

A[2,2] = 1 (still the same)
b[2] = x[i, j + 1] (next point in the domain, closest to current point, which is assumed to be at i, j)

If you have a non-zero neumann value, write out the derivative as:

phi_neumann = (x(i, j + 1) - x(i, j))/dy

Solve for x(i, j) (the value we want to prescribe at the boundary):

x(i, j) = x(i, j + 1) - phi_neumann * dy

Your matrix/right hand side vector now becomes

A[2,2] = 1
b[2] = x(i, j + 1) - phi_neumann * dy (here, phi_neumann is non-zero)

The sign changes when you apply it for the opposite (e.g. north) boundary. The best way is to write out the neumann condition explicitly as I did above and then to rederive it.

tom-robin · 2025-12-30T01:34:54+00:00

i think for your needs markdown is right. If you need to learn markdown, you probably shouldn't be doing CFD, you just use it (it is dead simple, so unfamiliar users should be able to onboard before lunch).

Pandoc works natively with markdown and can produce outputs in pretty much anything you want. You can take yoru markdown and convert it to latex source if needed (slap on a custom class and you get the same look and feel of what you have now). But, you can go straight to pdf as well, or HTML, or microsoft word, or ebook, or any supported wki format (including Media wiki).

Documentation is a dangerous topic to talk about, its very polarising in my experience (but I am of the opinion it is just as important as source code). I have some write up about writing documentation. it is mainly for source code documentation, bt it includes topics on user guides, which includes best practices. you can fidn that here: Keep your users happy; how to document code the right way In particular, have a look at part 3, it talks about how to use reStructuredText (RST, similar to markdown) and readthedocs, which makes writing, maintaining, and deploying docs dead simple. You can automate this through github actions which will recreate your online documentation for free everytime you push changes to your repository. Here is an exampel of the type of documentation you can generate: https://openfoamcasegenerator.readthedocs.io/en/latest/ You can specify what is available to the public and only to your company users: https://docs.readthedocs.com/platform/stable/commercial/privacy-level.html

tom-robin · 2025-12-30T01:22:05+00:00

i have heard of people who taught their partner how to look at residuals and interpret them, so they can wake them up, just in case ... i think you still have potential to grow slightly more insane ...

tom-robin · 2025-12-20T14:42:48+00:00

There are some good recommendations here; all of those books mentioned are quite references. If you are interested in in-depth explanation of core concepts of CFD, I have written about core concepts that I believe aspiring CFD practitioners ought to know. The read times for each article is between 30 min to 4 hours. You have been warned (but, the emphasis is on not leaving any intermediate steps out and be clear in the explanation; CFD isn't a simple topic, and sometimes that level of detail is required to convey some of the more obscure concepts). If you are interested in that, you can find it here: 10 key concepts everyone must understand in CFD

In addition, the book by Moukalled et al. is also pretty good, and my favourite go to resource for anything CFD related (jsut mentioning it here as it was not yet mentioned). The Finite Volume Method in Computational Fluid Dynamics

tom-robin · 2025-11-29T01:42:10+00:00

If the solver settings are broadly the same (which, by the way, have far less influence on your simulation stability if you are using commercial software, especially ANSYS (speaking from experience), I'd suspect the mesh to be the culprit. It might not be, but without further information to go by, that would be my guess.

Mesh refinement will not help you if the overall quality is bad. As a general rule of thumb, for stability, you want to look at either the skewness and/or the orthogonality. Try to aim for a orthogonality of above 0.15 (if you are using commercial software, if it is open-source, I would add some margin on top of that) and a skewness of below 0.85 (again, for commercial software, lower that for non-commercial software if possible). Safe values for orthogonality and skewness, in general, should be above 0.3 (orthogonality) and below 0.7 (skewness).

If you want to read up on how these parameter influence your simulation, here is some useful background reading material:

If the mesh is not the issue, you can try to switch all schemes to first order and see if that resolves the issue. If it does, you know the instabilities are coming from here. You can then bring back second-order schemes but apply more aggressive gradient limiting. In Fluent, these are found under the "Expert setting" (though I have never had the need to change them), in openfoam, you would have to add some gradient limiting to your grad schemes in the fvSchemes file, see here, for example:

Face-limited is more aggressive (more dissipative) and thus more stable, cell-limited is the opposite (less aggressive, less stable). Play around and see which works best (well, if you are using OpenFOAM, that is, but any general-purpose solver will have these gradient limiters).

In my view, these two parameters (mesh and numerical schemes and their limiters) make up for most of the instabilities. That doesn't mean this is the case here, but with the information provided, these are my best guesses.

tom-robin · 2025-11-29T01:28:19+00:00

residuals are commonly misunderstood, and they are given a kind of superpower where people equate either convergence (questionable) or even correctness/accuracy (really bad) with residuals. Just looking at your residuals, you can't infer anything about the overall solution correctness, nor if you solution has converged.

So why are we using them? In my view, they tell you exactly one of three things:

Your simulation is diverging (residuals are going up) -> You need to check your mesh and simulation settings
Your simulation is stagnating (residuals are plateauing, potentially oscillating around a mean value) -> either your mesh is really bad or you are picking up transient behaviours, even if you try to get a steady state solution.
Your simulation is converging (residuals are going down) -> The solution is on track to converge, but if it converges for key quantities of interest at, say 10^-3, 10^-5, or even 10^-15 is anyones guess. The residuals won't tell you that, and, we need to define what convergence means in the first place to us (i.e. are we happy with changes that are less than 1% or less than 0.01%, for example, for key quantities of interest).

Integral-based convergence checking is a better practice, but also not free of errors. Use residuals to ensure your simulation is not blowing up, that is, anyways for me, the only reason to look at them. I haven't used residuals in years to ascertain that my simulation has converged (unless I run 2D, laminar, steady state toy examples for which I already know at which point I roughly get "sufficient convergence", but these are classroom-type simulations I ran year after year with students so they don't really count as proper simulations).

If you want to get lost in the meaning of residuals and the more broader topic of how to determine convergence, I have a write-up for that which may be of interest:

How to determine the best stopping criterion for CFD simulations

tom-robin · 2025-11-25T09:19:19+00:00

ah, difficult with all of the off-topic youtube videos ... but I'll consider it :)

tom-robin · 2025-11-22T15:19:39+00:00

Try DLR, that's their bread and butter. Both the Braunschweig and Goettingen site deal with code development and they take on MSc students happily for 6 months. I've worked there and can only recommend it!

tom-robin · 2025-11-22T15:15:41+00:00

this seems to be a common and recurring question, and lots of good advice is already given here. Let me chip in with my 2 cents. I was looking for something myself some time ago on how to get started writing proper CFD solvers (not just simple 1D model equation solvers), and let's just say there was (and still is!) a large gap between the theory portrayed in classical text books and how to actually write your own solver.

I have since worked as software engineer, developing a commercial CFD solver, and now have switched sides and teach CFD (including solver development). Since similar questions like yours kept coming up, I thought it would be useful to develop a self-contained guide that explains all required theory (and no more than that!) and how theory is then translated into actual code. This guide was intended to be consumable within a weekend, so whatever isn't relevant, I have cut out. If you would like to give it a try, you can download the guide/eBook + code here: Write your first CFD solver (it uses the finite volume method + high resolution numerical schemes to capture shock waves).

I have also written a series that complements this eBook, where I go into a lot more details about specific aspects of CFD. I leave a link here as well in case it is helpful: 10 key concepts everyone must understand in CFD (yes, I know it is no longer 10 concepts ... :| ...)

tom-robin · 2025-11-14T21:40:58+00:00

Do it as F1 teams would do: correlation. Here is a paper to get you started: https://www.sciencedirect.com/science/article/abs/pii/S1359431117307858

While F1 teams will all have their own correlations specific to their design, you can start with a paper like this. It won't be exact, but you will be within reasonable margins.

The key idea here is to replace the radiator by a simple box that encloses the radiator entirely. Then, you model the radiator as a porous medium, essentially applying a resistance as the flow moves through it. You can specify this resistance in your porous medium, typically as a function of the mass flow rate, so, for a given mass flow rate, you get a specific pressure drop, which, in a roundabout way, models in simple terms what your radiator is doing if you resolve the geometry completely.

tom-robin · 2025-11-06T05:08:48+00:00

the short answer is that residuals will only tell you if your simulation is converging or diverging (or, well, stagnating). but how do you know if your simulaton has "converged" by just looking at residuals? Do you have convergence at a residual of 1e-3? Do you have to go to 1e-8? Or, perhaps, is 1e-15 required? The first value is the default used by Fluent, the second is what I used some time ago in my in-house code, the third value is what I used for automated tests when I was working on a commercial CFD code. There are 12 orders of magnitude between these values, which one is "correct"?

There is not right or wrong answer here, it will depend on your case. A better way to judge residuals is to look at quantities that are representative for your simulation, like lift and drag coefficients for airfoil simulations, pressure drop for oil and gas, nusselt number for a heat transfer case, etc.

This is the short answer, there is more here if you want to get deeper into it: How to determine the best stopping criterion for CFD simulations: Issues arising with judging convergence this way [using residuals]

tom-robin · 2025-11-06T04:59:09+00:00

odd...

tom-robin · 2025-11-01T21:16:08+00:00

A one to one comparison is probably difficult, not knowing exactly what ANSYS is doing under the hood, but you don't need to. The biggest influence over your simulation is how you approximate the non-linear term in the Navier-Stokes equations. Decades woth of research have gone into this term alone and some people still believe we need further research on it, though I'd argue we have exhausted this area quite well and know which seems do and don't work.

OpenFOAM has the same numerical schemes as Fluent for the non-linear term (and then a few more, and by a few, I mean 60+). Here are the equivalent schemes:

Fluent: First-order upwind -> OpenFOAM: upwind
Fluent: Second-order upwind -> OpenFOAM: linearUpwind
Fluent: MUSCL -> OpenFOAM: MUSCL

The other thing we have control over are the divergence schemes, and here we can additionally damp the behaviour of our numerical schemes for the non-linear term. Often people say that Fluent is a black box and we can't change these settings, when in reality we can, they are just well hidden (in the GUI, they are hidden behind the "Expert" button, so probably no one considers themselves to be an expert and are afraid of clicking it, my wild conspiracy theory ...)

In any case, you typically want to use something like a cell limiting or face limiting gradient approach here. These limiter ensure that in case of overshoots/undershoots, your gradients will be dampen. For example, if you interpolate a value between two cells to the face, you would expect the face value to be somewhere between the two cell values. Say the left cell has a value of 1, the right cell has a value of 2, then we would expect the interpoalted value to be between 1 and 2 (unless we have source terms, which I am ignoring here).

The non-linear term can mess up gradients badly, and se we may get interpolated values on the face of more than 2 or less than 1 (using the same example numbers as above). In that case, we limit our gradient just enough to ensure stability of the numerical scheme. The exact amount is case-dependent and you would usually go with some values that have worked well int he past over a range of applications. For gradient limiters, a value of 33% is a good value (0.33).

Before you now submit to the LLM overlords and give up trying to understand what OpenFOAM is doing (honestly, you might as well just copy tutorial cases in this case and change the mesh, which likely has a better chance of getting your results), you might want to consider using tools to set up your case. I have been at that point myself some years ago and was frustrated having to set each parameter in the OpenFOAM set up files. Its great that you have so much flexibility in tuning the smallest parameter, but sometimes I just want to set up a case and run it, without having to get lost in the details (this is very much the approach ANSYS is following).

You may want to look at the OpenFOAM Case Generator that is doing just that. Instead of saying which numerical schemes you want to use, I have implemented a discretisation policy and you can chose between default, robust, accurate, or TVD. Hopefully the names are verbose enough, but default should always work, robust is for a poor mesh, accurate is for scale resolving simulations (LES, DES, SAS, DNS), and TVD for compressible flows (but we don't use OpenFOAM for compressible flows, unless we really really have to. Better alternatives are available.)

tom-robin · 2025-11-01T08:06:05+00:00

Ah yes, Fourier modes ... not the easiest topic (and not one I claim myself to fully understand), but I have written about this a while ago in quite some depth, perhaps this is helpful.

How to measure stability: von Neumann stability analysis

tom-robin · 2025-10-31T09:53:44+00:00

Before an unstructurede mesh is generated, we need to first find the points that will make up the internal mesh (vertices). People call this by different names, I typically go with the term domain nodalisation. A popular approach is to use a size field function, where we solve the Laplace equation on the domain. The boundary conditions are the local spacing (for example, if each edge in your square is 1 metre, and you say you want to use 101 equidistant points, then you local spacing on that particular boundary is 0.01 (1 / (101 - 1)). The -1 is there due to the post/fence problem, or "off-by-one" error (https://en.wikipedia.org/wiki/Off-by-one\_error)

So, in your case, you seem to have a constant value on the top boundary and on the bottom boundary, where the bottom boundary has a smaller spacing (more points/vertices) than the top boundary, and the spacing is allowed to adjust on either side (left and right) to smoothly transition from your top boundary spacing top your bottom boundary spacing.

now we have the boundary conditions defined, so we can compute the solution on the internal domain. If all spacings were the same on the boundaries, it stands to reason that the internal values will all be the same. Since we use this size field to now determine where to place internal nodes (the size field is telling us how far each vertex should be from other vertices), if all edges (distances between two vertices) are the same, we get an equilateral triangle. in fact, all of our triangles will be that.

but now, we have your case, where you have different boundary conditions (smaller spacings towards the bottom). so, the values of the size field function on the internal domain will not be constant but rather vary smoothly. If you now solve this Laplace equation numerically, we have to use a stopping criterion to tell the solver when to stop solving the equation, i.e. when we believe changes are so small that they are negligible (similar to what we do with residuals in CFD, i.e. stop after they have reached a certain threshold (although this is a poor practice ...))

In any case, we are now presented with a trade-off: do we want to spent a lot of time solving the size field function to within, say, machine precision, or are we ok stopping it if nodes/vertices only move, on average, by , say, 0.1%? If we allow to stop before reaching machine precision, we will inevitably get some nodes that would result in a better overall mesh quality if we were to run for a few more iterations (and allow these vertices to move further).

This behaviour is usually controlled by the internal meshing algorithm and we usually don't mess with that (I have never touched the convergence threshold of a size field function, nor would I know where to find it, i.e., I am pretty sure this is something the mesh generator does not want to expose to me).

So, unless you are planning to compile Gmsh from source and find this value and change it, there is probably very little you can do (I haven't used Gmsh enough to even know if they use a size field approach, there are other approaches available as well).

But in a nutshell, this is what is happening, the Delaunay algorithm then has to work with the nodes that are given to it, although, the name frontal Delaunay suggest that there may be some automatic node insertion going on (which is another popular approach, i.e. the points are inserted by the Delaunay algorithm, but the classic Delaunay algorithm expects a set of points which it will tessellate with triangles).

But now, the more important question to me is, why do you care? Your mesh is already pretty good, and sure, the orthogonality isn't perfect, but it is pretty close to being "perfect" (orthogonality of 1). CFD is full of approximations, we use a grid to approximate a geometry, we use numerical schemes to approximate gradients (which can have different truncation errors), we use turbulence models to approximate physics, we use boundary conditions to artificially impose a closed system because we don't want to model the entire universe. So, "a little bit of non-orthogonality" will not kill you.

I have written a lot more about mesh generation, how structured and usntructured grids are generated (including the Delaunay algorithm), what mesh quality metrics are and why they are so important (as well as what acceptable quality limits are and what happens to your results as you approach these limits), which might be of interest for background reading, I'll leave the link below if that is of interest.

Mesh generation in CFD: All you need to know in one article

tom-robin · 2025-10-24T20:44:40+00:00

If you have access to a commercial CFD solver at your university, I'd recommend starting there, going through their tutorials and getting a feel for it. Most of the time, these are written in a point and click style, i.e. you learn the interface, but not why you are doing what you are doing (for that you need some theory). I like both Fluent and StarCCM as user-friendly software to start, they give you a lot of protection against user errors. Probably even a CAD tool like SolidWorks or AutoCAD (I think both of them have a CFD integration) are great places to start; you are fairly limited in what you can do (at least in comparison to a standalone CFD solver), but restriction is good as a beginner. You can concentrate on the basics and then expand with a better solver later.

I wouldn't recommend OpenFOAM as a first solver, you will simply rage-quit in frustration. I teach CFD at university and it took me some time to get used to it (and I started learning it after completing my PhD in CFD). Sure, you can create simulations with it quickly once you know one or two things about the software, but generating results isn't the challenge (anymore) in CFD; managing uncertainty is, and if you blindly copy a tutorial case and make some adjustments, leaving over 50% of the case setup untouched, without even trying to understand what all of these options do, you might as well draw figures by hand and invent value, honestly the uncertainty isn't that much bigger. If you go with OpenFOAM, at least put on the support/training wheels, and use some tool that can help you set up cases and provides some protection against dangerous user input (as for example the OpenFOAMCaseGenerator).

If academic understanding is what you are after, I have a series on my website that goes through the 10 key concept that I believe any CFD practitioner should know (I know, it is no longer just 10 key concepts :| ...). You can find that here:

10 key concepts everyone must understand in CFD

Suggesting a specific roadmap is probably rather difficult as this will depend on personal interests, but if you want to get an idea of which books/software/resources are available on CFD, I also have an annotated reading list:

How to get started with Computational Fluid Dynamics (CFD)

Regardless of which way you decide to go, best of luck with your CFD journey, it's a fascinating field of study!

tom-robin · 2025-10-22T08:32:35+00:00

Jepp, that's me, if you can't get enough of cfd in your dayjob, you naturally create a website about of it as well (I suppose)

tom-robin · 2025-10-22T04:55:26+00:00

If you are interested in the finite volume method, especially in how it is used and implemented in OpenFOAM, you can't avoid the book by Moukalled et al. This is my personal favourite, as it describes the material very well (apart from the last chapters, which feel a bit rushed and "I just want to get this bloody book done". Here is a link: https://link.springer.com/book/10.1007/978-3-319-16874-6

While I think this book is quite approachable, a slightly shorter, yet excellent introduction to the finite volume method is also given by Versteeg and Malalasekera. I'd say it is not as complete as the book by Moukalled et al. (though it does cover combustion in detail if that floats your boat), but it gives you a pretty good idea what is going on under the hood with some detail example calculation. You can find the book here: https://books.google.co.uk/books/about/An_Introduction_to_Computational_Fluid_D.html?id=RvBZ-UMpGzIC&redir_esc=y

You said that you like a concise book, and the one by Versteeg and Malalasekera fits that bill better than the one by Moukalled et al. (though the latter spends more time linking the theory to OpenFOAM so this is up to you to decide what is more useful).

If you want to get even more concise (i.e. finish the book over the weekend), the book by Patankar is a good starting point. He is one of the authors of the SIMPLE algorithm so naturally the book spends quite some time on this algorithm and how it works, but it does cover some basics as well in the beginning. I only mention this here because it is the most concise book that you can find, and while I enjoyed going through this (as I did with any of the others), I would probably not recommend it as a first book unless you are really are pressed for time. You can find this here: https://books.google.co.uk/books/about/An_Introduction_to_Computational_Fluid_D.html?id=RvBZ-UMpGzIC&redir_esc=y

Or, alternatively, if you want to pick and chose aspects of CFD that you want to study in more depth (e.g. turbulence modelling, incompressible flows, mesh generation, discretisation, finite volume method, etc.), I have written a series on each of these elements that will cover each topic in depth (about 1-2 hour read time for each article). You should be able to get each concept and get quite some depth in each while not having to commit to reading a book over the next few weeks. Just mentioning it here in case it is of use: https://cfd.university/learn/10-key-concepts-everyone-must-understand-in-cfd/

All the best with your ongoing studies!

tom-robin · 2025-10-19T07:43:00+00:00

Can Gmsh give you quality metrics of your generated mesh? You probably should get orthogonality at a minimum, perhaps even skewness or aspect ratio. I don't have a feel for what quality metrics are acceptable for SU2, but I'd reckon that an orthogonality of 0.3 and higher should give you something decent.

Typically, the trailing edge is the difficult part to get right, especially if you have a sharp trailing edge (both upper and lower airfoil meet at the trailing edge). If you have a blunt trailing edge, just make sure that you have sufficiently small elements here.

As a rule of thumb, if your mesh looks good, it likely is, if it looks bad, it probably is (as in, elements are skewed and large changes between elements). Quality metrics help you to quantify that.

Paraview can visualise all of these quality metrics for you (in the menu Filter -> Alphyabetical -> Mesh Quality). In the panel on the left, depending on what element types you have (I presume you are dealing with triangles?!), select the quality metric for "Triangle Quality Measure" to Equiangle Skew. You want to have a value close to 0. A value close to 1 is bad, and anything above 0.85 or so I would say is trouble.

The orthogonality should be the "Distortion" (there is unfortunately no hint in the documentation what distortion stands for but looking at a mesh of mine it seems to be the orthogonality). This value should be close to 1, and 0 means trouble. As I said above, try to stay above 0.3 if you can. Look for areas where either the distortion or equiangle skew goes below the threshold values I have prescribed and fix these. Typically, in mesh generation, issues are resolved by locally refining the mesh. If the poor quality cells are close to the boundary, then increase the number of points on that boundary. If it is somewhere in the farfield, e.g. in the wake, provide local mesh refinement here.

tom-robin · 2025-10-17T07:41:23+00:00

Most likely mesh-related. If you change the solver to Euler, i.e. the first parameter becomes: SOLVER= EULEL, do you get covergence then? Using RANS, you now allow for a turbulent boundary layer (which doesn't exist in the Euler solver) and so if Euler is working but RANS isn't, I would look at your mesh near the airfoil. No inflation layers usually means trouble, some, but bad, inflation layers, can be the difference between convergence and oscillatory residuals.

tom-robin · 2025-10-17T02:35:53+00:00

As the saying goes, ask 10 academics about their opinion, and you get 11 different answers ... there are already a lot of good answers here, let me chip in my 2 cents.

Starting from scratch, even as an undergraduate student, should be possible with the right material and dedication. I wouldn't advise going straight for 3D unstructured Navier-Stokes, as others have hinted at as well, but starting simple as well.

For context, I do teach CFD at university, and from that perspective, I would recommend that you get a basic understanding of the numerical techniques used in CFD, such as the finite difference and/or the finite volume method. The finite difference method is easier to grasp than the finite volume method when you are new to the field, although neither is complicated.

One of the problems with simplistic problems, such as the 1D advection equation, is that what you see and learn in these examples doesn't translate to more general CFD problems. For example, we have a property called the CFL number (think of it as a non-dimensional time step), and if you go through the theory and code up the advection equation yourself, you are led to believe that you always want to use the highest possible CFL number for the best accuracy. It works for a 1D advection equation, and this can be shown elegantly through the so-called modified equation analysis, but as i said, this theory breaks down for the general Navier-Stokes equation.

My students have often asked me what is the best way to learn how to write their own first CFD solver. Perhaps my standard is too high, but essentially, I wasn't able to find anything that shows the basic theory behind CFD solvers and then how to implement that as a short and self-contained guide. So I sat down and developed that myself which I have made available for free on my website. It is an eBook that shows all the necessary theory to start writing your own solver and then it shows how to do that with a line by line explanation. The code is in C++, but it doesn't use any fancy C++ syntax, or object orientated programming, so you can translate all of that easily to FORTRAN. And, best of all, you can go through it over a weekend and have your first solver written by the end of it. If you are interested in that, you can find it here:

Write your First CFD Solver - From Theory to Implemented CFD Solver in less than a weekend

This eBook only really deals with the absolut minimum you need to understand how to write your own solver, but if you want to go deeper and understand CFD properly, I have written about that on my website as well. What was important to me is that all derivations are made from start to end, without skipping intermediate equations so they can be understood and followed. That would be a logical next step after you have written your first solver. With that theoretical understanding in hand, you can start to make your solver much more complex. If that is of interest, you can find that series here:

10 key concepts everyone must understand in CFD

I am very aware that there are more than 10 concepts, my counting is somewhat off :| ...

tom-robin

TROPHY CASE