[MsKK]

I am using the SIMPLE algorithm with a central difference scheme, using ghost cells and the Gauss-Seidel method on a staggered grid. It has taken me a while (longer than I expected) because I had to learn all these concepts (I didn't model fluids before) and started from scratch.

I wonder how long it took you all (who did this benchmark) to implement it and run it correctly?

Additionally, in what language did you implement it? I am currently working with C++.

Also, if you have suggestions I will be glad to accept them.

[mprinkey]

http://lorenabarba.com/blog/cfd-pyth...navier-stokes/

I don't know how many times I've posted that link here already, but it bears repeating.

While there is merit to learning things "the hard way," it need not be that way anymore. I sincerely wish I had resources like back in the 90s when I was learning CFD. That python step-by-step just covers all of the hard CFD concepts (for Finite Difference anyway) while not bogging you down with syntax or language complications. Python is (nearly) the perfect learning language, IMO. And once you get the hang of it, recoding in C/C++/Fortran requires minor effort.

[FMDenaro]

The lid-driven cavity was my first NS exercise when I was a student of CFD. At that time (1989) we worked on the 8088 CPU (and math co-processor 8087 ) using Fortran. I remember that I first developed my SOR routine to use in the stream-function vorticity formulation. Just in a couple of day I had the code running on a 15x15 grid at Re=O(10).
Now, I still suggest to my student to do the same exercise

[lcarasik]

It took me about a month or so to get a working lid-driven cavity code using the SIMPLE method in Matlab. I had a lot of issues with programming since it was my first real programming project.

[arjun]

I took embarrassingly long time but I did not write lid driven cavity, I wrote unstructured grid based navier stokes solver as my first trial.

Since I never did any CFD course and I had only done computer science basic college course (CS101, Pascal) I had to learn every thing myself from scratch.

It took me almost 8 months to get that code working and that was not really stable with anything complicated geometry wise. It worked with structured meshes but tetra were tough for it.

The only time I wrote lid driven cavity was when i wrote lattice boltzmann solver to learn and it took me 1 day to code and have it working. (actually may be 3 to 4 hours).


PS: The only course that could be considered closed to CFD that i did was fluid dynamics course and I remember I scored lowest marks in my class. :-)

[mprinkey]

Originally Posted by arjun

I took embarrassingly long time but I did not write lid driven cavity, I wrote unstructured grid based navier stokes solver as my first trial.

You jumped right into the deep end! But at least you didn't have to unlearn all of those "Cartesian" prejudices when you moved to an unstructured solver. 8)

[sbaffini]

Originally Posted by mprinkey

But at least you didn't have to unlearn all of those "Cartesian" prejudices when you moved to an unstructured solver. 8)

So true that I can't find the words to properly agree...

... btw, concerning the op question, it really depends from a lot of factors. The cavity is notable for the trivial bcs. Still, SIMPLE is not as straighforward as other algorithms (e.g., fractional step or vorticity-streamfunction). Moreover, it also counts if you are using precoded linear algebra routines or writing them at the moment. Finally, it is also a matter of acquaintance with programming and the used programming language.

If this is your first time, focus on learning, not on time (unless, of course, you're going unreasonably long on this).

[FMDenaro]

Well, actually when I wrote my first unstructured Navier-Stokes code I exploited many of my knowledge acquired before for structured codes...

[mprinkey]

Originally Posted by FMDenaro

Well, actually when I wrote my first unstructured Navier-Stokes code I exploited many of my knowledge acquired before for structured codes...

Yeah, but you are brilliant. And I'm just fumbling around in the dark. 8)

Seriously, I think it is a question of degree. I spent TOO MUCH time working on Cartesian and block-type solvers. Implementing QUICK and doing compact differences and high-order filtering and so many other things that implicitly rely on East of East and North of North neighbors, straight (or analytically curved) coordinate axes, etc. Had I done that for a semester or two and then moved on to unstructured, it would not have been too bad. But I spent all of grad school working on Cartesian-style solvers. Moving on to development work on FLUENT 5 was like stumbling into a new country with a completely new language.

[FMDenaro]

Originally Posted by mprinkey

Yeah, but you are brilliant. And I'm just fumbling around in the dark. 8)

Seriously, I think it is a question of degree. I spent TOO MUCH time working on Cartesian and block-type solvers. Implementing QUICK and doing compact differences and high-order filtering and so many other things that implicitly rely on East of East and North of North neighbors, straight (or analytically curved) coordinate axes, etc. Had I done that for a semester or two and then moved on to unstructured, it would not have been too bad. But I spent all of grad school working on Cartesian-style solvers. Moving on to development work on FLUENT 5 was like stumbling into a new country with a completely new language.

I think that the key is in learning either FD or FV-based approach. If you stay for years in the framework of FD, mapping of the domain and so on, I agree with you. But if you are lucky that the teacher introduces to the use of the general concept of FV, introducing the theory for the flux reconstruction and volume-based filtering, this would be so general that structured or unstructured approaches can be just slightly different. The same QUICK structure has several issues you will use. Of course, some step is required to work on complex 3D codes on unstructured grids.

[arjun]

Originally Posted by mprinkey

You jumped right into the deep end! But at least you didn't have to unlearn all of those "Cartesian" prejudices when you moved to an unstructured solver. 8)

I came back to Cartesian solver with immersed boundary for LES DNS in year 2008 or so. (produced some 4 to 5 patents for the company so they were happy).
I learned FFT and block cyclic reduction with it. Had lots of email exchange with Paul (https://www.researchgate.net/publica...n%27s_Equation ) (RIP).

I had very interesting journey when it comes to flow solver. This is how it went.

Unstructured grid solver -> Cartesian LES/DNS code -> Lattice Boltzmann -> Finite Volume Lattice Botzmann -> Moving particle meshless method -> Unstructured grid pressure based coupled solver


Now finally having done all this , I wrote 1D euler code for automotive (still building on the library so in few months will become part of Wildkatze project.

Now writing unstructured density based coupled solver (currently working along with higher order methods).

Its amusing that all these converged to 1D code in the end :-D

PS: Edited to add somewhere in between were LES DNS code in cylindrical cordinate and also locally refined oct tree based cartesian solvers.